AWS Database Migration Service 的最佳實務 - AWS Database Migration Service

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

AWS Database Migration Service 的最佳實務

若要以最有效率的方式使用 AWS Database Migration Service (AWS DMS),請參閱本節中有關遷移資料最有效率方式的建議。

適用於 AWS Database Migration Service 的遷移計劃

使用 AWS Database Migration Service 規劃資料庫遷移時,請考慮以下事項:

  • 若要將來源和目標資料庫連線到 AWS DMS 複寫執行個體,您需要設定網路。要這麼做很簡單,就像在與複寫執行個體相同的虛擬私有雲端 (VPC) 中連接兩個 AWS 資源一樣簡單。其可以適用於更複雜的組態,例如透過虛擬私有網路 (VPN),將內部部署資料庫連接到 Amazon RDS 資料庫執行個體。如需詳細資訊,請參閱 資料庫遷移的網路組態

  • 來源和目標端點:確保您知道來源資料庫中哪些資訊和資料表需要遷移到目標資料庫。AWS DMS 支援基本的結構描述遷移,包括資料表與主索引鍵的建立。但是,AWS DMS 不會在目標資料庫中自動建立輔助索引、外部索引鍵、使用者帳戶等等。視來源和目標資料庫引擎而定,您可能需要設定補充記錄或修改來源或目標資料庫的其他設定。如需詳細資訊,請參閱 資料遷移的來源資料遷移的目標

  • 結構描述和程式碼遷移:AWS DMS 不執行結構描述或程式碼轉換。您可以使用 Oracle SQL Developer、MySQL Workbench 和 pgAdmin III 等工具轉換結構描述。若要將現有的結構描述轉換成不同的資料庫引擎,您可以使用 AWS Schema Conversion Tool (AWS SCT)。其可以建立目標結構描述,也可以產生和建立整個結構描述:資料表、索引、檢視等。您也可以使用此工具將 PL/SQL 或 TSQL 轉換成 PgSQL 和其他格式。如需 AWS SCT 的相關詳細資訊,請參閱《AWS SCT 使用者指南》

  • 不受支援的資料類型:確保將來源資料類型轉換成目標資料庫的同等資料類型。如需受支援資料類型的詳細資訊,請參閱資料存放區的來源或目標區段。

  • 診斷支援指令碼結果:規劃移轉時,建議您執行診斷支援指令碼。透過這些指令碼的結果,您可以找到與潛在遷移失敗相關的進階資訊。

    如果資料庫有可用的支援指令碼,請使用下一節中對應指令碼主題中的連結下載該指令碼。驗證並檢閱指令碼之後,您可以根據本機環境中指令碼主題中所述的程序來執行指令碼。當指令碼執行完成時,您就可以檢閱結果。我們建議您執行這些指令碼,作為任何疑難排解工作的第一步。與 AWS Support 團隊合作時,這些結果可能很有用。如需詳細資訊,請參閱 在 AWS DMS 中使用診斷支援指令碼

  • 預遷移評估:預遷移評估會評估資料庫遷移任務的指定元件,以協助找出可能導致遷移任務無法如期執行的任何問題。透過使用此評估,您就可以在執行新任務或修改的任務前找出潛在問題。如需使用預遷移評估的詳細資訊,請參閱啟用和使用任務的預遷移評估

轉換結構描述

AWS DMS 不會執行結構描述或程式碼轉換。如果您想要將現有結構描述轉換為不同資料庫引擎,則可使用 AWS SCT。AWS SCT 會將來源物件、資料表、索引、檢視、觸發程序及其他系統物件,轉換成目標資料定義語言 (DDL) 格式。您也可以使用 AWS SCT,將大部分的應用程式程式碼 (如 PL/SQL 或 TSQL) 轉換為對等的目標語言。

您可以從 AWS 免費下載 AWS SCT。如需 AWS SCT 的詳細資訊,請參閱《AWS SCT 使用者指南》。

如果您的來源和目標端點位於相同的資料庫引擎上,您可以使用 Oracle SQL 開發人員、MySQL 工作台或 PgAdmin 4 等工具來移動結構描述。

檢閱 AWS DMS 公有文件

我們強烈建議您在第一次遷移前瀏覽來源和目標端點的 AWS DMS 公有文件頁面。本文件可協助您找出遷移的先決條件,並在開始之前了解目前的限制。如需詳細資訊,請參閱 使用 AWS DMS 端點

在遷移期間,公有文件可協助您疑難排解與 AWS DMS 有關的任何問題。文件中的疑難排解頁面可協助您解決使用 AWS DMS 和所選端點資料庫的常見問題。如需詳細資訊,請參閱 對 AWS Database Migration Service 中的遷移任務進行故障診斷

