香港服务器出现访问超时、接口报错或写入失败时，备节点即使显示在线，也不代表它已具备安全接管条件。故障可能发生在业务入口、网络、系统、应用或复制链路；如果主节点只是暂时无法被监控端访问，却仍能接受写入，贸然提升备节点就可能造成双主和数据分叉。

排查时先确认影响范围，再由外向内检查入口与网络、节点系统、应用服务和复制状态。只有确认旧主已停止写入、备节点的数据位置符合恢复目标，并且切换入口和应用依赖可用后，才执行提升。恢复后还要验证读写、数据一致性和新的复制链路；原主节点重新上线本身不是回切依据。

先把恢复目标和主备角色说清楚

RPO（恢复点目标）表示故障时最多允许丢失多大范围的数据；RTO（恢复时间目标）表示从确认故障到业务恢复所允许的时间。RPO决定复制和切换时能接受的数据缺口，RTO则取决于故障检测、旧主隔离、备节点提升、入口调整及业务验证所需的时间。只写“尽量不丢数据”或“尽快恢复”，无法据此判断是否应该切换。

如果业务要求已确认提交的数据不丢失，复制机制必须保证提交确认与所要求的数据持久化、复制确认相匹配；仅配置了“同步”字样，并不能脱离具体数据库和提交设置保证这一点。发生复制链路故障时，这类机制也可能暂停或限制写入，以换取一致性。若允许一定数据缺口，可使用异步复制，但要持续监测备节点已接收位置和已应用位置；切换判断应以可恢复的数据位置为准，而不是“连接正常”或“数据已到达”。异步复制的缺口超过RPO时，提升备节点可能恢复服务，但不能据此认定满足原定恢复目标。

主备方案至少应明确五项职责：主节点正常承接写入；备节点接收并应用数据，未经授权不允许写入；统一业务入口负责把请求导向当前主节点；切换控制负责检测故障、授予角色并隔离旧主；独立备份用于处理误删除、错误更新和主备分叉。复制会把部分错误变更同步到备节点，因此备节点不能替代备份。

设计时还要逐项检查单点：入口是否只能指向一台主机，健康检查是否只测端口，复制通道是否没有状态告警，角色控制是否可能让两台节点同时可写，以及切换后应用是否仍使用旧连接、凭据或配置。主备节点在网络分区时不能各自认定自己是主；若不能确认旧主停止写入，应先隔离旧主或撤销其写入资格，再提升备节点。

按优先级由外向内排查

1. 确认影响范围，先排入口与网络

记录故障开始时间、受影响域名和接口、主备角色、最后一次成功写入时间，以及客户端看到的错误。先判断是所有请求失败、只有部分接口异常，还是仅写操作失败。不要在尚未确认故障层级时先重启节点或强制切换。

以下命令适用于常见Linux系统，主要用于读取状态；将示例域名和路径替换为实际值：

date -Is
hostname
getent ahosts your-domain.example
curl -fsS --connect-timeout 5 --max-time 10 https://your-domain.example/health
ss -lnt
ip route
getent hosts replication-peer.example
ss -nt
timedatectl status

域名解析或入口仍指向不可用节点时，优先核对解析、转发和切换控制是否生效。外部健康检查失败而主机本地服务正常，故障更可能位于入口、访问控制、路由或监听地址；如果主备之间也无法通信，则还要考虑网络分区，不能仅凭一个监控点无法访问主节点就判断主节点已停止工作。反过来，入口已经指向备节点但业务仍失败，应继续检查备节点服务、应用配置和复制状态。

健康检查至少要区分网络可达、服务可响应和关键业务依赖可用。端口监听只能证明存在监听进程，不能证明应用已能完成读写。若主备互相失联，必须确认哪一侧仍有写入能力；在无法确认时，应先阻止两边继续同时写入，而不是让自动切换扩大风险。

2. 检查系统是否故障，备节点是否有接管能力

主节点可能因磁盘或inode耗尽、文件系统只读、内存压力、进程被终止或系统负载过高而失效。备节点也可能因资源不足而无法继续应用复制。以下命令适用于Linux系统，读取状态通常不改变服务；查看日志可能需要相应权限：

uptime
free -h
df -h
df -i
dmesg -T | tail -n 50
journalctl -p err..alert --since "30 minutes ago" --no-pager

磁盘或inode耗尽时，先确认占用来源和文件用途；不要直接清空数据目录或删除不明文件。文件系统只读时，不应强行启动写入服务，应先查明文件系统及存储状态。内存压力和高负载可能导致应用或数据库退出，也可能拖慢备节点的数据应用；平均负载本身不足以区分CPU、磁盘I/O、锁等待或复制压力。若暂未发现系统错误，只能说明没有找到明显的系统层证据，不能排除服务或应用故障。

重启会改变现场，且可能扩大影响。需要重启时，先保留相关日志、确认影响范围和当前数据权威节点，并确认入口指向可用节点；操作前明确如何恢复服务状态以及何时可以切回入口。

3. 检查服务和应用是否真正可用

