通過AWS DMS將關係型數據庫遷移到S3數據湖，第一部分

教學

AWS

AWS Database Migration Service 是一項雲端服務，可將關聯式資料庫、NoSQL 資料庫、資料倉儲和所有其他類型的資料存儲有效且安全地遷移至 AWS 雲端，或在雲端與本地設置之間進行遷移。DMS 支持多種來源和目標資料庫，例如 Oracle、MS SQL Server、MySQL、Postgres SQL、Amazon Aurora、AWS RDS、Redshift 和 S3 等。

資料遷移期間的觀察

我們致力於在 AWS Redshift 中設計和創建一個AWS S3 資料湖和資料倉庫，數據來源為來自本地的 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 基礎設施（OCI）站點到站點 VPN（Oracle AWS）可以提供高達 1.25 Gbps 的傳輸速率。這將足以支持小表遷移或具有較少 DML 流量遷移的表。
對於在表格上每秒進行大量數據遷移的高交易量，您應該考慮使用 AWS Direct Connect。它提供了創建具有支持1 Gbps、10 Gbps等帶寬的專用私人連接的選項。

結論

這是關於關係型數據庫遷移挑戰的多部分系列文章的第一部分，使用了 AWS DMS 並實施了它們的解決方案。本系列中提到的大多數挑戰都可能發生在數據庫遷移過程中，可以參考這些解決方案。

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