本頁面由 Cloud Translation API 翻譯而成。

設定來源
透過集合功能整理內容你可以依據偏好儲存及分類內容。

MySQL | PostgreSQL | PostgreSQL 到 AlloyDB

總覽

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

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

Amazon RDS 9.6.10 以上版本、10.5 以上版本、11.1 以上版本、12、13、14、15
Amazon Aurora 10.11 以上版本、11.6 以上版本、12.4 以上版本、13.3 以上版本、14、15
自行管理的 PostgreSQL (位於地端部署系統或您完全控管的任何雲端 VM) 9.4、9.5、9.6、10、11、12、13、14、15
Cloud SQL 9.6、10、11、12、13、14、15

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

設定來源執行個體

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

來源執行個體中必須包含 postgres 資料庫。如果沒有，請先建立這類資料庫。
在來源執行個體上安裝 pglogical 套件，並確認套件已納入 shared_preload_libraries 變數。
1. 請參閱在來源執行個體中安裝 pglogical 套件，瞭解如何在您的環境中安裝 pglogical 套件。

設定來源資料庫

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

地端部署來源：範本資料庫 template0 和 template1
Amazon RDS 來源：template0、template1 和 rdsadmin
Cloud SQL 來源：範本資料庫 template0 和 template1

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

僅限 PostgreSQL 9.4 版來源，請在來源執行個體中的每個資料庫上安裝下列 pglogical 擴充功能：
- CREATE EXTENSION IF NOT EXISTS pglogical;
- CREATE EXTENSION IF NOT EXISTS pglogical_origin;
對於其他所有版本，請只在來源例項的每個資料庫上安裝 pglogical 擴充功能：CREATE EXTENSION IF NOT EXISTS pglogical。
如果資料表沒有主鍵，資料庫移轉服務支援在 CDC 階段遷移初始快照和 INSERT 陳述式。您應手動遷移 UPDATE 和 DELETE 陳述式。

請參閱偵錯和其他工具，瞭解如何產生查詢，在沒有主鍵的 PostgreSQL 資料庫中列出資料表。對於您發現沒有主鍵的每個資料庫資料表，且該資料表並未屬於未遷移的資料庫，您應變更資料表，使其具備主鍵，或按照這個程序進行。如果資料表沒有主鍵，系統只會遷移初始快照和 INSERT 陳述式。
您用來連結來源執行個體的 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 套件，包括 max_replication_slots、max_wal_senders 和 max_worker_processes 參數的設定。您也可以在建立遷移工作時執行遷移工作測試，取得這些參數的正確值。在這個測試期間，資料庫移轉服務可以驗證您的設定，並建議正確的值。

內部部署或自行管理的 PostgreSQL

在伺服器上安裝 pglogical 套件。
連線至執行個體，並視需要設定下列參數：
- shared_preload_libraries 必須包含 pglogical。
  如要設定這個參數，請執行 ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]'; 指令。
  
  如要取得執行個體的現有程式庫，請執行 show shared_preload_libraries 指令。
- 將 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 = #; 指令，其中 # 代表要遷移的資料庫數量。
您在此步驟中設定的參數會套用至正在執行的 PostgreSQL 資料庫伺服器。您也可以在 postgresql.conf 檔案中加入下列程式碼行，讓這些變更持續生效：
- shared_preload_libraries = 'pglogical';
- wal_level = 'logical';
- wal_sender_timeout = 0;
- max_replication_slots = #;
- max_wal_senders = #;
- max_worker_processes = #;
如要套用設定變更，請重新啟動來源執行個體。

Amazon RDS PostgreSQL

在來源資料庫上安裝 pglogical 擴充功能。如需更多資訊，請參閱 Amazon RDS 說明文件中的「使用 PostgreSQL 擴充功能與 PostgreSQL 適用的 Amazon RDS」。
使用參數群組設定來源執行個體。
- 建立新的參數群組。在參數群組中：
將參數群組連結至執行個體。如果您要建立新的執行個體，可以前往「其他設定」下方查看這個選項。否則，請修改執行個體以附加參數群組。
如要套用設定變更，請重新啟動來源執行個體。

注意：pglogical 擴充功能可在來源執行個體上以純文字記錄憑證。這種行為是由擴充功能本身造成，與資料庫移轉服務或 Cloud SQL 無關。

PostgreSQL 適用的 Cloud SQL

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

將 cloudsql.logical_decoding 和 cloudsql.enable_pglogical 標記設為 on。
設定 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 數量。如果您打算使用調整過的資料傾印並行設定，請考量每個連線額外增加兩個 worker 程序 (最多 20 個 worker)。

這個標記的預設值為 8。
重新啟動來源執行個體，讓您對標記所做的設定變更生效。

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

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

方法 1：啟用資料庫移轉服務，授予特定查詢的存取權，以便追蹤複製延遲時間。使用具備 SUPERUSER 權限的使用者，執行下列操作：

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

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;
$$;

執行下列指令，將 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：使用下列查詢，獨立追蹤複製延遲時間：

如果是 PostgreSQL 10 以下版本，請以 superuser 身分執行這項指令。

    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 回應中反映複製延遲指標。

做好準備

建立來源連線設定檔