Leo Yeh's Blog

AWS 資料移轉 (1)

教學目標

初步了解 AWS 資料庫移轉服務之最佳實務的基本概念。

重點概念

首先目前已經有許多公司將資料庫的工作負載移轉至 AWS 雲端平台中,像是 Capital One 是美國一家金融控股公司為美國銀行業巨頭之一,專營信用卡、汽車貸款、銀行等金融產品,其主要使用 Amazon RDS 儲存狀態管理的交易資料,以及使用 Amazon DynamoDB 儲存使用者資料,以利客戶透過應用程式快速存取其資訊。 Airbnb 是一個讓大眾出租住宿民宿的網站,提供短期出租房屋或房間的服務,其主要使用 Amazon Aurora 建立高效能和可擴展的應用程式,以及使用 Amazon DynamoDB 儲存使用者搜尋的歷史記錄,以利方便快速查找,作為個人化搜尋的一部分。但是我們要如何將企業端的資料庫轉移至 AWS 雲端平台中呢?此時我們主要能夠透過 AWS Database Migration Service (AWS DMS) 雲端服務協助我們快速且安全的將資料庫移轉到 AWS 雲端平台中,並且來源資料庫在移轉期間也能夠維持所有功能的運作,同時確保資料庫之應用程式的停機時間降到最低。為何能夠做到呢?主要重點在轉移期間,AWS DMS 雲端服務會追蹤來源資料庫上所進行所有變更,並且套用至目的資料庫,最終使得兩個資料庫保持同步。

接著資料庫轉移可能是相同引擎類型之間的同質轉移 (Homogenous Migrations),或者是不同引擎類型之間的異質轉移 (Heterogeneous Migrations),至於當客戶使用 AWS DMS 時,將能夠設定複寫伺服器,定義來源資料庫和目的資料庫,並且建立來源資料庫和目的資料庫之間轉移資料的任務,任務基本上主要包括三個階段,分別為完全載入、套用快取變更和持續複寫。而在完全載入期間,資料將會從來源資料庫上的資料表載入至目的資料庫上,預設一次載入 8 個資料表,並且當滿載時所有正在載入資料表的變更會暫存至複寫伺服器的快取中,因此開始擷取個別資料表的變更將會有所不同,而當完全載入資料表之後,就能夠立即開始套用該資料表的快取變更,並且收集變更作為正在進行複寫階段的交易,而當所有暫存快取的變更皆套用之後,此時所有資料表在交易上的資料將會是一致的,並且轉移至正在進行的複寫階段,再將變更套用為交易,至於正在進行的複寫階段時累積的交易工作將會造成來源資料庫和目的資料庫之間的延遲,但是完成累積的交易工作之後,系統最終還是會達到穩定的狀態。此外在大多數情況下,我們將會花費最多時間進行設計綱要的轉移,若我們正在執行同質轉移,則能夠透過引擎對應的本機工具來執行相關操作來執行無資料匯出和匯入設計綱要,反之若我們正在執行異質轉移,則能夠透過 AWS Schema Conversion Tool (AWS SCT) 來產生完整的目標設計綱要。

再來常見的資料轉移類型,主要有三種,分別為:

  1. 轉移現有資料:主要根據需要建立的資料表從來源資料庫轉移資料至目的資料庫,此類型需要能夠承受長時間的中斷來轉移現有資料。
  2. 轉移複寫資料變更:主要使用外部其它方法批次產生現有資料之後,僅針對複寫資料變更進行富步,此時我們透過變更日誌中的時間開始進行同步,通常變更日誌會保留 24 小時以上以利進行複寫資料變更的轉移。
  3. 轉移現有資料且複寫正在進行的變更:主要執行完整資料在擷取來源資料庫上變更時載入,並且當完成載入完成之後,取變更將套用於目的資料蟀中,最終變更的套用將會達到一個穩定的狀態,此時就能夠關閉應用程式,讓剩下的變更轉向目的資料庫,然後重新啟動應用程式指定為目的資料庫。

