用云数据库 RDS for MySQL 做备份恢复与读写分离的实践笔记

业务库跑在自建 MySQL 上大半年，最近迁到了华为云 RDS for MySQL。这篇笔记不谈迁移本身，只记录迁完之后我把备份恢复和读写分离这两块「保命配置」补齐的过程和踩到的坑。

先把备份策略定下来

自建时代靠凌晨 mysqldump 定时任务，备份成功与否全看第二天有没有人记得检查。RDS 把这件事做成了配置项：自动备份保留天数我设了 7 天，备份窗口放在业务低谷的凌晨 3 点，额外开了一份跨区域备份——主区域真出问题时，至少还有一份异地数据能拉起来。

有个设置容易被忽略：备份保留时长决定了能回滚多远。有次测试环境需要恢复到 6 天前的数据，一看自动备份只留了 3 天，只能靠 binlog 硬啃。从那以后生产库的保留期我没再低于 7 天，重要系统 14 天起步。

恢复演练：没练过的备份等于没备份

RDS 恢复有两条路：从备份集恢复到新实例，或者按时间点恢复（PITR）。我挑了一个周末把两条路都真实跑了一遍，流程上没什么难度，控制台选备份点、建新实例、改连接串就行，半小时左右。但演练的价值在于发现问题：

• 恢复出来的新实例参数和主库不一致（max_connections 被重置成默认值），连接数打满过一次。解决办法是把参数模板先存好，恢复后第一件事就是套参数模板。
• 应用的连接串、只读账号权限都要在新实例上重新核对，别等切换那天才发现账号没授权。

建议每季度至少做一次恢复演练，并把耗时记下来——真出事时，恢复时长就是业务中断时长。

读写分离与只读实例

流量涨起来后，主库的慢查询日志开始刷屏，分析后发现七成是报表类的读请求。加了一个只读实例，开通数据库代理，读请求自动分流到只读，写和强一致读留在主库。

两个坑值得说：

主从延迟会咬人。 刚下单就查订单状态这类「写后立即读」的场景，碰上大事务同步时延迟能到秒级，用户会看到自己的订单「消失」。这类接口要在代码里显式指定走主库，代理的 Hint 注释或者连接串分组都能做，别指望全自动分流。

只读实例规格别省过头。 报表查询吃 CPU，只读实例规格比主库低太多时，慢查询会在只读侧堆积，延迟反而更大。我的经验是只读至少配到主库的七成，并单独给它设慢查询告警。

日常盯什么

迁移后我给自己定了三个日常动作：每周看一次备份成功列表和最近一次恢复演练记录；慢查询日志只盯新增的 Top 5，不追求全清；主从延迟超过 3 秒自动告警，超过 10 秒就把非核心读请求临时切回主库。

数据库这块没什么炫技空间，把备份、恢复、延迟这三件事做扎实，比任何调优技巧都管用。