进程存在不等于服务可用。应核对服务状态、监听地址、应用日志，以及它连接的数据服务和其他关键依赖。以下命令适用于使用systemd的Linux系统；示例服务名需替换为实际值：

systemctl is-active your-service.service
systemctl status your-service.service --no-pager
journalctl -u your-service.service --since "30 minutes ago" --no-pager
ss -lntp

若服务反复退出、监听端口不符、应用仍连接旧主节点，或出现连接池耗尽、权限失败、线程阻塞等错误，应先处理对应服务或配置问题，不能把它们误判为数据复制故障。切换后读请求正常、写请求失败，也不代表容灾完成：还需检查新主角色、写入权限、应用连接缓存和数据服务依赖。

验证业务读写时，优先使用应用提供的健康检查和安全探针。需要验证写路径时，使用测试租户、测试表或受控记录，并确认清理和核对方式；不要随意向生产业务数据写入测试内容。部分接口失败时，还要区分应用模块和依赖故障，避免仅凭单个接口异常判定整台服务器不可用。

4. 核对复制位置，再判断备节点能否提升

复制检查至少要取得主备角色、连接状态、主节点最新数据位置、备节点最后接收位置和最后应用位置、延迟、最近复制错误，以及节点是否只读。具体查询命令取决于数据库和复制组件；没有确定软件和版本时，不应套用其他产品的命令，应使用实际组件提供的状态工具或管理界面，并记录故障时点的数据。

位置和复制组件状态可帮助判断数据追到哪里；关键业务还可抽查订单状态、账户余额等核心记录，确认业务层结果是否一致。抽查应控制范围，避免故障期间执行大规模全表扫描，进一步增加负载。若组件状态与业务核对结果矛盾，应先查明原因，不要仅依据某一项指标宣布一致。

满足切换条件后再提升备节点

切换前要确认主节点确实无法提供服务，或已被明确隔离；备节点最后应用位置可查且其数据缺口符合RPO要求；备节点资源、应用配置、凭据和依赖能够承接业务；切换入口、负责人、验证方法和失败处理方式都已明确。任何一项关键条件无法确认，都应暂停自动提升，先恢复可判断性。

推荐按以下顺序执行：

1. 隔离旧主：停止旧主写入，或从业务入口及内部调用链中移除。无法确认隔离成功时，不提升备节点。
2. 确认备节点数据状态：核对最后接收和应用位置、复制错误及资源状态，记录可能的数据缺口。
3. 提升备节点：按已验证的复制组件流程变更角色。不要临时删除锁文件、直接改数据目录或绕过组件保护。
4. 切换统一入口：指向新主后，从实际业务访问路径验证入口生效，不能只看控制面板显示已切换。
5. 分层验证业务：先测健康检查和只读路径，再用受控方式验证写入、读取及后续复制。
6. 观察运行状态：检查应用错误、写入延迟、连接数、磁盘增长和复制位置是否持续变化。

切换失败时，不要重复执行提升操作。先区分失败发生在角色提升、入口调整、应用连接还是权限配置；保留主备日志及状态。若新主已经接受写入，回滚前必须确认这些新写入如何处理，不能直接把入口切回旧主，否则可能丢失新数据或再次形成分叉。

原主恢复后先追平，不要立即回切

原主重新上线只说明节点恢复，不代表其数据是最新的，也不代表它可以安全承担主角色。先保持其隔离或只读，保留故障期间的日志和数据文件；以当前承接业务的新主作为数据权威来源，确认故障期间产生的变更，再按复制组件支持的流程重新同步。

如果两边已经分叉，应根据组件要求重建或修复，不要未经核验直接覆盖数据目录。确认原主完整追平、复制连接和应用位置正常、错误日志无未解决问题后，再安排受控角色切换，验证其重新承担主角色的能力。切换后继续观察，再恢复常态主备排列。

若两台节点都曾经接受写入，必须先确定业务数据的权威来源。时间戳较新不必然代表数据正确，时钟偏差、应用重试和事务回滚都可能影响判断；无法自动合并时应暂停回切，按业务数据修复流程处理。

用恢复验证和监控发现复发风险

切换或恢复完成后，至少验证：外部入口指向正确节点；新主为唯一可写节点；旧主不再接受写入；关键读请求返回预期数据；受控写入成功且能在备节点观察到复制结果；接收与应用位置继续前进；应用日志不再出现连接旧主、权限失败或事务错误；资源没有持续耗尽；备份仍从新的数据权威节点正常执行。

记录故障发现时间、最后同步位置、切换开始时间、业务恢复时间和数据核对结果，才能对照实际RPO、RTO判断是否达标。“页面恢复”只能说明部分访问恢复，不能证明数据一致或容灾链路恢复。

日常监控应覆盖外部业务健康状态、主备角色是否唯一、复制连接与应用延迟、复制错误、磁盘增长、时间同步、备份结果及备份恢复验证。还应记录故障演练中检测、隔离、提升、入口切换和业务验证各阶段的耗时。复制延迟接近RPO预算、备份连续失败、健康检查与真实业务结果不一致，或主备同时可写时，应在下一次故障前处理。