設定������

總覽

資料庫遷移服務支援持續從來源資料庫遷移至 Cloud SQL 目的地資料庫。

PostgreSQL 支援的來源資料庫包括：

• Amazon RDS 9.6.10 以上版本、10.5 以上版本、11.1 以上版本、12、13、14、15、16、17。
• Amazon Aurora 10.11 以上版本、11.6 以上版本、12.4 以上版本、13.3 以上版本、14.6 以上版本、15.2 以上版本、16、17。
• 自行管理的 PostgreSQL (位於地端部署系統或您完全控管的任何雲端 VM) 9.4、9.5、9.6、10、11、12、13、14、15、16、17。
• PostgreSQL 適用的 Cloud SQL 9.6、10、11、12、13、14、15、16、17。
• Microsoft Azure Database for PostgreSQL Flexible Server：11 以上

設定來源時，您必須一併設定來源執行個體和基礎來源資料庫。

設定來源執行個體

如要設定來源執行個體，請按照下列步驟操作：

1. Cloud SQL 來源：如果您要從使用私人 IP 連線的 Cloud SQL 執行個體，遷移至使用非 RFC 1918 位址的 IP 範圍的 Cloud SQL 執行個體，請將非 RFC 1918 範圍新增至來源 Cloud SQL 執行個體的網路設定。請參閱 Cloud SQL 說明文件中的「設定授權網路」一節。
2. 來源執行個體中必須包含 postgres 資料庫。如果沒有，請先建立這類資料庫。

3. 在來源執行個體上安裝 pglogical 套件，並確認套件已納入 shared_preload_libraries 變數。請參閱在來源執行個體中安裝 pglogical 套件，瞭解如何在您的環境中安裝 pglogical 套件。

4. 請驗證來源例項中的擴充功能。資料庫移轉服務不會遷移 Cloud SQL 不支援的擴充功能。這些擴充功能不會阻擋遷移作業，但為了確保遷移過程順利進行，請確認您的物件或應用程式不會參照任何不支援的擴充功能。建���您������來源資料庫中������這些擴充功能和���照，再繼續操作。

5. 針對使用 pg_cron 擴充功能的來源：資料庫移轉服務不會遷移 pg_cron 擴充功能 (或與擴充功能相關聯的任何 cron 設定)，但 PostgreSQL 適用的 Cloud SQL 目的地支援這項功能。如果您在來源資料庫中使用 pg_cron 擴充功能，可以在遷移完成後，在目標執行個體上重新安裝該擴充功能。

設定來源資料庫

資料庫移轉服務會遷移來源執行個體中的所有資料庫，但下列資料庫除外：

• 內部部署 PostgreSQL 來源：範本資料庫 template0 和 template1
• Amazon RDS 來源：template0、template1 和 rdsadmin
• Cloud SQL 來源：範本資料庫 template0 和 template1
• Microsoft Azure 來源：azure_maintenance、azure_sys、template0、template1

在上方未提及的來源執行個體中，針對各個資料庫執行下列操作：

1. 僅限 PostgreSQL 9.4 版來源，請在來源執行個體中的每個資料庫上安裝下列 pglogical 擴充功能：

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

2. 對於其他所有版本，請只在來源例項的每個資料庫上安裝 pglogical 擴充功能：CREATE EXTENSION IF NOT EXISTS pglogical。

3. 如果資料表沒有主鍵，資料庫移轉服務支援在 CDC 階段遷移初始快照和 INSERT 陳述式。您應手動遷移 UPDATE 和 DELETE 陳述式。

4. 您用來連結來源執行個體的 USER (會設為 連線設定檔頁面中的使用者)，必須具備各個已遷移資料庫和預設 postgres 資料庫的特定權限。您可以建立新使用者，或是重複使用現有使用者。如要設定這些權限，請連結執行個體並執行下列指令：

   1. GRANT USAGE on SCHEMA SCHEMA to USER 在每個待遷移的資料庫中，針對所有結構定義 (資訊結構定義和開頭為「pg_」的結構定義除外) 執行。
   2. GRANT USAGE on SCHEMA pglogical to PUBLIC; 在每個要遷移的資料庫上。
   3. 針對所有資料庫執行 GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER，以便取得來源資料庫的複製資訊。
   4. GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER 在每個待遷移的資料庫中，針對所有結構定義 (資訊結構定義和開頭為「pg_」的結構定義除外) 執行。
   5. GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER 在每個待遷移的資料庫中，針對所有結構定義 (資訊結構定義和開頭為「pg_」的結構定義除外) 執行。
   6. 如果來源為 Amazon RDS，請執行下列指令：
      1. GRANT rds_replication to USER
   7. 如果來源並非 Amazon RDS，請執行下列指令：
      1. ALTER USER USER with REPLICATION 角色

