企业官网建设流程全解析

开年上班第一周，工位还没坐热，监控群就炸了。告警消息一条接一条：PolarDB 某个集群的只读节点连接失败，从节点状态异常，读流量告警直接飘红。说实话，看到这消息我第一反应是——开年“我”就丢人，这可不是什么好兆头。在云数据库时代，很多人觉得主节点才是命根子，但从节点不能用这件事，真要摊上了，同样能让一个团队手忙脚乱。这篇博文就把我这次 PolarDB 从节点不可用的完整经历、排查思路和解决方案写出来，给同样在用 PolarDB 的运维、DBA 和业务开发一份可参考的实战手册。

这篇文章不仅记录一次故障，更想把 PolarDB 从节点（即只读节点）的工作原理、常见故障边界、排查顺序和恢复手段一次性讲透。无论你是刚接手 PolarDB 集群的新手运维，还是已经踩过几次“节点坑”的资深开发，应该都能从中找到对你有用的东西。尤其是那些“控制台显示节点状态正常，但业务就是连不上”的诡异场景，最有必要提前吃透排查方法。

1. 从节点不可用，为什么这么让人头疼

1.1 先搞清楚 PolarDB 的从节点到底承担什么角色

PolarDB 是云原生架构的关系型数据库，它跟传统自建 MySQL 主从复制模型有很大区别。简单说，PolarDB 的集群由三类角色组成：主节点（Primary）、只读节点（ReadOnly）和共享分布式存储。主节点负责写入和强一致读，只读节点负责分担读流量，存储层是共享的，所有计算节点访问的都是同一份数据。

这个架构带来的核心变化是：只读节点不存数据副本，它通过回放 Redo Log，把主节点上的变更实时应用到自己的内存和缓存中。所以从节点的“数据追平”过程，不是传统意义上的 binlog 同步，而是基于物理复制的高效回放。这个机制的优点很明显——从节点扩容快、数据一致性强、同步延迟通常只有毫秒级。缺点则是：从节点本质上是一个“有状态的计算节点”，它依赖底层存储和日志回放链路，任何一个环节出问题，都可能让这个节点对业务“失联”。

那从节点具体承担什么角色？在实际业务里，绝大多数 PolarDB 用户会开启读写分离。主节点处理写入和事务型查询，从节点承接报表查询、数据分析、后台任务、接口读流量等。有些团队的从节点还会被专门的 BI 任务“压榨”，大查询、多表 JOIN、复杂聚合全往从节点上丢。从节点不是“备胎”，而是读流量的主力军。一旦它挂了，整个读链路都要重新分配。

1.2 从节点挂了，业务会经历什么

很多人对主节点故障的危害有非常清晰的认识——写入中断、事务失败、业务整体不可用。但说实话，主节点故障通常有清晰的高可用切换机制，主备切换后业务能快速恢复。从节点故障反而容易被人低估，实际影响面一点都不小。

从节点不可用，最直接的影响是：应用配置了独立只读地址的读写分离链路会瞬间变成“半瘫痪”状态。只读查询全部超时或者报连接失败，报表系统跑不出数据，后台批处理任务失败重试，接口读请求的延迟直线上升。如果应用用的是 PolarDB 集群地址，负载均衡可能会自动把异常只读节点摘除，但此时所有读流量会涌向主节点，主节点的 CPU 和 IOPS 会很快飙升。别小看这一点，读流量被强制切到主节点后，主节点的写入性能也会跟着下降，严重时整个业务都会卡顿。

从高可用视角看，只读节点挂掉意味着集群的横向扩展能力打了折扣。如果集群原本只有一个只读节点，挂掉之后整个集群就变成了“单节点支撑读写”，冗余能力归零，后续再有节点异常，连个缓冲余地都没有。这个隐患比当下业务报错更值得警惕。

1.3 开年这次故障的现场还原

这次出问题的集群配置不算复杂：一个主节点加两个只读节点，其中一个只读节点主要承接后台报表查询和运营看板的数据读取。事故发生的时间点也挺“巧妙”——元旦假期结束后的第一个工作日，凌晨到早上的批处理任务集中运行，大量跑数脚本在同一个时间段内启动。

