50 套生产库迁到 Aurora，停机不到 3 分钟

Thu, 10 Sep 2026 00:00:00 +0000

大约两年时间，我们把约 50 套生产库从自建 MySQL 迁到 AWS Aurora。最大的几套是数 TB 的 tier-0 系统， 7×24 写入。多数切换停机压在 3 分钟以内。

这个数字不靠维护窗口里小心点几下。它来自把停机预算当作 设计输入：一旦「3 分钟」变成硬性要求，而不是一句期望，后面每个决定 —— 复制拓扑、演练门禁、连接排空、DNS 权重 — — 都被逼出一种具体形态。这篇写的就是这条约束逼出来的方法论，外加路上真正咬过我们的那几口。

Vitess vs Aurora：MySQL 扩展该怎么选

Fri, 20 Dec 2024 00:00:00 +0000

单实例 MySQL 一旦到顶，你手上就只剩三条路，哪条都不轻松：给应用写自研分片逻辑、换一套数据库系统，或者上一套 Vitess 这样的集群方案。

先说结论，你据此决定要不要往下读：在生产环境跑了 3 年 Vitess 之后，我们把它换掉了 — — 换成 Aurora。 不是 Vitess 不行，而是撑起它运维成本的那项能力 —— 横向写分片 — — 我们从来就没真正需要过。你的写流量确实超过一台大规格主库的上限 —— 指的是持续每秒几万次写，不是突发峰值 —— 那 Vitess 很可能就是你的答案，这篇文章会说清运维它要付什么代价。低于这条线，Aurora 几乎肯定是更优解，这篇文章会说清为什么。

database on cloudplz

50 套生产库迁到 Aurora，停机不到 3 分钟

Vitess vs Aurora：MySQL 扩展该怎么选