Google Cloud允许您使用数据库迁移服务（DMS）将PostgreSQL数据库移动到云SQL。DMS使您能够在源在生产环境中运行时，将数据连续复制到目标数据库，使您能够以最少的停机时间进行迁移。

但是，TB级的迁移可能很复杂。例如，如果您的PostgreSQL数据库有大型对象，那么您将需要一些停机时间来手动迁移它们，因为这是DMS的限制。还有一些这样的限制-查看DMS的已知限制。如果处理不当，这些步骤可能会延长切换期间的停机时间，导致对源实例的性能影响，甚至延迟项目交付日期。所有这些都可能意味着重大的业务影响。

Searce是一家技术咨询公司，专门通过利用云、数据和人工智能实现应用程序和数据库基础设施的现代化。我们使客户能够加速实现其业务的未来。在我们的过程中，我们帮助了数十个客户端迁移到云SQL，并发现由于前面提到的原因，TB级迁移是最困难的。

本博客围绕我们支持企业客户机的工作展开，该客户机的目标是将数十TB级的任务关键型PostgreSQL数据库迁移到云SQL，并将停机时间降至最低。他们最大的数据库大小为20TB，所有数据库都有带有大型对象的表，有些表没有主键。请注意，DMS有一个限制，即在本项目期间不支持迁移没有主键的表。2022年6月，DMS发布了一项增强功能，支持无主键的表迁移。

在本博客中，我们将与您分享我们如何简化和优化此迁移的经验，以便您可以将我们的最佳实践融入到您自己的迁移中。我们探索了使用自动化脚本将DMS未处理的操作所需的停机时间减少约98%的机制。我们还探索了PostgreSQL中的数据库标志，以优化DMS性能，并将总迁移时间减少约15%。

使用数据库标志优化DMS性能

一旦客户决定将PostgreSQL数据库迁移到Google Cloud SQL，我们就考虑了两个决定业务影响的关键因素——迁移工作和迁移时间。为了最大限度地减少PostgreSQL数据库的迁移工作，我们利用了Google Cloud的DMS（数据库迁移服务），因为它非常易于使用，并且在源数据库处于生产状态时，通过不断地将数据从源数据库复制到目标云SQL实例来完成繁重的工作。

迁移时间呢？对于TB级数据库，根据数据库结构，迁移时间可能要长得多。从历史上看，我们观察到DMS迁移1 TB数据库需要大约3个小时。在客户数据库结构更复杂的其他情况下，迁移需要更长时间。谢天谢地，当源数据库在生产中运行时，DMS负责复制，因此在此期间不需要停机。然而，我们的客户将不得不承担源数据库和目标数据库的成本，对于大型数据库来说，这可能是巨大的。同时，如果数据库大小增加，则复制可能需要更长的时间，从而增加了因切换操作期间发生的停机而错过客户维护窗口的风险。由于客户的维护窗口是每月一次的，我们将不得不再等待30天才能进行下一个维护窗口，这要求客户再承担30天的两个数据库的成本。此外，从风险管理的角度来看，迁移时间越长，出错的风险就越大。因此，我们开始探索减少迁移时间的选项。即使迁移时间只稍微缩短，也可以显著降低成本和风险。

我们探讨了在源数据库上调优PostgreSQL数据库标志的选项。虽然DMS对源实例和数据库有自己的一组先决条件标志，但我们还发现，像shared_buffers、wal_buffers和maintenance_work_mem这样的标志有助于通过DMS加速复制过程。需要将这些标志设置为特定的值，以获得每个标志的最大好处。一旦设置，它们的累积影响是DMS复制1 TB数据库的时间减少了4小时，即20 TB数据库减少了3.5天。让我们深入研究每一个问题。

共享缓冲区

PostgreSQL使用两个缓冲区——它自己的内部缓冲区和内核缓冲IO。换句话说，该数据存储在存储器中两次。内部缓冲区称为shared_buffers，它决定了数据库用于操作系统缓存的内存量。默认情况下，此值设置为保守的低值。然而，在源数据库上增加这个值以适应我们的用例有助于提高读重操作的性能，这正是DMS在初始化作业后所做的。

经过多次迭代后，我们发现，如果将该值设置为数据库实例RAM的55%，它将大大提高复制性能（大量读取操作），进而减少复制数据所需的时间。

WAL缓冲区

PostgreSQL依赖于预写日志（WAL）来确保数据完整性。WAL记录被写入缓冲区，然后刷新到磁盘。标志wal_buffers确定了用于wal数据的共享内存量，该数据尚未写入磁盘，即尚未刷新的记录。我们发现，将wal_buffers的值从默认值16MB增加到数据库实例RAM的大约3%，通过在每次事务提交时向磁盘写入更少但更大的文件，显著提高了写入性能。