刚开始只是零星几条告警，说某个只读节点的连接成功率下降。我一开始以为是批处理任务跑得太猛，把连接池打满了，结果过了十来分钟，业务群开始有人反馈：管理后台的运营看板打不开了，部分报表数据刷新失败。登录控制台一看，那个只读节点状态居然还显示“运行中”，但用数据库客户端去连它的独立地址，连接直接超时。这时候我才意识到，问题比我想象中严重，这已经不是简单的“慢”，而是从节点真的“不能用”了。

后来我仔细回想了下，这种“控制台状态正常但业务连不上”的情况最容易让人走弯路。如果控制台直接显示节点异常，大家第一反应就是重启或者提工单。偏偏状态是正常的，就很容易让人先去怀疑网络、白名单、应用配置这些外围因素，白白浪费大量排查时间。这次踩坑之后，我梳理了一套完整的排查路径，下面详细展开。

2. 排查从节点不可用的核心思路

2.1 不要慌，先确认故障边界

遇到从节点连不上的问题，第一步不是去重启节点，也不是立刻提工单，而是先冷静下来，确认故障边界。

先回答几个问题：是单个只读节点连接失败，还是所有只读节点都不正常？是只有独立只读地址连不上，还是集群地址下的读请求也大面积失败？是应用侧连接失败，还是数据库侧已经无法对外提供服务？把这些问题搞清楚，排查范围能瞬间缩小。

举个例子，如果只有某一个只读节点的独立地址连不上，那基本可以定位是节点自身的问题；如果所有只读节点都连不上，那大概率是网络链路、白名单或者控制台侧的整体故障；如果集群地址的读流量正常，只有独立只读地址异常，那可能是应用连接池的配置问题，或者是该节点被负载均衡摘除之后没有重新纳管。我这次遇到的情况，就是典型的“单个只读节点不可用”，所以排查重心直接就放到了节点侧。

2.2 分清三类常见诱因

从节点不可用的诱因，我按实操经验归纳为三大类，排查时按这个框架走会很高效。

第一类是资源耗尽型。节点 CPU 打满、内存不足、连接数达到上限、IOPS 指标异常，都会导致新连接无法建立，或已有连接被强制断开。尤其是连接数打满这种情况，控制台上的节点状态往往还是“运行中”，但应用侧的感受就是“节点挂了”。这类问题的元凶，绝大多数是慢查询堆积、连接池配置过大、或者某个大查询把资源瞬间榨干。

第二类是同步异常型。PolarDB 的只读节点依赖 Redo Log 回放，如果回放速度跟不上主节点的产生速度，同步延迟会持续上涨，最终导致只读节点上的数据严重滞后。有些业务对一致性比较敏感，发现数据延迟就会主动报错或拒绝服务。同步异常通常由大事务、DDL 变更、从节点规格不足引发。

第三类是生命周期型。底层硬件故障、平台运维迁移、内核小版本升级、节点强制重启等都属于这一类。这类问题一般会在控制台的事件记录里有迹可循，排查时一定要先看事件和历史运维记录，避免一头扎进 SQL 优化里出不来。

2.3 从现象反推原因的方法

排查问题就像医生看病，症状决定了需要做哪些检查。连接超时和连接被拒绝，背后的原因逻辑完全不同；同步延迟高和 CPU 打满，处理手段也截然不同。

连接超时，通俗讲就是“连接请求发出去了，但对方没有回应”。这种情况通常是网络不通、节点负载过高导致无法及时处理握手请求，或者资源耗尽已经无法建立新连接。而连接被拒绝（比如报错信息直接提示拒绝连接），则往往是白名单配置不对、端口连不上，或者节点已经停止服务。

CPU 打满和同步延迟高也经常被混淆。有些从节点 CPU 冲到 100%，表面看是资源问题，实际是同步回放线程在跑一个超大事务，或者某一个复杂查询把 CPU 吃光了，导致回放线程被阻塞，进而拉高同步延迟。这时候光加 CPU 没用，得先找到那条罪魁祸首的 SQL。

从现象反推原因这个方法，核心是不要按照固定模板排查，而是先多维度收集现场信息，再结合故障类型做交叉判断。控制台状态、监控曲线、告警时间点、应用日志，这几类信息放一起对照，大多数问题的排查方向就清楚了。

3. 从节点故障排查与恢复实操记录

3.1 第一步：通过控制台确认节点状态

