總覽
資料庫遷移服務支援持續從來源資料庫遷移至 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 以上
設定來源時,您必須一併設定來源執行個體和基礎來源資料庫。
設定來源執行個體
如要設定來源執行個體,請按照下列步驟操作:
- Cloud SQL 來源:如果您要從使用私人 IP 連線的 Cloud SQL 執行個體,遷移至使用非 RFC 1918 位址的 IP 範圍的 Cloud SQL 執行個體,請將非 RFC 1918 範圍新增至來源 Cloud SQL 執行個體的網路設定。請參閱 Cloud SQL 說明文件中的「設定授權網路」一節。
- 來源執行個體中必須包含
postgres
資料庫。如果沒有,請先建立這類資料庫。 在來源執行個體上安裝
pglogical
套件,並確認套件已納入shared_preload_libraries
變數。請參閱在來源執行個體中安裝pglogical
套件,瞭解如何在您的環境中安裝pglogical
套件。請驗證來源例項中的擴充功能。資料庫移轉服務不會遷移 Cloud SQL 不支援的擴充功能。這些擴充功能不會阻擋遷移作業,但為了確保遷移過程順利進行,請確認您的物件或應用程式不會參照任何不支援的擴充功能。建議您先從來源資料庫中移除這些擴充功能和參照,再繼續操作。
針對使用
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
在上方未提及的來源執行個體中,針對各個資料庫執行下列操作:
僅限 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
陳述式。您用來連結來源執行個體的 USER (會設為 連線設定檔頁面中的使用者),必須具備各個已遷移資料庫和預設
postgres
資料庫的特定權限。您可以建立新使用者,或是重複使用現有使用者。如要設定這些權限,請連結執行個體並執行下列指令:GRANT USAGE on SCHEMA SCHEMA to USER
在每個待遷移的資料庫中,針對所有結構定義 (資訊結構定義和開頭為「pg_」的結構定義除外) 執行。GRANT USAGE on SCHEMA pglogical to PUBLIC;
在每個要遷移的資料庫上。- 針對所有資料庫執行
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER
,以便取得來源資料庫的複製資訊。 GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER
在每個待遷移的資料庫中,針對所有結構定義 (資訊結構定義和開頭為「pg_」的結構定義除外) 執行。GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER
在每個待遷移的資料庫中,針對所有結構定義 (資訊結構定義和開頭為「pg_」的結構定義除外) 執行。- 如果來源為 Amazon RDS,請執行下列指令:
GRANT rds_replication to USER
- 如果來源並非 Amazon RDS,請執行下列指令:
ALTER USER USER with REPLICATION
角色
在來源執行個體上安裝 pglogical
套件
本節說明如何根據來源執行個體設定 pglogical
套件和適用的參數。
內部部署或自行管理的 PostgreSQL
- 在伺服器上安裝 pglogical 套件。
- 連線至執行個體,並視需要設定下列參數:
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 = #;
指令,其中 # 代表要遷移的資料庫數量。
- 如要套用設定變更,請重新啟動來源執行個體。
適用於 PostgreSQL 的 Microsoft Azure Database
如要設定 Microsoft Azure Database for PostgreSQL 來源,請按照下列步驟操作:
- 在伺服器上安裝 pglogical 套件。
僅限 PostgreSQL 9.4 版來源,請在來源執行個體中的每個資料庫上安裝下列
pglogical
擴充功能:CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
對於其他所有版本,請在來源執行個體的每個資料庫上安裝
pglogical
擴充功能:CREATE EXTENSION IF NOT EXISTS pglogical
。使用 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
數量。如果您打算使用調整後的資料傾印平行處理設定,請務必增加工作站程序數量,並在建立遷移工作時 執行遷移工作測試,驗證設定。
- 將
檢查
require_secure_transport
設定的值。根據預設,Microsoft Azure 資料庫會要求所有傳入連線都使用 SSL/TLS 加密機制。根據
require_secure_transport
值,建立來源連線設定檔時,請使用下列其中一個加密設定:- 如果
require_secure_transport
設為on
,請選取「Basic」、「TLS」或「mTLS」。 - 如果
require_secure_transport
設為off
,請選取「None」。
- 如果
- 如要套用設定變更,請重新啟動來源執行個體。
Amazon RDS PostgreSQL
在來源資料庫上安裝
pglogical
擴充功能。如需更多資訊,請參閱 Amazon RDS 說明文件中的「 使用 PostgreSQL 擴充功能與 PostgreSQL 適用的 Amazon RDS」。
使用參數群組設定來源執行個體。
- 建立新的參數群組。在參數群組中:
- 請確認
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。
將參數群組連結至執行個體。如果您要建立新的執行個體,可以前往「其他設定」下方查看這個選項。
否則,請修改執行個體以附加參數群組。
如要套用設定變更,請重新啟動來源執行個體。
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
數量。如果您打算使用調整過的資料傾印並行設定,請務必增加工作站程序數量,並在建立遷移工作時 執行遷移工作測試來驗證設定。這個標記的預設值為 8。
將
wal_sender_timeout
參數設為0
:ALTER SYSTEM SET wal_sender_timeout = 0;
值
0
會停用終止不活躍複製連線的逾時機制。- 重新啟動來源執行個體,讓您對標記所做的設定變更生效。
針對 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:REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
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 回應中反映複製延遲指標。