Mem的维护工作

PostgreSQL维护操作，如真空、创建索引和ALTER TABLE ADD外键，会消耗自己的特定内存。该存储器被称为maintenance_work_mem。与其他操作不同，PostgreSQL维护操作只能由数据库顺序执行。设置一个明显高于默认值64 MB的值意味着没有维护操作会阻止DMS作业。我们发现maintenance_work_mem在1GB的值下工作得最好。

调整源实例的大小以避免性能影响

这三个标志都调整了PostgreSQL如何利用内存资源。因此，在设置这些标志之前，我们必须升级源数据库实例以容纳它们。如果不升级数据库实例，我们可能会导致应用程序性能下降，因为超过一半的数据库内存将分配给这些标志管理的进程。

我们计算了上述标志所需的内存，发现每个标志都需要设置为源实例内存的特定百分比，而不考虑可能为标志设置的现有值：

1.shared_buffers：源实例内存的55%

2.wal_buffers：源实例内存的3%

3.maintenance_work_mem：1 GB

我们通过标记添加了单独的内存需求，发现这些内存标记至少占用了58%的RAM。例如，如果源实例使用100GB内存，则shared_buffers和wal_Butters将占用58GB内存，maintenance_work_mem将占用额外1GB内存。由于这些标志的原始值非常低（~200MB），我们将源数据库实例的RAM增加了60%，以确保迁移不会影响应用程序在生产中的源性能。

使用WAL发送器超时标志避免连接错误

使用Google Cloud的DMS时，如果在DMS作业的“正在进行的完全转储”阶段，DMS和云SQL实例之间的连接终止，则DMS作业将失败，需要重新启动。遇到超时，特别是在迁移TB级数据库时，将意味着损失数天的迁移时间和切换计划的延迟。例如，如果20TB数据库迁移的DMS作业的连接在10天后丢失，则必须从头开始重新启动DMS作业，从而导致10天的迁移工作丢失。

调整WAL发送器超时标志

（WAL_sender_timeout）有助于我们避免终止在完全转储阶段长时间处于非活动状态的复制连接。此标志的默认值为60秒。为了避免这些连接终止，并避免此类影响较大的故障，我们在数据库迁移期间将此标志的值设置为0。这将避免连接终止，并允许通过DMS作业进行更平滑的复制。

通常，对于我们在这里讨论的所有数据库标志，我们建议客户在迁移完成后恢复默认标志值。

通过自动化减少DMS限制所需的停机时间

当源数据库实例在生产中运行时，DMS通过连续复制完成大部分数据库迁移，但DMS具有某些迁移限制，这些限制在数据库运行时无法解决。对于PostgreSQL，DMS的已知限制包括：

1.DMS作业初始化后在源PostgreSQL数据库上创建的任何新表都不会复制到目标PostgreSQL数据。

2.不迁移源PostgreSQL数据库中没有主键的表。对于这些表，DMS只迁移了模式。2022年6月产品更新后，这不再是限制。

3.DMS不支持大对象（LOB）数据类型。

4.仅迁移物化视图的模式；不迁移数据。

5.所有迁移的数据都是在cloudsqlexternalsync的所有权下创建的。

我们必须手动处理数据库迁移的这些方面。由于我们的客户机的数据库中有大型对象数据类型的数据，没有主键的表，以及DMS无法迁移的频繁变化的表结构，所以在DMS完成大部分数据迁移后，我们必须手动导出和导入这些数据。数据库迁移的这一部分需要停机以避免数据丢失。对于一个TB级的数据库，这些数据可以达到数百GBs，这意味着迁移时间更长，因此停机时间更长。此外，当您有几十个数据库要迁移时，在切换窗口期间，人工在时钟上执行这些操作可能会带来压力并容易出错！

这就是自动化帮助我们节省时间的地方！在停机期间自动化迁移操作不仅减少了手动工作和错误风险，还提供了可扩展的解决方案，可用于将100多个PostgreSQL数据库实例迁移到云SQL。此外，通过利用多处理和多线程，我们能够将100Gbs数据的总迁移停机时间减少98%，从而减少对客户的业务影响。

如何到达？

我们列出了停机期间需要执行的所有步骤，即DMS作业完成从源到目标的复制之后，以及将应用程序切换到迁移数据库之前。您可以在图1中看到一个图表，该图表描绘了停机期间执行的操作序列。