執行概念驗證

為了協助您在資料庫遷移的早期階段發現環境的相關問題,我們建議您執行小型測試遷移。這樣做也可以幫助您設定更實際的遷移時間表。此外,您可能需要執行全面測試遷移,以測量 AWS DMS 是否可以透過網路處理資料庫的輸送量。在此期間,我們會建議您進行基準測試並最佳化初始完整載入和持續複寫。這樣做可以幫助您了解網路延遲以及評估整體效能。

此時,您還能夠了解資料描述檔以及資料庫的大小 (包括以下內容):

  • 大型、中型和小型的資料表有多少。

  • AWS DMS 如何處理資料類型和字元集轉換。

  • 具有大型物件 (LOB) 欄的資料表數目。

  • 執行測試遷移需要多久的時間。

提升 AWS DMS 遷移的效能

影響 AWS DMS 遷移效能的因素有多種:

  • 來源的資源可用性。

  • 可用網路輸送量。

  • 複寫伺服器的資源容量。

  • 要擷取變更之目標的能力。

  • 來源資料的類型和分佈。

  • 要遷移的物件數。

您可以使用以下所述的部分或所有最佳實務來提升效能。您是否可以使用這些實務其中之一,取決於具體的使用案例。您可以找到以下一些限制:

佈建適當的複寫伺服器

AWS DMS 是在 Amazon EC2 執行個體上執行的受管服務。此服務會連線至來源資料庫、讀取來源資料、格式化資料以供目標資料庫使用,以及將資料載入目標資料庫。

此處理的大部分皆發生在記憶體中。但是,大型交易可能需要將一部分緩衝到磁碟。快取交易和日誌檔案也會寫入磁碟。在下面的區段中,您可以找到在選擇複寫伺服器時要留意的考量。

CPU

AWS DMS 是專為異質遷移而設計,同時也支援同質遷移。若要執行同質遷移,請先將每個來源資料類型轉換為其對等的 AWS DMS 資料類型。然後將每個 AWS DMS 類型的資料轉換為目標資料類型。您可以在《AWS DMS 使用者指南》中找到每個資料庫引擎的轉換參考資料。

若要讓 AWS DMS 以最佳方式執行這些轉換,則轉換發生時,CPU 必須是可用的狀態。超載 CPU 並且缺乏足夠 CPU 資源可能導致遷移速度變慢,還可能導致其他副作用。

複寫執行個體類別

某些較小的執行個體類別便已足夠用於測試服務或較小的遷移。若遷移涉及大量資料表,或是您想要執行多個同時複寫任務,請您考慮使用其中一個較大的執行個體。較大的執行個體可能是個好主意,因為此服務會消耗一定數量的記憶體和 CPU。

T2 類型執行個體旨在提供適度的基礎效能和容量,可視工作負載需要大幅提升效能。這類執行個體適用非經常或持續使用整個 CPU,但偶爾需要高載的工作負載。T2 執行個體非常適合一般用途工作負載,例如 Web 伺服器、開發人員環境和小型資料庫。如果您要針對遷移緩慢的問題進行疑難排解,並使用 T2 執行個體類型,請檢查 CPU 使用率主機指標。此指標可以顯示您是否超出該執行個體類型的基準。

C4 執行個體類別旨在交付最高層級的處理器效能,用於電腦密集型的工作負載。T2 執行個體大幅提升每秒封包數 (PPS) 效能、減少網路抖動和減少網路延遲。AWS DMS 可能會耗用大量 CPU,尤其是在執行異質遷移和覆寫 (例如從 Oracle 遷移至 PostgreSQL) 時。C4 執行個體在這些情況下便是個良好的選擇。

R4 執行個體類別針對記憶體進行最佳化,適合用於記憶體密集的工作負載。持續進行的遷移或複寫使用 AWS DMS 的高輸送量交易系統,有時候可能會使用大量的 CPU 及記憶體。R4 執行個體的每個 vCPU 皆包含了更多記憶體。

AWS DMS 對 R5 和 C5 執行個體類別的支援

R5 執行個體類別是記憶體優化執行個體,旨在為於記憶體內部處理大型資料集的工作負載提供快速效能。持續進行的遷移或複寫使用 AWS DMS 的高輸送量交易系統,有時候可能會使用大量的 CPU 及記憶體。R5 執行個體為每個 vCPU 提供比 R4 多出 5% 的記憶體,而最大的大小可提供 768 GiB 的記憶體。此外,與 R4 相比,R5 執行個體的每 GiB 價格提高 10%,而且 CPU 效能提高約 20%。

