通过AWS DMS将关系型数据库迁移至S3数据湖，第一部分

教程

AWS

AWS 数据库迁移服务是一项云服务，能够高效且安全地将关系数据库、NoSQL 数据库、数据仓库及其他类型的数据存储迁移到 AWS 云或在云与本地环境之间进行迁移。DMS 支持多种类型的源数据库和目标数据库，如 Oracle、MS SQL Server、MySQL、Postgres SQL、Amazon Aurora、AWS RDS、Redshift 和 S3 等。

数据迁移中的观察

我们设计并创建了一个 AWS S3 数据湖和在 AWS Redshift 中的数据仓库，数据源来自本地的 Oracle、MS SQL Server、MySQL、Postgres SQL 和 MongoDB 关系数据库。我们使用 AWS DMS 进行了初始全量加载和从这些源到 AWS S3 的每日增量数据传输。

通过这一系列帖子，我想解释在与不同关系数据库进行实际数据迁移时所面临的各种挑战。

1. 源端修改日期未正确填充

AWS DMS 用于全量加载和从源数据库的变更数据捕获。AWS DMS 根据事务日志捕获已更改的记录，但正确更新的修改日期列可以帮助应用去重逻辑，并提取 S3 目标中给定行的最新修改记录。

如果对于某个表不存在修改后的数据，或者数据未正确更新，AWS DMS 提供了一种转换规则选项，可以在从源数据库提取数据时添加一个新列。在这里，AR_H_CHANGE_SEQ 头部可帮助添加一个新列，其值是源数据库中的唯一递增数字，由时间戳和自增编号组成。

下面的代码示例将在目标表中添加一个名为DMS_CHANGE_SEQ的新列，该列包含源数据库中的唯一递增数字。这是一个 35 位的唯一数字，前 16 位用于时间戳，后 19 位用于数据库递增的记录 ID 编号。

JSON

{

    "rule-type": "transformation",

    "rule-id": "2",

    "rule-name": "2",

    "rule-target": "column",

    "object-locator": {

        "schema-name": "%",

        "table-name": "%"

    },

    "rule-action": "add-column",

    "value": "DMS_CHANGE_SEQ",

    "expression": "$AR_H_CHANGE_SEQ",

    "data-type": {

        "type": "string",

        "length": 100

    }

}

2. 启用 Oracle 作为源的补充日志记录

对于作为源数据库的 Oracle，为了捕获正在发生的更改，AWS DMS 需要在源数据库上启用最低限度的补充日志记录。因此，这将在重做日志中包含附加信息和列，以识别源数据库中的更改。

可以为主键、唯一键、一组列或所有列启用补充日志记录。对于所有列的补充日志记录会捕获源数据库表中的所有列，并有助于覆盖目标 AWS S3 层中的完整记录。

所有列的补充日志记录将增加重做日志的大小，因为表中的所有列都记录在日志中。需要相应地配置、重做和归档日志，以考虑其中的附加信息。

3. 源和目标数据库之间的网络带宽

来自本地源（如Oracle、MS SQL Server等）的初始全量加载很好，对于大部分时间也可以进行变更数据捕获。

除了每天结束时的营业结束流程、每天的午夜后和月末活动外，大部分时间内每天都有适度数量的交易。我们观察到DMS迁移任务在此期间失去同步或失败。

我们在日志中审查了源、目标和复制实例的指标，并发现了以下观察结果：

CDCLatencySource – 源端点捕获的最后事件与AWS DMS实例当前系统时间戳之间的时间差（以秒为单位）
CDCIncomingchanges – 某一时刻等待应用到目标的更改事件的总数。这会在清晨的对账活动期间从零增加到数千。
CDCLatencySource – 源端点捕获的最后事件与AWS DMS实例的当前系统时间戳之间的间隔，以秒为单位。在每日午夜后的对账活动期间，这个值会从零增加到几千秒，甚至增加到10-12K秒。在月末活动期间，这个值曾高达40K秒。

通过进一步分析日志并查看其他指标，我们观察到：

AWS DMS指标NetworkReceiveThroughput用于了解DMS复制实例上的传入流量，涵盖客户数据库和DMS流量。这些指标有助于了解源数据库和DMS复制实例之间是否存在任何网络相关问题。

观察到网络接收吞吐量高达30MB/s，即250Mb/s，这是由于源与AWS之间的VPN连接，该连接还用于其他应用程序。

对于这个问题的最终结论是，源数据库和目标数据库之间的连接对于成功的数据迁移至关重要。在实际数据迁移之前，请确保在本地或其他云源数据库与AWS环境之间设置了足够的带宽。

像AWS站点到站点VPN或Oracle Cloud Infrastructure（OCI）站点到站点VPN（Oracle AWS）这样的VPN隧道可以提供高达1.25 Gbps的吞吐量。这对于小表迁移或具有较少DML流量迁移的表来说是足够的。
对于需要每秒进行大量事务的大型数据迁移，您应该考虑使用AWS Direct Connect。它提供了创建专用私有连接的选项，支持1 Gbps、10 Gbps等带宽。

结论

这是关于关系数据库迁移挑战及其在AWS DMS中实现的解决方案的多部分系列的第一部分。系列中提到的大多数挑战可能发生在数据库迁移过程中，可以参考这些解决方案。

Source:
https://dzone.com/articles/relational-databases-migration-to-aws-environment