MySQL Backup - Xtrabackup backup set lock wait problem

Problem Description

innobackupex backup process needs to ensure backup data consistency, get back up the table to refresh the cache sites by Canadian global read lock (FLUSH TABLES WITH READ LOCK), and to prevent the lock wait timeout, you will first set up:

SET SESSION lock_wait_timeout=31536000

In MySQL, leading to FLUSH TABLES WITH READ LOCK operation to acquire the lock timeout scenario are:

1, long or large transaction DML operation 
2, Table DDL operation oversized

If you want to solve the problem of lock timeouts, you can query both start from the lock and KILL long, innobackupex command has the following parameters:

Use this option to disable table lock with "FLUSH TABLES
WITH READ LOCK". Use it only if ALL your tables are
InnoDB and you DO NOT CARE about the binary log position
of the backup. This option shouldn't be used if there are
any DDL statements being executed or if any updates are
happening on non-InnoDB tables (this includes the system
MyISAM tables in the mysql database), otherwise it could
lead to an inconsistent backup. If you are considering to
use --no-lock because your backups are failing to acquire
the lock, this could be because of incoming replication
events preventing the lock from succeeding. Please try
using --safe-slave-backup to momentarily stop the
replication slave thread, this may help the backup to
succeed and you then don't need to resort to using this

This option controls if backup locks should be used
instead of FLUSH TABLES WITH READ LOCK on the backup
stage. The option has no effect when backup locks are not
supported by the server. This option is enabled by
default, disable with --no-backup-locks.

This option specifies which types of queries should be
killed to unblock the global lock. Default is "all".

This option specifies the number of seconds innobackupex
waits between starting FLUSH TABLES WITH READ LOCK and
killing those queries that block it. Default is 0
seconds, which means innobackupex will not attempt to
kill any queries.


If the execution from a database backup, you can consider suspending the replication process to prevent obstruction:

Stop slave SQL thread and wait to start backup until
Slave_open_temp_tables in "SHOW STATUS" is zero. If there
are no open temporary tables, the backup will take place,
otherwise the SQL thread will be started and stopped
until there are no open temporary tables. The backup will
fail if Slave_open_temp_tables does not become zero after
--safe-slave-backup-timeout seconds. The slave SQL thread
will be restarted when the backup finishes.

How many seconds --safe-slave-backup should wait for
Slave_open_temp_tables to become zero. (default 300)


Guess you like