C5 執行個體類別針對運算密集型工作負載進行了最佳化,並以低廉的每個運算價格提供符合成本效益的高效能。其可實現明顯更高的網路效能。彈性網路介面卡 (ENA) 為 C5 執行個體提供最高 25 Gbps 的網路頻寬,以及最高 14 Gbps 的 Amazon EBS 專用頻寬。AWS DMS 可能會耗用大量 CPU,尤其是在執行異質遷移和複寫 (例如從 Oracle 遷移至 PostgreSQL) 時。C5 執行個體在這些情況下便是個良好的選擇。

儲存

根據執行個體類別,複寫伺服器可能包含 50 GB 或 100 GB 的資料儲存。此儲存用於日誌檔,以及載入期間收集的任何快取變更。如果來源系統正在忙碌中或需要大量交易,您可能需要增加儲存空間。如果您在複寫伺服器上執行多項任務,則可能還需要增加儲存空間。不過,預設的量通常就足夠了。

AWS DMS 中的所有儲存磁碟區都是 GP2 或一般用途固態硬碟 (SSD)。GP2 磁碟區具有每秒三個 I/O 操作 (IOPS) 的基本效能,並且能夠以額度的方式爆增至高達 3,000 IOPS。根據經驗法則,請檢查複寫執行個體的 ReadIOPSWriteIOPS 指標。請確定這些值的總和不會超過該磁碟區的基本效能。

Multi-AZ

選擇多可用區執行個體可保護遷移,避免儲存失敗。大多數遷移是暫時的,預期執行的時間不長。如果您將 AWS DMS 用於持續複寫目的,選擇多可用區執行個體可以在發生儲存問題時改善可用性。

在「完整載入」期間使用單一可用區或多可用區複寫執行個體,且發生容錯移轉或主機取代時,完整載入任務預期會失敗。對於未完成或處於錯誤狀態的剩餘資料表,您可以從故障點重新開始任務。

平行載入多個資料表

根據預設,AWS DMS 一次會載入八個資料表。當您使用非常大的複寫伺服器 (例如 dms.c4.xlarge 或較大的執行個體) 時,可以稍微增加此值來查看某項效能提升。不過,在某個時間點上,增加這種並行處理會降低效能。如果您的複寫伺服器相對較小 (例如 dms.t2.medium),建議您降低平行載入的資料表數目。

若要在 AWS Management Console 中變更這個數量,請開啟主控台,選擇任務、選擇建立或修改任務,然後選擇進階設定。在調校設定下,變更要平行載入的資料表數目上限選項。

若要使用 AWS CLI 變更此數量,請變更 TaskSettings 下的 MaxFullLoadSubTasks 參數。

使用平行完整載入

您可以根據分割區和子分割區,使用來自 Oracle、Microsoft SQL Server、MySQL、Sybase 和 IBM Db2 LUW 來源,來使用平行載入。這樣做可以改善整體完整載入持續時間。此外,在執行 AWS DMS 遷移任務時,您可以加快大型或分割區資料表的遷移速度。若要這樣做,請將資料表分割成區段,並在相同的遷移任務中平行載入區段。

若要使用平行載入,請使用 parallel-load 選項建立 table-settings 類型的資料表對應規則。在 table-settings 規則中,請指定您要平行載入的資料表選取條件。若要指定選取條件,請將 parallel-loadtype 元素設為以下其中一項:

  • partitions-auto

  • subpartitions-auto

  • partitions-list

  • ranges

  • none

如需這些設定的詳細資訊,請參閱資料表和集合設定規則與操作

使用索引、觸發程序和參考完整性限制

索引、觸發條件和參考完整性限制條件會影響您的遷移效能,並造成遷移失敗。這些限制影響遷移的方式取決於複寫任務是完整載入任務,還是持續複寫 (變更資料擷取,即 CDC) 任務。

如需完全載入任務,建議您丟棄主索引鍵索引、次要索引、參考完整性限制條件和資料處理語言 (DML) 觸發條件。或者,您可以將建立時間延後至完整載入任務完成之後。您在完整載入任務期間不需要索引,如果索引存在,則會產生維護額外負荷。由於完全載入任務會一次載入群組的資料表,因此違反了參考完整性限制條件。同樣地,插入、更新和刪除觸發程序可能會造成錯誤,例如,若針對先前大量載入的資料表觸發了資料列插入。其他類型的觸發條件也會因新增的處理而影響效能。

如果資料磁碟區相對較小且額外的遷移時間不是您考量的因素,您可以在完整載入任務之前建置主索引鍵和輔助索引。參考完整性限制和觸發程序應一律關閉。

