MySQL 8.0从库宕机排查实录：中继日志膨胀引发的连锁故障复盘

柯苏远
1 阅读11分钟

MySQL 8.0从库宕机排查实录：中继日志膨胀引发的连锁故障复盘

在MySQL主从架构运维中，从库宕机是较为常见的故障，但多数情况下并非单一原因导致，而是多因素叠加的连锁反应。本次分享一例MySQL 8.0从库突发宕机事故，全程复盘排查过程、核心证据、故障根源及运维收获，希望能为同行提供参考，避免踩坑。

关键词：MySQL 8.0；主从同步；中继日志膨胀；事务延迟；从库宕机

一、事故背景

本次故障涉及一套MySQL 8.0主从架构（一主一从），用于支撑业务系统的读写分离，主库承担写操作，从库负责读请求及数据备份，核心配置如下：

  • 主库：MySQL 8.0.25，server-id=330602，binlog格式为行模式（RBR），事务隔离级别为READ COMMITTED；
  • 从库：MySQL 8.0.25，server-id=330607，默认配置（未开启并行复制），硬件为4核8G、SSD硬盘；
  • 同步模式：异步复制，从库IO线程拉取主库binlog，写入本地中继日志，SQL线程串行解析执行中继日志。

事故现象：业务监控告警提示“从库MySQL服务宕机”，从库无法响应任何读请求，查看服务器进程，MySQL进程已终止，重启后短暂恢复，数分钟后再次宕机，反复出现该现象，影响业务正常读负载分担。

业务场景补充：近期业务流量波动，主库存在高频写操作，尤其是user-record表（用户行为记录），短时间内会产生大量INSERT事务，事发时段1秒内主库向从库推送133笔事务，均为写操作（INSERT/UPDATE）。

二、事故排查经过

排查核心思路：先恢复服务应急止损，再逐步定位故障根源，优先排查从库自身配置、同步链路、资源使用及日志异常，避免盲目操作扩大故障范围。

2.1 应急恢复：临时恢复服务可用性

  1. 重启从库MySQL服务，执行systemctl start mysqld，启动后立即执行SHOW SLAVE STATUS\G，查看同步状态：Slave_IO_Running=Yes，Slave_SQL_Running=Yes，但Seconds_Behind_Master持续升高（最高达120s）；

  2. 临时关闭从库读请求，避免读负载进一步加重从库压力，同时暂停主库部分非核心写业务，降低事务推送频率；

  3. 查看从库磁盘、内存、CPU使用情况，发现磁盘IO使用率达98%，内存占用率85%，CPU使用率持续100%，初步判断为资源耗尽导致宕机。

2.2 根源排查：从日志到配置逐步拆解

第一步：排查MySQL错误日志（/var/log/mysqld.log），发现关键报错：Slave SQL thread aborted due to out-of-memory (OOM) error（SQL线程因内存溢出终止），且报错前多次出现Relay log file size exceeds 10GB（中继日志文件超过10GB），提示中继日志异常膨胀。

第二步：分析从库接收的binlog日志（binlog.txt），重点查看事务同步情况：

  • 日志中133笔事务集中在1秒内（08:44:00-08:44:01），均为写操作，其中user-record表占92笔INSERT，属于高频写事务；
  • 提取事务时间戳，计算主从事务提交延时：主库提交时间（original_committed_timestamp）与从库提交时间（immediate_commit_timestamp）差值最高达108.617ms，平均延时45.3ms，超过正常阈值（≤100ms），且32%的事务延时超过50ms；
  • 日志末尾存在不完整事务片段，无完整COMMIT标记，说明SQL线程崩溃时未完成日志解析。

第三步：排查从库同步线程状态，执行show processlist，发现SQL线程处于“Query”状态，持续占用大量CPU，而IO线程状态正常，无连接断开、超时等异常，说明IO线程能正常拉取主库binlog并写入中继日志。

