English
中文 FLUSH TABLES WITH READ LOCK简称(FTWRL)，该命令主要用于备份工具获取一致性备份(数据与binlog位点匹配)。由于FTWRL总共需要持有两把全局的MDL锁，并且还需要关闭所有表对象，因此这个命令的杀伤性很大，执行命令时容易导致库hang住。如果是主库，则业务无法正常访问；如果是备库，则会导致SQL线程卡住，主备延迟。本文将详细介绍FTWRL到底做了什么操作，每个操作的对库的影响，以及操作背后的原因。
FTWRL做了什么操作？
FTWRL主要包括3个步骤：
1.上全局读锁(lock_global_read_lock)
2.清理表缓存(close_cached_tables)
3.上全局COMMIT锁(make_global_read_lock_block_commit)
FTWRL每个操作的影响
上全局读锁会导致所有更新操作都会被堵塞；关闭表过程中，如果有大查询导致关闭表等待，那么所有访问这个表的查询和更新都需要等待；上全局COMMIT锁时，会堵塞活跃事务提交。由于FTWRL主要被备份工具使用，后面会详细解释每个步骤的作用，以及存在的必要性。FTWRL中的第1和第3步都是通过MDL锁实现，关于MDL的实现，我之前总结了MDL锁的文章，这里主要介绍清理表缓存的流程。
清理表缓存
每个表在内存中都有一个table_cache，不同表的cache对象通过hash链表维护。
访问cache对象通过LOCK_open互斥量保护，每个会话打开的表时，引用计数share->ref_count++，
关闭表时，都会去对引用计数share->ref_count--。
若发现是share对象的最后一个引用(share->ref_count==0)，并且share有old_version,
则将table_def_cache从hash链表中摘除，调用free_table_share进行处理。关键函数close table流程如下：
1.关闭所有未使用的表对象
2.更新全局字典的版本号
3.对于在使用的表对象，逐一检查，若表还在使用中，调用MDL_wait::timed_wait进行等待
4.将等待对象关联到table_cache对象中
5.继续遍历使用的表对象
6.直到所有表都不再使用，则关闭成功。
清理表缓存函数调用
mysql_execute_command->reload_acl_and_cache->close_cached_tables
->TABLE_SHARE::wait_for_old_version->MDL_wait::timed_wait->
inline_mysql_cond_timedwait
会话操作表流程
1.打开表操作，若发现还有old_version,则进行等待
2.share->ref_count++
3.操作完毕，检查share->ref_count--是否为0
4.若为0,并且检查发现有新版本号，则认为cache对象需要重载
5.将cache对象摘除，调用MDL_wait::set_status唤醒所有等待的线程。
关闭表对象函数调用
dispatch_command->mysql_parse->mysql_execute_command->
close_thread_tables->close_open_tables->close_thread_table->
intern_close_table->closefrm->release_table_share->my_hash_delete->
table_def_free_entry->free_table_share
关闭表导致业务库堵住的典型场景
假设有3个会话，会话A执行大查询，访问t表；然后一个备份会话B正处于关闭表阶段，需要关闭表t；随后会话C也请求访问t表。三个会话按照这个顺序执行，我们会发现备份会话B和会话C访问t表的线程都处于“waiting for table flush”状态。这就是关闭表引起的，这个问题很严重，因为此时普通的select查询也被堵住了。下面简单解释下原因：
1.会话A打开表t，执行中……
2.备份会话B需要清理表t的cache，更新版本号(refresh_version++)
3.会话B发现表t存在旧版本(version != refresh_version)，表示还有会话正在访问表t，
等待,加入share对象的等待队列
4.后续会话C同样发现存在旧版本(version != refresh_version)，
等待，加入share对象的等待队列
......
5. 大查询执行完毕，调用free_table_share,唤醒所有等待线程。
free_table_share //逐一唤醒所有等待的线程。
{
while ((ticket= it++))
ticket->get_ctx()->m_wait.set_status(MDL_wait::GRANTED);
}
第4步与第5步之间，所有的访问该表的会话都处于“waiting for table flush”状态，唯有大查询结束后，等待状态才能解除。
主备切换场景
在生产环境中，为了容灾一般mysql服务都由主备库组成，当主库出现问题时，可以切换到备库运行，保证服务的高可用。在这个过程中有一点很重要，避免双写。因为导致切换的场景有很多，可能是因为主库压力过大hang住了，也有可能是主库触发mysql bug重启了等。当我们将备库写开启时，如果老主库活着，一定要先将其设置为read_only状态。“set global read_only=1”这个命令实际上也和FTWRL类似，也需要上两把MDL，只是不需要清理表缓存而已。如果老主库上还有大的更新事务，将导致set global read_only hang住，设置失败。因此切换程序在设计时，要考虑这一点。
关键函数：fix_read_only
1.lock_global_read_lock(),避免新的更新事务，阻止更新操作
2.make_global_read_lock_block_commit，避免活跃的事务提交
FTWRL与备份
Mysql的备份方式，主要包括两类，逻辑备份和物理备份，逻辑备份的典型代表是mysqldump，物理备份的典型代表是extrabackup。根据备份是否需要停止服务，可以将备份分为冷备和热备。冷备要求服务器关闭，这个在生产环境中基本不现实，而且也与FTWRL无关，这里主要讨论热备。Mysql的架构支持插件式存储引擎，通常我们以是否支持事务划分，典型的代表就是myisam和innodb，这两个存储引擎分别是早期和现在mysql表的默认存储引擎。我们的讨论也主要围绕这两种引擎展开。对于innodb存储引擎而言，在使用mysqldump获取一致性备份时，我们经常会使用两个参数，--single-transaction和--master-data，前者保证innodb表的数据一致性，后者保证获取与数据备份匹配的一致性位点，主要用于搭建复制。现在使用mysql主备集群基本是标配，所以也是必需的。对于myisam，就需要通过--lock-all-tables参数和--master-data来达到同样的目的。我们在来回顾下FTWRL的3个步骤：
1. 上全局读锁
2. 清理表缓存
3. 上全局COMMIT锁
第一步的作用是堵塞更新，备份时，我们期望获取此时数据库的一致状态，不希望有更多的更新操作进来。对于innodb引擎而言，其自身的MVCC机制，可以保证读到老版本数据，因此第一步对它使多余的。第二步，清理表缓存，这个操作对于myisam有意义，关闭myisam表时，会强制要求表的缓存落盘，这对于物理备份myisam表是有意义的，因为物理备份是直接拷贝物理文件。对于innodb表，则无需这样，因为innodb有自己的redolog，只要记录当时LSN，然后备份LSN以后的redolog即可。第三步，主要是保证能获取一致性的binlog位点，这点对于myisam和innodb作用是一样的。
所以总的来说，FTWRL对于innodb引擎而言，最重要的是获取一致性位点，前面两个步骤是可有可无的，因此如果业务表全部是innodb表，这把大锁从原理上来讲是可以拆的，而且percona公司也确实做了这样的事情，具体大家可以参考blog链接。此外，官方版本的5.5和5.6对于mysqldump做了一个优化，主要改动是，5.5备份一个表，锁一个表，备份下一个表时，再上锁一个表，已经备份完的表锁不释放，这样持续进行，直到备份完成才统一释放锁。5.6则是备份完一个表，就释放一个锁，实现主要是通过innodb的保存点机制。相关的bug可以参考链接：http://bugs.mysql.com/bug.php?id=71017。
参考文献
https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/
https://www.percona.com/blog/2012/03/23/how-flush-tables-with-read-lock-works-with-innodb-tables/
http://bugs.mysql.com/bug.php?id=71017
http://www.cnblogs.com/bamboos/p/3458233.html
————————————————
版权声明：本文为CSDN博主「zuozhiji」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/jolly10/article/details/79704761