若為完整載入 + CDC 任務,建議您在 CDC 階段之前新增輔助索引。由於 AWS DMS 使用的是邏輯複寫,因此請確保支援 DML 操作的輔助索引應該就位,以防止完整資料表掃描。您可以在 CDC 階段之前暫停複寫任務,以便在重新開始任務之前建置索引以及建立參考完整性限制。

您應該在切換之前啟用觸發程序。

關閉備份和交易記錄

遷移到 Amazon RDS 資料庫時,最好能夠先關閉目標的備份和多可用區,直到您準備好進行切換為止。同樣地,在遷移到非 Amazon RDS 系統時,關閉目標的任何記錄直到切換後通常是不錯的主意。

使用多個任務

使用多個任務進行單一遷移有時可提升效能。如果您有一組不參與一般交易的資料表,則可能可以將遷移劃分為多個任務。交易一致性的維護會在任務中進行,因此,個別任務中的資料表不得參與共同的交易,這點很重要。此外,每個任務會獨立讀取交易串流,因此請小心不要對來源資料庫施加過多壓力。

您可以使用多個任務來建立個別的複寫串流。如此一來,您就可以平行進行來源的讀取、複寫執行個體上的程序,以及對目標資料庫的寫入。

最佳化變更處理

根據預設,AWS DMS 會在交易模式下處理變更,進而保留交易完整性。如果您能夠承受交易完整性的臨時失誤,則可以改用批次最佳化套用選項。此選項可有效率地分組交易,並為了提高效率以批次方式加以套用。使用批次最佳化的套用選項幾乎總是違反參考完整性限制。因此,我們建議您在遷移過程中關閉這些限制,並在切換過程中再次開啟這些限制。

使用自己的內部部署名稱伺服器

通常,AWS DMS 複寫執行個體會在 Amazon EC2 執行個體中使用網域名稱系統 (DNS) 解析程式來解析網域端點。但是,如果您使用 Amazon Route 53 Resolver,就可以使用自己的內部部署名稱伺服器來解析特定端點。您可以透過此工具,使用傳入和傳出端點、轉送規則和私人連線,在內部部署以及 AWS 之間進行查詢。使用內部部署名稱伺服器的好處包括在防火牆後方增強的安全性以及易用性。

如果您有傳入端點,則可以使用來自內部部署的 DNS 查詢來解析 AWS 託管的網域。若要設定端點,您可透過在要提供解析程式的每個子網路中指派 IP 地址。若要建立內部部署 DNS 基礎設施和 AWS 之間的連線,請使用 AWS Direct Connect 或虛擬私有網路 (VPN)。

傳出端點會連線到內部部署名稱伺服器。名稱伺服器只會授予在允許清單中包含並在傳出端點中設定之 IP 地址的存取權。您名稱伺服器的 IP 地址是目標 IP 地址。當您為傳出端點選擇安全群組時,請選擇複寫執行個體所使用的相同安全群組。

若要將特定網域轉送至名稱伺服器,請使用轉送規則。傳出端點可處理多個轉送規則。轉送規則的範圍是虛擬私有雲端 (VPC)。透過使用與 VPC 相關聯的轉送規則,您可以佈建 AWS 雲端的邏輯隔離區段。從這個邏輯隔離的區段中,您可以啟動虛擬網路中的 AWS 資源。

您可以將在內部部署 DNS 基礎設施中託管的網域設為條件式轉送規則,此規則會設定傳出 DNS 查詢。當對其中一個網域進行查詢時,規則會觸發嘗試將 DNS 請求轉送到該規則所設伺服器的動作。同樣地,您需要透過 AWS Direct Connect 或 VPN 進行私有連線。

下圖顯示 Route 53 解析程式的架構。

Route 53 解析程式架構

如需 Route 53 DNS Resolver 的更多資訊,請參閱《Amazon Route 53 開發人員指南》中的開始使用 Route 53 解析程式

使用 Amazon Route 53 Resolver 搭配 AWS DMS

您可以為 AWS DMS 建立內部部署名稱伺服器,以使 用 Amazon Route 53 Resolver解析端點。

