共计 1697 个字符，预计需要花费 5 分钟才能阅读完成。
作者：郭斌斌
爱可生 DBA 团队成员，负责我的项目日常问题解决及公司平台问题排查。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
一、背景
客户反馈生产环境中，MySQL 5.7 通过 xtrabackup+ Binlog 做基于工夫点的复原操作时，继续卡在 Binlog 的回放阶段，旷日持久，久到离谱。他对于这种旷日持久的操作产生了狐疑，想要确认数据库的这种行为是否正当，因而有了本文的 Binlog 回灌验证操作。
二、复现前提
MySQL Version：5.7.22
Binlog format：Row
筹备 Delete 800 多万记录的 Binlog
三、复现筹备
3.1 创立表、结构数据
mysql> create table t1(id int primary key,name varchar(10));
Query OK, 0 rows affected (0.02 sec)
mysql> insert into t1 values(1,repeat('a',10));
Query OK, 1 row affected (0.01 sec)
mysql> insert into t1 select (select count(1) from t1)+id,name from t1;
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
………………
mysql> insert into t1 select (select count(1) from t1)+id,name from t1;
Query OK, 4194304 rows affected (57.75 sec)
Records: 4194304 Duplicates: 0 Warnings: 03.2 筹备 Delete 800 多万记录的 Binlog 文件
MySQL Binlog mysql-bin.000003 用于回灌测试
3.3 因为 Binlog 的回灌和造数是在同一个实例上，之前为了构建 Delete 800 多万记录的 Binlog，曾经将数据删除，因而在进行 binlog 回灌前，须要应用之前造数的办法，从新造数
3.4 同一个实例上先进行了 Delete，又从新构建新的数据。导致 Delete 操作的 GTID 要比重新造数操作的 GTID 小，为保障能够失常回灌，能够执行 reset master
四、复现测试
4.1 解析 MySQL Binlog mysql-bin.000003
4.2 导入解析文件
A Few Moment Later
4.3 查看 processlist，发现导入线程始终处于 Sleep 状态，景象跟客户形容符合。
4.4 随即中断导入操作，从新发动导入同时应用 strace 记录操作的行为。
4.5 通过观测产生的 strace.log，发现两个 read 的工夫距离不固定，少的也须要 140ms 左右，而读取的大小却只有 4k（4096），读取效率偏低。
五、剖析
通过 Google 检索“MySQL Mem Load Slow”发现这是一个 BUG，MySQL 5.7 Client 在读取较大事务（波及多行操作）时，因为内存调配效率比拟低，导致耗费大量的工夫，已在 MySQL 8.0.13 中修复。
六、复测
6.1 Mysql 8.0.18 客户端进行 Binlog 解析文件的回灌，提醒 MySQL Server has gone away
6.2 导数报错时数据库没触发重启，查看 error 日志，有如下报错：
6.3 调大 max_allowed_packet 配置后从新测试
6.4 观测 strace 日志，每次读取 Binlog 大小 16M，远高于原来的 4k
6.5 观测线程状态
6.6 察看执行耗时，MySQL 8.0.18 客户端导数工夫变短，效率晋升显著。
七、论断
目前官网在 MySQL 8.0.13 版本中，解决了“在应用 MySQL Client 进行批量导数时，内存调配效率低”的问题，因而 MySQL 8.0.18 客户端在进行回灌 Binlog 解析后的文件时，读取文件效率显著高于 5.7.22 的客户端，晋升了 Binlog 回放的效率。
参考链接
https://bugs.mysql.com/bug.ph…
https://dev.mysql.com/doc/rel…