在來源執行個體上安裝 pglogical 套件

本節說明如何根據來源執行個體設定 pglogical 套件和適用的參數。

內部部署或自行管理的 PostgreSQL

1. 在伺服器上安裝 pglogical 套件。
2. 連線至執行個體，並視需要設定下列參數：

   • shared_preload_libraries 必須包含 pglogical。

     如要設定這個參數，請執行 ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]'; 指令。

   • 將 wal_level 設為 logical。

     如要設定這個參數，請執行 ALTER SYSTEM SET wal_level = 'logical'; 指令。

   • 將 wal_sender_timeout 設為 0。

     如要設定這個參數，請執行 ALTER SYSTEM SET wal_sender_timeout = 0; 指令，其中 0 會停用用來終止不活躍複製連線的逾時機制。

   • max_replication_slots 定義來源執行個體可支援的複製運算單元數量上限。這個值必須至少設為預期連結的訂閱項目數量，再加上一些用於資料表同步處理的備用值。

     資料庫移轉服務需要為每個要遷移的資料庫 (也就是來源執行個體下的所有資料庫) 預留一個插槽。

     舉例來說，如果來源執行個體上有 5 個資料庫，且為來源建立了 2 項遷移工作，那麼複製作業運算單元就至少必須有 5 * 2 = 10 個，加上您已使用的複製作業運算單元數量。如果您打算使用調整過的資料傾印平行處理設定，請務必增加複製時段數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

     如要設定這個參數，請執行 ALTER SYSTEM SET max_replication_slots = #; 指令，其中 # 代表複製作業的最大時段數。

   • max_wal_senders 的設定值至少應與 max_replication_slots 相同，再加上執行個體已使用的傳送者數量。

     舉例來說，如果 max_replication_slots 參數設為 10，且您已使用 2 個傳送者，則同時執行的 WAL 傳送者程序數量為 10 + 2 = 12。 如果您打算使用調整過的資料傾印平行處理設定，請務必增加傳送端數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

     如要設定這個參數，請執行 ALTER SYSTEM SET max_wal_senders = #; 指令，其中 # 代表同時執行的 WAL 傳送程序數量。

   • max_worker_processes 的設定值至少應為資料庫移轉服務要遷移的資料庫數量 (即來源執行個體下的所有資料庫)，再加上執行個體中已使用的 max_worker_processes 數量。

     如果您打算使用調整後的資料傾印平行處理設定，請務必增加工作站程序數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

     如要設定這個參數，請執行 ALTER SYSTEM SET max_worker_processes = #; 指令，其中 # 代表要遷移的資料庫數量。

3. 如要套用設定變更，請重新啟動來源執行個體。

適用於 PostgreSQL 的 Microsoft Azure Database

如要設定 Microsoft Azure Database for PostgreSQL 來源，請按照下列步驟操作：

1. 在伺服器上安裝 pglogical 套件。

2. 僅限 PostgreSQL 9.4 版來源，請在來源執行個體中的每個資料庫上安裝下列 pglogical 擴充功能：

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

3. 對於其他所有版本，請在來源執行個體的每個資料庫上安裝 pglogical 擴充功能：CREATE EXTENSION IF NOT EXISTS pglogical。

