Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说
docker 迁移_k8s和docker区别,希望能够帮助你!!!。

关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。

本文深入介绍了使用 AWS Data Migration Service 从本地 Oracle 19 数据库迁移到 AWS RDS PostgreSQL 的见解。

AWS Data Migration Service ( DMS ) 已被构建为数据迁移的瑞士刀。本文支持跨本地和 AWS 云的 13 个源和 15 个目标数据存储类型。唯一的条件是源或目标之一必须在 AWS 上。

处于云迁移和转型浪潮下的应用程序，基本上任何现代化和云原生的方法，都必须更快地解决数据问题。应用程序现代化/迁移只是数据迁移的一个用例。使用数据仓库、数据湖和 CDC 为 EDA、CQRS 和搜索等流解决方案构建数据管道。AWS Data Migration 支持其中的许多用例。

多次使用 AWS DMS 从本地 Oracle 19 迁移到 AWS RDS PostgreSQL 以进行云应用程序迁移，我记录了一系列源自经验、失败、命中和试验以及有关源数据库的事实的见解（挑战和缓解）是在本地设置的。这些可以被视为经验教训或不错的选择，但在我看来，对于任何相当复杂的异构数据迁移案例来说，这些都是司空见惯的。我从我的工作中引用的迁移始终是 Full Load，然后是 Ongoing Replication ( CDC )。因此，总是需要结合应用程序的推出来规划数据迁移。

以下是见解列表：

1. 在 AWS 上隔离 DMS 基础设施
2. 迁移用户提升 Oracle 权限的风险
3. 迁移序列
4. Oracle 本机网络加密与 Oracle SSL 钱包
5. 处理 Oracle DBLink
6. DMS 控制台上大表的验证状态冻结
7. 控制迁移并发和批处理
8. 使用 DMS 规则和过滤器使迁移可预测。
9. 使用模式转换工具自动化
10. 要跟踪的关键指标
11. DMS 迁移任务 - 验证和迁移前评估
12. 不可避免的维护窗口

本文的目的不是解释 AWS DMS 的设置，而是假定您熟悉基本的 AWS 服务。AWS 对AWS DMS 服务进行了详尽的记录。

高层设计

图 1 – DMS 设计

该设计经过简化以表示一些基本组件和概念：

AWS Direct Connect：显然，对于混合数据迁移，AWS VPC 和 On-Prem 之间的高速连接必须到位。在这种情况下，存在冗余的 AWS Direct Connectivity，并且 DMS VPC 使用连接到 DMS VPC 的共享服务 Transit Gateway。DMS 中的出站端点（源端点）通过 TGW 连接到 Oracle 实例，以进行全负载和持续复制。这是最基本的设置。

Network Segregation and Peering : 后面会详细解释，DMS已经设置在自己的VPC内，在DMS VPC中有一个跨两个AZ的子网组来支持DMS服务。此选择不同于AWS 在 DMS 文档中解释潜在拓扑的方式。原因和好处将在接下来的部分中进行解释。

通过 Direct Connect 和网络隔离和对等，数据不会离开单个区域。没有跨区域数据移动。这是客户端信息安全授权对数据驻留的关键要求。

来自 VPC 的 DNS 解析：虽然基于 IP 地址的查找通常有效，但如果使用 CA 证书和主机名检查，那么从 VPC 到本地服务进行 DNS 查找的能力是很有价值的。为了从 DMS VPC 启用 DNS 查询解析，VPC 通过 Route53 使用 AWS 提供的 DNS 查找。Route53 配置了一条规则，将 DNS 查找委托给出站 DNS 解析器，该解析器将常见本地域的 DNS 查找查询转发到本地 DNS 服务器。

IAM 角色：DMS 任务、源和目标端点在迁移生命周期的各个阶段承担角色。为 DMS 创建具有最少和特定权限的角色，以及 DMS VPC 内或与对等 RDS VPC 的安全组之间的窄网络访问。

在设置背景和设计中的一些见解后，接下来的部分将解释迁移期间为解决特定问题而遵循的一系列决策或实践，以及有关如何务实地处理迁移的关键方面的一些见解。

1. 在 AWS 上隔离 DMS 基础设施

AWS DMS 与在数据迁移任务中组合在一起的多个单独服务一起使用。这些资源中的大多数都是 VPC 绑定的。可以在“应用程序 VPC”中设置整个 DMS，即托管目标数据库（在我们的示例中为 AWS RDS PostgreSQL）的VPC 。AWS 推荐了不同的拓扑结构。我们推出的那个（参考图 1 中的设计）是对这些的选择性组合，其中 DMS 托管在其自己的专用 VPC 中，并与 RDS VPC 对等。具有 PrivateLink 的 VPC 端点也可以正常工作。这种拓扑有几个优点：

