共用方式為

無縫移轉至適用於 PostgreSQL 的 Azure 資料庫的最佳做法

  • 發行項

適用範圍： 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器

本文說明為確保順利且成功地移轉至適用於 PostgreSQL 的 Azure 資料庫，所會遇到的常見陷阱，以及進行此移轉的最佳做法。

移轉前驗證

在移轉的第一個步驟中，請先執行移轉前驗證，再執行移轉。 您可以使用移轉 [設定] 頁面中的 [驗證] 和 [驗證並移轉] 選項。 移轉前驗證會針對預先定義的規則集進行徹底的檢查。 目標是找出潛在問題，並提供可付諸行動的見解以進行補救動作。 請不斷執行移轉前驗證，直到其產生成功狀態為止。 若要深入了解，請參閱預先移轉驗證。

目標彈性伺服器設定

在初始基底資料複本期間，會在目標上執行多個 insert 陳述式，以產生預寫記錄 (WAL)。 在這些 WAL 封存前，記錄會取用目標上的儲存體以及資料庫所需的儲存體。

若要計算數目，請登入來源執行個體，然後針對要移轉的所有資料庫執行此命令：

SELECT pg_size_pretty( pg_database_size('dbname') );

建議您在彈性伺服器上配置足夠的儲存體，數目相當於上述命令所使用儲存體的 1.25 倍或多 25% 的儲存體。 您也可以使用儲存體自動成長。

重要

您無法在手動設定或儲存體自動成長中減少儲存體大小。 儲存體設定頻譜中的每個步驟都會讓大小加倍，因此請務必事先估計所需的儲存體。

使用入口網站建立適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器執行個體的快速入門是絕佳起點。 如需每個伺服器設定的詳細資訊，請參閱適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器中的計算和儲存體選項。

重要

建立彈性伺服器之後，請務必先將彈性伺服器上的 password_encryption 伺服器參數從 SCRAM-SHA-256 變更為 MD5，再進行移轉。 這對於單一伺服器上的現有認證在彈性伺服器上運作至關重要

移轉時間表

每次移轉開始之後都會有最長七天 (168 小時) 的存留期，七天後就會逾時。 在資料驗證和所有檢查都完成之後，您可以完成移轉和應用程式完全移轉，以避免移轉逾時。在連線移轉中，初始基底複本完成之後，完全移轉視窗會持續三天 (72 小時)，之後便會逾時。在離線移轉中，應用程式應該停止寫入至資料庫，以防止資料遺失。 同樣地，針對連線移轉，請在整個移轉過程保持低流量。

大多數的非實際執行伺服器 (開發、UAT、測試和預備) 會使用離線移轉來進行移轉。 因為這些伺服器的資料比實際執行伺服器少，所以移轉十分快速。 若為生產伺服器的移轉，則必須知道要完成移轉所需的時間，才能事先做好規劃。

完成移轉所需的時間取決於幾個因素。 這些因素包括資料庫數目、大小、每個資料庫內的資料表數目、索引數目，以及所有資料表的資料分佈情況。 時間也取決於目標伺服器的 SKU，以及來源執行個體和目標伺服器上可用的 IOPS。 因為可影響移轉時間的因素很多，所以很難估計完成移轉所需的總時間。 最佳方式是使用您的工作負載來執行測試移轉。

在計算執行實際執行伺服器移轉的總停機時間時，會考慮下列各階段：

  • PITR 的移轉：若要準確估計實際執行資料庫伺服器移轉所需的時間，最好的方式是對實際執行伺服器進行時間點還原 (PITR)，並在這個新還原的伺服器上執行離線移轉。

  • 緩衝區的移轉：完成上述步驟之後，您可以規劃在應用程式流量低的時段期間進行實際的實際執行環境移轉。 您可以規劃在同一天或大約一星期後進行此移轉。 在到達這個時間之前，來源伺服器的大小可能會增加。 請根據所增加的大小，更新生產伺服器的預估移轉時間。 如果增加幅度很大，則可以考慮使用 PITR 伺服器再做一次測試。 但針對大多數的伺服器，增加的大小應該不會相當顯著。

  • 資料驗證：實際執行伺服器移轉完成之後，您需要確認彈性伺服器中的資料是否完全複製來源執行個體。 您可以使用開放原始碼或第三方工具，也可以手動進行驗證。 在實際移轉之前，請準備您想要執行的驗證步驟。 驗證可以包括：

    • 資料列計數與移轉所涉及的所有資料表相符。

    • 比對所有資料庫物件 (資料表、序列、延伸模組、程序和索引) 的計數。

    • 比較重要應用程式相關資料行的最大或最小識別碼。

      注意

      資料庫的比較大小不是正確的驗證計量。 來源執行個體可能會有膨脹或無效 Tuple，而這可能會增加來源執行個體的大小。 來源執行個體與目標伺服器之間的大小有差異十分正常。 前三個驗證步驟中的問題指出移轉發生問題。

  • 伺服器設定的移轉：任何自訂伺服器參數、防火牆規則 (如果適用)、標記和警示都必須從來源執行個體手動複製至目標。

  • 變更連接字串：驗證成功之後，應用程式應該將其連接字串變更為彈性伺服器。 此活動會與應用程式小組進行協調，以變更指向來源執行個體之連接字串的所有參考。 在彈性伺服器中，可於連接字串中以 user=username 的格式使用 user 參數。

