Google Cloud SQL - 将实例从一个项目移动到另一个项目，且停机时间为零？

Question

以最短或零停机时间将 Google Cloud SQL 实例（Postgres 9.6）从一个 Google 项目移动到另一个项目的最简单方法是什么？实例大小约20GB

有一项名为“迁移作业”的服务，看起来非常相关https://cloud.google.com/database-migration/docs/postgres/create-migration-job。但我不明白它是否可以用于将实例从一个谷歌项目移动到另一个项目。

从备份进行简单恢复并不是我真正的情况，因为我希望实现尽可能短的停机时间，所以我正在寻找诸如 2 个具有同步实时数据的运行实例之类的东西。

PS。我还使用 pgbouncer 配置了虚拟机

Answer 1

是的，数据库迁移服务可用于将一个 Cloud SQL 实例从一个 GCP 项目移动到另一个。这是比下一种方法更便宜的方法，虽然它需要更多的设置，但它也应该更快。可以为现有 Cloud SQL 实例创建连接配置文件，并且必须在目标项目中创建 Cloud SQL 目标，但一旦一切设置完毕，大部分迁移将自动完成。这是一个有据可查的过程，您可以在我们的文档中找到相关信息。

开发人员有时希望以“零”停机时间迁移他们的（正常）关系数据库。 虽然可以减少停机时间，但迁移无法在不对应用程序产生任何影响的情况下完成（即零停机时间）。复制会导致复制滞后。

一旦决定将所有应用程序从一个副本“迁移”到另一个副本，应用程序（以及开发人员）在使用新数据库之前必须等待（即停机）至少与“复制延迟”一样长的时间。实际上，停机时间要高几个数量级（分钟到小时），因为：

• 数据库查询可能需要几秒钟才能完成，并且动态查询必须在迁移时完成或中止。
• 如果数据库具有大量缓冲内存，则必须“预热”数据库 - 这在大型数据库中很常见。
• 如果数据库分片有重复的表，在迁移分片时可能需要暂停一些写入操作。
• 应用程序必须从源停止并在 GCP 中重新启动，并且必须建立与 GCP 数据库实例的连接。
• 必须重新路由到应用程序的网络路由。根据 DNS 条目的设置方式，这可能需要一些时间。

所有这些都可以通过一些规划和“成本”来减少（某些操作在迁移之前/之后的一段时间内不允许）。

减少源数据库上的负载直到迁移完成可能会有所帮助，并且停机时间可能会减少中断。

其他注意事项：

1. 增加机器类型增加网络吞吐量。
2. 增加 SSD 大小以获得更高的 IOPS/MBps。

更多关于。

最直观的方法是将数据从Cloud SQL实例导出到GCS存储桶，然后将其导入到新项目中的新实例。这意味着需要一些停机时间，并且您必须在目标项目中手动创建具有与原始配置相同的实例；它确实需要一些手动步骤，但这将是一种在不同项目中的实例之间复制数据的简单且可验证的方法。

Answer 2

鉴于它似乎是一个常见的用例，这令人惊讶地记录不足。

我找不到任何针对 Cloud SQL => Cloud SQL 跨项目的 DMS 的内置支持。 DMS 似乎没有任何能力在另一个项目中选择 Cloud SQL 实例。

以下是唯一对我有用的东西：

1. 在destination项目中使用DMS，而不是源项目。
2. 创建一个到源数据库的连接配置文件，将其描述为 Postgres——即“自我管理的 Postgres”。您将欺骗 GCP，使其认为它不是 Cloud SQL 实例。否则，您将仅限于当前项目中的实例。
   • 由于您告诉 DMS 这不是 Cloud SQL，而是普通 Postgres，因此您必须为源数据库配置逻辑复制，就像它是普通 Postgres 一样。
   • 这意味着在配置源中，您应该遵循本地或自我管理的 PostgreSQL 说明。
   • 例外情况是，您仍然需要设置

     cloudsql.logical_decoding

     和

     cloudsql.enable_pglogical

     标志，这将导致 Cloud SQL 在服务器上安装扩展程序，因为您自己无法执行此操作。基本上，阅读自我管理指令和 Cloud SQL 指令并将两者“合并”。
   • 连接配置与 Cloud SQL 完全相同
3. 创建并运行迁移作业，在当前项目中配置目标数据库

祝你好运！