1. PolarDB从节点故障排查实战指南最近在维护PolarDB集群时遇到了一个典型问题从节点突然不可用。这种情况在数据库运维中并不少见但每次遇到都需要系统性地排查解决。本文将分享我从这次故障中学到的完整排查流程和经验总结。1.1 问题现象描述我们的生产环境使用的是PolarDB MySQL版集群采用一主两从的架构。某天凌晨监控系统突然报警显示其中一个从节点的连接成功率骤降至30%以下。具体表现为应用程序通过集群地址连接时部分查询请求超时直接连接该从节点地址时连接建立缓慢且经常失败控制台显示该节点状态为运行中但CPU利用率异常低5%重要提示当从节点出现异常时建议立即将应用连接切换到主节点或其他正常从节点避免影响业务连续性。1.2 初步诊断步骤首先通过PolarDB控制台检查节点基本信息登录阿里云控制台进入PolarDB实例详情页在节点管理页面查看问题节点的状态和基础指标确认节点规格、存储空间、网络带宽等配置无异常接着通过命令行进行深入检查# 连接到管理节点 mysql -h[集群地址] -u[用户名] -p[密码] # 查看节点状态 SHOW PROCESSLIST; SELECT * FROM information_schema.innodb_trx;发现一个关键现象该从节点的SQL线程状态长时间停留在Waiting for master to send event表明主从同步可能出现了问题。1.3 深入排查方向根据经验从节点不可用通常涉及以下几个方面的原因1.3.1 主从复制延迟检查复制延迟情况SHOW SLAVE STATUS\G重点关注以下字段Seconds_Behind_Master延迟秒数Slave_SQL_Running_StateSQL线程运行状态Last_Error最近错误信息1.3.2 资源瓶颈排查检查系统资源使用情况# 连接到问题节点 mysql -h[从节点地址] -u[用户名] -p[密码] # 查看资源限制 SHOW VARIABLES LIKE max_connections; SHOW STATUS LIKE Threads_connected;1.3.3 网络连接测试测试节点间网络连通性# 从应用服务器测试 telnet [从节点IP] 3306 # 在从节点上测试到主节点的连接 telnet [主节点IP] 33061.4 问题定位与解决经过上述排查最终定位到问题根源从节点的临时目录空间耗尽导致无法处理主节点传送的binlog事件。解决方案如下清理临时文件# 登录从节点服务器 cd /tmp rm -rf mysql_*调整临时目录配置SET GLOBAL tmpdir/data/tmp;重启复制线程STOP SLAVE; START SLAVE;监控恢复情况SHOW SLAVE STATUS\G1.5 预防措施为避免类似问题再次发生我们实施了以下改进增加临时目录空间监控设置自动清理临时文件的定时任务优化binlog传输压缩设置调整从节点的innodb_buffer_pool_size参数2. PolarDB架构深度解析要彻底理解从节点故障的根源需要深入了解PolarDB的架构设计。2.1 计算与存储分离架构PolarDB采用计算与存储分离的设计计算节点运行数据库引擎无本地存储存储节点采用分布式块存储数据多副本这种架构下从节点不可用通常不会导致数据丢失但会影响读扩展能力。2.2 主从复制机制PolarDB的主从复制基于物理复制Redo Log而非逻辑复制Binlog主节点将Redo Log写入共享存储从节点从共享存储读取Redo Log并应用相比传统MySQL的binlog复制延迟更低2.3 代理层设计PolarDB的代理层负责请求路由自动屏蔽异常节点支持读写分离提供连接池功能3. 高级故障排查技巧3.1 性能日志分析通过性能日志定位瓶颈-- 开启性能监控 SET GLOBAL performance_schemaON; -- 查询等待事件 SELECT * FROM performance_schema.events_waits_current;3.2 锁等待分析检查锁等待情况SELECT * FROM sys.innodb_lock_waits;3.3 存储引擎状态查看InnoDB状态SHOW ENGINE INNODB STATUS;4. 运维最佳实践4.1 容量规划建议计算节点预留20%的CPU和内存余量存储空间监控增长率提前扩容连接数根据应用需求合理设置max_connections4.2 监控指标清单必须监控的关键指标指标类别具体指标告警阈值资源使用CPU利用率80%持续5分钟复制状态主从延迟60秒连接数活跃连接数max_connections的80%4.3 自动化运维脚本分享一个实用的监控脚本#!/bin/bash # 检查复制状态 check_replication() { status$(mysql -h$1 -u$2 -p$3 -e SHOW SLAVE STATUS\G | grep Running) echo $status } # 主从延迟检查 check_lag() { lag$(mysql -h$1 -u$2 -p$3 -e SHOW SLAVE STATUS\G | grep Seconds_Behind_Master | awk {print $2}) echo $lag } # 调用示例 check_replication slave-host admin password check_lag slave-host admin password5. 典型问题解决方案5.1 从节点重建流程当从节点无法恢复时需要重建在控制台删除问题从节点添加新的从节点等待数据同步完成验证数据一致性5.2 参数优化建议关键参数调整-- 增加复制线程数 SET GLOBAL slave_parallel_workers8; -- 调整复制缓冲区大小 SET GLOBAL slave_pending_jobs_size_max256M;5.3 连接池配置建议配置# 应用连接池配置示例 spring: datasource: hikari: maximum-pool-size: 20 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 18000006. 经验总结与教训这次故障给我们带来了几个重要启示监控要全面不能只监控基础资源还需要关注复制状态等数据库特有指标容量规划要前瞻临时目录这种小空间往往被忽视却可能引发大问题故障处理要果断当从节点出现问题时及时隔离可以避免影响扩大在实际运维中我们还发现PolarDB的从节点对内存特别敏感。当并发查询较多时适当增加从节点的内存配置可以显著提高稳定性。另外定期重启从节点也能预防一些难以定位的偶发问题。最后分享一个实用技巧在PolarDB控制台的参数配置页面可以设置主库不接受读这样当从节点出现问题时所有读请求会自动路由到其他正常从节点而不会落到主库上有效保护主库性能。