Vitess 生产部署

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

问题

一套 MySQL 部署顶到了垂直扩展的天花板。写入量和工作集，单台调优到位的实例已经吞不下。 可用性要求又排除了裸的主库故障转移。

做法

• 先别分片。 数据还装得进一个分片的时候，Vitess 先帮忙管拓扑、故障转移和连接池。 运维收益早来了好几年，分片那笔收益当时还用不上。
• 把重分片当成演练过的操作。 VSchema 驱动的一套流程，在 staging 副本上练，服务切换和回滚都演练过。
  • 成本要算清楚。 Vitess 买到的扩展性，代价是分布式系统那笔税：新的故障模式、 更重的 on-call 负担，还有应用侧必须顾及分片边界的查询写法。

结果

三年稳定生产运行，也更清楚这笔税什么时候值得交。后来托管 Aurora 能满足 workload 的实际需求， 我们迁出时和当初迁入一样，做了充分的规划。