注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

FLUSH TABLES WITH READ LOCK

MySQL 彭东稳 7848次浏览 已收录 0个评论

一、FTWRL

FLUSH TABLES WITH READ LOCK简称(FTWRL),该命令属于MySQL服务端命令,多用于备份的时候对全局表进行锁定来获取binlog信息。虽然持有时间很短,但容易被大操作堵塞造成备份不能完成。由于FTWRL总共需要持有两把全局的MDL(Metadata Data Lock)锁,并且还需要关闭所有表对象,因此这个命令的杀伤性很大,执行命令时容易导致库hang住。如果是主库,则业务无法正常访问;如果是备库,则会导致SQL线程卡住,主备延迟。本文将详细介绍FTWRL到底做了什么操作,每个操作的对库的影响,以及操作背后的原因。

FTWRL做了什么操作?

  • 获取MDL GLOBAL的S锁,直到unlock tables释放。
  • 获取MDL COMMIT的S锁,直到unlock tables释放。
  • 关闭所有的表重新打开,先释放table cache(包含TABLE_SHARED),然后重新加载生成table cache。

常见操作与FTWRL兼容性?

  • DML\FOR UPDATE:需要获取GLOBAL的IX锁持有到语句结束,但是TABLE MDL持有到事务结束一般为(MDL_SHARED_WRITE(SW) ),DML提交的时候会持有COMMIT的IX锁。
  • SELECT:不需要GLOBAL的IX锁,但是TABLE级别的MDL需要持有到事务结束,一般为(MDL_SHARED_READ(SR))。
  • DDL: 需要获取GLOBAL的IX锁到语句结束,TABLE MDL多变。

如果FLWRL发出之前已经有一个Query:select count(*) from tb,那么FTWRL也得等待(show processlist可以看到waiting for table flush)。长时间的select堵塞FTWRL, 因为FTWRL要关闭所有的表,如果有活跃的语句正在执行,table cache不能清空,因此需要等待。实际上即便是flush tables也不能在有语句执行的时候执行同样需要等待。

由于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进行处理。

关键函数关闭表流程如下:

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,唤醒所有等待线程。

第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有自己的redo log,只要记录当时LSN,然后备份LSN以后的redo log即可,当然物理备份工具也会做刷新redo log这个步骤,保证innodb表数据一致。第三步,主要是保证能获取一致性的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.jianshu.com/p/2397ccc8de83


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (2)or分享 (0)
关于作者:

您必须 登录 才能发表评论!