mysql on cloudplz

Aurora 迁移工具集

Mon, 01 Jan 0001 00:00:00 +0000

迁一套数据库到 Aurora，那是个项目。迁五十套 —— 里面还有数 TB、7×24 写入的 tier-0 系统 — — 那就是一套平台。这套工具链和方法论，让迁移变成可重复的事。

Vitess 生产部署

Mon, 01 Jan 0001 00:00:00 +0000

Vitess 连跑三年生产环境，横向扩展真正咬人的地方就露出来了：是运维纪律，不是 demo。这里记的是：跑那套系统要付出什么。它撑着 YouTube 那批 MySQL 集群。我们规模比 YouTube 小得多，而这让整笔账不一样。

Vitess vs Aurora：MySQL 扩展该怎么选

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

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

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