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

Question

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

很明显，应用程序的架构会随着时间的推移而改变和发展，并且需要运行迁移。目前我手动运行迁移。这是不可扩展的。

有没有人有解决办法？

我看到了一些具体的挑战:

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

• 但是，当您上传新版本的应用程序时，使用新架构的 GAE 会慢慢地 migrate your traffic这意味着一旦您的新版本中的第一个 init() 实例运行并且迁移完成，到旧版本的流量将在这些数据库事务中失败。

• 我可以通过对 API 进行版本控制来稍微缓解上述问题。但是这限制了迁移策略，比如丢表等。

最后，我很失望没有documentation据我所知。

Answer 1

我必须同意 Robert 的观点，虽然这是一个具有挑战性的情况，但它与 CloudSQL 关系不大。几乎任何需要迁移具有不同 SQL 架构的两个版本的应用程序的情况都会造成这种情况。

你基本上有两个选择

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

• 按照您的描述对您的应用程序/API 进行版本控制，将给定版本与给定模式相关联并使用不同的数据库，这可能需要在两个数据库之间复制数据，这可能会使用比您多得多的存储空间喜欢。

向后兼容的方法通常是最好的，尽管你会得到一些丑陋的代码来处理不同的模式。但通常可以做到。

您问的是如何获得给定版本是否具有给定迁移，但请记住迁移是数据库的一个属性，而版本是应用程序的一个属性。所以问题实际上只是版本正在与哪个数据库对话以及该数据库的模式是什么。您对数据库中迁移的“版本”号的想法实际上是非常合理的，许多 ORM 都为此提供了某种功能。

存在此问题的事实是为什么您在首次制作应用程序原型(prototype)时通常最好使用更灵活的数据建模方法(允许更多 NULL，不使用外键，或者只使用像 Datastore 这样的 NoSQL 方法)，然后实现一旦您对自己的数据模型更有信心，就可以提高数据完整性。

最后，我负责 Google Cloud 文档，如果您对我们没有更清楚地解决这个问题感到失望，我深表歉意，但希望您能理解这是一个一般的数据库操作问题，而不是特定于 Google 的问题云或应用引擎。如果您确实提出了自己喜欢的解决方案，您应该考虑将其写成博客，我们很乐意帮助推广您的解决方案!