本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 割接
数据库割接策略通常与应用程序的停机时间要求密切相关。可用于数据库割接的策略包括离线迁移、快闪迁移、主动/主动数据库配置和增量迁移。以下各节将讨论这些内容。
## 离线迁移
如果可以在写入操作期间让应用程序长时间脱机，则可以使用 AWS DMS 满载作业设置或离线迁移选项之一进行数据迁移。迁移进行期间，读取流量可以继续，但必须停止写入流量。由于需要从源数据库复制所有数据，因此会占用源数据库资源，例如 I/O 和 CPU。
总体来说，离线迁移涉及以下步骤：
1. 完成架构转换。
1. 开始停机写入流量。
1. 使用离线迁移选项之一迁移数据。
1. 验证您的数据。
1. 将应用程序指向新数据库。
1. 结束应用程序停机时间。
## 快闪迁移
在快闪迁移中，主要目标是将停机时间降至最低。此策略依赖于从源数据库到目标数据库的连续数据复制 (CDC)。迁移数据时，当前数据库上的所有读/写流量都将继续。由于需要从源数据库复制所有数据，因此会占用源服务器资源，例如 I/O 和 CPU。您应该进行测试以确保此数据迁移活动不会影响您的应用程序性能 SLA。
总体来说，快闪迁移涉及以下步骤：
1. 完成架构转换。
1. 在连续数据复制模式下设置 AWS DMS。
1. 当源数据库和目标数据库同步时，请验证数据。
1. 启动应用程序停机时间。
1. 推出该应用程序的新版本，该版本指向新数据库。
1. 结束应用程序停机时间。
## 主动/主动数据库配置
主动/主动数据库配置包括设置一种机制，在源数据库和目标数据库都用于写入流量时保持源数据库和目标数据库同步。与离线或快闪迁移相比，此策略涉及更多工作量，但在迁移期间亦提供了更大的灵活性。例如，除了在迁移期间最大限度地减少停机时间外，您还可以按受控的小批量将生产流量转移到新数据库，而不必执行一次性割接。您可以执行双写操作以便对两个数据库进行更改，也可以使用类似 [HVR](https://www.hvr-software.com/product/) 的双向复制工具来保持数据库同步。这种策略在设置和维护方面更加复杂，因此需要进行更多测试以避免数据一致性问题。
总体来说，主动/主动数据库配置涉及以下步骤：
1. 完成架构转换。
1. 将现有数据从源数据库复制到目标数据库，然后使用双向复制工具或从应用程序进行双向写入，使两个数据库保持同步。
1. 当源数据库和目标数据库同步时，请验证数据。
1. 开始将一部分流量转移到新数据库。
1. 继续转移流量，直到所有数据库流量都转移到新数据库。
## 增量迁移
在增量迁移中，您可以将应用程序分成较小的部分迁移，而不是执行一次性的完全割接。根据您当前的应用程序架构或您意愿在应用程序中进行的重构，这种割接策略可以有多种变化。
您可以使用[设计模式](https://samirbehara.com/2018/09/10/monolith-to-microservices-using-strangler-pattern/)添加新的独立微服务，以替换现有整体遗留应用程序的某些部分。这些独立的微服务有自己的表，应用程序的任何其他部分都不能共享或访问这些表。您可以使用任何其他直接割接策略将这些微服务逐一迁移到新数据库。迁移后的微服务开始使用新数据库进行读/写流量，而应用程序的所有其他部分则继续使用旧数据库。迁移完所有微服务后，即可停用遗留应用程序。这种策略将迁移分成更小、更易于管理的部分，因此可以减少一次性大规模迁移带来的风险。