不管故障表象多复杂，第一步永远是登录 PolarDB 控制台，进入集群详情页，找到节点信息区域。

重点看三个东西：节点状态、节点角色、最近事件。节点状态如果显示“异常”，说明平台侧已经探测到节点不健康，这类情况一般可以直接走重启或者提工单的流程。如果状态显示“运行中”，但业务连接失败，就要继续往下看监控和事件。

最近的事件记录非常关键。平台侧的操作，比如内核补丁升级、底层硬件维护、节点迁移，都会留下事件记录。如果你在事件记录里发现故障时间段内有一次平台变更，那大概率可以从这个方向继续查。我这次排查时特意翻了一遍事件记录，确认没有平台变更，这才把注意力放到节点自身的资源指标上。

另外，节点信息区域会展示每个节点的规格、连接地址、角色状态。确认一下故障节点的规格是不是和其他节点一致，有没有可能是规格太小扛不住业务流量。这些信息在后续判断“是否需要扩容或替换节点”时很有用。

3.2 第二步：检查应用侧配置和网络链路

确认节点侧没有明显的异常状态后，不要急着下结论，先把应用侧配置和网络链路排查一遍。

检查连接串配置。PolarDB 提供了多种连接地址，包括主地址、集群地址、只读地址。确认你的应用用的是哪种地址，连接串里的端口号是否正确，账号是否有访问该节点的权限。很多“从节点不能用”的案例，最后查下来其实是连接串配置写错了白名单没放通，根本不是节点故障。

检查白名单配置。PolarDB 的访问控制比较严格，ECS 实例或应用所在网络的 IP 必须加入白名单才能访问。如果应用侧 IP 发生变化，或者新增了一组应用服务器没有加白名单，就会出现部分来源能连、部分来源不能连的诡异现象。

网络链路的连通性测试也很重要。在应用服务器上用 telnet 或数据库客户端尝试连接只读节点地址，看能收到什么错误信息。如果连接直接超时，说明网络层可能就有问题。如果提示认证失败，那说明网络是通的，只是账号权限的问题。这一步能把故障范围从“数据库不可用”缩小到“应用侧配置问题”。

3.3 第三步：拉取关键监控指标

如果网络、白名单、连接串都没问题，那基本可以确定是节点自身的问题了。这时候就要打开监控页面，拉取故障时间段的关键指标曲线，做一次“案发现场还原”。

我这次重点看了四类指标：CPU 使用率、内存使用率、连接数、同步延迟。

CPU 使用率如果长时间维持在 100%，说明节点在执行一个或一批计算密集型的任务。配合慢查询日志，基本能找到耗 CPU 的 SQL。内存使用率过高，则要考虑是否因为大查询、排序操作或者缓存命中率下降导致的内存压力。连接数是最容易出问题的指标，如果连接数接近 max_connections 上限，新连接会被拒绝，表现为“节点不可用”。同步延迟这个指标，是判断从节点是否存在回放瓶颈的重要依据，延迟持续上涨就要警惕大事务或者 DDL。

我的经验是，不要只看故障发生时的瞬时值，要把半小时前、故障开始时、故障持续中的曲线都拉出来对比。有些指标异常是“果”而不是“因”，比如 CPU 100% 可能是连接数被打满后的连带反应，真正的“因”是某条慢查询把连接池耗尽，进而拖垮整个节点。

3.4 第四步：重启只读节点

资源型故障，如果定位到了具体原因，比如慢查询已经找到、连接数已经释放，但节点仍然处于“能查到监控却连不上”的状态，控制台重启就是一个非常有效的恢复手段。

PolarDB 控制台的操作路径并不复杂：进入集群详情页，找到出问题的只读节点，点击重启。重启过程中，该节点会短暂下线，业务侧如果配置了合理的探活机制，会自动把读流量切到其他正常节点，不会造成太明显的业务感知。重启完成后，节点会重新挂载共享存储，并从 Redo Log 的位点继续回放，把数据追平。

这里有一个非常重要的提醒：重启只读节点之前，一定要确认集群里还有其他健康的只读节点可以承接流量。如果只有一个只读节点且它已经挂了，重启期间读流量全部压到主节点，主节点可能瞬间被打爆。遇到这种情况，更稳妥的做法是先新增一个只读节点，把读流量分担过去，再对故障节点做重启或替换。

