蝨孨槑黽1. PolarDB从节点故障排查实战指南
上周五凌晨2点37分，我正喝着第三杯咖啡盯着监控大屏，突然收到PolarDB集群从节点失联的告警。这种"开年就丢人"的运维事故，相信各位DBA同行都深有体会。今天我们就来完整复盘这个经典故障案例，手把手教你如何快速定位和解决PolarDB从节点不可用问题。
PolarDB作为阿里云自研的云原生数据库，其"一主多读"架构在业务高峰期能有效分担主库压力。但当从节点罢工时，不仅会导致读请求全部回落到主库，更可能因复制延迟引发数据一致性问题。下面这个排查流程，是我在近三年处理过17次类似故障后总结的黄金法则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 故障现象与初步诊断
2.1 典型症状识别
当出现以下任一情况时，你的PolarDB从节点可能已经"躺平"：
- 监控面板显示
Seconds_Behind_Master持续增长 - 应用日志频繁报错"Read-only connection refused"
- 控制台从节点状态显示为"不可用"或"同步异常"
- 主库
SHOW PROCESSLIST中可见大量未完成的复制线程
重要提示：从节点故障初期往往表现为查询响应变慢，容易被误判为网络问题。建议在业务低峰期定期执行
SELECT 1测试从库基础可用性。
2.2 第一响应检查清单
接到报警后，请立即按此顺序检查（完整命令见附录）：
- 从节点基础状态：
systemctl status polardb - 磁盘空间占用：
df -h /polardb_data - 内存使用情况：
free -m - 网络连通性：
ping <主节点内网IP> - 复制线程状态：
SHOW SLAVE STATUS\G
上周的故障案例中，我们就是在执行到第2步时发现数据目录所在磁盘已100%占满。这是最常见的"低级错误"之一——监控系统漏配了数据盘告警阈值。
3. 深度故障排查手册
3.1 磁盘空间问题处理
场景还原：
某电商大促期间，从节点突然不可用。检查发现500GB的数据盘仅剩8MB空间，原因是开启了全量SQL审计日志却未配置日志轮转。
解决方案：
bash复制# 紧急释放空间（慎用！）
rm -f /polardb_data/log/audit.log.*
# 永久解决方案
vim /etc/logrotate.d/polardb
添加以下配置：
/polardb_data/log/audit.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
}
避坑指南：
- 数据盘建议保留至少20%空闲空间
- 定期检查
innodb_temp_data_file_path定义的临时表空间大小 - 使用
du -sh * | sort -rh快速定位大文件
3.2 复制冲突解决方案
当出现"Duplicate entry"或"Can't find record"等复制错误时，按此流程处理：
-
确认冲突类型：
sql复制SHOW SLAVE STATUS\G 查看Last_Error字段 -
临时跳过错误（仅限非关键数据）：
sql复制STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE; -
彻底修复方案：
sql复制-- 在主库查找冲突数据 SELECT * FROM problematic_table WHERE id = [冲突ID]; -- 在从库手动修复 REPLACE INTO problematic_table VALUES (...);
3.3 网络隔离故障处理
某金融客户遇到过经典案例：安全组规则变更后，从节点无法连接主库的3306端口。诊断步骤：
-
从节点执行：
bash复制
telnet <主节点IP> 3306 -
主节点检查：
bash复制
iptables -L | grep 3306 -
云平台安全组检查：
- 确认入方向允许从节点IP访问
- 检查网络ACL规则
4. 高级恢复技巧
4.1 无损重建从节点
当从节点严重损坏时，推荐使用物理备份重建：
bash复制# 在主库创建备份账号
CREATE USER 'backup_user'@'%' IDENTIFIED BY 'ComplexP@ssw0rd';
GRANT SELECT, RELOAD, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO 'backup_user'@'%';
# 使用PolarDB物理备份工具
./polardb_backup \
--host=<主库IP> \
--user=backup_user \
--password=ComplexP@ssw0rd \
--output=/backup/polardb_full \
--parallel=8
# 在从节点恢复
./polardb_restore \
--input=/backup/polardb_full \
--datadir=/polardb_data \
--parallel=8
4.2 复制延迟优化方案
针对高频出现的Seconds_Behind_Master问题，可实施以下优化：
-
参数调优：
ini复制[mysqld] slave_parallel_workers = 8 slave_parallel_type = LOGICAL_CLOCK slave_preserve_commit_order = ON -
硬件升级：
- 从节点配置不低于主节点的IOPS性能
- 建议使用ESSD PL3云盘
-
架构优化：
sql复制-- 对大表添加合适索引 ALTER TABLE large_table ADD INDEX idx_optimize (time_column);
5. 预防性维护策略
5.1 监控体系搭建
推荐部署以下监控指标（采样间隔≤1分钟）：
| 指标名称 | 告警阈值 | 检查方式 |
|---|---|---|
| 复制延迟 | > 60秒 | SHOW SLAVE STATUS |
| 从库线程状态 | != Yes | SHOW SLAVE STATUS |
| 数据盘使用率 | > 80% | df -h |
| 内存使用率 | > 90% | free -m |
| 主从数据一致性 | 存在差异 | pt-table-checksum |
5.2 自动化处理脚本
部署以下脚本到crontab（每日执行）：
bash复制#!/bin/bash
# 检查复制状态并自动告警
STATUS=$(mysql -uroot -p$PASSWORD -e "SHOW SLAVE STATUS\G" | grep -E "Running|Seconds_Behind")
if ! grep -q "Yes" <<< "$STATUS"; then
curl -X POST "https://alert-api.example.com" \
-d '{"title":"PolarDB复制异常","content":"$STATUS"}'
fi
6. 附录：常用诊断命令速查表
sql复制-- 查看所有从节点状态
SELECT * FROM performance_schema.replication_group_members;
-- 检查未完成事务
SELECT * FROM information_schema.innodb_trx WHERE trx_mysql_thread_id IN
(SELECT id FROM processlist WHERE command = 'Binlog Dump');
-- 查看当前复制过滤规则
SHOW SLAVE STATUS\G
经过这次故障复盘，我总结出三条血泪经验：第一，监控覆盖率比监控精度更重要；第二，任何配置变更必须双人复核；第三，凌晨处理数据库问题前，请先确保自己完全清醒。