根據 Route 53 為 AWS DMS 建立內部部署名稱伺服器
  1. 登入 AWS Management Console 並開啟位於 https://console.aws.amazon.com/route53/ 的 Route 53 主控台。

  2. 在 Route 53 主控台上,選擇 Route 53 解析程式設定所在的 AWS 區域。Route 53 解析程式是區域特有的。

  3. 選擇查詢方向 (傳入、傳出或兩者)。

  4. 提供傳入查詢組態:

    1. 輸入端點名稱並選擇 VPC。

    2. 從 VPC 指派一或多個子網路 (例如,選擇兩個以提供可用性)。

    3. 指派特定 IP 地址作為端點使用,或是讓 Route 53 解析程式自動指派。

  5. 為您的內部部署網域建立規則,讓 VPC 內的工作負載可以將 DNS 查詢路由至您的 DNS 基礎設施。

  6. 輸入內部部署 DNS 伺服器的一或多個 IP 地址。

  7. 提交規則。

建立所有項目後,VPC 便會與傳入和傳出規則建立關聯,並且可以開始路由流量。

如需 Route 53 解析程式的更多資訊,請參閱《Amazon Route 53 開發人員指南》中的開始使用 Route 53 解析程式

遷移大型二進位物件 (LOB)

一般而言,AWS DMS 會以兩個階段遷移 LOB 資料。

  1. AWS DMS 在目標資料表中建立新的資料列,並在資料列中填入所有資料 (相關聯的 LOB 值除外)。

  2. AWS DMS 在目標資料表中以 LOB 資料更新資料列。

這個 LOB 遷移程序需要在遷移期間,目標資料表上的所有 LOB 資料行都必須是可為 null。即使來源資料表上的 LOB 資料行不可為 null,也是如此。如果 AWS DMS 建立目標資料表,它預設會將 LOB 資料行設為可為 null。在某些情況下,您可能會使用其他機制 (例如匯入或匯出),來建立目標資料表。在這類情況下,請確定 LOB 欄可為 Null,然後再開始遷移任務。

此要求有一個例外狀況。假設您從 Oracle 來源執行同質遷移到 Oracle 目標,並選擇 Limited Lob mode (有限 LOB 模式)。在這種情況下,整個資料列是一次填入,包括任何 LOB 值。對於這類情況,AWS DMS 在必要時可以建立具有不可為 null 限制條件的目標資料表 LOB 資料行。

使用有限 LOB 模式

當遷移包含 LOB 值時,AWS DMS 會使用兩種方法來平衡效能與便利性:

  1. Limited LOB mode (有限 LOB 模式) 可遷移最多到使用者指定大小限制 (預設為 32 KB) 的所有 LOB 值。大於大小限制的 LOB 值則必須手動遷移。Limited LOB mode (有限 LOB 模式) 是所有遷移任務的預設值,通常可提供最佳效能。不過,請確保 LOB 大小上限參數的設定正確無誤。將此參數設為所有資料表的最大 LOB 大小。

  2. Full LOB mode (完整 LOB 模式) 可遷移資料表中的所有 LOB 資料 (無論大小為何)。Full LOB mode (完整 LOB 模式) 便於移動資料表中的所有 LOB 資料,但此程序可能會大幅影響效能。

對於某些資料庫引擎 (如 PostgreSQL),AWS DMS 會處理像是 LOB 的 JSON 資料類型。請確定如果您選擇的是有限 LOB 模式,則 LOB 大小上限選項將設定為不會導致 JSON 資料遭截斷的值。

AWS DMS 全面支援使用大型物件資料類型 (BLOB、CLOB 及 NCLOB)。下列來源端點具有完整的 LOB 支援:

  • Oracle

  • Microsoft SQL Server

  • ODBC

下列目標端點具有完整的 LOB 支援:

  • Oracle

  • Microsoft SQL Server

下列目標端點具有有限的 LOB 支援。您無法針對這個目標端點使用有限 LOB 大小。

  • Amazon Redshift

  • Amazon S3

對於具有完整 LOB 支援的端點,您還可以設定 LOB 資料類型的大小限制。

改善 LOB 效能

遷移 LOB 資料時,您可以指定下列不同的 LOB 最佳化設定。

每個資料表 LOB 設定

使用每個資料表 LOB 設定,您就可以覆寫部份或所有資料表的任務層級 LOB 設定。若要執行此操作,請在 table-settings 規則中定義 lob-settings。以下是包含一些較大的 LOB 值的範例表。

SET SERVEROUTPUT ON CREATE TABLE TEST_CLOB ( ID NUMBER, C1 CLOB, C2 VARCHAR2(4000) ); DECLARE bigtextstring CLOB := '123'; iINT; BEGIN WHILE Length(bigtextstring) <= 60000 LOOP bigtextstring := bigtextstring || '000000000000000000000000000000000'; END LOOP; INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue'); END; / SELECT * FROM TEST_CLOB; COMMIT