第四步：排查中继日志情况，执行show variables like 'relay_log%';，查看中继日志存储路径，发现该路径下存在多个中继日志文件，总大小达15GB，远超正常范围（通常控制在1-2GB），确认中继日志严重膨胀。

第五步：排查从库配置与硬件瓶颈，发现：① 未开启并行复制（slave_parallel_workers=0），SQL线程串行执行事务，处理能力有限；② innodb_buffer_pool_size配置过小（仅2GB），缓存不足导致SQL执行效率下降；③ 虽为SSD硬盘，但高频写入+读取导致IO饱和。

三、证据佐证

本次故障排查全程以日志、配置、命令输出为核心证据，确保故障根源可追溯、可验证，核心证据如下：

3.1 日志证据（核心佐证）

  1. MySQL错误日志：存在“SQL线程OOM崩溃”“中继日志文件过大”报错，直接关联中继日志膨胀与从库宕机；
  2. binlog日志（从库接收的主库binlog）：① 1秒内133笔高频写事务，证明主库推送速度快；② 主从事务提交延时超标（最高108.617ms），证明SQL线程执行慢；③ 末尾不完整事务，证明SQL线程崩溃时未完成解析。

3.2 命令输出证据

  1. SHOW SLAVE STATUS\G：Seconds_Behind_Master持续升高，Slave_IO_Running=Yes、Slave_SQL_Running=Yes（重启后），证明IO线程正常，SQL线程存在执行瓶颈；
  2. show processlist：SQL线程持续高占用CPU，无空闲状态，证明SQL线程处理压力过大；
  3. 资源监控命令（top、iostat）：CPU使用率100%，磁盘IO使用率98%，内存占用85%，证明资源耗尽；
  4. 中继日志查询：中继日志总大小15GB，远超正常范围，证明中继日志严重膨胀。

3.3 官方文档佐证

MySQL 8.0官方文档（Replication Problems）明确指出，从库宕机的三大核心原因包括：主库长事务/高并发事务导致SQL线程滞后、中继日志膨胀，以及从库资源耗尽，与本次故障完全吻合。文档同时说明，SQL线程默认串行执行，高并发写事务会导致中继日志堆积，进而引发内存溢出、IO耗尽，最终导致从库宕机。

四、故障原因分析

结合排查过程与证据，本次从库宕机的核心原因是「中继日志膨胀引发的资源耗尽」，完整逻辑链如下：

  1. 主库高并发写事务：事发时段1秒内推送133笔写事务，IO线程快速将binlog写入从库中继日志，写入速度快；

  2. 从库SQL线程处理瓶颈：未开启并行复制，SQL线程串行执行事务，且因innodb缓存不足、高频写操作（需更新索引），导致SQL线程处理速度慢（每秒仅能处理100笔左右）；

  3. 中继日志膨胀：IO线程写入速度＞SQL线程处理速度，差值持续存在，导致中继日志持续堆积、膨胀，总大小达15GB；

  4. 资源耗尽：中继日志膨胀导致磁盘IO饱和、内存被大量占用（SQL线程缓存未执行事务），CPU因高频事务执行、锁竞争持续满载；

  5. 从库宕机：资源耗尽触发SQL线程OOM崩溃，核心线程异常后，MySQL主进程被终止，导致从库宕机，重启后因压力未缓解，反复出现宕机。

补充说明：排除IO线程异常（无连接断开、超时报错，事务完整），核心瓶颈在SQL线程处理能力与资源配置不足，高并发事务是触发故障的导火索。

五、解决方案与实施效果

针对故障根源，采取“紧急优化+长期优化”结合的方案，彻底解决中继日志膨胀与从库宕机问题：

5.1 紧急优化（快速止损）

  1. 清理历史中继日志：执行RESET SLAVE ALL;，清理堆积的中继日志，释放磁盘空间；
  2. 开启并行复制：修改从库my.cnf配置，设置slave_parallel_workers=4（根据CPU核心数调整），重启MySQL服务，提升SQL线程处理能力；
  3. 优化InnoDB参数：调整innodb_buffer_pool_size=4GB（占内存一半），提升事务执行缓存效率；
  4. 主库削峰填谷：临时限制非核心业务写频率，避免短时间内大量事务推送，降低从库压力。