例如：psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

雖然移轉的執行通常不會有任何問題，但最好還是要規劃應變措施，以免您需要更多時間進行偵錯，或需要重新開始移轉。

移轉速度基準

下表顯示使用移轉服務針對各種大小的資料庫執行移轉所需的時間。 此移轉是使用彈性伺服器搭配 SKU Standard_D4ds_v4 (4 核心、16 GB 記憶體) 執行。

資料庫大小 所花費的大約時間 (HH:MM)
1 GB 00:01
5 GB 00:03
10 GB 00:08
50 GB 00:35
100 GB 01:00
500 GB 04:00
1,000 GB 07:00

上述數字是完成移轉所需的大約時間。 強烈建議您使用工作負載執行測試移轉，以取得移轉伺服器所需的精確時間。

重要

雖然高載 SKU 並非限制，但建議選擇較高的 SKU，讓彈性伺服器執行更快速的移轉。 「適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器」支援近乎零停機的計算和 IOPS 縮放，因此可在最短停機時間下更新 SKU。 您隨時可以變更 SKU，以符合移轉後的應用程式需求。

改善移轉速度：資料表的平行移轉

建議針對目標使用功能強大的 SKU，因為 PostgreSQL 移轉服務會在彈性伺服器上用盡容器。 強大的 SKU 可讓您平行移轉更多資料表。 您可以在移轉之後，將 SKU 縮放回您慣用的設定。 如果資料表中的資料分佈需要更加平衡，或是功能更強大的 SKU 未大幅影響移轉速度，則本節包含可改善移轉速度的步驟。

如果來源上的資料分佈高度扭曲，而且大部分的資料都在某個資料表中，則需要充分利用針對移轉所配置的計算，而這會產生瓶頸。 因此，會將大型資料表分割成較小的區塊，然後平行進行移轉。 這項功能適用於具有超過 1,000,000 (1 百萬) 個 Tuple 的資料表。 如果符合下列其中一個條件，則可以將資料表分割成較小的區塊：

  • 資料表必須具有一個資料行，而此資料行具有類型為 int 或 significant int 的簡單 (非複合) 主索引鍵或唯一索引。

    注意

    如果是第一種或第二種方式，則您必須仔細評估將唯一索引資料行新增至來源結構描述的影響。 只有在確認新增唯一索引資料行不會影響應用程式的情況下，您才能繼續進行變更。

  • 如果資料表沒有類型為 int 或 significant int 的簡單主索引鍵或唯一索引，但具有符合資料類型準則的資料行，則可以使用下列命令以將資料行轉換成唯一索引。 此命令不需要鎖定資料表。

        create unique index concurrently partkey_idx on <table name> (column name);

  • 如果資料表沒有 simple int/big int 主索引鍵或唯一索引，或沒有任何符合資料類型準則的資料行，則您可以使用 ALTER 來新增這類資料行，並在移轉後將其捨棄。 執行 ALTER 命令需要鎖定資料表。

        alter table <table name> add column <column name> big serial unique;

如果符合上述任何條件，則會在多個磁碟分割中平行移轉資料表，移轉速度應該會增加。

運作方式

  • 移轉服務會查閱資料表的主索引鍵/唯一索引的最大和最小整數值，而資料表必須進行分割並平行移轉。
  • 如果最小值與最大值之間的差異超過 1,000,000 (1 百萬)，則會將資料表分割成多個部分，而且會平行移轉每個部分。