接下來,建立遷移任務,並使用新 lob-settings 規則修改資料表的 LOB 處理。此 bulk-max-siz 值會決定 LOB 大小上限 (KB)。如果其大於指定的大小,將會遭到截斷。

{ "rules": [{ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "HR", "table-name": "TEST_CLOB" }, "rule-action": "include" }, { "rule-type": "table-settings", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "HR", "table-name": "TEST_CLOB" }, "lob-settings": { "mode": "limited", "bulk-max-size": "16" } } ] }

即使使用 FullLobMode : true 建立此 AWS DMS 任務,每個資料表 LOB 設定也會引導 AWS DMS 將此特定資料表中的 LOB 資料截斷為 16,000。您可以檢查任務日誌以確認此操作。

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table 'HR.TEST_CLOB' was truncated to length 16384

內嵌 LOB 設定

當您建立 AWS DMS 任務時,LOB 模式會決定 LOB 的處理方式。

完整 LOB 模式和有限 LOB 模式,每有其優缺點。內嵌 LOB 模式結合完整 LOB 模式和有限 LOB 模式的優點。

當您需要同時複寫小型和大型 LOB,而且大部分 LOB 都很小時,就可以使用內嵌 LOB 模式。當您選擇此選項時,在完整載入期間,AWS DMS 任務會以內嵌方式傳輸小型 LOB,因為這麼做效率更高。此 AWS DMS 任務會從來源資料表執行查詢,以傳輸大型 LOB。

在變更處理期間,會透過從來源資料表執行查詢,來複寫小型和大型 LOB。

當您使用內嵌 LOB 模式時,AWS DMS 任務會檢查所有 LOB 大小,以判斷要以內嵌方式傳輸的 LOB 大小。會使用完整 LOB 模式複寫大於指定大小的 LOB。因此,如果您知道大部分 LOB 都大於指定的設定,建議不要使用此選項。而是允許無限制的 LOB 大小。

您可以使用任務設定中的屬性 (true) 來設定此選項,只有在將 FullLobMode 設定為 InlineLobMaxSize 時才可使用此屬性。InlineLobMaxSize 的預設值為 0,範圍介於 1 –102400 KB (100 MB)。

舉例來說,您也許會使用下列 AWS DMS 任務設定。在這裡,將 InlineLobMaxSize 設為值 5 會導致所有小於或等於 5 KiB (5,120 位元組) 的 LOB 皆以內嵌方式傳輸。

{ "TargetMetadata": { "TargetSchema": "", "SupportLobs": true, "FullLobMode": true, "LobChunkSize": 64, "LimitedSizeLobMode": false, "LobMaxSize": 32, "InlineLobMaxSize": 5, "LoadMaxFileSize": 0, "ParallelLoadThreads": 0, "ParallelLoadBufferSize":0, "BatchApplyEnabled": false, "TaskRecoveryTableEnabled": false}, . . . }

改善使用列篩選遷移大型資料表時的效能

如果您想要改善在遷移大型資料表時的效能,則可以將遷移分成多個任務。若要使用資料列篩選將遷移分成多個任務,請使用索引鍵或分割區索引鍵。比方說,如果您有一個 1 到 8,000,000 的整數主索引鍵 ID,則可以使用資料列篩選建立八個任務,每個遷移 100 萬筆記錄。

若要在主控台中套用資料列篩選:
  1. 開啟 AWS Management Console。

  2. 選擇任務,然後建立新任務。

  3. 選擇資料表對應索引標籤,然後展開選擇規則

  4. 選擇新增選擇規則。您可以立即使用小於或等於、大於或等於、等於或介於兩個值之間的範圍條件,來新增資料欄篩選條件。如需欄篩選的詳細資訊,請參閱 從主控台指定資料表選取及轉換

如果您有一個依日期分割的大型分割資料表,則可以根據日期遷移資料。例如,假設您有一個依月份分割的資料表,而且只更新了當月的資料。在這種情況下,您可以針對每個靜態月份分割區建立完整載入任務,並針對目前更新的分割區建立完整載入 + CDC 任務。

如果資料表具有單欄主索引鍵或唯一索引,您可以讓 AWS DMS 任務使用範圍類型的平行載入將資料表分段,以平行載入資料。如需詳細資訊,請參閱 資料表和集合設定規則與操作

持續複寫

AWS DMS 提供資料的持續複寫,讓來源和目標資料庫保持同步。其只會複寫有限數量的資料定義語言 (DDL) 陳述式。AWS DMS 不會傳播項目,例如索引、使用者、權限、預存程序,以及其他與資料表資料無直接關聯的資料庫變更。