重启这个操作本身不复杂，但它不是万能的。如果节点存在底层硬件问题或者长期处于不健康状态，重启之后可能很快再次异常。这种情况下单纯靠重启解决不了根本问题，应该果断选择替换节点，或者联系平台技术支持排查底层原因。

3.5 第五步：替换节点或寻求平台支持

重启无效或不适合重启时，替换节点是更可靠的恢复手段。PolarDB 支持在控制台直接添加新的只读节点，新节点创建完成后会自动从共享存储和 Redo Log 追平数据，加入集群后就可以正常承接读流量。

替换流程上，我会优先新增节点，等新节点状态变为运行中，再修改应用连接配置，把故障节点的流量切换到新节点。如果应用使用的是集群地址和读写分离，负载均衡会自动感知新节点并纳入流量分配，基本不需要手动干预。切换完成后，可以把故障节点释放掉，完成一轮“新旧替换”。

如果平台侧有不可见的问题，比如底层存储异常、节点所在物理机故障，自己处理往往会走弯路。这时候不要死扛，直接提工单并附上排查信息：故障时间段、节点 ID、监控截图、应用报错日志。平台技术支持能看到你平时看不到的底层状态，很多疑难杂症在工单层面很快就能定位。我处理过的多数“控制台正常但业务连不上”的案例，最终靠工单拿到了底层事件信息，问题才真正闭环。

4. 从节点常见问题速查表与避坑手册

4.1 常见问题速查表

每次故障排查完，我都会习惯性地把问题和解决方案沉淀成一张速查表。这里整理一份 PolarDB 从节点常见问题的速查表，遇到同类问题可以直接对照排查：

表格不是万能的，但它能在故障发生时提醒你不要遗漏方向。我每次遇到新问题，也会往这张表里补一行，时间久了就是一份非常贴合自己业务的排障手册。

4.2 实操避坑技巧

第一个避坑技巧：不要轻易在业务高峰期直接重启只读节点。很多同学发现问题后，第一反应是“重启试试”，但这个操作在高峰期可能引起更大的连锁反应。正确姿势是先确认集群内有其他节点可以承接流量，或者先把读流量切走，再执行重启。

第二个避坑技巧：应用连接池一定要配置探活和自动剔除机制。如果连接池不探活，故障节点恢复之后，连接池里的坏连接不会自动重建，业务会持续报错。配置了探活和剔除机制后，负载均衡和连接池能够自动感知节点状态，把流量调度到健康节点上，故障恢复过程会顺畅很多。

第三个避坑技巧：监控告警不能只盯主节点。只读节点的 CPU、内存、连接数、同步延迟这些指标，都应该配置独立的告警规则。很多时候从节点异常不是一瞬间发生的，而是有一段时间的资源水位上涨，如果能在早期接到预警，完全可以在业务受损之前做干预。我这次开年故障，事后复盘就发现只读节点的连接数在故障前半小时已经涨到平常的三倍，可惜当时没有对应的告警规则，白白错过了最佳干预窗口。

4.3 日常巡检建议

最后分享几个日常巡检的建议，这些都来自我个人的实践总结。

从节点同步延迟要每天看。哪怕业务流量不大，也要养成看一眼同步延迟的习惯。延迟突然上涨，往往意味着有异常大事务或者回放链路出问题，早发现早处理。

只读节点规格要和读流量匹配。很多人只关注主节点规格，从节点规格随意选，结果读流量一上来，从节点先扛不住。建议定期观察只读节点的 CPU 水位，如果长期超过 60%，就该考虑升级规格或者增加只读节点数量了。

变更操作前先做容量评估。上线新报表、跑批任务、导出大表数据之前，先评估一下这些操作是否会给只读节点带来明显压力。如果批处理任务集中在同一时段，考虑错峰执行，或者在低峰期加大只读节点资源，避免同一时间把所有压力都砸到节点上。

我个人在实际操作中还有一个体会：PolarDB 虽然托管了底层基础设施，但只读节点的“健康管理”这件事，平台能做的是有限的。节点上的慢查询、连接管理、资源水位，最终还是需要业务侧和运维侧共同关注。开年就丢人不可怕，把这个“丢人”的过程完整复盘一遍、把预防措施补上，后续集群的稳定性才真正有保障。