FTWRL原理与重要性

概念

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)

详细版：

1. 步骤一、请求获得相关类型的 MDL lock,这里我们暂时称之为 FTWRL_MDL_LOCK.
2. 步骤二、清空query cache中的内容（当前应该很少有人开启这个功能了）
3. 步骤三、FLUSH TABLES,将当前所有打开的table的fd关闭
4. 步骤四、请求获得全局table-level lock
5. 步骤五、上全局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可以参考链接

有比FTWRL更好的方法吗

我们发现FTWRL是一种非常重量级锁，或者说采取了一些额外过度的动作。有非常大的可能失败，比如非常大的事务正在执行，这时候会被阻塞；而阻塞的时候又会影响其他的DML事务的执行，这时候是很危险的！

那是否有改良的更好方案呢，percona的回答的是肯定的，在 5.6.16-64.0这个版本中，percona开始引入了两个新的MDL类型的锁，相应的引入了两个新的备份命令

LOCK TABLES FOR BACKUP
LOCK BINLOG FOR BACKUP

lock tables for backup

执行该命令后，获得的新的MDL锁会阻塞对非事务表的更新及所有DDL动作，此时其他用户可以继续更新inonodb引擎的表，但是无法对myisam表进行更新动作。

lock binglog for backup

执行该命令后，如果加锁成功，将会阻塞binglog的更新，此时所有的DML操作被阻塞。

那么通过上面两个命令在获取一致性的数据备份相比之前用FTWRL，有什么好处呢，我们通过下面两张图可以看到区别：

首先我们看下在非percona-5.6.16-64.0版本中。xtrabackup的工作流程：

然后我们看下percona-5.6.16-64.0版本及以上中，xtrabackup备份的流程是怎样的：

从上面两张图我们可以总结如下：

1. 使用FTWTRL备份的方式，如果myisam表数量众多，或者当前有大事务在执行，FTWTRL处于等待或者FTWTRL保持，这个时间段期间，后续对innod的DML都将被阻塞，因此时间持续越长，对业务影响越大。
2. 使用 lock tables for backup备份myisam表期间，对innodb的dml事务无影响，且加锁过程不受当前是否有大事务正在执行的影响

我们可以发现使用 lock table和lock binlog来备份数据，不仅可以实现更轻量级的上锁，并且可以节约myisam备份期间对业务的写操作影响，我在percona server的环境下试验证了以下，可以看到xtrabackup不再使用FTWRL命令了

percona这个小的改动解决了之前长期以来热备数据的问题，特别是非percona server 版本下的云平用户有的执着使用myisam引擎，在备份期间非常容易造成监控程序的写入失败，从而触发告警，-_-。