如果您計劃使用持續複寫,則在建立複寫執行個體時,設定多可用區選項。您可透過選擇多可用區選項,取得複寫執行個體的高可用性和容錯移轉支援。不過,此選項可能會影響效能,而且在將變更套用至目標系統時可能會拖慢複寫速度。

在升級來源或目標資料庫之前,建議您停止在這些資料庫上執行的任何 AWS DMS 任務。升級完成後繼續任務。

在持續複寫期間,找出來源資料庫系統與 AWS DMS 複寫執行個體之間的網路頻寬至關重要。確定網路在持續複寫期間不會造成任何瓶頸。

識別來源資料庫系統上每小時變更和封存日誌產生速率也很重要。這麼做可協助您了解持續複寫期間可能獲得的輸送量。

降低來源資料庫的負載

AWS DMS 會使用來源資料庫上的一些資源。在完全載入任務期間,AWS DMS 會針對每個平行處理的資料表執行來源資料表的完整資料表掃描。此外,作為遷移一部分建立的每個任務都會在 CDC 程序中查詢來源資料庫是否有變更。為了讓 AWS DMS 對某些來源 (例如 Oracle) 執行 CDC,您可能需要增加對資料庫變更日誌寫入的資料數量。

如果您發現來源資料庫不堪負載,則可以為遷移降低任務數或每個任務的資料表數目。每個任務都是獨立取得來源變更,因此合併任務可以降低變更擷取的工作負載。

減少目標資料庫的瓶頸

在遷移期間,請嘗試移除任何在目標資料庫上競爭寫入資源的程序:

  • 關閉不必要的觸發程序。

  • 在初始載入期間關閉輔助索引,稍後在持續複寫期間重新開啟次要索引。

  • 使用 Amazon RDS 資料庫時,建議您在切換前關閉備份和多可用區。

  • 遷移至非 RDS 系統時,建議您在切換前關閉目標上的任何記錄。

在遷移期間使用資料驗證

若要確保資料正確地從來源遷移至目標,我們極力建議您使用資料驗證。如果您對任務開啟資料驗證,AWS DMS 會在資料表完整載入後立即開始比較來源和目標資料。

只要 AWS DMS 支援以下資料庫做為來源和目標端點,資料驗證就適用於這些資料庫:

  • Oracle

  • PostgreSQL

  • MySQL

  • MariaDB

  • Microsoft SQL Server

  • Amazon Aurora MySQL-Compatible Edition

  • Amazon Aurora PostgreSQL-Compatible Edition

  • IBM Db2 LUW

  • Amazon Redshift

如需詳細資訊,請參閱 AWS DMS 資料驗證

使用指標監控 AWS DMS 任務

您有數個選項,可用來透過 AWS DMS 主控台監控任務的指標:

主機指標

您可以在每個特定複製執行處理的CloudWatch 測量結果頁籤中找到主機測量結果。您可以在此監控複寫執行個體的大小是否適當。

複寫任務指標

您可以在每個特定工作的測量結果標籤上找到複寫工作的測量結CloudWatch 果,包括內送和確認的變更,以及複製主機與來源/目標資料庫之間的延遲。

資料表指標

您可以在每個個別任務的資料表統計資料索引標籤中找到個別資料表指標。這些指標包括以下數字:

  • 在完整載入期間載入的資料列。

  • 自任務開始後插入、更新和刪除。

  • 自任務開始以來的 DDL 操作。

如需指標監控的詳細資訊,請參閱監控 AWS DMS 任務

事件和通知

AWS DMS 會使用 Amazon SNS 以在 AWS DMS 事件發生 (例如建立或刪除複寫執行個體) 時提供通知。您可以使用 Amazon SNS 針對 AWS 區域支援的任何形式處理這些通知。其中可能包括電子郵件訊息、文字訊息或對 HTTP 端點的呼叫。

如需詳細資訊,請參閱 在 AWS Database Migration Service 中處理 Amazon SNS 的事件和通知

使用任務日誌針對遷移問題進行故障診斷

在某些情況下,AWS DMS 可能會遇到只在任務日誌中出現警告或錯誤訊息的問題。特別是,因為外部索引鍵違規而導致的資料截斷問題或資料列拒絕只會寫入任務日誌中。因此,在遷移資料庫時,請務必檢閱任務日誌。若要檢視任務日誌,請將 Amazon 設定 CloudWatch 為任務建立的一部分。

如需詳細資訊,請參閱使用 Amazon 監控複寫任務 CloudWatch

使用時間歷程針對複寫任務進行疑難排解

若要針對 AWS DMS 遷移問題進行疑難排解,您可以使用時間歷程。如需時間歷程的詳細資訊,請參閱時間歷程任務設定

