最近，Etsy 的工程团队介绍了他们如何将长期运行的 MySQL 分片基础设施迁移至 Vitess。此次迁移将分片路由逻辑从 Etsy 内部系统迁移到了 Vitess，并通过 vindexes（虚拟索引）实现了数据重新分片、对原先未分片的表进行分片等功能。
Vitess 是一个用于 MySQL 水平扩展的开源数据库集群系统。它最初作为中间层部署在 ORM（对象关系映射）框架与数据库之间，负责查询路由，而由 ORM 继续指定目标分片。
在 Vitess 中，vindexes 定义了应用数据如何映射到数据库分片，以及查询如何在分片间进行路由。Etsy 高级软件工程师 Ella Yarmo-Gray 介绍了 Etsy 在迁移过程中面临的挑战：
随着新基础设施部署完成，我们开始着手研究 vindexes，它定义了 Vitess 内部的分片策略。由于 ORM 的分片映射是随机的，而非基于算法实现，如果采用现成方案，就需要对所有数据重新分片——这一手动过程可能耗时数年。因此，我们选择编写自定义 vindexes，将现有的分片逻辑移植到 Vitess 中，从而在无需承担数据迁移的复杂度与风险的前提下测试 vindexes 在我们环境中的运行效果。
自 2010 年左右起，Etsy 便采用分片 MySQL 架构存储大部分的生产数据，并使用自研的分片逻辑。该架构目前包含约 1000 个分片、425 TB 数据，每秒可处理 170 万次请求。
Etsy 工程师通过内部的对象关系映射（ORM）层访问 MySQL，每个数据库表对应一个模型。对于分片表，模型中会定义一个名为 shardifier ID 的唯一 ID 字段，用于确定每条记录存储在哪个分片。尽管大多数模型使用 shop_id 或 user_id 作为分片键，但整体上共使用了三十多种不同的 ID，记录与分片的映射关系则存储在一个未分片的“索引”数据库中。这种方案提升了系统可扩展性，并能将故障影响控制在小部分流量范围内，但扩容操作缓慢且依赖人工执行，索引数据库存在单点故障问题，同时开发人员必须自行管理分片。
几年前，公司决定迁移至 Vitess，以便在保持 MySQL 兼容性的同时解决这些问题：移除“索引”数据库，并对开发人员屏蔽分片的复杂性。此次迁移需要重新设计部分数据模型以优化分片策略、选定分片键，并在验证数据一致性的同时逐步将生产流量切换到新环境。Yarmo-Gray 总结道：
五年后，在提交了约 2500 个拉取请求、执行了 6000 次查询后，我们成功将 Etsy 的分片管理迁移至 Vitess vindexes！尽管我们为简化迁移过程做了大量工作，但替换 Etsy 这种规模和历史积淀的代码库的数据库基础设施依然充满挑战。
在过去几年里，Etsy 工程团队发布了一系列题为《使用 Vitess 对支付系统进行分片》的文章，记录了他们针对支付平台的迁移工作，讲述了迁移数据模型时遇到的挑战，介绍了关键高流量系统的切换过程，并对切换风险进行了评估。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
查看英文原文：https://www.infoq.com/news/2026/04/etsy-vitess-sharding-migration/
