TG咨询刚开始做数据库高可用部署时，最容易产生的误解是“主库加一台备库就完成了”。实际上，高可用方案还要回答几个问题：数据怎样复制，主库故障后谁负责接管，应用如何连接新主库，网络分区时怎样避免双主，以及恢复后如何重新加入集群。
建议先从单一数据库类型和明确的故障范围入手，不要一开始就叠加跨地域、多活和复杂中间件。以下配置适合用于理解基础原理，具体参数仍需结合版本、硬件、业务写入量和网络条件调整。
先分清高可用要解决的故障
数据库高可用部署通常针对三类问题：单台服务器宕机、数据库进程异常，以及网络或存储故障。它不等同于备份。备份主要用于误删数据、逻辑错误和历史恢复，高可用则侧重于缩短服务中断时间。
- 主备复制：一台节点负责写入，其他节点接收复制日志。结构清晰，适合大多数读写分离场景，但切换后需要重新确认主从关系。
- 多主或同步集群：多个节点都可能接受写入，故障切换更灵活，但冲突处理、网络延迟和脑裂防护更加复杂。
- 共享存储方案：数据库实例依赖共同存储。切换逻辑相对直接，但共享存储本身会成为重点风险，需要独立设计冗余。
例如，PostgreSQL 常见的物理流复制是一主多备模式；MariaDB Galera Cluster 更偏向多节点同步复制。初学者应先掌握一种模型，再比较其他方案。
需要优先配置的五个基础部分
1. 节点角色与网络
先为每个节点确定固定主机名、管理地址和数据库服务地址，确保节点之间可以稳定解析。数据库复制端口、管理端口和监控端口应分别规划，并通过防火墙只开放给必要的节点或管理网段。
生产环境通常至少准备两个数据节点；如果方案需要选主或仲裁，最好再配置独立的仲裁节点或见证节点。仲裁节点不一定保存业务数据，但应尽量放在与两个数据库节点不同的故障域，避免一处断电导致整个集群失去判断能力。
2. 数据复制与一致性
复制配置决定了故障切换时可能丢失多少已经提交的数据。异步复制响应较快，但主库突然损坏时，备库可能尚未收到最近的日志；同步复制能降低这一风险，却会受到备库延迟和网络质量影响。
以 PostgreSQL 为例，需要配置主库允许复制连接、创建专用复制账户、启用预写日志相关参数，并在备库设置主库连接信息和复制槽。开启同步复制前，应先观察复制延迟，再评估业务是否能够接受写入等待。不要只复制配置文件，必须验证备库是否持续接收并正确回放日志。
3. 故障转移与脑裂防护
故障转移既可以人工执行，也可以由 Patroni 等集群管理组件配合 Consul 或 etcd 完成。自动切换前，必须定义健康检查条件，例如数据库进程状态、复制延迟、磁盘可写性和节点间通信状态，而不能只检查端口是否打开。
脑裂是两个节点都认为自己是主库，进而同时接受写入。防护手段包括仲裁、租约、STONITH（隔离或关停失效节点）以及严格的主库身份校验。没有隔离旧主库的能力时，不建议直接启用完全自动的提升操作。
4. 连接入口与应用重连
应用不应把某一台数据库服务器的固定地址写死。可以使用代理、虚拟 IP、服务发现记录或云平台提供的数据库连接地址作为统一入口。切换发生后，连接池必须能够丢弃失效连接并重新建立连接。
这里要注意：数据库切换成功，不代表正在执行的事务会自动完成。应用仍需处理连接断开、事务回滚和有限次数的重试。涉及支付、库存或订单状态时，重试逻辑还应配合幂等设计，避免同一请求被重复执行。
5. 监控、告警与恢复
至少监控以下指标：主备复制延迟、复制连接状态、数据库连接数、事务提交延迟、磁盘空间、磁盘写入等待、CPU 和内存使用率。告警应区分“即将影响服务”和“已经发生切换”，例如复制中断与节点完全不可达不应使用同一严重级别。
备份也必须纳入数据库高可用部署。建议同时保留全量备份与连续归档日志，并定期在隔离环境中做恢复演练。只有能恢复出可用数据库，备份方案才算真正有效。
一套适合入门的实施顺序
- 选定一种数据库版本，在两台独立主机上完成基础安装，并统一时区、时间同步、字符集和目录规划。
- 先做手工主备复制，记录复制延迟、断网后的行为和备库恢复时间。
- 增加统一连接入口，测试主库停止、数据库进程退出和单节点网络隔离三种故障。
- 再接入集群管理组件或云平台托管能力，明确自动切换的触发条件、回切方式和人工确认点。
- 执行恢复演练：模拟误删表、日志损坏和主节点永久下线，分别验证备份恢复与节点重建。
- 把切换步骤、账号权限、配置变更和回滚方法写成操作手册，避免只依赖个人经验。
初学者常见的选择误区
| 选择 | 主要优点 | 需要承担的代价 |
|---|---|---|
| 异步主备 | 写入延迟较低，结构容易理解 | 极端故障下可能丢失尚未复制的数据 |
| 同步主备 | 数据一致性更强 | 备库或网络变慢时可能拖慢写入 |
| 自动切换 | 减少人工介入时间 | 误判、脑裂和回切控制更复杂 |
| 人工切换 | 操作风险更容易审核 | 依赖值班人员，恢复速度通常较慢 |
常见问题
只有两台数据库服务器，能不能做高可用？
可以实现主备复制，但在网络分区时很难安全判断谁应继续提供写服务。若方案支持，增加独立见证或仲裁节点会更稳妥。
备库能不能直接承担全部查询？
要先确认备库是否允许读取、复制延迟是否可接受，以及查询结果是否要求最新数据。强一致场景不宜盲目把读请求切到备库。
高可用是否可以替代备份？
不能。复制可能把误删、错误更新同步到所有节点，必须用独立备份和日志归档支持历史恢复。
什么时候适合自动故障转移？
当健康检查、仲裁、旧主隔离、应用重连和回切流程都经过演练后，才适合逐步启用自动切换。
总的来说，入门数据库高可用部署应先建立“复制、判断、切换、重连、恢复”这条完整链路。先把单主多备或清晰的同步集群运行稳定，再根据业务的可用性目标扩大到更复杂的架构。
