These options are for backing up database servers that play specific roles in replication, or contain certain kinds of data that require special care in backing up.
When backing up a replication slave server, this option captures information needed to set up an identical slave server. It creates a file
meta/ibbackup_slave_infoinside the backup directory, containing a
CHANGE MASTERstatement with the binary log position and name of the binary log file of the master server. This information is also printed in the mysqlbackup output. To set up a new slave for this master, restore the backup data on another server, start a slave server on the backup data, and issue a
CHANGE MASTERcommand with the binary log position saved in the
ibbackup_slave_infofile. See Section 7.1, “Setting Up a New Replication Slave” for instructions.Note
Only use this option when backing up a slave server. Its behavior is undefined when used on a master or non-replication server.
This option is not compatible with the
--no-lockingoption; using both options together will make mysqlbackup throw an error.
For a statement-based replication (SBR) or a mixed-based replication setup, the option specifies the time (in seconds) mysqlbackup will wait for
Slave_open_temp_tablesto become “0” (which is true when no temporary tables are open) to complete the backup for a slave server by asserting a global read lock and copies all the non-InnoDB tables. If the duration of the wait exceeds that specified with the option, mysqlbackup times out and throws an error. The wait is for preventing mysqlbackup from finishing a slave backup when there are temporary tables still open. See descriptions in Temporary tables on statement-based replication (SBR) slave for details on how mysqlbackup deals with temporary tables on a slave server.
In addition, mysqlbackup also runs an initial check at the beginning of a slave backup to see if
Slave_open_temp_tables=0becomes true within the duration set by
--safe-slave-backup-timeout. If it does not, mysqlbackup takes it as an early sign that before the backup is completed, some temporary tables are likely to remain open after the timeout limit is exceeded; mysqlbackup then throws an error, instead of continuing with the backup. When that happens, you can either restart the backup with a higher value for
--safe-slave-backup-timeout, or retry at a time when fewer temporary tables are being used.
Do not set the value for this option too high. The wait time starts after all the InnoDB tables have been copied and ends when the global read lock is asserted on the database. If you need to wait for a long time for there to be no more temporary tables, the chance is that the change rate for your database is quite high, which means a lot of tables will need to be copied again during the lock period, resulting in a long lock time. In such a case, it would have been more efficient to have let mysqlbackup timeout and then restart the backup operation, so the modified tables are copied without a lock. It is therefore not helpful to set a high timeout value for the option.
For a row-based replication (RBR) setup, temporary tables are not replicated onto the slave. Users who are certain that SBR is not occurring for the slave can set
--safe-slave-backup-timeout=0, with which mysqlbackup will not check for any open temporary tables before finishing the backup.
This option pauses the mysqlbackup command when the backup procedure is close to ending. It creates a file called
ibbackup_suspendedin the backup log group home directory and waits until you delete that file before proceeding. This option is useful to customize locking behavior and backup of non-InnoDB files through custom scripting.
All tables are locked before suspending, putting the database into a read-only state, unless you turn off locking with the
--only-innodb-with-frmoptions also prevent the locking step. Because locking all tables could be problematic on a busy server, you might use a combination of
--suspend-at-endto back up only certain InnoDB tables.
Property Value Command-Line Format
--exec-when-locked="utility arg1 arg2 ..."
You can use this option to run a script that backs up any information that is not included as part of the usual backup. For example, with
--exec-when-locked, you can use mysqldump to back up tables from the MEMORY storage engine, which are not on disk.
Set any variable you want to use within your script before you run mysqlbackup. In the following example, the
BACKUP_DIRenvironment variable is set to point to the current backup directory (quotes are used for the argument of
--exec-when-locked, to prevent premature expansion of the variable
On Unix or Linux systems:
export BACKUP_DIR=path_to_backupdir mysqlbackup --exec-when-locked="mysqldump mydb t1 > $BACKUP_DIR/t1.sql" other_options mysqlbackup_command
Or on Windows systems:
set BACKUP_DIR=path_to_backupdir mysqlbackup --exec-when-locked="mysqldump mydb t1 > %BACKUP_DIR%/t1.sql" other_options mysqlbackup_command
If the utility cannot be executed or returns a non-zero exit status, the whole backup process is cancelled. If you also use the
--suspend-at-endoption, the utility specified by
--exec-when-lockedis executed after the suspension is lifted.