至於 AWS Database Migration Service (AWS DMS) 則主要是協助我們在幾乎不停機的情況下,將資料庫移轉到 AWS 雲端平台,並且在移轉期間來源資料庫的所有資料變更皆會持續複寫到目標資料庫,讓來來源資料庫在移轉期間內仍然能夠完全運作,以及當資料庫完成移轉之後,目標資料庫會在所選擇的時間與來源資料庫保持同步,讓我們在方便的時間切換來源資料庫至目的資料庫。此外持續資料複寫有許多使用案例,像是災難復原同步執行、開發和測試環境的資料庫同步,當然我們更能夠使用 AWS DMS 針對所有支援資料庫引擎的同質和異質資料複寫,而來源資料庫或目的資料庫能夠企業內部 IT 環境或 AWS 雲端平台中,同時更能夠將同一個資料庫的資料複寫到一或多個目的資料庫,也能夠從多個來源資料庫合併資料且複寫到一或多個目的資料庫中。

最後有許多因素會影響移轉的效能,像是來源資料庫上的可用性,可用網路輸出量,複寫伺服器的資源容量,擷取目的資料庫變更的能力,來源資料的類型和分佈,需要轉移物件的數量、… 等。而當我們遇到轉移效能一個或多個瓶頸的限制與挑戰時,就能夠透過以下方式來提高效能,分別為:

  1. 平行載入多個資料表:預設 AWS DMS 會平行載入 8 個資料表,請注意若是複寫伺服器轉小時,則透過平行載入多個資料將會降低效能,因此需要減少平行載入多個資料表的數量,反之若是複寫伺服器較大時,則透過平行載入多個資料將會提高效能,因此需要增加平行載入多個資料表的數量。
  2. 移除目的資料庫上的瓶頸:通常在資料轉移的過程中將會發生資源競爭的問題,此時建議用不必要的觸發事件、資料驗證、輔助索引、日誌記錄、資料備份、…等直到備進行切換時同樣。遷移到非RDS時
    系統,禁用任何日誌記錄,直到切換通常是一個好主意。
  3. 使用多個任務:當進行單次轉移時使用多個任務將能夠提高性能,所以針對非交易的資料表將能夠透過多個任務進行轉移,請注意在任務中維護交易一致性是非常重要的事情,因為單獨任務中的資料表不參與共同交易,並且每個任務將獨立讀取交易,而對於非常大的來源資料庫或具有許多大型物件的資料庫,則能夠考慮使用多個複寫伺服器,每個包含一個或多個任務優化處理的效能。
  4. 改善大型物件處理效能:請注意大型物件 (Large objects,LOB) 參數,盡可能使用有限的 LOB 模式,並且若我們有由一些大型 LOB 和大多數小型 LOB 所組成的資料表時,則考慮拆分資料表至一個包含大的 LOB 資料表和一個包含小的 LOB 資料表進行,然後我們就能夠在有限的 LOB 模式 (Limited LOB mode) 下使用任務來轉移小的 LOB 資料表,以及透過完全 LOB 模式 (Full LOB mode) 下的任務,用於轉移包含大的 LOB 資料表。
  5. 優化變更處理:預設 AWS DMS 會以交易模式處理變更,這會保留交易完整性,若我們能夠承擔交易完整性的暫時性失誤,則能夠啟用批次優化,以利優化變更處理的效能,請注意使用批次優化的應用肯定會違反參考完整性約束,因此我們應該在轉移期間禁用處理,並且將其作為切換過程的一部分。

除此之外,在資料轉移期間,則建議降低來源資料庫的負載,因為 AWS DMS 會對正在處理的每個來源資料表平行執行全資料表掃描,以及每個任務都會定期查詢來源資料庫以取得更更資訊,而若要執行變更處理,則我們可能會需要增加寫入目的資料庫變更日誌的資料,若發現來源資料庫負載過重時,則建議減少每個轉移任務的資料表數量,或者考慮讀取副本執行資料轉移相關作業,請注意使用讀取副本將會增加複寫的延遲。

相關資源

⬅️ Go back