4. 使用 Microsoft Azure 入口網站，在來源上設定必要的伺服器參數。詳情請參閱 Microsoft 說明文件中的「在 Azure Database for PostgreSQL 中設定伺服器參數」和「Azure Database for PostgreSQL 中的伺服器參數」。

   設定下列參數：

   • 將 shared_preload_libraries 設為包含 pglogical。
   • 將 azure.extensions 設為包含 pglogical。
   • 將 wal_level 設為 logical。

   • 將 max_replication_slots 設為至少要連線的訂閱數量，再加上一些備用值，用於資料表同步處理。

     max_replication_slots 參數會定義來源執行個體可支援的複製作業單元數量上限。

     資料庫移轉服務需要為每個要遷移的資料庫 (也就是來源執行個體下的所有資料庫) 預留一個插槽。

     舉例來說，如果來源執行個體上有 5 個資料庫，且為來源建立了 2 項遷移工作，那麼複製作業運算單元就至少必須有 5 * 2 = 10 個，加上您已使用的複製作業運算單元數量。如果您打算使用調整過的資料傾印平行處理設定，請務必增加複製時段數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

   • 將 max_wal_senders 設為至少與 max_replication_slots 相同，再加上執行個體已使用的傳送者數量。

     舉例來說，如果 max_replication_slots 參數設為 10，且您已使用 2 個傳送者，則同時執行的 WAL 傳送者程序數量為 10 + 2 = 12。

     如果您打算使用調整過的資料傾印平行處理設定，請務必增加傳送端數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

   • 將 max_worker_processes 設為至少與資料庫移轉服務要遷移的資料庫數量 (也就是來源執行個體下的所有資料庫) 相同，再加上執行個體已使用的 max_worker_processes 數量。

     如果您打算使用調整後的資料傾印平行處理設定，請務必增加工作站程序數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

5. 檢查 require_secure_transport 設定的值。

   根據預設，Microsoft Azure 資料庫會要求所有傳入連線都使用 SSL/TLS 加密機制。根據 require_secure_transport 值，建立來源連線設定檔時，請使用下列其中一個加密設定：

   • 如果 require_secure_transport 設為 on，請選取「Basic」、「TLS」或「mTLS」。
   • 如果 require_secure_transport 設為 off，請選取「None」。
6. 如要套用設定變更，請重新啟動來源執行個體。

Amazon RDS PostgreSQL

1. 在來源資料庫上安裝 pglogical 擴充功能。

   如需更多資訊，請參閱 Amazon RDS 說明文件中的「 使用 PostgreSQL 擴充功能與 PostgreSQL 適用的 Amazon RDS」。

2. 使用參數群組設定來源執行個體。

   1. 建立新的參數群組。在參數群組中：
   • 請確認 shared_preload_libraries 參數包含 pglogical。
   • 將 rds.logical_replication 參數設為 1。這樣就能在「logical」層級啟用 WAL 記錄。
   • 將 wal_sender_timeout 參數設為 0。這麼做會停用用來終止不活躍複製連線的逾時機制。

   • 設定 max_replication_slots 參數。這個參數會定義來源執行個體可支援的複製作業時段數量上限。必須至少設為預期連線的訂閱項目數量，再加上一些表格同步處理的備用值。

     資料庫移轉服務需要為每個要遷移的資料庫 (也就是來源執行個體下的所有資料庫) 預留一個插槽。

     舉例來說，如果來源執行個體上有 5 個資料庫，且將為來源建立 2 個遷移工作，那麼複製作業運算單元就至少必須有 5 * 2 = 10 個，加上您已使用的複製作業運算單元數量。如果您打算使用調整過的資料傾印平行處理設定，請務必增加複製時段數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

     這個參數的預設值為 10。

   • 將 max_wal_senders 參數設為至少與 max_replication_slots 相同，再加上在執行個體中已使用的傳送者數量。

     舉例來說，如果 max_replication_slots 參數設為 10，且您已使用 2 個傳送者，則同時執行的 WAL 傳送者程序數量為 10 + 2 = 12。如果您打算使用調整過的資料傾印平行處理設定，請務必增加傳送者數量，並在建立遷移工作時 執行遷移工作測試來驗證設定。

     這個參數的預設值為 10。

   • 將 max_worker_processes 來源參數設為至少與資料庫移轉服務要遷移的資料庫數量 (也就是來源執行個體下的所有資料庫) 相同，再加上執行個體上已使用的 max_worker_processes 數量。如果您打算使用調整過的資料傾印平行處理設定，請務必增加工作站程序數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

     這個參數的預設值為 8。

   2. 將參數群組連結至執行個體。如果您要建立新的執行個體，可以前往「其他設定」下方查看這個選項。

      否則，請修改執行個體以附加參數群組。

3. 如要套用設定變更，請重新啟動來源執行個體。

