GAE CloudSQL的最佳迁移策略是什么？

Question

我真的找不到有关如何使用Google App Engine和CloudSQL处理迁移的文档。我正在使用Go运行时。

显然，随着时间的推移，应用程序的模式将会发生变化和演变，并且需要运行迁移。目前我是手动运行迁移。这不可扩展。

是否有人有解决方案？

我看到了一些特定的挑战：

• 我可以使用VersionID获取当前app.yaml部署版本的版本号。但是，如何检查是否对此版本进行了迁移？我需要在数据库表中保留一个版本号，并在init()函数中检查吗？

• 然而，当您上传应用的新版本并使用新模式时，GAE将逐渐迁移您的流量，这意味着一旦新版本中第一个init()实例运行并完成迁移后，旧版本的流量在这些db事务中将失败。

• 通过为我的API进行版本控制，我可以在某种程度上减轻上述问题。但是，这限制了迁移策略，例如删除表等。

最后，我很失望没有找到任何文档。

- Ralph Pina

---

我认为没有任何特定于环境的独特问题。Cloud SQL只是mysql，而gae只是您运行代码的地方。 - Robert Moskal

可能感兴趣的至少一个特定案例：http://stackoverflow.com/questions/34670194/handling-schema-migrations-in-app-engine - Dan Cornilescu

@DanCornilescu 谢谢！不过那似乎是针对数据存储实体的。 - Ralph Pina

@RobertMoskal，我觉得你的说法不正确。虽然我刚涉足后端工作，并且大多数经验都是在客户端开发方面，但我认为GAE异步和分布式本质上带来了一些独特的挑战。我在我的问题中添加了一些具体内容。 - Ralph Pina

Answer 1

我同意 Robert 的观点，虽然这是一个具有挑战性的情况，但与 CloudSQL 关系不大。在任何需要迁移具有不同 SQL 模式的两个应用程序版本的情况下，基本上都会出现这种情况。

你基本上有两个选择：

1. 至少暂时使所有更改向后兼容。这可能涉及到一个中间版本的应用程序，可以优雅地处理模式的任何一个版本。

2. 像你描述的那样为你的应用程序/API 进行版本控制，将给定版本与给定模式相关联，并使用不同的数据库。这可能需要在两个数据库之间复制数据，这可能会使用比你想要的更多的存储空间。

通常向后兼容的方法是最好的，尽管你需要编写一些代码来处理不同的模式，但通常是可行的。

你询问如何确定特定版本是否具有给定迁移，但请记住，迁移是数据库的属性，而版本是应用程序的属性。因此，问题实际上只是版本正在与哪个数据库交互，以及该数据库的模式是什么。你提出的为数据库中的迁移设置“版本”号码的想法实际上相当合理，许多 ORM 都有这方面的特性。

这个问题存在的事实就是为什么你通常最好在首次创建应用程序原型时采用更灵活的数据建模方法（允许更多的 NULL，不使用外键，或者只是使用 NoSQL 方法，如 Datastore），并在对数据模型更有信心后再实现更多的数据完整性。

最后，我在 Google Cloud 文档中工作，如果您对我们没有更清晰地解释这个问题感到失望，我很抱歉。但希望您理解这是一个一般的数据库操作问题，而不是针对 Google Cloud 或 App Engine 的特定问题。如果你找到了自己喜欢的解决方案，可以考虑写博客，我们将很乐意帮助推广你的解决方案！

- Bill Prin