【问题标题】:Handling Schema Migrations in App Engine在 App Engine 中处理架构迁移
【发布时间】:2016-04-12 17:33:17
【问题描述】:

通过在其中一个 App Engine 应用程序中移动一些属性,我更新了几个频繁使用的 NDB 模型。因此,一些模型现在包含我的应用程序的以前版本会在不同位置查找的数据(但这样做会失败)。我已经更新了我的处理程序,以确保在我运行伴随我发布的迁移之后不会发生这种情况。

但是,我担心架构迁移时会发生什么。我已经用几百个实体在本地测试了我的迁移,任务大约需要 1 秒(使用延迟的)。由于我有超过 1000 个生产实体,我想这个任务实际上需要几秒钟。同时,我相信用户会遇到服务问题。

从其他问题(例如this one)中,我收集到一个好的做法是将用户重定向到一个页面,该页面会提醒他们计划停机进行维护。但是,这对我来说并不是一个真正的选择——我们需要尽可能延长正常运行时间。

因此,我的问题是:有没有办法让我的应用程序保持在线并仍然执行可能很长的迁移?我正在考虑使用 App Engine 的“流量拆分”在新应用版本迁移时让用户继续使用旧应用版本,但这仍然会导致服务问题。

【问题讨论】:

    标签: google-app-engine database-migration google-cloud-datastore


    【解决方案1】:

    您可以进行 2 次迁移(add + delete)而不是一次(move)。

    第一次迁移只是添加要移动到模型中的新位置的属性。

    更新读取属性的代码以首先检查新位置,如果属性不存在,则回退到旧位置。对于 2 个位置,查询可能需要加倍,并添加逻辑以识别和跳过重复的结果。几乎是新旧代码的组合。

    然后您可以更新编写属性的代码以使用新位置。在此之后创建的实体将不再具有旧位置。如果您想玩得更安全(能够回滚到旧代码版本),或者如果您想让旧版本的应用程序运行一段时间,您可以让编写代码在新旧位置都编写。

    然后运行一次性作业,将属性内容从旧位置(如果存在)复制到新位置。这可确保所有实体的所有属性都存在于新位置。

    此时您可以删除所有访问旧位置的代码。

    这是不归路。在下一步之前,您需要停止运行旧应用程序代码的任何 GAE 实例 - 它们将无法再正常运行,并且如果没有另一个数据库更新作业,您将无法回滚您的代码。

    然后运行一次性清理作业,从所有实体的旧位置删除属性 - 最新版本的代码不再访问它们。

    完成第二次迁移删除模型中旧位置的属性。

    可能工作量很大,但无论迁移的持续时间如何,都应该可以实现零停机时间(对于最新的应用程序版本)。

    更新:

    How to rename a Datastore entity field but be able to retrieve records via old and new property names? 中描述了一种可能更好的迁移算法(避免有问题的OR'd 双重查询)

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2015-08-05
      • 1970-01-01
      • 2011-05-24
      • 2011-01-22
      • 2016-05-25
      • 2018-08-14
      • 2013-12-06
      • 1970-01-01
      相关资源
      最近更新 更多