一、为什么还要讨论主从架构？——从一次午夜故障说起——RDS高可用主从架构
配置前的检查
关于RDS高可用主从架构，最值得先弄清楚的是配置边界和排错顺序。很多团队在业务初期图省事，直接上单库，直到某次慢查询拖垮整个服务。那次我们核心报表库在双十一预热期间，主库CPU飙到98%，从库延迟累积到10分钟，读写分离形同虚设。事后复盘发现，原生MySQL主从复制在限流、连接池、自动故障转移等方面几乎裸奔。这迫使我们重新评估RDS高可用主从架构的选型——是继续用云厂商托管方案，还是自建？
本文将以对比评测为主线，把我在三个不同业务场景中踩过的坑拆开揉碎：
- 场景A：中小电商订单库（单库→一主一从→读写分离）
- 场景B：Saas计费库（多租户隔离下弹性扩容）
- 场景C：实时数仓（混合负载下的从库扩容）
每个场景都会给出配置对比、性能差异、典型故障与解决方案，并最终提炼出一套可复用的弹性扩容方法论。
想继续深入：此处可内链到“RDS高可用主从架构优化清单”文章。
二、读场景分裂：从库延迟才是最大杀手
2.1 对比1：半同步复制 vs 异步复制
我们最初采用云厂商默认的异步复制，遇到大事务（比如批量更新几十万行）时，从库延迟从几秒飙到几分钟。而开启半同步复制后，延迟控制在毫秒级，但主库写入RT平均增加15%。对比测试结果如下：
- 异步复制：主库TPS 12K，从库最大延迟32秒，业务侧出现频繁读脏数据（用户看到订单已支付但状态未变）。
- 半同步复制：主库TPS 10.5K，从库最大延迟0.8秒，读一致性得到保障，但写性能下降12.5%。
踩坑教训：很多方案文档只说半同步好，却没人告诉你如果网络抖动频繁，半同步可能退化为异步。我们曾在跨可用区部署时，由于专线带宽不足，每天发生数十次退化，导致监控报警雪崩。最终方案是：核心交易库强制半同步+设置合理超时（2秒），非核心库保留异步。
2.2 对比2：从库连接池 vs 直连从库
早期我们让应用直连从库IP，当从库扩容缩容时，必须重启应用更新连接串。而采用Proxy（如ProxySQL或阿里云DBProxy）后，读写分离对应用透明，但引入了一层额外延迟（约0.3ms）。对比数据：
- 直连从库：P99读延迟1.2ms，运维成本高（每次扩缩容需发布）。
- Proxy读写分离：P99读延迟1.6ms，扩缩容零停机，且支持自动探测从库健康状态。
结论：对于延迟敏感的实时查询（如秒杀库存），我们仍然保留部分直连通道；对一般业务全面采用Proxy模式，节省了运维人力。
补充参考：此处可内链到“RDS高可用主从架构故障排查实例”。
三、写场景弹性：从库扩容的“静悄悄”方案
3.1 传统扩容的痛点
当从库负载过高时，最常见的做法是增加一个从库节点。但直接添加从库会导致主库额外dump全量数据（即使采用GTID），期间主库IO压力骤增，影响线上写入。我们曾因此导致一次5分钟的写入毛刺。
3.2 对比3：物理备份恢复 vs 延迟从库克隆
我们测试了两种扩容方式：
- 物理备份恢复：主库执行xtrabackup -> 传文件 -> 启动新从库 -> 追binlog。总耗时约40分钟（200GB数据），主库IO飙升2.3倍。
- 基于现有从库克隆：先选择一个延迟最低的从库作为数据源，利用MySQL 8.0的Clone Plugin快速克隆，然后在新节点上追Relay Log。总耗时15分钟，主库IO几乎无变化。
实战效果：我们采用了“预先克隆+临时追日志”的组合策略：提前建立几个空壳从库（只clone数据不启动），当需要扩容时直接启动并追赶GPOS位置，实际对业务影响几乎为零。
3.3 弹性伸缩的自动化脚本
最终我们编写了一套基于Ansible+MySQL Router的自愈脚本：
- 监控从库复制延迟、连接数、CPU使用率；
- 当指标超过阈值（延迟>5秒或连接数>80%），自动触发扩容；
- 先检查是否已有空闲cloned实例，有则直接挂载；若无则触发克隆流程，同时临时将新建连接路由到其他健康从库；
- 扩容完成后，更新Router配置，并下线旧从库（如果检测到已过载）。
这套方案上线后，我们成功应对了一次单日300%流量突增，0次人工干预。
四、监控与告警：对比三种指标体系的取舍
4.1 对比4：原生监控 vs 自建Prometheus+Grafana vs 云监控
为了实时掌握主从状态，我们对比了三套方案：
- 原生MySQL监控（SHOW SLAVE STATUS）：采集简单，但无法聚合历史数据，且无法自定义告警规则。
- 自建Prometheus + mysqld_exporter + Grafana：覆盖全面（延迟、io thread、sql thread、binlog大小等），但需要维护中间件，且跨云多区域部署时网络打通成本高。
- 云厂商RDS监控：免运维，提供了延迟趋势图、慢查询分析，但无法对自定义指标（如半同步退化次数）设置告警。
最后我们采用混合策略：核心指标（延迟、IOPS、连接数）走云监控告警（因为响应快、触达渠道全）；辅助指标（GTID gap、半同步退化、从库复制错误码）走自建，并关联到PagerDuty。
4.2 一个奇怪的坑：从库一直卡在Waiting for dependent transaction
这是我们在对比测试中遇到的——半同步模式下，从库有时会长时间等待一个已提交但未同步的事务。排查发现是并行复制配置不当，导致依赖关系锁死。解决方案：将slave_parallel_workers从4降低到2，并调整slave_pending_jobs_size_max。调整后平均复制延迟从7秒降到1.2秒。
延伸阅读：此处可内链到“RDS高可用主从架构配置案例”相关文章。
五、选型建议：别盲目追求“弹性”，先看看这些数字与RDS高可用主从架构
验证与回滚
通过上述对比，我给出三点实操建议：
- 读多写少场景：优先使用异步复制+Proxy模式，从库弹性扩容采用clone plugin方案，不要轻易升级到组复制（复杂度过高且性能收益不大）。
- 写密集型场景：强制半同步复制+主库限流（如阿里云SQL限流或自建qps限制），从库数量不易超过3个（过多从库会反向拖慢主库导致复制风暴）。
- 预算有限的小团队：不要自己折腾MySQL Router，直接上云原生的读写分离地址（例如阿里云实例的“只读实例”功能），虽然贵一点但省心；弹性扩容时注意先创建只读实例再加入集群，避免主库dump。
最后分享一个血泪教训：无论选哪种架构，一定在业务低峰期做故障演练。我们曾自信满满认为主从切换完美，结果真正切换时发现DNS缓存导致部分流量五分钟内仍打到老主库。性能对比虽好，但真正的弹性在于系统对异常的兜底能力。按这个顺序复查，RDS高可用主从架构遇到异常时也更容易定位。
延伸阅读