Hot answers tagged

2

The million dollar question is - is it worth adding an extra server to the windows failover cluster in your current scenario ? IMHO, NO - since you are on sql server 2012. Why ? SQL server 2012 and 2014 will allow read-only routing directed traffic to the FIRST available replica defined in the routing list - provided the first read-only replica is ...


2

In a MS SQL Server 2014 AlwaysOn AG setup, I would like to schedule backup jobs for a given availability group. The ultimate goal is to have the regular backups run on the synchronized secondary and, most importantly, not bound to the availability of a particular secondary node. This can be accomplished without issue. Just keep in mind that your ...


2

The best way is not to shrink it at all. You are not losing any data when you shrink the log or when switching recovery models. You are losing recovery points though. But there's a reason the file was sized that way. Backup your transaction logs frequently, such as every minute, to minimize its size. If the size is still bigger than what you'd think, ...


2

Besides being unaware that your backup is being performed as a COPY_ONLY backup instead of not being backed up at all, are there any caveats that anyone can think of if this switch is set to default Y or even if it's used at all? A COPY_ONLY full backup is still a full backup. The only difference between the two is the COPY_ONLY will not reset certain ...


2

Since I happened to be researching this myself, here's a summary of what I found. According to a 2015 blog post from the MySQL dev team, the main advantages of mysqlpump are that it can use multiple threads in parallel to speed up the dumping and that it doesn't share mysqldump's backwards compatibility requirements, which should open the door for further ...


1

After you change the recovery model to SIMPLE, perform a full backup, that should truncate your tlog. From MSDN: After Switching to the Simple Recovery Model If you switch from the full or bulk-logged recovery model to the simple recovery model, you break the backup log chain. Therefore, we strongly recommend that you back up the log immediately before ...


1

You need to check the actual size of the database files which you can check by running RESTORE FILELIST ONLY FROM <backup_device> This will give you information about the files contained in the backup and their sizes in bytes You need the same space available on the server as the database file size, the backups can be compressed. Now you need ...


1

No, you don't need to prep every backup. You only need to create the full backup on Sunday and then create the incrementals from Monday to Saturday. Full: innobackupex --user=USER --password=PASSWORD /path/to/backup/dir/ Incr: innobackupex --incremental /path/to/inc/mon --incremental-basedir=$FULLBACKUP --user=USER --password=PASSWORD innobackupex --...


1

pg_dumpall --clean will not issue DROP DATABASE statements for databases like template1 or postgres that have been created by initdb at cluster initialization time. However it will dump the contents of these databases if you created any objects in it (by default they're empty). So when restoring the result of pg_dumpall --clean into the same instance, it's ...


1

You have not decompressed the Xtrabackup files if they still have the .qp extension. Try using this inside the current folder: sudo innobackeupex --decompress --parallel=4 where 4 stands for the number of threads you would like to use. Also, for clean-up afterwards: sudo find ${DEST_DIR}/ -name "*.qp" -delete


1

Ola Hallengren automated backup solution will solve your problem for newly added databases. Check for the MirrorDirectory option: MirrorDirectory Specify one or multiple directories to perform a mirrored backup. The MirrorDirectory option in DatabaseBackup uses the MIRROR TO option in the SQL Server BACKUP command.


1

From here, the complete command for a hot backup of a MySQL database using only InnoDB tables is: mysqldump -u user -ppass --single-transaction --routines --triggers --all-databases > backup_db.sql Note the gap between -u and user and the lack of a gap between -p and pass. This is correct - a quirk of MySQL which has caught me on more than one occasion....



Only top voted, non community-wiki answers of a minimum length are eligible