MySQL备份锁

     不管逻辑备份仍是物理备份，为了获取一致性位点，都强依赖于FTWRL(Flush Table With Read Lock)。这个锁杀伤力很是大，由于持有锁的这段时间，整个数据库实质上不能对外提供写服务的。此外，因为FTWRL须要关闭表，若有大查询，会致使FTWRL等待，进而致使DML堵塞的时间变长。即便是备库，也有SQL线程在复制来源于主库的更新，上全局锁时，会致使主备库延迟。FTWRL这把锁持有的时间主要与非innodb表的数据量有关，若是非innodb表数据量很大，备份很慢，那么持有锁的时间就会很长。即便所有是innodb表，也会由于有mysql库系统表存在，致使会锁必定的时间。为了解决这个问题，Percona公司对Mysql的Server层作了改进，引入了BACKUP LOCK，具体而言，经过"LOCK TABLES FOR BACKUP"命令来获取一致性数据(包括非innodb表)；经过"LOCK BINLOG FOR BACKUP"来获取一致性位点，尽可能减小由于数据库备份带来的服务受损，咱们将这一特性引入到AliSQL，下面详细介绍这个特性。

功能介绍

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

1.LOCK TABLES FOR BACKUP，执行语句申请backup-lock的共享锁，经过unlock tables释放锁。

2.LOCK BINLOG FOR BACKUP，执行语句申请binlog-lock的共享锁，经过unlock binlog释放锁。

3.UNLOCK BINLOG，释放LOCK BINLOG FOR BACKUP持有的锁。

对于backup-lock：

已经持有lock table for backup后，若是在本会话执行更新操做(非innodb表)，会报错；若是在其它会话执行更新操做，会等待。show processlit 能够看到会话处于"Waiting for backup lock"状态。

对于binlog-lock：

已经持有lock binlog for backup后，若是本会话执行更新操做，不会报错，由于不会堵塞会话；若是其它会话执行，则会等待。show processlist 能够看到会话处于"Waiting for binlog lock"状态。

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

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和backup lock进来

(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和backup lock进来

(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

引入备份锁的优点

LOCK TABLES FOR BACKUP
做用：获取一致性数据
1.禁止非innodb表更新
2.禁止全部表的ddl
优化点：
1.不会被大查询堵塞(没有flush tables 致使关闭表操做)
2.不会堵塞innodb表的读取和更新，这点很是重要，对于业务表所有是并innodb的状况，则备份过程当中DML彻底不受损

LOCK BINLOG FOR BACKUP

做用：获取一致性位点。
1.禁止对位点更新的操做
优化点：
1.容许DDl和更新，直到写binlog为止。
UNLOCK BINLOG

物理备份流程变化

修改前：

1. get redo-lsn

2. copy InnoDB data

3. FLUSH TABLES WITH READ LOCK;

4. copy .frm, MyISAM, etc.

5. get the binary log coordinates

6. finalize the background copy of REDO log

7. UNLOCK TABLES;

修改后：

1. get redo-lsn

2. copy InnoDB data

3. LOCK TABLES FOR BACKUP;

4. copy .frm, MyISAM, etc

5. LOCK BINLOG FOR BACKUP;

6. finalize the background copy of REDO log

7. UNLOCK TABLES;

8. get the binary log coordinates

9. UNLOCK BINLOG;

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

功能限制

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

参考文档

https://www.percona.com/doc/percona-server/5.6/management/backup_locks.html#interaction-with-other-global-locks

https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/