Java自学者论坛

 找回密码
 立即注册

手机号码,快捷登录

恭喜Java自学者论坛(https://www.javazxz.com)已经为数万Java学习者服务超过8年了!积累会员资料超过10000G+
成为本站VIP会员,下载本站10000G+会员资源,会员资料板块,购买链接:点击进入购买VIP会员

JAVA高级面试进阶训练营视频教程

Java架构师系统进阶VIP课程

分布式高可用全栈开发微服务教程Go语言视频零基础入门到精通Java架构师3期(课件+源码)
Java开发全终端实战租房项目视频教程SpringBoot2.X入门到高级使用教程大数据培训第六期全套视频教程深度学习(CNN RNN GAN)算法原理Java亿级流量电商系统视频教程
互联网架构师视频教程年薪50万Spark2.0从入门到精通年薪50万!人工智能学习路线教程年薪50万大数据入门到精通学习路线年薪50万机器学习入门到精通教程
仿小米商城类app和小程序视频教程深度学习数据分析基础到实战最新黑马javaEE2.1就业课程从 0到JVM实战高手教程MySQL入门到精通教程
查看: 333|回复: 0

flush table with read lock的轻量级解决方案

[复制链接]
  • TA的每日心情
    奋斗
    2024-4-6 11:05
  • 签到天数: 748 天

    [LV.9]以坛为家II

    2034

    主题

    2092

    帖子

    70万

    积分

    管理员

    Rank: 9Rank: 9Rank: 9

    积分
    705612
    发表于 2021-5-9 11:38:04 | 显示全部楼层 |阅读模式

    为什么要使用FTWRL

      MySQL dba在日常工作中,数据备份绝对是工作频度最高的工作内容之一。当你使用逻辑方式进行备份(mydumper,mysqldump)或物理方式进行备份(percona-xtrabackup),为了保证数据的一致性,这两种备份方式都会在备份过程中执行 flush table with read lock 这个命令(**以下简称为FTWRL**),通过执行FTWRL,来对事务和非事务表来加table level级别的共享锁,取得此时的gtid或者binlog偏移量,继而得到某一个时间点的备份数据。

     

    FTWRL是如何工作的

      在过去的很长一段时间内,我们做备份一直是按以上的方式来做的,那么这种依靠FTWRL这种方式获得备份点的做法是否真的合理,对数据库有什么不良的影响吗?

      首先让我们来看下,FTWRL具体做了哪些事情,当flush tables with read lock这条命令在数据库中被执行的时候,执行逻辑可以分为下面的几个步骤:

    步骤一、请求获得相关类型的 MDL lock,这里我们暂时称之为 FTWRL_MDL_LOCK. 步骤二、清空query cache中的内容(当前应该很少有人开启这个功能了) 步骤三、FLUSH TABLES,将当前所有打开的table的fd关闭 步骤四、请求获得全局table-level lock
    步骤五、
    上全局COMMIT锁(make_global_read_lock_block_commit)


      以上步骤,在某些db场景下会产生非常严重的问题,我们以下面栗子说明: 
      当有很大的事务在进行的时候,此时FTWRL的步骤一,步骤二可以完成,但是进行到步骤三的时候,由于表相关的事务正在执行中,相应table的句柄被占用,无法进行flush table操作。

      笔者当时在现网就遇到这种情景,当时使用的工具是mydumper,该工具在进行到FTWRL步骤的时候,在步骤三卡住了,此时工具hang在那里,但是还误以为加锁失败,自然对业务不会造成影响,实际上步骤一,步骤二已经成功执行了,要命的是步骤一的FTWRL_MDL_LOCK对DML事务的排他的,所以在工具hang住的期间,其他的后续DML事务都是被阻塞的 -_-

     

    有比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引擎,在备份期间非常容易造成监控程序的写入失败,从而触发告警,-_-。

    哎...今天够累的,签到来了1...
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    QQ|手机版|小黑屋|Java自学者论坛 ( 声明:本站文章及资料整理自互联网,用于Java自学者交流学习使用,对资料版权不负任何法律责任,若有侵权请及时联系客服屏蔽删除 )

    GMT+8, 2024-5-15 23:17 , Processed in 0.071526 second(s), 29 queries .

    Powered by Discuz! X3.4

    Copyright © 2001-2021, Tencent Cloud.

    快速回复 返回顶部 返回列表