1. 在这种情况下，DMS 基础设施是临时的，仅在迁移期间需要。因此，应用程序服务和基础架构与 DMS 基础架构隔离开来，以干净地维护这些服务的生命周期。
2. Terraform IaC 管道是独立且干净的。两者中的任何更改都不会影响整个 Terraform 状态，如果 DMS 基础设施与“应用程序 VPC”共存，则不会发生这种情况。
3. 由于 DMS 与本地网络的连接，启用来自与应用程序 VPC 不同的 DMS VPC 的网络入口使得应用程序 VPC 中的路由规则、安全组和 NACL 不受影响。这也增强了安全性，因为仅出于数据迁移的特定原因才授予本地网络访问权限。

2. 迁移用户提升 Oracle 权限的风险

根据迁移的范围，任务可以是一次性完全加载和/或连续复制，又名 CDC，它基于允许读取重做日志（联机或归档重做日志）的 Oracle Log Miner API ). 源 oracle 端点的 DMS 用户需要对系统表、ALL_* DB 对象和 V_$* 对象具有 SELECT 授权。此外，用户还需要对 DBMS_LOGMNR 进行 EXECUTE 授权。与提供基本 CRUD 访问权限的普通应用程序数据库用户相比，此权限集得到提升并且更强大。两个更相关的问题：

1. 这些授权不能仅限于迁移范围内的特定模式，一旦获得授权，就可以访问 Oracle 19 实例上的所有数据库模式。
2. 并且需要在 AWS Secrets 中设置用户来配置 DMS 迁移任务的源端点。

根据组织的看法，这可能被视为一个阻碍。我不得不提出一个安全风险，经过深思熟虑后不得不接受，主要是因为没有等效的解决方案可用。这些赠款是为特定的迁移窗口提供的，然后被删除。迁移窗口以及拨款的公开很重要，特别是对于 CDC，这是一个长期运行、不断复制的过程。

正确理解特权和组织接受风险是最关键的一步，我不得不花费数周时间。

3. 迁移序列

我们广泛使用 Oracle 序列来生成递增的数字序列，用作实体的标识符和 PK。DMS 不会迁移序列状态。在表中生成和使用的序列号在完全加载和 CDC 期间作为表数据的一部分进行迁移。迁移完成后，PostgreSQL 中的序列需要重新建立基础；否则，新插入将导致 PK 违规错误。下面解释了这种情况。

在迁移之前，Oracle Sequence 已经达到了一些使用次数，并被实体用来提供下一个序号。

数据迁移完成后（即完全加载和 CDC），PostgreSQL 表由 DMS 填充数据。但是，PostgreSQL 中序列的状态保持不变。

在 PostgreSQL 中的新写入中，序列将提供一个起始编号，该编号可能通过数据在 Oracle 上处于活动状态时生成的旧 Oracle 序列值存在于表中。

为防止这种情况，在 PostgreSQL 中允许写入流量之前，应执行一个额外的步骤来重新设置序列的基数。rebase 将从引用序列的实体 PK 中获取最大值并更新序列状态

4. Oracle 本机网络加密与 Oracle SSL 钱包

AWS DMS 允许为源和目标终端节点上传公共客户端证书。这允许 DMS 任务在所有阶段使用基于 CA 证书的 SSL 连接。以Oracle为源，客户端证书需要设置为Oracle Wallet，需要在TNS listener中配置。另一种加密连接的方法是使用Oracle 本机网络加密 (NNE)，它允许连接加密。NNE 允许安全的 Oracle 客户端和 Oracle 实例公布加密信息并生成安全密钥。使用此选项，无需设置单独的 SSL 密钥。

虽然 DMS 文档非常详细地介绍了如何设置 Oracle Wallet，但没有太多关于如何支持 NNE 的内容。我们花了很多时间让 Oracle 管理员设置钱包（据我们了解，这是加密连接的唯一方法），但事实证明，如果启用 NNE，DMS 可以使用 NNE 与 Oracle 源通信。这通过监控 DMS 的会话得到证实。

显然，在同一个 TNS 侦听器上，不允许（或不鼓励）同时设置 NNE 和钱包。通常使用两者之一就足够了。使用 NNE 时，源端点无法导入证书，因此需要将 ssl_mode 设为 none。

5. 处理 Oracle DBLink

Oracle DB 链接是一种功能，允许一个 Oracle 实例为另一个数据库创建代理连接，以创建目标数据的视图，该视图在源模式中本地访问。这两个数据库作为一个逻辑数据库呈现给客户端应用程序。

DBLink 在微服务领域备受争议。DBLink 是一种服务跨越边界并为另一服务访问数据库的间接方式，尽管是数据库提供的功能。因此，这些是否应该用作模式是一个上下文讨论，具体取决于 DBLink 访问的数据的边界。