通过以这种顺序方法自动化所有停机操作，我们观察到，对于一个1 TB的数据库，执行整个停机流程需要13个小时。这包括在新表中迁移250 MB，在没有主键的表中迁移60 GB，在大型对象中迁移150 GB。

我们所做的一个关键观察是，在所有步骤中，只有三个步骤占用了大部分时间：迁移新表、迁移没有主键的表和迁移大型对象。这些操作花费的时间最长，因为它们都需要对各自的表进行转储和恢复操作。然而，这三个步骤彼此之间没有硬依赖关系，因为它们分别针对不同的表。因此，我们试图并行运行它们，如图2所示。但它们后面的步骤-“刷新物化视图”和“恢复所有权”必须顺序执行，因为它们针对整个数据库。

然而，并行运行这三个步骤需要升级云SQL实例，因为我们希望每个步骤都有足够的可用资源。这导致我们将云SQL实例的vCPU增加了50%，内存增加了40%，因为导出和导入操作严重依赖于vCPU消耗，而不是内存消耗。

迁移新表（在DMS作业启动后创建）和没有主键的表非常简单，因为我们能够利用PostgreSQL提供的本地实用程序-pg_dump和pg_ restore。这两个实用程序都使用多个线程并行处理表——表计数越高，可以并行执行的线程数就越高，从而允许更快的迁移。使用这种改进的方法，对于相同的1 TB数据库，执行整个停机流程仍然需要12.5小时。

这一改进减少了切换停机时间，但我们仍然发现我们需要12.5小时的时间来完成所有步骤。然后我们发现，99%的停机时间只需要一个步骤：导出和导入150 GB的大型对象。事实证明，在PostgreSQL中，多线程不能用于加速转储和恢复大型对象。因此，单独迁移大型对象将迁移的停机时间延长了几个小时。幸运的是，我们能够找到一个解决方法。

优化从PostgreSQL数据库迁移大型对象

PostgreSQL包含一个大型对象工具，提供对存储在特殊大型对象结构中的数据的流式访问。当存储大型对象时，它们被分解为多个块并存储在数据库的不同行中，但在单个对象标识符（OID）下连接。因此，此OID可用于访问任何存储的大型对象。尽管用户可以将大型对象添加到数据库中的任何表中，但在后台，PostgreSQL将数据库中的所有大型对象物理存储在一个名为pg_largeobjects的表中。

当利用pg_dump和pg_ restore导出和导入大型对象时，这个单一的表-pgUlargeObject成为瓶颈，因为PostgreSQL实用程序无法执行多个线程进行并行处理，因为它只是一个表。通常，这些实用程序的操作顺序如下：

1.pg_dump从源数据库读取要导出的数据

2.pg_dump将该数据写入正在执行pg_ dump的客户端的内存

3.pg_dump将内存写入客户端的磁盘（第二次写入操作）

4.pg_restore从客户端磁盘读取数据

5.pg_restore将数据写入目标数据库

通常，这些实用程序需要按顺序执行，以避免由于进程冲突而导致的数据丢失或数据损坏。这导致大型对象的迁移时间进一步增加。

这个单线程过程的解决方法涉及两个元素。首先，在我们的解决方案中，我们消除了第二个写入操作-从内存写入磁盘（点#3）。相反，一旦数据被读取并写入内存，我们的程序将开始导入过程并将数据写入目标数据库。其次，由于pg_dump和pg_ restore不能使用多个线程来处理pgulargeobjects表中的大型对象，因此我们自己开发了一个可以使用多线程的解决方案。线程计数基于表-pg_largeobjects中OID的数量，并将单个表分解为更小的块，以便并行执行。

这种方法将大型对象迁移操作从数小时缩短到数分钟，因此将DMS无法处理的所有操作所需的停机时间从13小时缩短到18分钟。所需停机时间减少约98%。

结论

经过多次优化和试运行后，我们能够为客户开发一个过程，将数十TB级的PostgreSQL数据库迁移到Google Cloud SQL，而对业务的影响最小。我们开发了使用数据库标志优化基于DMS的迁移15%的实践，并在自动化和创新的帮助下减少了98%的停机时间。这些实践可用于将PostgreSQL数据库迁移到Google Cloud SQL的任何TB级迁移，以加速迁移、最小化停机时间并避免对关键任务应用程序的性能影响。

原文标题：Optimizing terabyte-scale PostgreSQL migrations to Cloud SQL with Searce
原文作者：Chinmay Joshi，Karan Kaushik
原文链接：https://cloud.google.com/blog/products/databases/reduce-downtime-for-postgresql-migration-to-google-cloud-sql