TG咨询数据库高可用部署并不等于“主库有一个从库”。主从复制解决的是数据同步和副本保留问题，但主库宕机后谁来接管、应用如何发现新主、未复制事务如何处理，以及切换后能否恢复写入，仍需要单独设计。
因此，判断一套方案是否高可用，不能只看复制线程是否运行，而要验证从故障发生到业务恢复的完整链路。
主从复制解决了什么，还没有解决什么
主从复制通常采用一个节点负责写入，其他节点接收变更并提供备份或只读服务。它可以降低单节点损坏带来的数据风险，也能在部分场景下分担查询压力。
但复制本身一般不等于自动故障切换。主库断电后，从库可能仍处于延迟状态；应用连接可能继续指向旧地址；多个节点还可能同时认为自己有资格对外提供写入。若没有仲裁和身份校验，就可能出现脑裂，造成数据一致性问题。
数据库高可用部署要检查的六个环节
1. 副本是否真正可用
检查内容不能局限于端口和进程。应确认复制通道正常、日志持续生成和接收、从库能够重放变更，且数据目录具备足够磁盘空间。可以定期执行校验查询，例如比较关键表的记录数量、最大业务编号或校验摘要，但不能用单个简单查询替代完整的数据校验。
复制延迟需要结合业务容忍度判断。对支付状态、库存数量等强时效数据，几秒延迟也可能影响故障切换；对历史报表，较长延迟或许可以接受。切换前应明确哪些事务已经安全落盘，哪些事务可能需要重新提交。
2. 是否有明确的故障切换机制
高可用方案必须说明谁触发切换、切换哪些节点、怎样确认旧主库已经停止写入。自动切换需要健康检查、仲裁规则和隔离措施；手动切换则要有值班权限、操作清单和回滚条件。
以 IBM Db2 HADR 这类带有主备机制的方案为例，配置复制关系并不代表所有故障都能无感恢复。还要验证备用节点能否提升为主节点、客户端连接是否使用统一入口，以及旧主节点重新上线后是否会被错误地当作主库。
3. 网络入口和应用重连是否闭环
数据库切换完成后，应用必须能够找到新主。常见做法包括使用数据库代理、虚拟服务地址或服务发现入口，但入口本身也要避免单点故障。
应用侧应设置连接超时、连接池失效连接清理和有限次数的重试。写操作重试前必须考虑幂等性，否则一次已提交但响应丢失的请求可能被重复执行。连接池如果长期保留旧连接，也会让数据库已经切换，业务仍然报错。
4. 是否能防止脑裂和误切换
脑裂是高可用系统最危险的状态之一。网络分区时，两个节点都在线，却未必能互相通信。若两边都允许写入，恢复后很难简单合并。
应采用多数节点投票、租约、仲裁节点或其他一致性机制，并在必要时隔离失效节点。自动切换的健康检查还应区分“数据库进程正常”和“数据库能够正确读写”这两种状态，避免只因端口存活就判定节点健康。
5. 备份与恢复是否独立存在
副本不是备份。主库误删数据、错误脚本批量更新或数据被加密时，变更可能快速复制到从库。数据库高可用部署仍需配合全量备份、增量或日志备份，并将备份保存到与数据库节点不同的故障域。
至少应定期做一次恢复验证：从备份介质恢复到隔离环境，检查备份是否可读、日志是否完整、应用所需账号和权限是否齐全。只记录“备份成功”而不做恢复测试，无法证明真正具备恢复能力。
6. 监控告警是否面向业务结果
监控应覆盖复制状态、复制延迟、磁盘空间、日志堆积、节点角色、连接数、锁等待和切换事件。告警需要设定持续时间和分级规则，避免短暂抖动造成频繁切换，也避免真正的复制中断无人处理。
更重要的是进行故障演练。可在维护窗口模拟主库进程停止、主机断电、网络隔离和磁盘接近满容量等情况，记录发现故障、完成切换和业务恢复分别耗时多久。演练结果应转化为操作手册，而不是停留在架构图上。
一套可执行的验收步骤
- 绘制主库、备库、仲裁组件、网络入口、应用连接池和备份存储之间的关系。
- 写入一组带有唯一编号的测试数据，确认副本能够接收并重放。
- 在复制延迟可控时停止主库，验证故障切换、客户端重连和写入恢复。
- 检查旧主库重新上线后的角色，确认它不会自动重新夺取主身份。
- 恢复一份备份到隔离环境，核对关键表、账号权限和日志连续性。
- 记录切换耗时、丢失或需重试的事务范围，并据此调整方案。
常见问题
主从延迟为零，就能保证不丢数据吗？
不能。延迟为零通常只是某一时刻的观测结果，还要确认事务是否已经在副本持久化，以及故障发生时客户端是否收到提交确认。
只保留一个从库可以吗？
可以作为基础方案，但主库和从库同时故障、维护或数据损坏时缺少替代路径。关键业务通常需要根据故障域、成本和恢复目标评估更多副本或异地备份。
自动切换一定比手动切换好吗？
不一定。自动切换恢复更快，但误判风险更高；手动切换可控性较强，却依赖人员响应。故障特征清晰、仲裁可靠时适合自动化，否则应先完善人工确认流程。
高可用部署完成后还需要演练吗？
需要。只有经过停止主库、隔离网络和恢复备份等测试，才能确认切换机制、应用重连和数据恢复真正有效。
所以，数据库高可用部署的验收标准不是“有主有从”，而是故障发生后能够安全判断、正确切换、稳定重连，并且在异常数据或误操作场景下仍有可验证的备份恢复路径。
