MySQL备份锁

　

　无论逻辑备份还是物理备份，为了获取一致性位点，都强依赖于FTWRL(FlushTableWithReadLock)。这个锁杀伤力非常大，因为持有锁的这段时间，整个数据库实质上不能对外提供写服务的。此外，由于FTWRL需要关闭表，如有大查询，会导致FTWRL等待，进而导致DML堵塞的时间变长。即使是备库，也有SQL线程在复制来源于主库的更新，上全局锁时，会导致主备库延迟。FTWRL这把锁持有的时间主要与非innodb表的数据量有关，如果非innodb表数据量很大，备份很慢，那么持有锁的时间就会很长。即使全部是innodb表，也会因为有mysql库系统表存在，导致会锁一定的时间。为了解决这个问题，Percona公司对Mysql的Server层做了改进，引入了BACKUPLOCK，具体而言，通过"LOCKTABLESFORBACKUP"命令来获取一致性数据(包括非innodb表)；通过"LOCKBINLOGFORBACKUP"来获取一致性位点，尽量减少因为数据库备份带来的服务受损，我们将这一特性引入到AliSQL，下面详细介绍这个特性。

　　功能介绍

　　在MysqlServer层新增2种类型MDL全局范围锁，backup-lock和binlog-lock，并新增了3种语法：

　　1.LOCKTABLESFORBACKUP，执行语句申请backup-lock的共享锁，通过unlocktables释放锁。

　　2.LOCKBINLOGFORBACKUP，执行语句申请binlog-lock的共享锁，通过unlockbinlog释放锁。

　　3.UNLOCKBINLOG，释放LOCKBINLOGFORBACKUP持有的锁。

　　对于backup-lock：

　　已经持有locktableforbackup后，如果在本会话执行更新操作(非innodb表)，会报错；如果在其它会话执行更新操作，会等待。showprocesslit可以看到会话处于"Waitingforbackuplock"状态。

　　对于binlog-lock：

　　已经持有lockbinlogforbackup后，如果本会话执行更新操作，不会报错，因为不会堵塞会话；如果其它会话执行，则会等待。showprocesslist可以看到会话处于"Waitingforbinloglock"状态。

　　下面介绍具体的原理和相关接口的实现

　　A:备份操作

　　申请backup-lock，持有(backup,MDL_SHARED,MDL_EXPLICIT)锁

　　B:库的DDL操作

　　调用lock_schema_name加库对象锁(修改库操作，schema_lock)

　　接口(mysql_create_db,mysql_alter_db,mysql_rm_db,mysql_upgrade_db等)

　　1.如果已经持有全局锁(backup,global)，则报错。

　　2.加库的排它锁(SCHEMA,MDL_EXCLUSIVE,MDL_TRANSACTION)

　　3.申请IX范围锁，避免后续的global和backuplock进来

　　(global,MDL_INTENTION_EXCLUSIVE,MDL_STATEMENT)

　　(backup,MDL_INTENTION_EXCLUSIVE,MDL_STATEMENT)

　　C:表的DDL操作

　　调用lock_table_names加表对象锁(修改表操作)

　　接口(mysql_rename_tables,mysql_rm_table,mysql_drop_view,truncate_table等)

　　1.加表对象锁(TABLE,MDL_EXCLUSIVE,MDL_TRANSACTION)

　　2.加上对应schema的对象锁(SCHEMA,MDL_INTENTION_EXCLUSIVE,MDL_TRANSACTION),避免库的ddl操作。

　　3.如果已经持有全局锁(backup,global)，则报错。

　　4.申请IX范围锁，避免后续的global和backuplock进来

　　(global,MDL_INTENTION_EXCLUSIVE,MDL_STATEMENT)

　　(backup,MDL_INTENTION_EXCLUSIVE,MDL_STATEMENT)

　　D:表的DML操作

　　调用acquire_protection来申请IX范围锁

　　接口open_table

　　这里只针对非innodb引擎，且是写操作的表

　　mdl_request.type>=MDL_SHARED_WRITE&&share->db_type()->flags&HTON_SUPPORTS_ONLINE_BACKUPS

　　引入备份锁的优势

　　LOCKTABLESFORBACKUP

　　作用：获取一致性数据

　　1.禁止非innodb表更新

　　2.禁止所有表的ddl

　　优化点：

　　1.不会被大查询堵塞(没有flushtables导致关闭表操作)

　　2.不会堵塞innodb表的读取和更新，这点非常重要，对于业务表全部是并innodb的情况，则备份过程中DML完全不受损

　　LOCKBINLOGFORBACKUP

　　作用：获取一致性位点。

　　1.禁止对位点更新的操作

　　优化点：

　　1.允许DDl和更新，直到写binlog为止。

　　UNLOCKBINLOG

　　物理备份流程变化

　　修改前：

　　1.getredo-lsn

　　2.copyInnoDBdata

　　3.FLUSHTABLESWITHREADLOCK;

　　4.copy.frm,MyISAM,etc.

　　5.getthebinarylogcoordinates

　　6.finalizethebackgroundcopyofREDOlog

　　7.UNLOCKTABLES;

　　修改后：

　　1.getredo-lsn

　　2.copyInnoDBdata

　　3.LOCKTABLESFORBACKUP;

　　4.copy.frm,MyISAM,etc

　　5.LOCKBINLOGFORBACKUP;

　　6.finalizethebackgroundcopyofREDOlog

　　7.UNLOCKTABLES;

　　8.getthebinarylogcoordinates

　　9.UNLOCKBINLOG;

　　对应的Xtrabackup工具在执行命令流程需要相应的改动。

　　功能限制

　　1.对于Myisam表，当delay_key_write=ALL时，索引并没有及时刷盘，导致xtrabackup无法获取一致的备份，因此在这种情况下，加backup-lock失败。