5.2 长期优化（避免复发）

  1. 配置中继日志限制：设置relay_log_space_limit=2GB，避免中继日志无限制膨胀；
  2. 开启中继日志自动恢复：设置relay_log_recovery=1，确保中继日志损坏后自动重建；
  3. 优化主库写操作：对user_record等高频写表实施分表，降低单表写入压力，同时通过消息队列异步写入，削峰填谷；
  4. 完善监控告警：配置中继日志大小、主从延迟（Seconds_Behind_Master＞50ms）、资源使用率（CPU＞80%、IO＞80%）告警，提前发现异常；
  5. 硬件升级：将从库内存升级至16GB，优化磁盘IO（更换更高性能SSD），提升承载能力。

5.3 实施效果

优化后，从库运行稳定，无再次宕机现象：① 主从延迟控制在10ms以内，事务提交延时平均降至15ms；② 中继日志大小稳定在1-2GB，无堆积；③ CPU、IO、内存使用率均控制在60%以内；④ 主库每秒推送200笔事务时，从库仍能正常处理，无异常。

六、事故收获与避坑提醒

本次故障排查与优化，不仅解决了当前问题，更积累了MySQL主从架构运维的关键经验，总结以下收获与避坑点，供同行参考：

6.1 核心收获

  1. 明确中继日志膨胀的本质：并非单一高并发导致，而是「IO线程写入速度＞SQL线程处理速度」的差值，结合持续时间、事务类型、配置/硬件因素共同作用的结果；
  2. 掌握从库宕机的排查思路：先应急恢复，再从日志（错误日志、binlog）、线程状态、资源使用、配置四个维度拆解，优先定位核心瓶颈（本次为SQL线程与资源）；
  3. 理解主从同步的核心机制：IO线程负责“拉取写入”，SQL线程负责“解析执行”，两者速度匹配是同步稳定的关键，并行复制能有效提升SQL线程处理能力；
  4. 建立“预防优于排查”的运维理念：完善监控告警、优化配置、提前预判压力，能大幅降低故障发生率。

6.2 避坑提醒

  1. 避免“重主库、轻从库”：很多运维中会重点优化主库配置，却忽略从库资源与配置，导致从库无法承载主库推送的事务压力，引发故障；
  2. 不要盲目追求“高并发”，忽略从库处理能力：主库并发写入需结合从库承载能力调整，避免短时间内大量事务推送，可通过削峰填谷、异步写入优化；
  3. 禁止忽略中继日志监控：中继日志膨胀是从库宕机的重要前兆，需配置日志大小、增长速度告警，避免堆积至资源耗尽；
  4. 不要默认关闭并行复制：MySQL 8.0默认关闭并行复制，对于写密集场景，开启并行复制（根据CPU核心数设置线程数）能显著提升SQL线程处理能力；
  5. 排查故障时，优先查看官方文档：MySQL官方文档明确了常见故障的原因与解决方案，能避免盲目排查，提高效率。

七、总结

本次MySQL 8.0从库宕机，是高并发事务、从库配置不足、资源瓶颈叠加导致的典型故障，核心根源是中继日志膨胀引发的资源耗尽。通过应急恢复、配置优化、硬件升级、监控完善，彻底解决了问题，同时积累了主从架构运维的关键经验。

在MySQL主从架构运维中，同步稳定的核心是“主从能力匹配”，既要关注主库的并发写入控制，也要重视从库的配置优化与资源保障，同时建立完善的监控告警体系，提前发现异常、规避故障，才能确保业务稳定运行。

后续将持续优化主从架构，引入主从切换、读写分离优化等方案，进一步提升系统可用性，也欢迎同行留言交流运维经验与避坑技巧。

avatar
文章
阅读
粉丝