Currently I'm studying Percona's xtrabackup. In the manual in the paragraph "Taking Backups in Replication Environments" it says that using the --safe-slave-backup
option is always recommended and I understand the reasons behind it.
I'm just wondering now, if there is actually a difference in the result when I do not use this option. After applying the logs on a backup, I don't see why there should be a difference between a backup taken with or without this option.
I'm asking, because in our production environment we do not use this option. The backup runs at midnight, but it failed this night. The backup is taken on a slave and I'd have a bad feeling about stopping the SQL thread now to take the backup.
Best Answer
As the manual says:
The reason for this is because Percona Xtrabackup basically mimics a controlled crash/shutdown of the server, and temporary tables can make the slave inconsistent, as you can see on the MySQL manual. This is not a problem of consistency per se (buckups will be consistent with the given timestamp/binlog), but it may make a slave lose some transactions when resynchronized with a master (typical usage- cloning a slave for creating another).
This does not happen if you use ROW-based replication, so I would recommend you using that. But some people cannot or do not want to use it, so this is the way to be 100% sure that new slaves work well. On a typical replication scenario, using
--safe-slave-backup
may not be very problematic, assuming there are not many temporary tables being created, but that is the workaround (and typically these options are added because someone had a problem in the past).What I would recommend you is to use always
--slave-info
unless you are using GTID replication.As the own manual says, using
pt-table-checksum
to test the backups is a good piece of advise.