📚 课程目录第3章主从架构基础

3. 主从架构基础：数据库主从复制原理、读写分离架构、切换对业务的影响

在数据库高可用架构中，主从复制与读写分离是最基础且应用最广泛的模式。理解其底层原理、架构设计以及切换时的业务影响，是后续进行 Terraform 驱动主从切换移植适配的前提。本章将拆解这三个核心知识点，并配合架构图与流程表进行说明。

3.1 数据库主从复制原理

主从复制（Master-Slave Replication）的核心机制是：主库（Master）将数据变更记录到二进制日志（Binlog），从库（Slave）通过 I/O 线程拉取日志并写入中继日志（Relay Log），再由 SQL 线程重放日志以保持数据同步。常见的复制模式包括异步复制、半同步复制和全同步复制。

复制模式	数据一致性	性能影响	典型场景
异步复制	最终一致，主库故障可能丢数据	主库无等待，性能最高	日志、报表、非关键业务
半同步复制	至少一个从库确认收到日志后才提交	主库有轻微延迟，性能折中	金融交易、订单系统
全同步复制	所有从库确认后才提交，强一致	主库等待所有从库，性能最低	分布式数据库、强一致性要求

实践提示：在变更窗口的主从切换场景中，半同步复制是推荐的最低配置。它能在保证数据不丢失的前提下，维持可接受的写入性能，避免异步复制带来的数据丢失风险。

3.2 读写分离架构

读写分离架构将写流量（INSERT/UPDATE/DELETE）路由到主库，将读流量（SELECT）分发到多个从库，从而降低主库负载、提升系统吞吐量。常见的实现方式包括：应用层代码路由、中间件代理（如 ProxySQL、MaxScale）以及数据库原生读写分离。

应用层路由：开发人员在代码中显式指定数据源，灵活性高但耦合度强。
中间件代理：通过透明代理层自动解析 SQL 并分发流量，对应用透明，便于统一管理。
数据库原生：部分云数据库或分布式数据库内置读写分离能力，配置简单。

  架构要点：读写分离的核心挑战在于数据一致性延迟。从库复制存在天然延迟，可能导致刚写入的数据无法立即被读到。常见解决方案包括：强制读主库（写后读一致性）、延迟阈值控制、以及使用缓存中间件。

3.3 主从切换对业务的影响

主从切换（Failover / Switchover）是指将主库角色转移给一个从库，原主库降级为从库或下线。切换操作对业务的影响主要体现在连接中断、数据一致性和性能抖动三个方面。

关键风险：切换过程中，如果从库复制延迟较大，未同步的数据可能丢失，导致业务数据不一致。因此，切换前必须检查复制延迟（Seconds_Behind_Master），并确保延迟在可接受范围内。

3.3.1 切换流程与影响分析

阶段	操作内容	对业务的影响	持续时间
1. 前置检查	检查复制延迟、主从状态、磁盘空间	无影响，只读操作	秒级
2. 阻塞写入	关闭主库写入权限或设置只读	写操作失败或排队，读正常	秒级到分钟级
3. 等待同步	等待从库追上主库最后一条日志	写操作持续阻塞	取决于延迟大小
4. 角色切换	将从库提升为新主库，原主库降级	连接短暂中断（秒级）	秒级
5. 恢复写入	应用重新连接新主库，恢复写流量	业务恢复，可能有少量重试	秒级

3.3.2 切换对业务的具体影响

连接中断：切换瞬间，数据库连接池中的连接会失效，应用需要重新建立连接。如果连接池配置不当（如超时时间过短），可能导致大量请求失败。
数据不一致：异步复制模式下，主库故障时未同步的 Binlog 会丢失，导致新主库缺少部分数据。半同步复制可大幅降低此风险。
性能抖动：切换后，新主库需要重新建立复制关系、加载缓存，短时间内性能可能低于正常水平。同时，应用层的重试风暴可能加剧负载。
读写分离失效：如果切换后未及时更新读写分离代理的路由规则，部分读流量可能仍指向旧主库，导致数据读取错误。

3.4 切换对 Terraform 驱动适配的启示

在 Terraform 驱动的自动化切换方案中，需要重点关注以下适配点：

复制状态检测：Terraform 资源或外部数据源需要能够读取 Seconds_Behind_Master 等指标，作为切换前置条件。
连接池管理：切换后，Terraform 需要触发应用层的连接池刷新或 DNS 更新，避免旧连接残留。
读写分离路由更新：如果使用中间件代理，Terraform 需要调用 API 更新路由规则，将写流量指向新主库。
回滚能力：切换失败时，Terraform 应能自动触发回滚流程，将角色恢复至切换前状态。

  最佳实践：在 Terraform 中定义主从切换的状态机，将前置检查、阻塞写入、等待同步、角色切换、恢复写入、回滚等步骤抽象为独立的模块或资源，便于复用和测试。