如何在 Google Cloud Platform 上进行 Django 迁移?

igs*_*gsm 5 django google-app-engine google-cloud-sql google-cloud-platform

我想在 Google App Engine 上托管我的应用程序,并拥有一个用于数据库的 Google SQL 实例。该应用程序的主要部分是使用 Django Rest Framework 构建的 API。当我需要修改数据库的架构时,我向 Google Cloud 支持人员询问了在生产中进行迁移的最佳实践。由于我是 Web 开发的新手,也许这里的任何专家都有类似的经验,并且可以验证建议的过程是否是我真正可以遵循的?

对于数据库迁移最佳实践,您可以为 Cloud SQL 数据库创建单独的开发/测试/备份实例。例如,假设您的生产数据库实例是 DB1,创建一个开发实例 DB2,其中包含 DB1 的所有表。之后,将您的应用程序配置为临时指向 DB2 实例。请确保两个实例同步并更新。然后,部署指向 DB2 的应用程序的新版本,以便您可以将 DB1(添加新表、列)更新为生产环境中的官方数据库实例。然后您可以再次将其指向 DB1 并更新 DB2。

Lun*_*ast 11

使用第二个 CloudSQL 来执行迁移确实是一个很好的做法。我建议:

  1. 部署新的 App Engine 版本,该版本使用新的 db 架构但尚未将流量定向到它(使用gcloud app deploy --no-promote
  2. 克隆您的 CloudSQL 实例以创建一个新实例,您将在其中运行迁移
  3. 在您的本地机器上,将Cloud SQL 代理配置为指向这个新的 CloudSQL 实例并运行python manage.py migrate
  4. 迁移完成后,将流量定向到新的 App Engine 版本。

在生产环境中,您的新 CloudSQL 实例将缺少在您执行步骤 2 到 4 时写入第一个实例的数据。完全避免这种情况的最简单解决方案是在迁移期间停止您的 App Engine 应用程序。但是,如果您无法承受一些停机时间,则需要在克隆第一个实例后跟踪对它所做的更改,并将这些更改手动应用于新实例。

  • 这是一个极其低效的解决方案。数据库可能有几 TB 大,并且每小时可能会进行多次部署。 (3认同)
  • 在复制的数据库上执行迁移是否值得同步在此过程中写入的更改?当然,在实时系统上执行迁移而不是安排停机时间会更好吗? (2认同)