1. PolarDB从节点故障排查实录当备库突然罢工时那天早上刚到工位监控系统就疯狂报警——PolarDB集群的从节点全部处于不可用状态。主库扛着所有读写压力CPU已经飙到90%。作为DBA这种场景就像外科医生遇到病人大出血必须快速止血。下面分享这次故障的完整排查过程以及从中学到的宝贵经验。PolarDB作为阿里云自研的云原生数据库采用存储计算分离架构。其一主多从的设计本应提供高可用保障但当所有从节点同时失效时系统就进入了危险的单点模式。这种情况往往比主库宕机更棘手因为主库仍在服务但系统的容灾能力已归零。2. 故障现象与初步诊断2.1 异常症状速描通过SHOW SLAVE STATUS命令查看复制状态所有从节点均显示Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: Client requested master to start replication from position file size更诡异的是主库的binlog文件完好无损但从库却坚称主库的binlog位置不合法。这种认知失调通常意味着复制坐标的元数据出现了混乱。2.2 关键线索挖掘使用SHOW BINARY LOGS对比主从库的binlog序列主库 mysql-bin.000017 (1.2GB) mysql-bin.000018 (800MB) 从库复制坐标 Relay_Master_Log_File: mysql-bin.000019 Exec_Master_Log_Pos: 1073741824问题浮出水面——从库试图读取根本不存在的mysql-bin.000019文件。这种时空错乱往往由以下原因导致主库binlog被手动清理排除自动清理策略未触发主库异常重启导致binlog索引文件损坏需验证网络分区期间发生了脑裂需检查时间线3. 根因分析与数据抢救3.1 元数据损坏验证检查主库的binlog索引文件cat /polardb_data/binlog.index发现文件末尾存在异常的空行和重复条目。这种腐败通常发生在存储层异常断电时PolarDB的共享存储架构使得此类问题会同时影响所有节点。3.2 事务拆分陷阱故障时间点恰逢业务执行了大事务拆分Transaction Split。PolarDB的优化器将单个大事务拆分为多个并行子事务时如果遇到如下配置loose_transaction_split_mode OPTIMISTIC可能导致binlog事件顺序与实际提交顺序出现偏差。当主库崩溃恢复时这种差异会被放大。血泪教训在跨AZ部署中务必设置transaction_split_mode CONSERVATIVE4. 完整恢复方案4.1 紧急恢复步骤主库锁定防止数据不一致FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only ON;从库重建# 使用PolarDB克隆功能快速重建 pcl restore-from-backup --instance-idslave01 --sourcemaster --point-in-time2024-02-20 09:00:00复制链路重置STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000017, MASTER_LOG_POS4; START SLAVE;4.2 防复发配置优化调整binlog保留策略binlog_expire_logs_seconds 604800 # 7天 binlog_space_usage_limit 80G启用增强型复制校验SET GLOBAL slave_checkpoint_group 512; SET GLOBAL slave_parallel_workers 16;5. 深度避坑指南5.1 监控项黄金组合复制延迟微分不要只看Seconds_Behind_Master要监控rate(mysql_slave_status_exec_master_log_pos[1m]) - rate(mysql_binlog_position[1m])元数据健康度定期校验pcl verify-binlog-index --full-scan5.2 大事务处理铁律超过500MB的事务必须拆分拆分后子事务大小控制在50MB以内使用显式XA TRANSACTION确保原子性6. 高阶排查工具链6.1 PolarDB诊断视图SELECT * FROM information_schema.alisql_cluster_health; SELECT * FROM information_schema.alisql_cluster_events WHERE event_time NOW() - INTERVAL 1 HOUR;6.2 二进制日志解析术使用mysqlbinlog的进阶技巧mysqlbinlog --start-datetime2024-02-20 08:00:00 \ --stop-datetime2024-02-20 09:00:00 \ --base64-outputDECODE-ROWS \ --verbose mysql-bin.000017 | grep -A 30 Transaction Split这次故障给我的最大启示是云数据库不是银弹。即使像PolarDB这样的托管服务也需要DBA深入理解其内部机制。现在我们的巡检清单上新增了binlog索引文件CRC校验项毕竟预防永远比抢救来得轻松。