當您使用時間歷程時,請注意下列考量:

  • 若要避免 DMS 複寫執行個體的額外負荷,請僅針對需要偵錯的任務開啟「時間歷程」。

  • 當您使用歷程對可能執行數天的複寫任務進行疑難排解時,請監控複寫執行個體指標的資源負荷。此方法特別適用於長時間在來源資料庫上執行高交易負載的情況。如需詳細資訊,請參閱監控 AWS DMS 任務

  • 當時間歷程任務設定 EnableRawData 設為 true 時,DMS 複寫期間的任務記憶體用量可能會高於未開啟時間歷程的使用量。如果「時間歷程」的開啟時間很長,請監控任務。

  • 目前,您只能在任務層級開啟「時間歷程」。對所有資料表的變更都會記錄在「時間歷程」日誌中。如果您要針對具有高交易量之資料庫中的特定資料表進行疑難排解,請建立個別的任務。

變更 Oracle 目標的使用者和結構描述

將 Oracle 用作為目標時,AWS DMS 會將資料遷移到目標端點使用者擁有的結構描述。

例如,假設您將名為 PERFDATA 的結構描述遷移到 Oracle 目標端點,而且目標端點使用者名稱是 MASTER。AWS DMS 將連接到 Oracle 目標當作 MASTER,並將 PERFDATA 中的資料庫物件填入 MASTER 結構描述中。

若要覆寫此行為,請提供結構描述轉換。例如,若要將 PERFDATA 結構描述物件遷移到目標端點上的 PERFDATA 結構描述,請使用以下轉換。

{ "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "PERFDATA" }, "rule-target": "schema", "rule-action": "rename", "value": "PERFDATA" }

如需轉型的詳細資訊,請參閱 使用 JSON 指定資料表選擇及轉換

變更 Oracle 目標的資料表和索引資料表空間

將 Oracle 用作為目標時,AWS DMS 會將所有資料表和索引遷移到目標中的預設資料表空間。例如,假設您的來源是 Oracle 以外的資料庫引擎。所有目標資料表和索引都會遷移到相同的預設資料表空間。

若要覆寫此行為,請提供對應的資料表空間轉換。例如,假設您希望將資料表和索引遷移到 Oracle 目標中的資料表和索引資料表空間,而且是以來源中的結構描述命名資料表空間。在這種情況下,您可以使用類似如下的轉換。其中,來源中的結構描述名為 INVENTORY,目標中對應的資料表和索引資料表空間則名為 INVENTORYTBLINVENTORYIDX

{ "rule-type": "transformation", "rule-id": "3", "rule-name": "3", "rule-action": "rename", "rule-target": "table-tablespace", "object-locator": { "schema-name": "INVENTORY", "table-name": "%", "table-tablespace-name": "%" }, "value": "INVENTORYTBL" }, { "rule-type": "transformation", "rule-id": "4 "rule-name": "4", "rule-action": "rename", "rule-target": "index-tablespace", "object-locator": { "schema-name": "INVENTORY", "table-name": "%", "index-tablespace-name": "%" }, "value": "INVENTORYIDX" }

如需轉型的詳細資訊,請參閱 使用 JSON 指定資料表選擇及轉換

當 Oracle 同時是來源和目標時,您可以設定 Oracle 來源額外連線屬性,來保留現有的資料表或索引資料表空間指派:enableHomogenousTablespace=true。如需詳細資訊,請參閱 使用 Oracle 作為來源時的端點設定 AWS DMS

升級複寫執行個體版本

AWS 會定期發行 AWS DMS 複寫引擎軟體的新版本,內含新功能及效能改善。每個複寫引擎軟體的版本都有其各自的版本編號。在將複寫執行個體升級至更新版本之前,測試執行生產工作負載的現有 AWS DMS 複寫執行個體版本至關重要。如需可用版本升級的相關詳細資訊,請參閱 AWS DMS 發行版本資訊

了解遷移成本

AWS Database Migration Service 可協助您輕鬆、安全地以低成本的方式,將資料庫遷移至 AWS。您只需為複寫執行個體和任何額外的日誌儲存空間付費。每個資料庫遷移執行個體都包含足夠儲存空間,可容納交換空間、複寫日誌和資料快取,以供大部分複寫使用,而入站資料傳輸是免費的。

在初始載入期間或尖峰負載期間,您可能需要更多資源。您可以使用雲端監控指標密切監控複寫執行個體資源使用率。然後,您可以根據使用情況縱向擴展和縮減複寫執行個體大小。

如需估算遷移成本的詳細資訊,請參閱: