I
Member
主从延迟报警来了，别急着加机器，按这个顺序查一遍，多数情况半小时内能定位。
第一步，确认延迟的量级和真实性。Seconds_Behind_Master 是 SQL 线程的时间差，大事务提交瞬间会虚高。更准的是 pt-heartbeat：在主库写心跳表，从库读时间差，这才是业务视角的真实延迟。
第二步，分清是 IO 线程慢还是 SQL 线程慢。IO 线程慢（Master_Log_File 落后）查网络和主库 binlog 写入；SQL 线程慢（Relay_Log 落后）才是回放瓶颈，大部分延迟属于后者。
第三步，找 SQL 线程慢的根因。排前三的：大事务（一个事务几十万行，回放时单线程卡死）、无主键/无索引的大表更新（row 模式下全表扫描）、从库上跑了慢查询或备份任务抢 IO。用 mysqlbinlog 抽一段延迟时段的 binlog 看看事务大小，基本一目了然。
第四步，并行复制调优。5.7 之后按 LOGICAL_CLOCK 并行，slave_parallel_workers 先给到 CPU 核数，观察 worker 队列是否打满。如果延迟时段 binlog 里全是单库单表热点，并行也救不了，得从业务分片想办法。
第五步，查从库自身。只读业务压到从库上、磁盘 IO 打满、从库配置低于主库，这些都会放大延迟。从库的配置我习惯和主库对等，省得背锅。
你们主从延迟的报警阈值设多少？遇到过并行复制也压不住的热点库吗，最后怎么解的？
第一步，确认延迟的量级和真实性。Seconds_Behind_Master 是 SQL 线程的时间差，大事务提交瞬间会虚高。更准的是 pt-heartbeat：在主库写心跳表，从库读时间差，这才是业务视角的真实延迟。
第二步，分清是 IO 线程慢还是 SQL 线程慢。IO 线程慢（Master_Log_File 落后）查网络和主库 binlog 写入；SQL 线程慢（Relay_Log 落后）才是回放瓶颈，大部分延迟属于后者。
第三步，找 SQL 线程慢的根因。排前三的：大事务（一个事务几十万行，回放时单线程卡死）、无主键/无索引的大表更新（row 模式下全表扫描）、从库上跑了慢查询或备份任务抢 IO。用 mysqlbinlog 抽一段延迟时段的 binlog 看看事务大小，基本一目了然。
第四步，并行复制调优。5.7 之后按 LOGICAL_CLOCK 并行，slave_parallel_workers 先给到 CPU 核数，观察 worker 队列是否打满。如果延迟时段 binlog 里全是单库单表热点，并行也救不了，得从业务分片想办法。
第五步，查从库自身。只读业务压到从库上、磁盘 IO 打满、从库配置低于主库，这些都会放大延迟。从库的配置我习惯和主库对等，省得背锅。
你们主从延迟的报警阈值设多少？遇到过并行复制也压不住的热点库吗，最后怎么解的？