MYSQL 8 备份数据库 "新锁" 旧"锁"

MYSQL 在备份中会使用 FTWRL,  来获得备份的数据一致点和对应的BINLOG 的位置.众所周知 FLUSH TABLE WITH READ LOCK 会关闭所有打开的表,强制所有的表.

FTWRL 对于备份的意义在于,在我们操作这个命令的时候,会获取每个表的metadata lock , 此时获取表的lock 是逐步的过程,必须等待每个表的事务完成后,才能获得表元数据锁,并将锁的模式锁定到共享锁.此时所有对数据库的表的操作都变成 READ的模式, 其他的操作都不可以.

此时备份的程序软件,都可以读取系统的BINLOG 的GTID 或  BINLOG+POS的位置,在获得这些信息后,备份程序就通过 unlock tables 来释放锁,让系统正常工作.

实际上 FTWRL 做了以下几个工作 1  对所有的表上了全局的读锁, 2 清理了表缓存  3  上全局commit锁. 在清理表缓存的过程中,对于每个表都有一个table_cache, 不同表的cache对象通过hash链表维护,访问cache 对象通过lock_open互斥量保护, 每个会话打开表都会进行计数, 在会话关闭表的情况下会进行减数, 当判断表的打开数字是0 的情况下,就可以将缓存的数据刷入到磁盘. 那么阻塞读的事情就是从这里来的, 表面上 FTWRL 原理上是不会阻塞读的轻量级锁,但是在上面为了将内存的数据刷入到磁盘,就必然在同一个时刻所有表都进行落盘. 所以 FTWRL 在短时间是必然会影响读操作.

总结FTWRL ,几个步骤, 请求锁, 等待锁, 刷新表,持有锁.而我们今天要说的mysql 8.0 的LOCK INSTANCE FOR BACKUP 新特色, 其实在 PERCONA 5.6 版本的MYSQL 就已经有了. 所以今天的题目有两个含义

1  FTWRL 与 LOCK INSTANCE FOR BACKUP 是新锁和旧锁的关系

2  LOCK INSTANCE FOR BAKCUP 其实早就在多年就已经有了,现在可以看做是新的"旧锁"

官方文档中对LOCK INSTANCE FOR BACKUP 获得一个instance level 的backup lock 锁, 可以在锁持有时进行DML 操作. 并且可以保证期间操作的一致性,并且为这个产生了一个权限 BACKUP ADMIN.

LOCK INSTANCE FOR BACKUP 在执行时会阻止文件被创建,改名,移除,或者是REPAIR , TRUNCATE TABLE, ,OPTIMIZE TABLE, (这里注意到这些操作都无法在BINLOG中出现对应的物理的日志,都是逻辑的语句)

实际上从MYSQL 8.03 提供了这个lock instance for backup 锁, 通过这个锁进行数据备份的时候,不会在purge binary log 和 relay log 文件,通过产生新的文件来去达到统一的时间点的日志位置统一.

我们在来捋一捋, 锁的力度小了,没有对表在全部的FTWRL了,那统一的时间点在哪里了?  一股脑的将数据文件都拷贝走? 

这个问题在 MYSQL 8.011 中的 log_status提出了解决的方案.

当查询log_status 表的时候, 服务器会在短时间组织日志写入,并填充相关的表信息.log_status 表主要的功能通知在线的备份应该拷贝那些BINLOG 日志以及每个复制channel的变化,并提供 LSN 号以及最后的 checkpoint 点等信息.

所以MYSQL 8 新备份的方式的改变是通过LOCK INSTANCE for BACKUP 和  log_status  联合完成的, 基于MYSQL 8 的第三方备份软件等都需要对此进行研究并改变目前的备份的方式.