作为DBA的你，遇到问题无从下手，除了在问题面前徘徊，还能如何选择？如果你一次或多次遇到该问题还是无法解决，又很懊恼，该如何排忧呢？关注公众号，关注《包拯断案》专栏，让小编为你排忧解难~

说了这么多理论，想必实战更让你心动。那我们就拿一个真实项目案例进行分析---某金融客户现场，运维人员在进行数据库集群定时备份（从节点备份）时，出现了主从延迟较大的告警，该如何快速分析处理。

1、故障发生场景

在客户现场兢兢业业进行项目运维的你，正在为某个数据库集群进行定时备份，却收到了主从延迟较大的告警，没法完成定时备份，不清楚是从节点、服务器或者其他哪个环节出了问题。

2、故障排查

遇到主从延迟告警，第一件事肯定是要排查主从状态。

通过show slave status\G看，IO和SQL线程都是YES，Exec_Master_Log_Pos值和gtid值无变化，看Slave_SQL_Running_State，

为Waiting for dependent transaction to commit状态。这时会想：是不是遇到啥并行复制死锁了。

通过show processlist 查看并行复制各个线程状态，就看到这一幕：备份的xtrabackup执行flush table with read lock与并行复制死锁了，卡在这了。

这咋办？得恢复呀~只能将备份执行的flush table with read lock语句 kill掉。

kill后主从同步恢复了，主从延迟也逐渐降低恢复到0了。

虽然指标暂时恢复正常了，但这个问题得仔细分析分析，之前没遇到过。

通过保留的show slave status结果和show processlist中的信息，解析对应的binlog并进行分析，尝试复现这种场景。

通过分析binlog，查询当前配置参数，确认了当前问题的触发逻辑。

简单描述下当前的配置和执行语句：

flush table with read lock：这是一个老生常谈的语句，会关闭所有打开的表，并使用全局读锁锁定所有数据库的所有表。当前从节点配置了slave_preserve_commit_order=1，主节点执行的是xa事务。

slave_preserve_commit_order：这个参数主要控制并行复制中多线程之间的事务提交顺序是否和主节点一致。设置为1后，将保证提交顺序与主库一致。当有线程等待其他工作线程提交事务时，将会显示Waiting for preceding transaction to commit状态。

flush table with read lock 和并行复制触发死锁的逻辑如下：

至此，我们就梳理出了整个事情的逻辑：从节点为了保证提交顺序与主库达成一致，多个sql线程之间就存在一定的依赖关系。flush table with read lock又在任意时刻都可能执行，对于xa事务来说，可能存在xa start与xa commit在binlog中相距很远的情况。若ftwrl在两个sql线程间隙执行，则可能存在session1需要等sessoin2提交，session2要等flush table with read lock释放锁，flush table with read lock 又在等session 1提交的情况。

绕了一大圈，把包大人都绕迷糊了，可能很多人也被绕蒙圈了。

知道问题原因了，我们来看看如何解决吧~

在MySQL 5.7版本使用xtrabackup，是躲不掉flush table with read lock的。对于MySQL 8.0而言，有了clone功能，有lock instance for backup，并且xtrabackup在MySQL8.0对应版本中也做了优化；对于没有myisam表的，将不会执行flush table with read lock。

在MySQL5.7停服背景下遇到此问题，强烈推荐大家使用万里安全数据库GreatDB替换当前MySQL5.7版本，数据库不仅易用、稳定、高效，还能帮你一站式解决使用数据库使用过程中的疑难杂症。详情可点击文章底部“阅读原文”，查看万里数据库MySQL 5.7停服专区解决方案

如果暂时不能升级，可以先尝试试用GreatDB，我们在此给出优化方法。

在xtrabackup执行过程中，增加外部检测脚本，遇到flush table with read lock语句执行超过指定时间后，将语句kill并重新发起备份（数据量较少、备份速度快的可以使用，怕的是重复重试，超过预期备份窗口时间）。

修改xtrabackup代码，将flush table with read lock重试逻辑加入到其中（在此只演示将percona版本mysql中才能使用的backup超时和重试参数简单套用上，在flush table with read lock时进行超时重试，非专业版本，仅供参考）

下载percona xtrabackup代码

wget https://github.com/percona/percona-xtrabackup/archive/refs/tags/percona-xtrabackup-2.4.28.tar.gz

修改storage/innobase/xtrabackup/src/backup_mysql.cc中lock_tables_maybe函数

原代码如下

1143         if (have_galera_enabled) {1144                 xb_mysql_query(connection,1145                                 "SET SESSION wsrep_causal_reads=0", false);1146         }11471148         xb_mysql_query(connection, "FLUSH TABLES WITH READ LOCK", false);11491150         if (opt_kill_long_queries_timeout) {1151                 stop_query_killer();1152         }

调整后代码如下 主要调整为：1148-117

1143         if (have_galera_enabled) {
1144                 xb_mysql_query(connection,1145                                 "SET SESSION wsrep_causal_reads=0", false);1146         }11471148         if (retry_count>0) {1149                 for (int i = 0; i <= retry_count; ++i) {1150                         msg_ts("Executing FLUSH TABLES WITH READ LOCK retry %d....\n", i);1151                         xb_mysql_query(connection, "FLUSH TABLES WITH READ LOCK", false, false);1152                         uint err = mysql_errno(connection);1153                         if (err == ER_LOCK_WAIT_TIMEOUT) {1154                                 os_thread_sleep(1000000);1155                                 continue;1156                         }1157                         if (err == 0) {1158                                 tables_locked = true;1159                         }1160                         break;11611162                 }1163                 if (!tables_locked) {1164                         exit(EXIT_FAILURE);1165                 }1166                 return(true);1167         } else {1168                 xb_mysql_query(connection, "FLUSH TABLES WITH READ LOCK", false);1169         }1170         /* xb_mysql_query(connection, "FLUSH TABLES WITH READ LOCK", false); */11711172         if (opt_kill_long_queries_timeout) {1173                 stop_query_killer();1174         }

之后进行源码编译，发起备份，测试一下修改后的逻辑是否可用。在备份命令中需额外添加两个参数，以控制超时时间和重试次数。（这两个参数在修改源码时也描述了，是直接套用的现有参数）

--backup-lock-timeout=3 --backup-lock-retry-count=10

下图是加了重试后的备份日志截图，包大人看到后心中甚慰。

至此就完成了此次问题的全流程分析和处理。最后的“终极绝招”是一些小小尝试，仅供参考。在MySQL5.7停服的背景下，建议选择更易用、更稳定、更高效的数据库产品，才能为业务系统长久保驾护航。