无论逻辑备份还是物理备份,为了获取一致性位点,都强依赖于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/blog/2014/03/11/introducing-backup-locks-percona-server-2/