PostgreSQL 適用的 Cloud SQL

設定下列旗標，為來源資料庫啟用邏輯複製和解碼功能：

1. 將 cloudsql.logical_decoding 和 cloudsql.enable_pglogical 標記設為 on。

2. 設定 max_replication_slots 標記。這個標記會定義來源執行個體可支援的複寫分割區數量上限。這個值必須至少設為預期連結的訂閱項目數量，再加上一些用於資料表同步處理的備用值。

   資料庫移轉服務需要為每個要遷移的資料庫 (也就是來源執行個體下的所有資料庫) 預留一個插槽。

   舉例來說，如果來源執行個體上有 5 個資料庫，且將為來源建立 2 個遷移工作，那麼複製作業運算單元就至少必須有 5 * 2 = 10 個，加上您已使用的複製作業運算單元數量。如果您打算使用調整過的資料傾印平行處理設定，請務必增加複製時段數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

   這個標記的預設值為 10。

3. 將 max_wal_senders 標記設為至少與 max_replication_slots 相同，再加上在執行個體中已使用的傳送者數量。

   舉例來說，如果 max_replication_slots 標記設為 10，且您已使用 2 個傳送者，則同時執行的 WAL 傳送者程序數量為 10 + 2 = 12。 如果您打算使用調整過的資料傾印平行處理設定，請務必增加傳送端數量，並在建立遷移工作時 執行遷移工作測試，驗證設定。

   這個標記的預設值為 10。

4. 將 max_worker_processes 來源標記設為至少與資料庫移轉服務要遷移的資料庫數量相同 (也就是來源執行個體下的所有資料庫)，加上在執行個體上已使用的 max_worker_processes 數量。如果您打算使用調整過的資料傾印並行設定，請���必增加工作站程序數量，並在建立遷移工作時 執行遷移工作測試來驗證設定。

   這個標記的預設值為 8。

5. 將 wal_sender_timeout 參數設為 0：

   ALTER SYSTEM SET wal_sender_timeout = 0;

   值 0 會停用終止不活躍複製連線的逾時機制。

6. 重新啟動來源執行個體，讓您對標記所做的設定變更生效。

針對 9.6 以下版本的 PostgreSQL 啟用複製延遲時間監控功能

如果您要從 9.6 以下版本的 PostgreSQL 遷移，則複製延遲時間指標預設為不可用。您可以使用下列替代方案追蹤這項指標，盡可能縮短資料庫升級期間的停機時間：

• 選項 1：授予特定查詢的存取權，讓資料庫遷移服務追蹤複製延遲時間。使用具備 SUPERUSER 權限的使用者，執行下列操作：

  1. 定義下列函式，讓資料庫移轉服務查詢複製延遲時間。

     CREATE OR REPLACE FUNCTION pg_stat_replication_user()
     RETURNS TABLE (
     pid               integer                  ,
     usesysid          oid                      ,
     username          name                    ,
     application_name  text                     ,
     client_addr       inet                     ,
     client_hostname   text                     ,
     client_port       integer                  ,
     backend_start     timestamp with time zone ,
     backend_xmin      xid                      ,
     state             text                     ,
     sent_location     pg_lsn                   ,
     write_location    pg_lsn                   ,
     flush_location    pg_lsn                   ,
     replay_location   pg_lsn                   ,
     sync_priority     integer                  ,
     sync_state        text
     )
     LANGUAGE SQL
     SECURITY DEFINER
     AS $$
      SELECT *
      FROM pg_catalog.pg_stat_replication;
     $$;
     

  2. 執行下列指令，將 EXECUTE 權限授予 USER：

     1. REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
     2. GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};

• 選項 2：直接將 SUPERUSER 權限授予用於連線至來源例項的 USER。這樣一來，資料庫移轉服務就能直接讀取複製延遲時間。

• 選項 3：使用下列查詢，獨立追蹤複製延遲時間：

      SELECT current_timestamp, application_name,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.sent_location) AS sent_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.write_location) AS write_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.flush_location) AS flush_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.replay_location) AS replay_location_lag
      FROM pg_stat_replication
      WHERE application_name like 'cloudsql%';
    

  在這個選項中，資料庫遷移服務不會在圖表或 API 回應中反映複製延遲指標。