簡而言之，在下列情況下，PostgreSQL 移轉服務會以平行執行緒移轉資料表，並縮短移轉時間：

  • 資料表的資料行具有整數類型或巨大整數的簡單主索引鍵或唯一索引。
  • 資料表至少有 1,000,000 (1 百萬) 個資料列，而這讓主索引鍵的最小值與最大值之間的差異超過 1,000,000 (1 百萬)。
  • 所使用的 SKU 有閒置核心可用於平行移轉資料表。

清理 PostgreSQL 資料庫中的膨脹

隨著時間過去，資料會新增、更新和刪除，PostgreSQL 可能會累積無效的資料列和遭到浪費的儲存體空間。 此膨脹可能會導致儲存體需求增加，並讓查詢效能降低。 清理是一項重要的維護工作，可協助回收這個遭到浪費的空間，並確保資料庫有效率地運作。 清理可解決無效資料列和資料表膨脹這類問題，確保有效率地使用儲存體。 其也有助於確保加快移轉速度，因為移轉時間是資料庫大小的函數。

PostgreSQL 提供 VACUUM 命令，以回收無效資料列所佔用的儲存體。 ANALYZE 選項也會收集統計資料，進而將查詢規劃最佳化。 針對具有大量寫入活動的資料表，可以使用 VACUUM FULL 以讓 VACUUM 程序更為積極，但需要更多的時間來執行。

  • 標準清理

    VACUUM your_table;

  • 清理與分析

    VACUUM ANALYZE your_table;

  • 大量寫入資料表的積極清理

    VACUUM FULL your_table;

在此範例中，請將 your_table 取代為實際的資料表名稱。 沒有 FULL 的 VACUUM 命令會有效率地回收空間，而 VACUUM ANALYZE 會將查詢規劃最佳化。 請謹慎使用 VACUUM FULL 選項，因為其效能影響更大。

某些資料庫會儲存大型物件 (例如影像或文件)，而隨著時間過去，這些物件可能會造成資料庫膨脹。 VACUUMLO 命令是針對 PostgreSQL 中的大型物件所設計的。

  • 清理大型物件

    VACUUMLO;

定期納入這些清理策略可確保維護良好的 PostgreSQL 資料庫。

特殊考量

您在繼續進行教學課程或模組之前需要知道一些通常涉及獨特情況、設定或必要條件的特殊狀況。 這些狀況可能包括成功完成學習內容所需的特定軟體版本、硬體需求或其他工具。

線上移轉

連線移轉會利用 pgcopydb 遵循，並套用一些邏輯譯碼限制。 此外，建議您在進行連線移轉之資料庫的所有資料表中都具有主索引鍵。 如果主索引鍵不存在，則這個缺陷會導致在移轉期間只反映 insert 作業，而未包含 update 或 delete。 先將暫存主索引鍵新增至相關資料表，您才能繼續進行連線移轉。

注意

在沒有主索引鍵的情況下，對資料表進行連線移轉時，只會在目標上重新執行 insert 作業。 如果來源上所更新或刪除的記錄未反映在目標上，則這可能會造成資料庫中的不一致。

替代方法是使用 ALTER TABLE 命令，其中動作為 REPLICA IDENTIY (英文) 搭配 FULL 選項。 FULL 選項會記錄資料列中所有資料列的舊值，如此一來，即使沒有主索引鍵，所有 CRUD 作業仍會反映在連線移轉期間的目標上。 如果這些選項都無法運作，請執行離線移轉作為替代方法。

具有 postgres_fdw 延伸模組的資料庫

postgres_fdw 模組會提供外部資料包裝函式 postgres_fdw，其可用來存取外部 PostgreSQL 伺服器中所儲存的資料。 如果您的資料庫使用此延伸模組，則必須執行下列步驟才能確保移轉成功。

  1. 暫時移除 (取消連結) 來源執行個體上的外部資料包裝函式。
  2. 使用移轉服務來執行待用資料移轉。
  3. 在移轉之後，將外部資料包裝函式角色、使用者和連結還原到目標上。

具有 postGIS 延伸模組的資料庫

postGIS 延伸模組在不同的版本之間存在重大變更/精簡問題。 如果您移轉至彈性伺服器，則請針對較新的 postGIS 版本來檢查應用程式，以確保應用程式不受影響，或必須進行必要的變更。 postGIS 新聞和發行備註是了解不同版本之間中斷性變更的好起點。

資料庫連線清除

有時候，您可能會在開始移轉時遇到此錯誤：

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

在此情況下，您可以向 migration user 授與權限，讓其關閉資料庫的所有作用中連線，或在您重試移轉之前手動關閉連線。

相關內容