迁移 Oracle 的数据和架构时，DBLink 不会自动迁移到等效的 PostgreSQL 功能。如果目标平台也需要支持此功能，则必须单独处理 DBLink。

数据迁移与应用迁移相辅相成，在目标状态下，可能存在这些场景：

• 迁移后的 PostgreSQL 需要通过数据库本身与遗留 Oracle 集成。可能是因为遗留应用程序无法提供替代集成方式。
• 通过 DBLink 集成的应用程序不会随数据库一起迁移到 AWS RDS PostgreSQL，但没有对遗留服务进行重构以通过已发布的接口提供集成。

在这些场景中，仍然需要通过 PostgreSQL 支持集成，通过连接到上游遗留 Oracle 或上游迁移的 PostgreSQL 创建代理连接和视图。

要启用此模式，请使用允许类似功能的 PostgreSQL外部数据包装器扩展，尽管它支持多个数据库引擎。

这种支持应该被视为具有战略架构的战术，以支持应用程序提供的接口在服务的有界上下文内或跨服务的集成。

6. DMS 控制台上大表的验证状态冻结

在迁移满载后配置了验证阶段的大型表时，AWS 似乎无法更新表的验证状态，即使数字表明所有行都已传输和验证。

从上面可以看出，Full Load Rows 和 Total Rows 匹配，验证不是挂起的，也没有被暂停或失败，但验证状态是“Pending Validation”。

如果 DMS 仅用于 Full Load，则可以忽略此问题，因为此时 DMS 任务已停止。但是，如果 CDC 跟随满载，恢复任务将导致对该表的验证再次开始，因为 AWS DMS 检查状态字段并决定在 CDC 开始之前再次运行验证。如果没有对源数据库的写入，那么在 CDC 启动时再次进行验证是可以的（只是意味着要花费更多时间在迁移上），尽管如果源数据库开始看到写入并且 CDC 开始复制额外的写入，则验证可能由于记录不匹配而失败。避免这种情况的最佳方法是停止写入源数据库，直到所有模式和表都完成验证。

7. 控制迁移并发和批处理

DMS 允许许多选项来优化迁移。当然，为 DMS 实例选择正确的实例类是一个至关重要的选择（通用：dms.tN.xxxx，计算优化：dms.cN.Mxlarge，内存优化：dms.rN.Mxlarge）。

有两个关键设置在我们的迁移过程中实现了巨大的性能优势。

在完全加载期间使用并行表加载以并发加载表。我根据范围内的模式和表的数量、表的大小以及选择的实例类 (dms.r6i.4xlarge) 调整了这种并发性。 在完全加载期间，DMS 创建了多个内存缓冲区来存储源表数据和缓存的更改。与足够大的实例并行加载数据会增加迁移吞吐量，这对于大型迁移来说是必须的。几点考虑：

• 增加并行度超过一个点会导致内存压力和目标负载的延迟，因此需要基于数据库进行优化。
• 并行加载将以不可预测的顺序加载数据，因此无法保证任何引用完整性。必须禁用所有参照完整性约束。

当 CDC 期间源数据库中的工作负载很高时，在 CDC 期间使用批量优化应用来解决源加载延迟问题。我们已经将 CDC 阶段保持了 7 天，在高峰期，源数据库导致 DMS 的事件流量很高，并且由于默认情况下 DMS 使用单线程复制来处理 CDC 更改，这导致了很高的目标延迟。默认情况下，DMS 将每个更改应用到目标。在批量应用模式中，DMS 创建一个按时间排序的更改缓冲区，并在单个事务中将其提交到数据库。 几点考虑：

• 批处理应用模式假定不需要在目标上保持引用完整性，因为批处理不会事务性地隔离对源数据库的写入。
• 应该在源数据库预计在迁移过程中负载不足，并且目标数据库因此面临延迟问题的情况下使用。否则，使用按事件提交到目标数据库会更简单。

8. 使用 DMS 规则和过滤器使迁移可预测

DMS 任务包括一个选项，用于从一个或多个模式映射表以进行迁移。由于源端点可以访问 Oracle 实例中的所有模式，因此使用通配符来包含所有模式通常不是一个好主意。 为了使迁移可测量并有意义地跟踪它，表映射选择规则和过滤器应该根据模式和这些模式中的表来定义 DMS 迁移的精确范围。此外，在模式中使用通配符名称进行表选择会使 DMS 在 AWS RDS PostgreSQL 中创建不必要的系统表或 Oracle 生成的表或临时和冗余表。如果 Oracle 模式中有一个干净的表清单，那么表通配符可能没问题。

为多个模式和表创建规则需要更多工作，但稍后会带来丰厚的回报。

