1. PolarDB从节点故障排查实战从丢人到大能人的进阶之路那天早上刚到公司就收到告警PolarDB集群的从节点挂了。作为DBA最怕的就是开年第一周就遇到生产环境故障这可不就是标题说的开年我就丢人么不过处理完这个case后我反而积累了一套完整的PolarDB从节点故障排查方法论今天就把这个丢人经历变成技术干货分享给大家。PolarDB作为阿里云自研的云原生数据库兼容MySQL和PostgreSQL协议在企业级应用中越来越常见。但就像所有分布式系统一样主从架构下的从节点故障是运维过程中最高频的问题之一。本文将以我实际遇到的故障为例手把手带你走通从节点故障的完整排查流程包含20个关键检查点和5种典型故障场景的修复方案。2. 从节点基础架构与故障分类2.1 PolarDB主从架构核心原理PolarDB采用计算与存储分离的架构设计其主从节点有几个关键特点共享存储所有节点访问同一份数据存储PolarStore读写分离主节点可读写从节点默认只读日志同步通过物理复制Redo Log保持数据一致性代理层通过PolarProxy实现自动读写分离当出现从节点不可用时通常表现为以下几种症状应用连接从节点时返回ERROR 1290 (HY000)错误监控显示从节点复制延迟不断增大从节点进程崩溃或处于恢复状态主从节点数据出现不一致2.2 从节点故障的五种典型场景根据阿里云官方文档和我的实战经验从节点故障主要分为以下类型故障类型发生频率典型表现影响程度网络分区★★★★☆复制中断连接超时高存储异常★★☆☆☆I/O错误数据损坏严重配置错误★★★★★启动失败参数冲突中资源不足★★★☆☆OOMCPU 100%中版本不兼容★☆☆☆☆协议错误功能异常高3. 故障排查六步法实战3.1 第一步基础状态检查通过PolarDB控制台或命令行工具执行基础诊断# 查看节点状态 SHOW PROCESSLIST; SHOW SLAVE STATUS\G # 检查引擎状态 SELECT * FROM information_schema.innodb_trx; SHOW ENGINE INNODB STATUS;重点关注以下字段Slave_IO_RunningI/O线程状态Slave_SQL_RunningSQL线程状态Seconds_Behind_Master复制延迟Last_IO_Error最后I/O错误信息提示如果Slave_IO_Running为Connecting状态通常说明网络连接存在问题3.2 第二步日志分析三板斧错误日志分析# 查看PolarDB错误日志 grep -E ERROR|WARNING /polardb/log/mysql-error.log常见错误模式[ERROR] Slave I/O: error connecting to master→ 网络问题[ERROR] Slave SQL: Could not execute Write_rows event→ 数据冲突[Warning] Slave: ... duplicate entry ...→ 主键冲突慢查询日志检查-- 开启慢日志记录 SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;审计日志追踪# 查看最近的操作记录 cat /polardb/log/audit.log | tail -n 503.3 第三步资源瓶颈诊断使用Linux工具检查系统资源# 实时监控按1查看CPU核数 top -c vmstat 1 10 # 内存检查 free -h cat /proc/meminfo | grep -E MemFree|Swap # 磁盘I/O iostat -x 1 5 df -hT /polardb关键阈值参考CPU利用率持续80%内存Swap使用1GB磁盘util90%3.4 第四步复制链路验证测试主从节点间的网络连通性# 测试端口连通性 telnet master_ip 3306 nc -zv master_ip 3306 # 测量网络延迟 ping -c 10 master_ip mtr --report master_ip如果发现网络问题需要检查安全组规则入方向需开放3306端口VPC路由表配置网络ACL设置3.5 第五步数据一致性校验使用pt-table-checksum工具进行校验pt-table-checksum \ --hostmaster_ip \ --usercheck_user \ --passwordxxx \ --databases目标库 \ --replicatepercona.checksums然后通过pt-table-sync修复差异pt-table-sync \ --replicatepercona.checksums \ --sync-to-master \ hslave_ip,ucheck_user,pxxx警告执行同步前务必先备份数据3.6 第六步故障场景处置方案根据不同的故障类型采取对应的恢复措施场景1网络中断-- 临时解决方案跳过当前错误 STOP SLAVE; SET GLOBAL sql_slave_skip_counter 1; START SLAVE; -- 永久解决方案配置重试参数 CHANGE MASTER TO MASTER_RETRY_COUNT86400, MASTER_CONNECT_RETRY10;场景2数据冲突-- 找出冲突数据 SHOW SLAVE STATUS\G -- 根据Last_SQL_Error定位冲突行 -- 解决方案A删除冲突数据谨慎 DELETE FROM 表 WHERE id冲突ID; -- 解决方案B重建复制关系 STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO ...; START SLAVE;场景3存储损坏# 使用PolarDB的物理备份恢复 rdsadmin restore_database \ -i 备份ID \ -t 时间点 \ -d 目标实例4. 预防性运维策略4.1 监控体系搭建建议推荐部署以下监控项以Prometheus为例# metrics示例 - name: polar_replication rules: - alert: ReplicationDown expr: mysql_slave_status_slave_io_running 0 or mysql_slave_status_slave_sql_running 0 for: 1m labels: severity: critical annotations: summary: PolarDB复制中断 (instance {{ $labels.instance }}) description: 从节点复制已停止超过1分钟4.2 自动化运维脚本示例定期检查复制状态的Python脚本import pymysql import smtplib from email.mime.text import MIMEText def check_replication(host, user, password): conn pymysql.connect(hosthost, useruser, passwordpassword) try: with conn.cursor() as cursor: cursor.execute(SHOW SLAVE STATUS) slave_status dict(zip( [col[0] for col in cursor.description], cursor.fetchone() )) alert False if slave_status[Slave_IO_Running] ! Yes: alert True send_alert(IO线程停止, slave_status[Last_IO_Error]) if slave_status[Slave_SQL_Running] ! Yes: alert True send_alert(SQL线程停止, slave_status[Last_SQL_Error]) return alert finally: conn.close() def send_alert(subject, content): msg MIMEText(content) msg[Subject] f[PolarDB告警] {subject} msg[From] alertexample.com msg[To] dba-teamexample.com with smtplib.SMTP(smtp.example.com) as server: server.send_message(msg)4.3 配置优化参数推荐在my.cnf中添加以下参数可增强从节点稳定性[mysqld] # 复制配置 slave_parallel_workers8 slave_parallel_typeLOGICAL_CLOCK slave_preserve_commit_orderON # 资源限制 slave_max_allowed_packet1G slave_net_timeout60 # 错误处理 slave_exec_modeIDEMPOTENT slave_transaction_retries105. 疑难问题解决方案5.1 典型错误代码处理手册错误代码原因分析解决方案1236binlog位置无效重新配置复制起点1062主键冲突跳过或修复冲突数据1032行不存在检查数据一致性2003连接拒绝检查网络和权限1317查询中断调整wait_timeout参数5.2 从节点重建标准流程当从节点无法修复时重建步骤在主节点创建备份FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS; -- 记录binlog位置 UNLOCK TABLES;在从节点执行# 清理旧数据 service mysql stop rm -rf /polardb/data/*使用物理备份恢复xtrabackup --backup --target-dir/tmp/backup xtrabackup --prepare --target-dir/tmp/backup xtrabackup --copy-back --target-dir/tmp/backup重新配置复制CHANGE MASTER TO MASTER_HOST主节点IP, MASTER_USERrepl, MASTER_PASSWORD密码, MASTER_LOG_FILE记录的binlog文件, MASTER_LOG_POS记录的binlog位置; START SLAVE;6. 深度优化技巧6.1 并行复制优化实战通过调整以下参数提升复制性能-- 查看当前并行复制状态 SHOW VARIABLES LIKE slave_parallel%; -- 动态调整worker数量 SET GLOBAL slave_parallel_workers16; -- 监控worker利用率 SELECT THREAD_ID, NAME FROM performance_schema.threads WHERE NAME LIKE %worker%;6.2 大事务处理方案对于超过1GB的大事务拆分事务将大事务拆分为多个小事务调整参数slave_max_allowed_packet2G slave_pending_jobs_size_max2G使用GTID跳过STOP SLAVE; SET GLOBAL.gtid_purged需要跳过的GTID; START SLAVE;6.3 从节点读写分离优化在应用层实现智能路由class DBRouter: def db_for_read(self, model, **hints): if hints.get(force_write): return master return random.choice([slave1, slave2]) def db_for_write(self, model, **hints): return master这次故障排查经历让我深刻体会到PolarDB从节点问题看似简单实则涉及网络、存储、配置、资源等多个维度。掌握系统化的排查方法比记住具体命令更重要这也是我从丢人到真正成为大能人的关键转变。建议每个DBA都建立自己的故障排查清单并定期演练各种故障场景。
