引言
在 MySQL 中主从延迟是常见现象，可能的原因有很多种，比如大事务、DDL、网络延迟等，本文介绍一个案例，半同步复制导致主从延迟。首先可以考虑一个问题，半同步复制对于主从延迟的影响有多大呢？
现象
监控
20221103 收到告警 MySQL 主从延迟，监控显示主从延迟变化接近直线，延迟持续增大，并且期间延迟反复跳动，多次显示延迟等于 0。
查看复制位点时显示位点在变化，因此复制没有阻塞。
要解决主从延迟的问题，首先需要定位问题的原因，可能导致主从延迟的原因有很多，主要可以分为两类，IO 线程慢与 SQL 线程慢，因此首先需要分析瓶颈是在 IO 线程还是 SQL 线程。
场景
该实例是一个上云的 RDS 从库，是一个级联从库，称为二级从库。
如下图所示，对应的主库是做数据同步的 RDS 主库，称为一级从库，一级从库对应的主库是物理机。
主从延迟出现在从物理机向 RDS 增量同步的过程中。经查看，两个 RDS 都有主从延迟。
注意：物理机到 RDS 是异步复制，RDS 之间是半同步复制。
分析
二级从库
复制
三次查看 RDS 的主从复制，显示主从复制的位点与 GTID 均在变化，表明复制正常运行。
# 第一次
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Log_File: mysql-bin.062326
Read_Master_Log_Pos: 29877290
Relay_Log_File: relay-log.119185
Relay_Log_Pos: 29863173
Relay_Master_Log_File: mysql-bin.062326
Exec_Master_Log_Pos: 29862960
Seconds_Behind_Master: 23858
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Retrieved_Gtid_Set: b1636cb4-af43-11ec-9dd3-fa163e84db80:49919-631183,
b945cfe4-be28-11e7-b047-246e9673a3b9:11903376505-14154248266
Executed_Gtid_Set: b1636cb4-af43-11ec-9dd3-fa163e84db80:1-631183,
b945cfe4-be28-11e7-b047-246e9673a3b9:11832098400-14154248266
Auto_Position: 1
# 第二次
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Log_File: mysql-bin.062326
Read_Master_Log_Pos: 31343804
Relay_Log_File: relay-log.119185
Relay_Log_Pos: 31326750
Relay_Master_Log_File: mysql-bin.062326
Exec_Master_Log_Pos: 31326537
Seconds_Behind_Master: 0
Retrieved_Gtid_Set: b1636cb4-af43-11ec-9dd3-fa163e84db80:49919-631183,
b945cfe4-be28-11e7-b047-246e9673a3b9:11903376505-14154250624
Executed_Gtid_Set: b1636cb4-af43-11ec-9dd3-fa163e84db80:1-631183,
b945cfe4-be28-11e7-b047-246e9673a3b9:11832098400-14154250624
Auto_Position: 1
# 第三次
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Log_File: mysql-bin.062326
Read_Master_Log_Pos: 32459051
Relay_Log_File: relay-log.119185
Relay_Log_Pos: 32427436
Relay_Master_Log_File: mysql-bin.062326
Exec_Master_Log_Pos: 32427223
Seconds_Behind_Master: 23870
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Retrieved_Gtid_Set: b1636cb4-af43-11ec-9dd3-fa163e84db80:49919-631183,
b945cfe4-be28-11e7-b047-246e9673a3b9:11903376505-14154252848
Executed_Gtid_Set: b1636cb4-af43-11ec-9dd3-fa163e84db80:1-631183,
b945cfe4-be28-11e7-b047-246e9673a3b9:11832098400-14154252848
Auto_Position: 1
其中：
-
Auto_Position: 1，表明复制关系基于 GTID； -
第二次查看时显示主从延迟等于 0，明显这是不合理的； -
三次查看时均显示 SQL 线程与 IO 线程实时运行。两个线程的状态如下所示：
Slave_IO_State: Waiting for master to send event
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
对比 Master_Log_File（mysql-bin.062326） 与 Relay_Master_Log_File（mysql-bin.062326），显示 SQL 线程当前滞后 IO 线程不到 1 个 binlog 文件。
连接
查看当前连接。
mysql> SHOW PROCESSLIST;
+---------+-------------+----------------------+-------+---------+----------+--------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+---------+-------------+----------------------+-------+---------+----------+--------------------------------------------------------+------------------+
| 6 | system user | | NULL | Connect | 0 | Slave has read all relay log; waiting for more updates | NULL |
| 7 | system user | | NULL | Connect | 23860 | Waiting for an event from Coordinator | NULL |
| 8 | system user | | NULL | Connect | 23860 | Waiting for an event from Coordinator | NULL |
| 9 | system user | | NULL | Connect | 23862 | Waiting for an event from Coordinator | NULL |
| 10 | system user | | NULL | Connect | 23903 | Waiting for an event from Coordinator | NULL |
| 11 | system user | | NULL | Connect | 24012 | Waiting for an event from Coordinator | NULL |
| 12 | system user | | NULL | Connect | 24917 | Waiting for an event from Coordinator | NULL |
| 13 | system user | | NULL | Connect | 29861 | Waiting for an event from Coordinator | NULL |
| 14 | system user | | NULL | Connect | 34215 | Waiting for an event from Coordinator | NULL |
| 15 | system user | | NULL | Connect | 34225 | Waiting for an event from Coordinator | NULL |
| 16 | system user | | NULL | Connect | 34997 | Waiting for an event from Coordinator | NULL |
| 17 | system user | | NULL | Connect | 35261 | Waiting for an event from Coordinator | NULL |
| 18 | system user | | NULL | Connect | 35261 | Waiting for an event from Coordinator | NULL |
| 19 | system user | | NULL | Connect | 35261 | Waiting for an event from Coordinator | NULL |
| 20 | system user | | NULL | Connect | 35512 | Waiting for an event from Coordinator | NULL |
| 21 | system user | | NULL | Connect | 35512 | Waiting for an event from Coordinator | NULL |
| 22 | system user | | NULL | Connect | 92697 | Waiting for an event from Coordinator | NULL |
| 23 | system user | | NULL | Connect | 18198597 | Waiting for master to send event | NULL |
| 5806425 | monitor | 127.0.0.1:43447 | NULL | Sleep | 15 | | NULL |
| 5806480 | os_admin | 127.0.0.1:46573 | mysql | Sleep | 17 | | NULL |
| 6199775 | os_admin | 127.0.0.1:16174 | mysql | Sleep | 7 | | NULL |
| 6420314 | os_admin | 127.0.0.1:53460 | NULL | Sleep | 2 | | NULL |
| 6420481 | os_admin | 127.0.0.1:15631 | NULL | Sleep | 7 | | NULL |
| 6420515 | os_admin | 127.0.0.1:18405 | NULL | Sleep | 7 | | NULL |
| 6421258 | os_admin | 127.0.0.1:26718 | mysql | Sleep | 57 | | NULL |
| 6421267 | os_admin | 127.0.0.1:27232 | mysql | Sleep | 47 | | NULL |
| 6421272 | os_admin | 127.0.0.1:27678 | mysql | Sleep | 37 | | NULL |
| 6421276 | os_admin | 127.0.0.1:28196 | mysql | Sleep | 27 | | NULL |
| 6421280 | os_admin | 127.0.0.1:28828 | mysql | Sleep | 17 | | NULL |
| 6421286 | os_admin | 127.0.0.1:29300 | mysql | Sleep | 7 | | NULL |
| 6421290 | admin | x.x.x.x:15737 | NULL | Query | 0 | starting | SHOW PROCESSLIST |
+---------+-------------+----------------------+-------+---------+----------+--------------------------------------------------------+------------------+
31 rows in set (0.04 sec)
分别查看复制相关线程的运行状态：
-
IO 线程，Slave has read all relay log; waiting for more updates -
SQL Coordinator 线程，Waiting for master to send event -
SQL worker 线程，Waiting for an event from Coordinator
综上，RDS 二级从库复制实时更新，理论上延迟等于 0，但实际上延迟很大。
一级从库
复制
查看一级从库 RDS，显示也有主从延迟。
对比 Master_Log_File（mysql-bin.018794） 与 Relay_Master_Log_File（mysql-bin.018784），显示 SQL 线程当前落后 IO 线程 10 个 binlog 文件。
mysql> SHOW SLAVE STATUS G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: x.x.x.x
Master_User: replicater_wl
Master_Port: 3358
Connect_Retry: 60
Master_Log_File: mysql-bin.018794
Read_Master_Log_Pos: 754953374
Relay_Log_File: relay-log.004018
Relay_Log_Pos: 16320744
Relay_Master_Log_File: mysql-bin.018784
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Exec_Master_Log_Pos: 16320571
Relay_Log_Space: 11492400133
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 23879
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 75133181
Master_UUID: b945cfe4-be28-11e7-b047-246e9673a3b9
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Waiting for dependent transaction to commit
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: b945cfe4-be28-11e7-b047-246e9673a3b9:13283490577-14165140358
Executed_Gtid_Set: b1636cb4-af43-11ec-9dd3-fa163e84db80:1-631183,
b945cfe4-be28-11e7-b047-246e9673a3b9:11832098400-14154256087
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.03 sec)
同样查看复制相关线程运行状态：
-
Slave_IO_State: Waiting for master to send event，表明从库 IO 线程已向主库发送请求，等待主库发送 event； -
Slave_SQL_Running_State: Waiting for dependent transaction to commit，表明等待当前的 Group 提交后才能并行执行下一个 Group 的事务，也就是说主库事务还没有发送给从库。
连接
查看当前连接。
mysql> SHOW PROCESSLIST;
+---------+-------------+----------------------+-------+------------------+----------+---------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+---------+-------------+----------------------+-------+------------------+----------+---------------------------------------------------------------+------------------+
| 219575 | replicater | x.x.x.x:58781 | NULL | Binlog Dump GTID | 18198624 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 4064860 | system user | | NULL | Connect | 6549150 | Waiting for master to send event | NULL |
| 4064861 | system user | | NULL | Connect | 0 | Waiting for dependent transaction to commit | NULL |
| 4064862 | system user | | NULL | Connect | 23881 | Waiting for semi-sync ACK from slave | NULL |
| 4064863 | system user | | NULL | Connect | 23881 | Waiting for an event from Coordinator | NULL |
| 4064864 | system user | | NULL | Connect | 23882 | Waiting for an event from Coordinator | NULL |
| 4064865 | system user | | NULL | Connect | 23885 | Waiting for an event from Coordinator | NULL |
| 4064866 | system user | | NULL | Connect | 23893 | Waiting for an event from Coordinator | NULL |
| 4064867 | system user | | NULL | Connect | 23949 | Waiting for an event from Coordinator | NULL |
| 4064868 | system user | | NULL | Connect | 24404 | Waiting for an event from Coordinator | NULL |
| 4064869 | system user | | NULL | Connect | 24404 | Waiting for an event from Coordinator | NULL |
| 4064870 | system user | | NULL | Connect | 24500 | Waiting for an event from Coordinator | NULL |
| 4064871 | system user | | NULL | Connect | 24623 | Waiting for an event from Coordinator | NULL |
| 4064872 | system user | | NULL | Connect | 24623 | Waiting for an event from Coordinator | NULL |
| 4064873 | system user | | NULL | Connect | 25093 | Waiting for an event from Coordinator | NULL |
| 4064874 | system user | | NULL | Connect | 32854 | Waiting for an event from Coordinator | NULL |
| 4064875 | system user | | NULL | Connect | 35350 | Waiting for an event from Coordinator | NULL |
| 4064876 | system user | | NULL | Connect | 35354 | Waiting for an event from Coordinator | NULL |
| 4064877 | system user | | NULL | Connect | 35354 | Waiting for an event from Coordinator | NULL |
| 6716910 | replicater | x.x.x.x:20018 | NULL | Binlog Dump GTID | 839135 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 6716919 | monitor | 127.0.0.1:20311 | NULL | Sleep | 15 | | NULL |
| 6716963 | os_admin | 127.0.0.1:23795 | mysql | Sleep | 6 | | NULL |
| 7357618 | os_admin | 127.0.0.1:30404 | NULL | Sleep | 0 | | NULL |
| 7357624 | os_admin | 127.0.0.1:30940 | NULL | Sleep | 1 | | NULL |
| 7357625 | os_admin | 127.0.0.1:30946 | NULL | Sleep | 0 | | NULL |
| 7362800 | os_admin | 127.0.0.1:27504 | mysql | Sleep | 16 | | NULL |
| 7362803 | os_admin | 127.0.0.1:28104 | mysql | Sleep | 6 | | NULL |
| 7362804 | admin | x.x.x.x:46283 | NULL | Query | 0 | starting | SHOW PROCESSLIST |
+---------+-------------+----------------------+-------+------------------+----------+---------------------------------------------------------------+------------------+
28 rows in set (0.03 sec)
其中：
-
dump 线程：Master has sent all binlog to slave; waiting for more updates，表明作为主库已发送 binlog 给从库，因此一级从库与二级从库之间无延迟； -
system user 线程：Waiting for master to send event，表明作为从库 IO 线程已向主库发送请求，等待主库发送 event，因此 IO 线程无延迟；
The “Waiting for master to send event” state shows that the slave IO thread sent a request for a new event, and is waiting for the event from the master.
-
system user 线程：Waiting for semi-sync ACK from slave，表明作为主库等待从库半同步响应，因此怀疑是半同步复制导致主从延迟，因此 SQL 线程有延迟。
半同步日志
查看半同步复制相关配置。
mysql> show variables like '%semi%';
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 1000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
| rpl_semi_sync_slave_enabled | OFF |
| rpl_semi_sync_slave_trace_level | 32 |
+-------------------------------------------+------------+
8 rows in set (0.04 sec)
其中：
-
rpl_semi_sync_master_timeout=1000，单位毫秒，表示半同步复制 1 秒超时后将自动切换为异步复制； -
rpl_semi_sync_master_enabled，表示主库是否开启半同步复制； -
[slave] rpl_semi_sync_slave_enabled，表示从库是否开启半同步复制； -
rpl_semi_sync_master_wait_for_slave_count，表示主库每个事务需要接收到响应的从库数量，如果直到超时，接收到响应的从库数量始终小于该值，自动切换为异步复制； -
rpl_semi_sync_master_wait_no_slave，与 rpl_semi_sync_master_wait_for_slave_count 共同作用决定半同步复制是否切换为异步复制； -
rpl_semi_sync_master_wait_point，控制半同步模式下主库在返回给会话事务成功之前提交事务的方式； -
rpl_semi_sync_master_trace_level，表示主库半同步复制的调试级别，默认 32； -
[slave] rpl_semi_sync_slave_trace_level，表示从库半同步复制的调试级别，默认 32。
注意：
-
标识 [slave] 表示从库配置，其他表示主库配置； -
rpl_semi_sync_master_wait_point 参数非常重要，后续将单独一篇详细介绍。
开启 debug trace。
mysql> set global rpl_semi_sync_master_trace_level=16;
Query OK, 0 rows affected (0.03 sec)
开启 debug 日志后，查看错误日志，显示半同步复制延迟平均 3ms 左右。
11:02:09.009 – 11:02:09.006 = 0.003 s
11:02:09.013 – 11:02:09.010 = 0.003 s
2022-11-03T11:02:09.006716+08:00 4064862 [Note] ReplSemiSyncMaster::commitTrx: init wait position (mysql-bin.062334, 17620087),
2022-11-03T11:02:09.006727+08:00 4064862 [Note] ReplSemiSyncMaster::commitTrx: wait 1000 ms for binlog sent (mysql-bin.062334, 17620087)
2022-11-03T11:02:09.006736+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17619669) sync(0), repl(1)
2022-11-03T11:02:09.006760+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17619732) sync(0), repl(1)
2022-11-03T11:02:09.006769+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17619865) sync(0), repl(1)
2022-11-03T11:02:09.006779+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17620056) sync(0), repl(1)
2022-11-03T11:02:09.006786+08:00 6716910 [Note] ActiveTranx::is_tranx_end_pos: probe (mysql-bin.062334, 17620087) in entry(15621)
2022-11-03T11:02:09.006790+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17620087) sync(1), repl(1)
2022-11-03T11:02:09.006800+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17619669) sync(0), repl(1)
2022-11-03T11:02:09.006824+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17619732) sync(0), repl(1)
2022-11-03T11:02:09.006833+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17619865) sync(0), repl(1)
2022-11-03T11:02:09.006840+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17620056) sync(0), repl(1)
2022-11-03T11:02:09.006846+08:00 219575 [Note] ActiveTranx::is_tranx_end_pos: probe (mysql-bin.062334, 17620087) in entry(15621)
2022-11-03T11:02:09.006852+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17620087) sync(1), repl(1)
2022-11-03T11:02:09.009812+08:00 0 [Note] ReplSemiSyncMaster::reportReplyPacket: Got reply(mysql-bin.062334, 17620087) from server 1682448447
2022-11-03T11:02:09.009830+08:00 0 [Note] ReplSemiSyncMaster::reportReplyBinlog: Got reply at (mysql-bin.062334, 17620087)
2022-11-03T11:02:09.009835+08:00 0 [Note] ReplSemiSyncMaster::reportReplyBinlog: signal all waiting threads.
2022-11-03T11:02:09.009909+08:00 4064862 [Note] ReplSemiSyncMaster::commitTrx: Binlog reply is ahead (mysql-bin.062334, 17620087),
2022-11-03T11:02:09.009917+08:00 0 [Note] ReplSemiSyncMaster::reportReplyPacket: Got reply(mysql-bin.062334, 17620087) from server 1682448479
2022-11-03T11:02:09.009940+08:00 4064862 [Note] ActiveTranx::::clear_active_tranx_nodes: cleared all nodes
2022-11-03T11:02:09.009952+08:00 0 [Note] ReplSemiSyncMaster::reportReplyBinlog: Got reply at (mysql-bin.062334, 17620087)
2022-11-03T11:02:09.010224+08:00 4064862 [Note] ActiveTranx:insert_tranx_node: insert (mysql-bin.062334, 17620570) in entry(19803)
2022-11-03T11:02:09.010333+08:00 4064862 [Note] ReplSemiSyncMaster::commitTrx: wait pos (mysql-bin.062334, 17620570), repl(1)
2022-11-03T11:02:09.010353+08:00 4064862 [Note] ReplSemiSyncMaster::commitTrx: init wait position (mysql-bin.062334, 17620570),
2022-11-03T11:02:09.010359+08:00 4064862 [Note] ReplSemiSyncMaster::commitTrx: wait 1000 ms for binlog sent (mysql-bin.062334, 17620570)
2022-11-03T11:02:09.010371+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17620152) sync(0), repl(1)
2022-11-03T11:02:09.010387+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17620152) sync(0), repl(1)
2022-11-03T11:02:09.010407+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17620215) sync(0), repl(1)
2022-11-03T11:02:09.010414+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17620215) sync(0), repl(1)
2022-11-03T11:02:09.010427+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17620348) sync(0), repl(1)
2022-11-03T11:02:09.010443+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17620539) sync(0), repl(1)
2022-11-03T11:02:09.010453+08:00 219575 [Note] ActiveTranx::is_tranx_end_pos: probe (mysql-bin.062334, 17620570) in entry(19803)
2022-11-03T11:02:09.010459+08:00 219575 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448479), (mysql-bin.062334, 17620570) sync(1), repl(1)
2022-11-03T11:02:09.010471+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17620348) sync(0), repl(1)
2022-11-03T11:02:09.010482+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17620539) sync(0), repl(1)
2022-11-03T11:02:09.010491+08:00 6716910 [Note] ActiveTranx::is_tranx_end_pos: probe (mysql-bin.062334, 17620570) in entry(19803)
2022-11-03T11:02:09.010495+08:00 6716910 [Note] ReplSemiSyncMaster::updateSyncHeader: server(1682448447), (mysql-bin.062334, 17620570) sync(1), repl(1)
2022-11-03T11:02:09.013503+08:00 0 [Note] ReplSemiSyncMaster::reportReplyPacket: Got reply(mysql-bin.062334, 17620570) from server 1682448479
2022-11-03T11:02:09.013521+08:00 0 [Note] ReplSemiSyncMaster::reportReplyBinlog: Got reply at (mysql-bin.062334, 17620570)
2022-11-03T11:02:09.013527+08:00 0 [Note] ReplSemiSyncMaster::reportReplyBinlog: signal all waiting threads.
2022-11-03T11:02:09.013541+08:00 0 [Note] ReplSemiSyncMaster::reportReplyPacket: Got reply(mysql-bin.062334, 17620570) from server 1682448447
2022-11-03T11:02:09.013542+08:00 4064862 [Note] ReplSemiSyncMaster::commitTrx: Binlog reply is ahead (mysql-bin.062334, 17620570),
2022-11-03T11:02:09.013568+08:00 4064862 [Note] ActiveTranx::::clear_active_tranx_nodes: cleared all nodes
2022-11-03T11:02:09.013580+08:00 0 [Note] ReplSemiSyncMaster::reportReplyBinlog: Got reply at (mysql-bin.062334, 17620570)
2022-11-03T11:02:09.013887+08:00 4064862 [Note] ActiveTranx:insert_tranx_node: insert (mysql-bin.062334, 17621053) in entry(23965)
2022-11-03T11:02:09.013982+08:00 4064862 [Note] ReplSemiSyncMaster::commitTrx: wait pos (mysql-bin.062334, 17621053), repl(1)
因此二级从库有延迟的原因是一级从库有延迟。
但是半同步复制延迟平均 3ms 的影响有多大，会导致主从延迟吗？
主库
连接
查看当前连接。
mysql> select * from information_schema.processlist where command like 'Binlog%';
+----------+---------------+---------------------+------+-------------+----------+---------------------------------------------------------------+------+
| ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO |
+----------+---------------+---------------------+------+-------------+----------+---------------------------------------------------------------+------+
| 55370173 | wms_rep | x.x.x.x:49636 | NULL | Binlog Dump | 18718499 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 75010596 | replicater_wl | x.x.x.x:59864 | NULL | Binlog Dump | 788753 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 75010583 | report_tran_s | x.x.x.x:26357 | NULL | Binlog Dump | 788760 | Master has sent all binlog to slave; waiting for more updates | NULL |
+----------+---------------+---------------------+------+-------------+----------+---------------------------------------------------------------+------+
3 rows in set (0.00 sec)
其中：
-
dump 线程：Master has sent all binlog to slave; waiting for more updates，表明主库已发送 binlog 给从库。
The thread has read all remaining updates from the binary logs and sent them to the replica. The thread is now idle, waiting for new events to appear in the binary log resulting from new updates occurring on the source.
因此，从库已请求主库 binlog，主库也已发送，从库也收到了，但是回放产生延迟。
网卡流量
怀疑是流量打满，因此查看网卡流量。
首先查看网卡信息，执行ip a命令显示当前使用的是 eth1 网卡。
[root@DB ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 24:6e:96:73:a3:b8 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 24:6e:96:73:a3:b9 brd ff:ff:ff:ff:ff:ff
inet ... brd ... scope global eth1
inet ... scope global eth1
inet6 fe80::266e:96ff:fe73:a3b9/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 24:6e:96:73:a3:ba brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 24:6e:96:73:a3:bb brd ff:ff:ff:ff:ff:ff
然后查看网卡流量，执行sar -n DEV 1 5命令，结果如下所示。
[root@DB ~]# sar -n DEV 1 5
Linux 2.6.32-431.el6.x86_64 (DB-I) 11/03/2022 _x86_64_(32 CPU)
10:31:45 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
10:31:46 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:46 AM eth4 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:46 AM eth1 6039.00 6483.00 1200.22 2654.37 0.00 0.00 11.00
10:31:46 AM eth2 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:46 AM eth3 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:46 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
10:31:47 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:47 AM eth4 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:47 AM eth1 11489.90 12765.66 1788.36 4669.60 0.00 0.00 11.11
10:31:47 AM eth2 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:47 AM eth3 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:47 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
10:31:48 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:48 AM eth4 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:48 AM eth1 7780.00 8371.00 1348.90 3124.21 0.00 0.00 11.00
10:31:48 AM eth2 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:48 AM eth3 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
10:31:49 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:49 AM eth4 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:49 AM eth1 5381.19 5857.43 1138.44 2606.55 0.00 0.00 10.89
10:31:49 AM eth2 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:49 AM eth3 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
10:31:50 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:50 AM eth4 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:50 AM eth1 6303.03 7413.13 1280.27 3643.48 0.00 0.00 11.11
10:31:50 AM eth2 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:31:50 AM eth3 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
Average: lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: eth4 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: eth1 7388.58 8165.73 1350.08 3334.90 0.00 0.00 11.02
Average: eth2 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: eth3 0.00 0.00 0.00 0.00 0.00 0.00 0.00
输出信息中 rxkB、txkB 字段分别表示每秒接收（写入）与发出的数据量。
结果表明最多当前网卡每秒发出流量 4M 左右，因此上传速度 4M/s，对应带宽 32M。
binlog
怀疑是 binlog 生成速度过快，导致流量打满，因此查看 binlog 的数据量。
如下所示，0 点-11 点之间，15-20 分钟生成一个 1G 的 binlog，因此写入数据量并不大。
[root@DB data]# pwd
/export/data/mysql/data
[root@DB data]# ll -h mysql-bin.*
-rw-r----- 1 mysql mysql 1.1G Nov 2 22:12 mysql-bin.018773
-rw-r----- 1 mysql mysql 1.1G Nov 3 00:01 mysql-bin.018774
-rw-r----- 1 mysql mysql 1.1G Nov 3 00:38 mysql-bin.018775
-rw-r----- 1 mysql mysql 1.1G Nov 3 01:52 mysql-bin.018776
-rw-r----- 1 mysql mysql 1.1G Nov 3 02:07 mysql-bin.018777
-rw-r----- 1 mysql mysql 1.1G Nov 3 02:16 mysql-bin.018778
-rw-r----- 1 mysql mysql 1.1G Nov 3 02:30 mysql-bin.018779
-rw-r----- 1 mysql mysql 1.1G Nov 3 02:45 mysql-bin.018780
-rw-r----- 1 mysql mysql 1.1G Nov 3 03:04 mysql-bin.018781
-rw-r----- 1 mysql mysql 1.1G Nov 3 03:22 mysql-bin.018782
-rw-r----- 1 mysql mysql 1.1G Nov 3 03:43 mysql-bin.018783
-rw-r----- 1 mysql mysql 1.1G Nov 3 04:00 mysql-bin.018784
-rw-r----- 1 mysql mysql 1.1G Nov 3 04:21 mysql-bin.018785
-rw-r----- 1 mysql mysql 1.1G Nov 3 04:46 mysql-bin.018786
-rw-r----- 1 mysql mysql 1.1G Nov 3 05:15 mysql-bin.018787
-rw-r----- 1 mysql mysql 1.1G Nov 3 05:44 mysql-bin.018788
-rw-r----- 1 mysql mysql 1.1G Nov 3 06:08 mysql-bin.018789
-rw-r----- 1 mysql mysql 1.1G Nov 3 06:39 mysql-bin.018790
-rw-r----- 1 mysql mysql 1.1G Nov 3 07:12 mysql-bin.018791
-rw-r----- 1 mysql mysql 1.1G Nov 3 07:41 mysql-bin.018792
-rw-r----- 1 mysql mysql 1.1G Nov 3 08:57 mysql-bin.018793
-rw-r----- 1 mysql mysql 1.1G Nov 3 10:53 mysql-bin.018794
-rw-r----- 1 mysql mysql 380M Nov 3 11:31 mysql-bin.018795
-rw-r----- 1 mysql mysql 2.0K Nov 3 10:53 mysql-bin.index
假设以 4M/s 的速度发送 binlog，1024M / 4M/s / 60s = 4 min，发送 1G 的 binlog 理论上需要 4 分钟左右，远小于生成用时 15-20 分钟，因此网络没有打满。
从一级从库中可以看到，SQL 线程当前滞后 IO 线程 10 个 binlog 文件，综上表明并没有慢在 IO 线程，因此可以判断慢在 SQL 线程。
处理
判断瓶颈
MySQL 的性能瓶颈通常出现在 CPU、IO、网络、内存等多方面，SQL 线程慢常见的性能瓶颈与对应处理方法如下：
-
瓶颈出现在 IO 时可以修改刷盘参数； -
瓶颈出现在网络时可以关闭半同步复制。
查看磁盘 IO 繁忙度，显示 IO 远没有达到瓶颈。
因此，怀疑是半同步复制导致的主从延迟。
关闭半同步
一级从库上关闭作为主库的半同步复制。
mysql> set global rpl_semi_sync_master_enabled=0;
Query OK, 0 rows affected (0.04 sec)
查看半同步复制状态参数，Rpl_semi_sync_master_status=OFF 表示该实例作为主库时关闭了半同步复制。
mysql> show global status like '%semi%';
+--------------------------------------------+---------------+
| Variable_name | Value |
+--------------------------------------------+---------------+
| Rpl_semi_sync_master_clients | 2 |
| Rpl_semi_sync_master_net_avg_wait_time | 0 |
| Rpl_semi_sync_master_net_wait_time | 0 |
| Rpl_semi_sync_master_net_waits | 4490839711 |
| Rpl_semi_sync_master_no_times | 137 |
| Rpl_semi_sync_master_no_tx | 3892 |
| Rpl_semi_sync_master_status | OFF |
| Rpl_semi_sync_master_timefunc_failures | 0 |
| Rpl_semi_sync_master_tx_avg_wait_time | 3095 |
| Rpl_semi_sync_master_tx_wait_time | 6666887744774 |
| Rpl_semi_sync_master_tx_waits | 2154065439 |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0 |
| Rpl_semi_sync_master_wait_sessions | 0 |
| Rpl_semi_sync_master_yes_tx | 2257539617 |
| Rpl_semi_sync_slave_status | OFF |
+--------------------------------------------+---------------+
15 rows in set (0.04 sec)
监控显示在关闭半同步后写入速度明显加快，以每秒写入行数为例，从 1140 增长至 10813，涨了将近十倍。
实例的 QPS、TPS 也明显增加。
查看监控，主从延迟在半小时内从峰值 40057s（约11h）恢复，主从延迟问题解决。
另一方面表明 3ms 的延迟对于半同步复制来说，已经很大了。
原理
半同步复制
MySQL 5.5 中引入半同步复制，用于解决数据一致性问题。
在此之前，MySQL 仅支持异步复制，也就是说主库并不关注从库是否接收到 binlog，因此如果在从库接收到 binlog 之前主库宕机，将从库提升为主库，就会发生数据丢失。
半同步复制的原理简单说就是主库在事务提交之前需要接收到从库响应，从库会在将 binlog 写入 relay-log 后发送 ACK 给主库，然后主库才会将 commit OK 结果反馈给客户端。
异步复制与半同步复制的对比见下图。
相比于异步复制，半同步复制提高了数据一致性，但是降低了写入性能，至少导致一个 TCP/IP 往返的延迟，可以理解为写放大。因此，半同步复制建议在低延时的网络中使用。
The performance impact of semisynchronous replication compared to asynchronous replication is the tradeoff for increased data integrity. The amount of slowdown is at least the TCP/IP roundtrip time to send the commit to the replica and wait for the acknowledgment of receipt by the replica.
之前遇到过相关案例，业务反馈多次出现写入慢，insert 用时 1 秒以上，查看错误日志显示原因是半同步复制超时。
2022-10-31 12:17:41 1915 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.266950, pos: 230357178), semi-sync up to file mysql-bin.266950, position 646767.
2022-10-31 12:17:41 1915 [Note] Semi-sync replication switched OFF.
2022-10-31 12:17:41 1915 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.266950, pos: 230360441), semi-sync up to file mysql-bin.266950, position 646767.
2022-10-31 12:17:41 1915 [Note] Semi-sync replication switched OFF.
2022-10-31 12:17:42 1915 [Note] Semi-sync replication switched ON with slave (server_id: 1682451620) at (mysql-bin.266950, 230394173)
2022-11-03 12:56:22 1915 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.267818, pos: 217044210), semi-sync up to file mysql-bin.267818, position 39797.
2022-11-03 12:56:22 1915 [Note] Semi-sync replication switched OFF.
2022-11-03 12:56:22 1915 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.267818, pos: 217045180), semi-sync up to file mysql-bin.267818, position 39797.
2022-11-03 12:56:22 1915 [Note] Semi-sync replication switched OFF.
2022-11-03 12:56:23 1915 [Note] Semi-sync replication switched ON with slave (server_id: 1682451620) at (mysql-bin.267818, 217064307)
根据叶老师的建议，异步复制本身就是有一定延迟，介意的话可以改为半同步复制。
因此，可以认为理论上半同步复制产生主从延迟的概率相对较低，原因是 binlog 已拉取到从库。
但是半同步复制也无法保证不会出现主从延迟，只保证 IO 线程拉取完成，不保证 SQL 线程回放完成，原因是应用 binlog 还是异步的。
主从 binlog 推拉
上文中提到，从库 System user 线程显示 Waiting for master to send event，表明作为从库 IO 线程已向主库发送请求，等待主库发送 event。
The “Waiting for master to send event” state shows that the slave IO thread sent a request for a new event, and is waiting for the event from the master.
那么，主从复制过程中 binlog 是主库 push 给从库，还是从库 pull 主库呢？
根据官方文档，每个从库连接到主库后从主库 pull binlog，而不是主库 push binlog 给从库。
Each replica that connects to the source requests a copy of the binary log. That is, it pulls the data from the source, rather than the source pushing the data to the replica.
不过，这两种方式有什么区别呢？
之前遇到过一个案例，上云同步数据过程中网络打满导致主从延迟，因此联系本地运维放宽网络限制。
网络问题首先需要明确的就是源与目标是从哪到哪，而网速也分上传与下载速度。
这种场景下，就有必要明确 binlog 是由从库 pull 主库，如果方向相反，放宽网络限制也无效。
小技巧
网速与带宽
网速根据数据传输的方向可以分为两种速度：
-
上传速度（上行带宽），设备可以将数据传输到互联网的速度； -
下载速度（下行带宽），设备可以从互联网接收数据的速度；
目前我们使用的 ADSL 是非对称的传输方式，一般下行速度大于上行速度。因为用户上网主要是从互联网下载数据，相比之下，上传数据要少很多。
需要注意的是带宽与网速的单位不同。
网络、网卡的带宽单位是 bit，网速的单位是 Byte。
两者一个小写，一个大写，因此通常分别称为小 B、大 B。
两者之间的关系是 1 Byte = 8 bit，因此理论上下载速度是网络带宽的 1/8。
比如上文中查看当前网卡每秒发出流量 4M 左右，因此上传速度 4M/s，对应带宽 32M。
从库位点坐标
文中通过对比 Master_Log_File（mysql-bin.018794） 与 Relay_Master_Log_File（mysql-bin.018784），发现 SQL 线程当前滞后 IO 线程 10 个 binlog 文件。
实际上，执行show slave status命令时，可以看到六个位点相关字段。
Master_Log_File: mysql-bin.062326
Read_Master_Log_Pos: 29877290
Relay_Log_File: relay-log.119185
Relay_Log_Pos: 29863173
Relay_Master_Log_File: mysql-bin.062326
Exec_Master_Log_Pos: 29862960
6 个位点相关字段中前 2个与 IO 线程有关，后 4 个与 SQL 线程有关。
| 字段 | 含义 |
|---|---|
| Master_Log_File | IO 线程拉取的 binlog 文件名 |
| Read_Master_Log_Pos | IO 线程拉取的 binlog 位点 |
| Relay_Log_File | SQL 线程执行的 relay log 文件名 |
| Relay_Log_Pos | SQL 线程执行的 relay log 位点 |
| Relay_Master_Log_File | SQL 线程执行的 binlog 文件名 |
| Exec_Master_Log_Pos | SQL 线程执行的 binlog 位点 |
SQL 线程有 4 个位点字段的原因是 relay log 中的位点与 binlog 中不一致，两者本质上是一样的。
参考英文介绍，可以更明确的看到 6 个位点字段的作用。
Master_Log_File: mysql-bin.001363 - master binlog filename from which the I/O thread is currently reading.
Read_Master_Log_Pos: 867649780 - position in master binlog file up to which the I/O thread has read.
Relay_Log_File: slave-relay.000453 - relay log filename from which the SQL thread is currently reading and executing.
Relay_Log_Pos: 867649926 - position in relay log file up to which the SQL thread has read and executed.
Relay_Master_Log_File: mysql-bin.001363 - binary log filename containing the most recent event executed by the SQL thread.
Exec_Master_Log_Pos: 867649780 - position in master binlog file to which the SQL thread has read and executed
如果将文件名与字节数（position）组成坐标（coordinates），可以将 6 个位点字段分为以下三类坐标：
-
(Master_Log_File, Read_Master_Log_Pos) – this pair of coordinates show information about slave I/O thread state. Slave I/O thread is reading from binlog mysql-bin.001363 and it has read up to 867649780 position in that file. -
(Relay_Log_File, Relay_Log_Pos) – this pair of coordinates show information about slave SQL thread state from relay log perspective. Slave SQL thread is reading from relay file slave-relay.000453 and has read and executed statements up to 867649926 position in that file. -
(Relay_Master_Log_File, Exec_Master_Log_Pos) – this pair of coordinates show information about slave SQL thread state from Master binlog perspective. Slave SQL thread is reading from relay file slave-relay.000453 and has read and executed statements up to 867649926 position in that file. This correspond to mysql-bin.001363 binlog file and position 867649780 in master server. That is if we start reading from master binlog file pointed by Relay_Master_Log_File in position starting from Exec_Master_Log_Pos and if we start reading from slave relay log file pointed by Relay_Log_File starting from position Relay_Log_Pos we should get the same information.
因此，处理复制中断问题过程中，如果需要重新搭建复制，指定的开始位点需要是从库 SQL 线程执行到的位点，即 (Relay_Master_Log_File, Exec_Master_Log_Pos) 坐标。
由于change master之前需要执行reset slave，因此 relay log 中接收到的未执行的 binlog 被删除，重新接收不会导致 binlog 重复消费。
如果指定 IO 线程执行到的位点即 (Master_Log_File, Read_Master_Log_Pos)，如果 SQL 线程落后于 IO 线程，将导致数据丢失。
主从延迟的原因
具体可以分为两类：
-
SQL 线程慢，如大事务、DDL、从库回放慢； -
IO 线程慢，如网络延迟、IO 压力大。
因此，发现主从延迟时需要首先验证瓶颈出现在 IO 线程还是 SQL 线程，针对性解决。
半同步 debug 日志
rpl_semi_sync_master_trace_level 参数用于控制主库半同步复制的 debug trace level，共支持四种级别：
-
1 = general level (for example, time function failures) -
16 = detail level (more verbose information)，debug 值 -
32 = net wait level (more information about network waits)，默认值 -
64 = function level (information about function entry and exit)
日常工作中，如果需要验证半同步复制对于性能的影响，比如写入变慢时，可以通过调整该参数查看 debug 日志，包括从库每次响应用时。不过开启后，日志量会很大，因此不建议长时间开启。
mysql> set global rpl_semi_sync_master_trace_level=16;
Query OK, 0 rows affected (0.03 sec)
结论
级联复制的两个从库均出现主从延迟，其中物理机到 RDS 是异步复制，RDS 之间是半同步复制。
经查看，二级从库与一级从库之间无延迟，一级从库的 SQL 线程落后 IO 线程 10 个 binlog 文件，因此瓶颈出现在 SQL 线程。从库已请求主库 binlog，主库也已发送，从库也收到了，但是回放产生延迟。
此外，一级从库的 SQL 线程显示 Waiting for semi-sync ACK from slave，表明作为主库等待从库半同步响应，因此怀疑是半同步复制导致主从延迟。
开启 debug trace 后发现，半同步复制延迟平均 3ms 左右。
关闭一级从库上关闭作为主库的半同步复制后发现，写入速度涨了将近十倍，主从延迟在半小时内从峰值 40057s（约11h）恢复。
因此：
-
半同步复制提高了数据一致性，但是降低了写入性能，导致写放大； -
3ms 的延迟对于半同步复制来说，已经很大了； -
每个从库连接到主库后从主库 pull binlog，而不是主库 push binlog 给从库； -
带宽的单位是 bit，网速的单位是 Byte。两者一个小写，一个大写，因此通常分别称为小 B、大 B，1 Byte = 8 bit。讨论网速时需要注意使用的单位； -
从库位点坐标可以分为以下三类：
| 坐标 | 线程 | 日志类型 |
|---|---|---|
| (Master_Log_File, Read_Master_Log_Pos) | IO | binlog |
| (Relay_Log_File, Relay_Log_Pos) | SQL | relay-log |
| (Relay_Master_Log_File, Exec_Master_Log_Pos) | SQL | binlog |
其中，如果需要重新搭建复制，指定的开始位点需要是从库 SQL 线程执行到的位点，即 (Relay_Master_Log_File, Exec_Master_Log_Pos) 坐标。
待办
-
半同步复制原理 -
半同步复制相关参数，重点 rpl_semi_sync_master_wait_point -
组提交原理 -
主从延迟计算公式 -
主从延迟反复跳动原因分析 -
Waiting for dependent transaction to commit
参考教程
-
Replication Source Thread States
-
MySQL Replication Troubleshooting: Q & A
-
MySQL Document: Semisynchronous Replication Administrative Interface
-
Understanding MySQL replication coordinates
-
主从同步中的关键技术解析
-
《叶问》第2期：你遇到过哪些原因造成MySQL异步复制延迟？
原文始发于微信公众号（丹柿小院）：MySQL 半同步复制导致主从延迟
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/178634.html