• 在迁移之前，迁移前评估报告基于精确的表和模式映射。
• 完整期间的表统计信息和 CDC 显示精确范围的有组织的表统计信息。
• 迁移过程本身针对精确迁移范围的资源利用进行了优化。

9. 使用模式转换工具自动化

目标数据库的选择涉及迁移或现代化过程中的一些注意事项。成本、预计性能和数据模型的性质是核心考虑因素。因此，目标数据库可能是不同的产品、不同的版本，甚至是不同的类别，即，例如，目标数据库可以是不同的 RDBMS OLTP 或类似 DynamoDB 的无 SQL，这会导致异构数据迁移。AWS DMS 支持异构数据迁移。但首先要解决的问题是数据模型转换，即将数据迁移范围内的源模式转换为兼容的目标模式。

使用AWS Schema Conversion Tool，支持多种源和目标数据库，特别支持 Oracle 到 PostgreSQL 以实现模式转换的自动化。我们曾尝试在 PostgreSQL 中构建目标数据库实体，但是由于复杂的实体、存储过程和不可预测的数据库查询代码使用（动态查询、ORM、JDBC 代理 Bean），模式转换工具的使用解决了大部分繁重的工作适应目标架构并分析与目标一起工作所需的应用程序代码更改。后者对于 RDBMS 到 RDMS 的迁移至关重要，其中应用程序代码可能不会直接暴露给底层数据库，而是在高级框架提供的抽象上工作。

架构转换工具：

• 支持生成目标架构，其中包含需要手动处理的不受支持对象或操作的指示符。
• 支持在无法自动转换的所有受支持语言和指标中生成目标代码。
• 支持为存储过程、函数和触发器生成目标代码。
• AWS DMS 控制台也支持该工具的Web 版本。

请注意，SCT 是一项数据迁移前活动。在数据迁移过程中，DMS 服务维护自己的数据类型以映射源数据类型和目标数据类型。可以使用迁移前评估来检查数据类型的兼容性。

10. 要跟踪的关键指标

在完全加载和复制阶段，目标数据库写入和源数据库读取吞吐量取决于配置的并发线程和在 DMS 设置中选择的 DMS 实例类型。要跟踪的关键指标是吞吐量、IOPS 和延迟。虽然应该自然地跟踪与 CPU、内存和磁盘相关的常用指标，但我们跟踪了一些特定于迁移的指标：

指标

来源

详细信息（来自 AWD 文档）

网络传输吞吐量

数据管理系统实例

复制实例上的传出（传输）网络流量，包括客户数据库流量和用于监控和复制的 AWS DMS 流量。

网络接收吞吐量

数据管理系统实例

复制实例上的传入（接收）网络流量，包括客户数据库流量和用于监控和复制的 AWS DMS 流量。

CDC即将发生的变化

复制任务

在某个时间点等待应用到目标的更改事件总数。此指标的大量数字通常表示 AWS DMS 无法及时应用捕获的更改，从而导致高目标延迟。

CDC延迟源

复制任务

CDCLatencySource 表示源和复制实例之间的延迟。高 CDCLatencySource 意味着从源捕获更改的过程被延迟。

CDC延迟目标

复制任务

目标延迟是复制实例与应用的最早事件之间的时间戳差异，但未经 TRG 端点确认 (99%)。当 CDCLatencyTarget 为高电平时，表示将更改事件应用于目标的过程被延迟。

写入 IOPS

RDS 数据库

写入 IOPS – 应在满载期间进行跟踪。具有低 CDCLatencyTarget 的高写入 IOPS 意味着写入正在高效进行。

11. DMS 迁移任务——验证和迁移前评估

在开始迁移之前，运行验证迁移规则的迁移前评估可以让迁移更有信心。 如果迁移前评估失败，则允许在迁移前解决问题，使迁移本身的出口相对顺畅；对于检查 Oracle 到 DMS 和 DMS 到 PostgreSQL 之间的数据类型不兼容性特别有用。

在任务定义中，启用 SMS 任务在数据迁移后验证数据的能力。这可确保维护数据完整性，并在满载后立即评估数据丢失情况。 验证阶段需要时间，因为比较发生在源和目标之间，但断言迁移质量至关重要。

12. 不可避免的维护窗口

通常，云迁移中的维护窗口被视为一种反模式。但对于本地和 AWS 之间的数据迁移（也伴随着应用程序迁移），维护窗口允许源数据库和目标数据库达到稳定的迁移状态，特别是如果有一个 CDC 阶段运行一些时间。

创建迁移阶段的时间顺序时，通常写入可以一直流向源数据库，但要让目标数据库在切换前达到平衡，之后 AWS RDS PostgreSQL 是唯一的权威写入端点，维护窗口是不可避免的，必须对其进行规划。

谢谢你！

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。