2、数据库高可用架构概述：主从复制、集群模式、分布式数据库的基本概念
在变更窗口内进行数据库可靠性配置，首先需要理解数据库高可用架构的核心模式。不同的架构决定了故障切换速度、数据一致性级别以及运维复杂度。本节将系统梳理三种主流高可用架构：主从复制、集群模式和分布式数据库，为后续的可靠性配置实战奠定理论基础。
2.1 主从复制架构
主从复制是最基础、应用最广泛的高可用方案。其核心思想是：一台主库（Master）负责处理写请求，一台或多台从库（Slave）通过异步或半同步方式复制主库的 Binlog（二进制日志），提供读扩展或故障切换能力。
关键指标： 主从复制延迟（Seconds_Behind_Master）是衡量健康度的核心指标，变更窗口内应确保延迟 < 1s 方可进行切换操作。
主从复制核心流程
- 主库写入： 应用发起写操作，主库提交事务并记录 Binlog。
- 日志传输： 从库的 I/O 线程连接主库，拉取 Binlog 并写入本地 Relay Log（中继日志）。
- 日志回放： 从库的 SQL 线程读取 Relay Log，在本地顺序回放，完成数据同步。
- 状态检测： 监控工具定期检查主从心跳和延迟，判断复制链路是否正常。
变更窗口建议： 主从切换前，务必先设置主库为
read_only 并等待从库追上所有 Relay Log，避免数据不一致。
2.2 集群模式架构
集群模式通常指多个数据库节点组成一个整体，通过共识算法或共享存储实现强一致性和自动故障转移。典型代表包括 MySQL Group Replication（MGR）、Galera Cluster 以及 PostgreSQL 的 Patroni + etcd 方案。
| 特性 | 主从复制 | 集群模式 |
|---|---|---|
| 一致性 | 最终一致性（异步） | 强一致性（多数派写入） |
| 故障切换 | 手动或半自动（需选主） | 自动（秒级） |
| 写扩展 | 单点写入 | 多节点写入（需解决冲突） |
| 网络要求 | 低延迟即可 | 低延迟 + 高稳定（心跳敏感） |
| 变更窗口风险 | 切换时可能丢数据 | 节点重启后需 State Transfer |
避坑提示： 集群模式在变更窗口内重启节点时，如果网络抖动导致多数派丢失，可能触发全集群只读保护。务必在业务低峰期操作，并确保至少 3 个节点存活。
2.3 分布式数据库架构
分布式数据库将数据按分片键（Shard Key）水平拆分到多个存储节点，每个分片内部通常再叠加主从复制或集群模式。典型产品包括 TiDB、OceanBase、CockroachDB 以及 ShardingSphere 生态。其核心组件包括：
- 计算层（SQL 引擎）： 解析 SQL，生成分布式执行计划，协调跨分片事务。
- 存储层（分片节点）： 每个分片是一个独立的 Raft/Paxos 组，保证数据强一致。
- 元数据服务： 维护分片路由表、节点状态、Schema 信息。
- 调度器： 自动均衡分片分布，处理节点扩缩容。
2.4 三种架构对比与选型
在变更窗口场景下，不同架构的运维关注点差异显著。下表从变更窗口视角进行横向对比：
| 对比维度 | 主从复制 | 集群模式 | 分布式数据库 |
|---|---|---|---|
| 变更窗口切换时间 | 分钟级（手动选主） | 秒级（自动选举） | 秒级（Raft 自动切换） |
| 数据一致性风险 | 异步复制可能丢数据 | 强一致，无丢失 | 强一致，无丢失 |
| 扩缩容复杂度 | 低（加从库即可） | 中（需全量 State Transfer） | 高（分片搬迁 + 路由更新） |
| 变更窗口回滚策略 | 切换回原主库 | 节点回退 + 快照恢复 | 分布式事务回滚 + 分片回退 |
| 适用场景 | 中小规模、读多写少 | 金融、电商核心交易 | 海量数据、高并发写入 |
2.5 架构选型决策要点
在变更窗口可靠性配置中，选择哪种架构取决于以下三个核心约束：
- RTO（恢复时间目标）： 业务能容忍的最长停机时间。主从复制通常 > 5 分钟，集群和分布式数据库 < 30 秒。
- RPO（恢复点目标）： 允许丢失多少数据。异步主从复制可能丢失秒级数据，集群和分布式数据库可做到零丢失。
- 运维成熟度： 团队是否具备自动化切换工具和变更窗口演练经验。分布式数据库的运维复杂度最高，建议先通过主从复制积累经验。
实战建议： 在首次变更窗口实施前，至少完成 3 次故障切换演练，并记录每次切换的实际耗时和延迟数据，用于校准 RTO 预期。