同时部署多个模式更改
内容提要
PlanetScale采用近原子方式进行多重模式更改部署，确保生产数据库模式的稳定性。通过“门控部署”，所有更改可在准备就绪时同时应用，降低了不一致性风险。这种方法允许在部署期间取消更改，避免对生产环境的影响。同时，PlanetScale利用Vitess的schemadiff库处理依赖关系，确保模式更改的有效顺序，实现高效的数据库管理。
延伸解读
近原子部署的权衡
PlanetScale 采用“近原子”而非完全原子，是因为 MySQL 无法对多个表结构变更进行事务性原子操作。通过门控部署，所有变更在就绪后几秒内依次应用，将不一致窗口从数小时缩短到几秒。这降低了风险，但并非零风险，读者需理解其本质是工程上的折中。
门控部署的实用价值
门控部署允许在变更准备期间随时取消，且不影响生产环境。所有变更作为一个整体部署，要么全部成功，要么全部失败。这解决了传统数据库模式变更中部分应用、难以回滚的痛点，尤其适合大型表的多项关联变更。
依赖解析与并发控制
PlanetScale 利用 Vitess 的 schemadiff 库分析变更间的依赖关系，将变更分组为等价类，并确定有效的执行顺序。同时，通过 copy-and-swap 算法实现并发执行，交替进行数据拷贝以控制生产负载。这确保了复杂变更集的安全部署。
回滚机制与限制
部署完成后，PlanetScale 会暂存回滚操作，用户有 30 分钟窗口决定是否撤销，回滚按原部署的逆序近原子应用。但资源有限，同时变更大量表可能不可行，过于复杂的变更集可能无法找到安全路径，因此需谨慎设计变更。
Q&A
PlanetScale如何确保数据库模式的稳定性？
PlanetScale采用近原子方式进行多重模式更改部署，确保生产数据库模式在整个部署过程中保持稳定。
什么是门控部署，它有什么优势？
门控部署允许所有更改在准备就绪时同时应用，降低了不一致性风险，并且可以在部署期间取消更改，避免对生产环境的影响。
PlanetScale如何处理模式更改的依赖关系？
PlanetScale利用Vitess的schemadiff库处理依赖关系，确保模式更改的有效顺序。
在传统数据库中，模式更改的风险有哪些？
传统数据库中，模式更改被认为是危险的，可能导致生产系统宕机，且通常需要顺序执行，增加了不一致性风险。
如何在PlanetScale中实现并发的模式更改？
PlanetScale使用复杂的复制和交换算法来模拟ALTER TABLE操作，从而实现多个表的并发操作，控制切换时机。
如果需要取消部署，PlanetScale是如何处理的？
在部署完成之前，用户可以在30分钟内撤销所有模式更改，撤销操作也是近原子地应用，确保数据不丢失。
