本文檔介紹如何使用 Database Migration Service 來遷移 PostgreSQL 實例及其資料庫。其中簡要介紹了整個遷移過程的各種準備步驟和最佳做法，包括注意事項和問題。本文檔適用於負責將 PostgreSQL 遷移到 Cloud SQL for PostgreSQL 的資料架構師和工程師。本文檔還包含有關將 PostgreSQL 完整遷移到 Cloud SQL for PostgreSQL 的說明。
管理同構資料庫遷移
通過 Database Migration Service for PostgreSQL，可將源 PostgreSQL 實例中的所有資料庫以同構資料庫遷移方式遷移到 Cloud SQL for PostgreSQL 實例。該 Cloud SQL for PostgreSQL 實例被特意創建為目標實例。下圖顯示了資訊流程。
Database Migration Service 是一種代管式 Google Cloud 服務。它提供了一個圖形介面，用於設置和啟動資料庫遷移過程以及切換到目標實例。遷移完成後，Database Migration Service 會將目標實例提升為新的源實例。
Database Migration Service 會在同一遷移作業中將所有資料庫從源實例遷移到目標實例。此方法可避免為每個資料庫創建單獨的遷移作業。在遷移之前，您必須準備源實例和來源資料庫。本文檔稍後將討論這些準備工作。
Database Migration Service 還支持跨版本遷移。
Database Migration Service 會自動創建和遷移目標實例、資料庫和帶有主鍵的表。不會對沒有主鍵的表這樣操作。遷移沒有主鍵的表部分介紹了該主題。
由於 Database Migration Service 是全代管式服務，因此不需要任何操作或管理監督。使用者可以完全專注于定義和運行資料庫遷移。
資料庫遷移概覽
通常，資料庫遷移過程涉及多個步驟。本文介紹基本步驟。本文檔後面部分介紹了遷移資料庫所需執行的詳細步驟。
準備源實例和資料庫
應用可實現零停機時間遷移的設置；Database Migration Service 需要這些設置。
安裝 pglogical。
指定遷移作業
遷移作業規範定義了以下項：
源實例和目標實例
網路連接
設置遷移所需的其他參數
遷移作業規範還提供連接測試，以確保 Database Migration Service 服務可訪問源實例。
計畫遷移非主鍵表
在開始遷移作業之前，為每個沒有主鍵的表創建遷移策略。
為其他例外情況做好準備
除了非主鍵表外，其他物件可能需要特別注意；請參閱準備運行資料庫遷移作業。
啟動遷移作業
完成並成功測試遷移作業設置任務後，請開始資料移轉。
驗證遷移的資料（可選）
遷移資料並將源實例處於靜默狀態以阻止進一步更改後，可選擇驗證所有資料是否在目標實例及其資料庫中。
提升目標實例
資料移轉完畢並選擇性地經過驗證後，將目標實例提升為新的主實例。
將應用遷移到新的主實例
將最初連接到源實例的應用遷移到新的主實例。
微調主實例
要優化性能，請在應用開始使用主實例後微調該實例。
設置高可用性和災難恢復
根據要求，請考慮為新的主實例啟用“跨地區副本進行災難恢復”。
本文詳細介紹了這些步驟，以便您在 Database Migration Service for PostgreSQL 上下文中全面瞭解完整資料庫遷移過程的各個方面。
假設和預期
本部分介紹按照本文檔中的說明遷移 PostgreSQL 實例及其資料庫所需的假設和預期。
資料庫引擎版本
以下說明適用於 PostgreSQL 13。源 PostgreSQL 實例在 Compute Engine 上運行。目標 Cloud SQL for PostgreSQL 版本也是 13 版。
如果您使用更早版本的 PostgreSQL，尤其是 9.4 或 9.6 版，則本文檔並不完全適用於您的情況。如需詳細瞭解這些差異，請參閱配置來源。
重啟源實例
基本假設是，您希望最大限度地減少重啟源實例的次數。根據此假設，本文對配置重新載入和實例重啟進行了區分。如果您可通過延遲實例重啟，並等待無法避免的實例重啟來避免源實例重啟，則文檔將指示重啟。
遷移所有資料庫
由於您無法僅遷移 PostgreSQL 實例中的一部分資料庫，因此本文假設您要遷移實例中的所有資料庫。
如果您只想遷移源實例中的一部分資料庫，請先移除不需要的資料庫，然後再開始遷移。或者，您也可以遷移所有資料庫，並在遷移完成後從目標實例中移除不需要的資料庫。
每種方法各有利弊：在遷移之前將資料庫遷移到不同的實例可能需要更改應用配置，還可能需要執行其他要訪問源實例的進程。在遷移後移除資料庫不會影響來源環境，但會影響遷移的費用和時間。
遷移沒有主鍵的表
Database Migration Service 不會自動遷移資料庫中沒有主鍵的表。您必須手動遷移這些表。遷移沒有主鍵的表部分概述了不同的策略。
擴展程式、大型物件和外部封裝容器
檢查來源資料庫中使用的所有功能在 Cloud SQL for PostgreSQL 中是否可用。對於您使用的所有資料類型和資料存儲方法（例如外部封裝容器），請檢查 pglogical 是否可以遷移它們或者您是否必須手動遷移它們。如需瞭解詳情，請參閱準備運行資料庫遷移作業。
費用
本教程使用 Google Cloud 的以下收費元件：
準備工作
如果您剛接觸 Google Cloud，請創建一個帳號來評估我們的產品在實際場景中的表現。新客戶還可獲享 $300 贈金，用於運行、測試和部署工作負載。
在 Google Cloud Console 中的專案選擇器頁面上，選擇或創建一個 Google Cloud 項目。
注意：如果您不打算保留在此過程中創建的資源，請創建新的專案，而不要選擇現有的項目。完成本教程介紹的步驟後，您可以刪除所創建的項目，並移除與該專案關聯的所有資源。轉到“項目選擇器”
確保您的 Cloud 專案已啟用結算功能。瞭解如何檢查項目是否已啟用結算功能。
準備資料庫遷移
以下說明介紹了如何從一個源實例遷移兩個資料庫。資料庫包含具有主鍵的常規表，以及沒有主鍵的表。
這些說明可説明您創建源 PostgreSQL 實例，以便通過 Database Migration Service 進行完整資料庫遷移。
在生產環境中，您應該已經有一個源實例，它用於為各種資料庫的用戶端提供特定的輸送量和延遲時間。
源實例存取權限
在準備遷移時，請確保您擁有足夠的存取權限。您需要適當的特權才能對源實例和來源資料庫執行所有必要的更改。
本文檔中提供了您可能必須執行的更改示例。
目標實例配置
資料庫遷移作業規範要求提供目標 Cloud SQL 實例的配置資訊。最佳做法是提供該資訊。配置資訊有助於確保您的應用在 Cloud SQL for PostgreSQL 實例上按預期運行。
通過在已配置來滿足輸送量和延遲時間要求的 Cloud SQL 實例上測試應用，可以確保實例滿足性能要求。在完成測試並確定所需的 Cloud SQL 配置後，請記下所有配置設置。指定資料庫遷移作業時需要用到它們。
如果您最開始沒有測試應用，則還可以在創建遷移作業時配置目標實例（如源實例）。在切換完成並且應用訪問目標實例的資料庫後，您可以微調資料庫。但請注意，可能在生產過程中執行此微調步驟。
網路連接
Database Migration Service 支援不同類型的網路連接。目標實例是源實例的副本，因此必須能夠連接。
請確保您的環境支持其中一種連接類型，以便在遷移作業規範期間配置這些連接類型。
資料庫架構更改
有三種類型的架構更改：
更改現有架構：例如，用戶可以通過添加列來更改現有表。
添加架構元素：例如，用戶可以添加新的表架構。
移除架構元素：例如，用戶可以移除現有的表架構。
請確定資料庫遷移期間是否會發生這些類型的更改。如果會，請使用管理架構更改部分中的資訊進行更改。
資料庫遷移工件概覽
下圖顯示了主要資料庫遷移工件及其相互關係，而不是各種資料庫的資料庫表：
上圖中的源實例由兩個資料庫組成。它還包含兩個設定檔 pg_hba.conf 和 postgresql.conf，您可能需要更改這些檔才能使用 Database Migration Service 遷移資料。
Database Migration Service 遷移作業是指源實例的連接設定檔。此設定檔指的是源實例。Database Migration Service 遷移作業也表示 Cloud SQL 目標實例。目標實例是源實例的副本（由虛線箭頭表示）。
目標實例會連接到源實例。源實例必須可通過目標實例的 IP 位址進行訪問。如果存在防火牆，則必須允許目標 Cloud SQL for PostgreSQL 實例的 IP 位址連接到源實例。
完成這些說明會在 Compute Engine 虛擬機器上創建一個源實例。要連接到源實例，您必須打開目標實例使用的 IP 位址的防火牆。
為了演示如何移動沒有主鍵的表，以下示例假定並非所有的表都有主鍵，而且您會手動遷移這些種類的表。
創建源 PostgreSQL 實例
以下步驟創建了一個示例源 PostgreSQL 實例。您可以按照說明創建新的示例實例，也可使用現有實例。
在 Cloud Shell 中，創建一個 Compute Engine 實例：
gcloud beta compute instances create pg-source-1 \ --zone=us-west1-b \ --machine-type=e2-standard-2 \ --image=ubuntu-2004-focal-v20210223 \ --image-project=ubuntu-os-cloud \ --boot-disk-size=10GB |
使用 SSH 連接到 Compute Engine 實例。
按照說明下載並安裝 PostgreSQL for Ubuntu。
登錄到 PostgreSQL shell：
sudo -u postgres psql
查詢伺服器版本：
show server_version;
記下主要版本。在指定遷移作業時使用它。
列出資料庫並觀察是否存在標準資料庫：
\l
輸出類似於以下資料庫清單：
List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+---------+---------+----------------------- postgres | postgres | UTF8 | C.UTF-8 | C.UTF-8 | template0 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres |
創建示例來源資料庫
在 PostgreSQL 實例中，創建兩個資料庫：
CREATE DATABASE dmspg_1; CREATE DATABASE dmspg_2; |
確認已創建它們：
\l
輸出類似於以下資料庫清單：
List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+---------+---------+----------------------- dmspg_1 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | dmspg_2 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | postgres | postgres | UTF8 | C.UTF-8 | C.UTF-8 | template0 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | C.UTF-8 | C.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres (5 rows) |
連接到第一個資料庫，並在每個資料庫中創建兩個表：
\c dmspg_1
CREATE TABLE accounts ( user_id VARCHAR(128) PRIMARY KEY, username VARCHAR (128) NOT NULL);CREATE TABLE notes ( note VARCHAR(256)); |
確認系統已創建資料庫表：
\dt
輸出類似於以下關係列表：
List of relations Schema | Name | Type | Owner --------+----------+-------+---------- public | accounts | table | postgres public | notes | table | postgres (2 rows) |
向表中插入一些行：
INSERT INTO accounts (user_id, username) VALUES('one','Alice'); INSERT INTO accounts (user_id, username) VALUES('two','Bob');INSERT INTO notes (note) VALUES('Initial note');INSERT INTO notes (note) VALUES('Second note');INSERT INTO notes (note) VALUES('Second note'); |
請注意，同一行會被添加到 notes 表中兩次，因為它沒有主鍵來避免重複。
確認行已插入到表中：
SELECT * FROM accounts; SELECT * FROM notes; |
創建相同的表，並將相同的行插入第二個資料庫 dmspg_2 中。如果您希望第二個資料庫中有不同的表，請創建這些表。
退出 PostgreSQL Shell：
exit;
此時，該實例包含兩個資料庫，每個資料庫包含兩個表。其中一個表沒有主鍵，並且兩行具有相同的值。這樣您就可以驗證建議的遷移方法是否有效。
準備源實例和資料庫
Database Migration Service 需要針對源實例和針對資料庫執行特定的準備步驟。下一部分將分別介紹如何準備源實例和來源資料庫。
準備源實例
配置源實例後，請重新載入它來應用新的配置值。
在 Cloud Shell 中，使用 SSH 連接到 Compute Engine 實例。
按照以下說明安裝 pglogical：pglogical 的安裝說明。
Ubuntu 上的 PostgreSQL 13 的安裝步驟如下所示：
sudo apt-get install postgresql-13-pglogical
登錄到 PostgreSQL Shell：
sudo -u postgres psql
運行以下命令來更改實例的配置（代碼示例使用預設 PostgreSQL 值）：
ALTER SYSTEM SET shared_preload_libraries = 'pglogical'; ALTER SYSTEM SET wal_level = 'logical'; ALTER SYSTEM SET max_replication_slots = 10;ALTER SYSTEM SET max_wal_senders = 10;ALTER SYSTEM SET max_worker_processes = 8; |
請參閱配置來源，瞭解如何確定適用於您的情況的值。
重新載入實例配置：
SELECT * FROM pg_reload_conf();
檢查其中一個配置是否需要重啟實例：
SELECT pending_restart FROM pg_settings WHERE name = 'max_replication_slots';
最佳做法是檢查您選擇的所有設置。這樣做有助於確保僅在一個或多個設置需要時重啟實例。
輸出如下所示：
pending_restart ----------------- t (1 row) |
輸出會顯示 pending_restart 為 true。這意味著配置的重新載入是不夠的，需要重啟實例。
從 psql 退出：
exit;
從 ssh shell 重啟實例：
sudo systemctl restart postgresql@13-main
這是一種實例重啟。它會影響對資料庫用戶端的訪問。您可考慮延遲實例重啟，直到知道沒有其他也需要實例重啟的額外配置更改為，例如，從 IDE 連接到實例或定義連接方法。
要檢查配置是否正確，請重新登錄 psql：
sudo -u postgres psql
檢查配置值是否設置為您之前指定的值：
SHOW shared_preload_libraries; SHOW wal_level; SHOW max_replication_slots;SHOW max_wal_senders;SHOW max_worker_processes; |
輸出類似於以下內容：
shared_preload_libraries -------------------------- pglogical (1 row)
postgres=# SHOW wal_level; wal_level ----------- logical (1 row)
postgres=# SHOW max_replication_slots; max_replication_slots ----------------------- 11 (1 row)
postgres=# SHOW max_wal_senders; max_wal_senders ----------------- 10 (1 row)
postgres=# SHOW max_worker_processes; max_worker_processes ---------------------- 8 (1 row) |
退出 PostgreSQL Shell：
exit;
創建遷移用戶
要遷移來源資料庫，使用者必須對所有使用者資料庫擁有特定特權。在以下步驟中，您將創建一名遷移使用者來實現此目的。如果您已在實例中定義了一名使用者來實現此目的，請跳過這些步驟並使用該使用者的個人資料。
遷移完成後，此使用者將不再提供服務。您可從源實例中移除此使用者。
在 Cloud Shell 中登錄 PostgreSQL shell：
sudo -u postgres psql
創建遷移用戶 dbmig：
CREATE USER dbmig WITH ENCRYPTED PASSWORD 'dbmig';
設置複製角色：
ALTER USER dbmig WITH REPLICATION;
退出 PostgreSQL Shell：
exit;
您可以要求使用者 postgres 設置密碼。用於設置示例密碼的命令是 ALTER USER postgres PASSWORD 'postgres'。通常，為使用者設置密碼是一種很好的做法，因此我們強烈建議您使用。如果您需要密碼登錄而非對等登錄，則必須更改 pg_hba.conf 文件（位於 /etc/postgresql/13/main/pg_hba.conf）。如需瞭解詳情，請參閱 pg_hba.conf 文件。
如果您在教程期間計畫連接到任何資料庫，請立即設置 postgres 的密碼，這樣您就不必回到本部分。
準備使用者資料庫
配置實例後，該實例中的每個使用者資料庫都需要配置。這包括您之前創建的兩個資料庫（dmspg_1 和 dmspg_2)）以及 postgres。
在 Cloud Shell 中登錄 PostgreSQL shell：
sudo -u postgres psql
列出所有使用者資料庫：
\l
此步驟有助於確保您可以看到所有使用者資料庫。您將在下一步中開始配置它們。
連接到每個 <user_database>（template0 和 template1 除外），並運行以下命令：
\c <user_database> CREATE EXTENSION IF NOT EXISTS pglogical; |
確定每個使用者資料庫中的所有使用者架構：
\dn
如果您到目前為止已按照說明操作，並且未創建架構，那麼每個資料庫中的唯一架構是 public 和 pglogical。
針對每個不是 pglogical 的 <schema> 運行以下命令（在每個使用者資料庫中）：
GRANT USAGE on SCHEMA <schema> to dbmig; GRANT SELECT on ALL TABLES in SCHEMA <schema> to dbmig; GRANT SELECT on ALL SEQUENCES in SCHEMA <schema> to dbmig; |
在每個使用者資料庫中針對 pglogical 架構運行以下命令：
GRANT USAGE on SCHEMA pglogical to dbmig; GRANT SELECT on ALL TABLES in SCHEMA pglogical to dbmig; |
您稍後指定的 Database Migration Service 遷移作業僅遷移具有主鍵的使用者資料庫表。您必須手動遷移每個使用者資料庫中沒有主鍵的表。
在每個使用者資料庫中，確定所有沒有主鍵的表。
列出所有資料庫：
\l
使用者資料庫為 dmspg_1、dmspg_2 和 postgres。對於每個資料庫，請運行以下查詢（如調試和其他工具中所述）：
select tab.table_schema, tab.table_name from information_schema.tables tableft join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY'where tab.table_type = 'BASE TABLE' and tab.table_schema not in ('pg_catalog', 'information_schema') and tco.constraint_name is nullorder by table_schema, table_name; |
結果將列出所有架構，並為每個架構列出沒有主鍵的表。忽略 pglogical 架構。記下不是 pglogical 的架構中列出的所有資料庫和表。此時，dmspg_1 架構和 dmspg_2 中的 notes 表沒有主鍵。
退出 PostgreSQL Shell：
exit;
此時，您已準備好源實例和來源資料庫。它們已準備好由 Database Migration Service 進行遷移。
從 IDE 連接到實例
本部分中的所有說明都是可選的。僅在您想要使用 DBeaver 等 IDE 連接到實例及其資料庫時才需要遵循。這些說明會打開用戶端設備 IP 位址的防火牆，並將 PostgreSQL 配置為接受來自它的連接請求。
確定設備的 IP 位址。搜索顯示您的 IP 位址的頁面，並將其記錄下來（除非您已知道設備的 IP 位址）。
在 Cloud Shell 中運行以下命令，打開 IP 位址和 TCP 埠 5432 的防火牆：
gcloud compute firewall-rules create my-device \ --allow tcp:5432 \ --source-ranges=device-ip |
替換以下內容：device-ip：您的設備的 IP 位址
使用 SSH 連接到運行 PostgreSQL 實例的虛擬機器。
將設備 IP 位址添加到允許連接的設備的清單中：
打開 pg_hba.conf 檔，它通常在 /etc/postgresql/13/main 目錄中。
在 # IPv4 local connections 部分添加一行，其中包含設備 IP 位址。
複製允許 IP 位址 127.0.0.1 進行連接的行。
將該行粘貼到設定檔中。
請修改它以包含您的設備的 IP 位址。
使用 /32 終止 IP 位址。
添加 PostgreSQL 實例應偵聽的位址：
打開 postgresql.conf 檔，它通常在 /etc/postgresql/13/main 目錄中。
找到注釋的條目 listen_addresses。
請修改它以指定 PostgreSQL 實例應偵聽的位址。
將位址設置為 '*'，以便接受任何連接：
listen_addresses = '*' |
此更改要求重啟源實例。
重啟源實例：
sudo systemctl restart postgresql@13-main |
實例重啟後，您可以從設備連接到實例中的資料庫。
稍後，Database Migration Service 會發佈需要訪問源實例來執行資料移轉的目標實例的 IP 位址。為避免再次重啟源實例，您可在此之前等著執行將打開源實例指向您的設備的步驟。然後，重啟一次實例就能同時完成這兩項更改（甚至包括您之前進行的配置更改）。
如果您將源實例打開到 '*'，則無需重啟另一個目標實例。如果您已列出特定 IP 位址，請等到目標實例 IP 位址可用為止，以避免重啟一個實例。
所有源實例和資料庫準備工作現都已完成。您現可創建源實例連接設定檔。完成此操作後，請遷移 PostgreSQL 實例。
創建來源連接設定檔
在創建資料庫遷移作業之前，請先創建源實例連接設定檔。
以下說明基於 Google Cloud 控制台介面。
在 Google Cloud 控制台中，轉到資料庫遷移頁面。
選擇連接設定檔，然後點擊創建設定檔。
從下拉清單中選擇 PostgreSQL。
填寫以下欄位：
連接設定檔名稱：使用與計算實例相同的名稱。
主機名稱或 IP 地址：使用運行 PostgreSQL 實例的 Compute Engine 實例的公共 IP 位址。
用戶名：使用您之前創建的資料庫遷移使用者。
點擊創建。
檢查您創建的連接設定檔 ID 是否顯示在連接設定檔清單中。
現在，存在與源 PostgreSQL 實例對應的連接設定檔，您可以通過其名稱來引用該設定檔。
指定資料庫遷移作業
如需指定資料庫遷移作業，請完成以下步驟：
描述您的遷移作業
此步驟會收集基本配置資訊。
在 Google Cloud 控制台中，填寫各個輸入欄位：
遷移作業名稱：提供遷移作業的名稱。最佳做法是將某種編號方案附加到名稱或其他某種指標。您可能需要指定一些遷移作業進行測試。
來源資料庫引擎：選擇 PostgreSQL 作為來源資料庫引擎。
目的地區域：選擇目標 Cloud SQL for PostgreSQL 實例的目標地區。
遷移作業類型：從下拉清單中選擇要執行的遷移類型。
查看前提條件，確保您滿足所有要求。
點擊保存並繼續。
指定源端
此步驟會配置源實例連接。完成上一步後，將顯示幕幕。
在 Google Cloud 控制台中，使用以下螢幕來定義來源：
該下拉清單顯示了可用的連接設定檔。還可以選擇創建連接設定檔。
選擇您之前創建的 pg-source-1 連接設定檔。此時螢幕會展開。
點擊保存並繼續。
創建目標端
在本部分中，您將配置目標實例。
在 Google Cloud 控制台中，轉到“資料庫遷移”頁面。
創建目標端。提供名稱和 root 密碼，並選擇目標實例版本。請務必記錄 root 密碼供將來使用。
重要提示：請記下您的 root 密碼。它需要登錄到目標實例。
實例名稱一旦創建便無法更改。您提供的名稱是遷移完成後新的主實例的名稱。最佳做法是針對其角色進行命名來作為主實例，而不是針對其臨時角色命名作為遷移目標（如本課中操作的那樣）。您選擇的名稱是為了便於您理解。但在生產環境中，您選擇的名稱應反映出它是（將是）一個主實例。
使用源實例所用的相同設置來配置目標實例。在生產環境中，您使用測試環境確定的配置值，如準備資料庫遷移部分中所述。
通過選擇存儲類型和存儲容量來繼續配置。
根據需要添加可選的標誌和標籤配置。
點擊創建並繼續。會出現以下對話方塊：
點擊創建目標並繼續。創建目標需要幾分鐘時間。
定義連接方法
在本部分中，您將配置與源實例的連接。創建目標實例後，系統會顯示其傳出 IP 位址。源實例必須能夠接受來自此 IP 位址的連接。
在 Google Cloud 控制台中，轉到“資料庫遷移”頁面。
從連接方法功能表中選擇一個選項，以更新源實例配置。根據您選擇的正在使用的設定檔類型（pg_hba.conf 和/或postgresql.conf）：
您可能必須重啟源實例，具體取決於源實例的配置方式。可在本部分執行重啟源實例中討論的優化。進行該重啟後，您之前所做的所有配置更改都會生效。
如果您只需要修改 pg_hba.conf，則重新載入配置就已足夠。如果您需要在 postgresql.conf 中更改 listen_addresses，則必須重啟源實例。
添加一條防火牆規則，以允許通過埠 5432（或您可能配置的任何其他埠）從目標實例的傳出 IP 位址傳入流量：
gcloud compute firewall-rules create pg-target-1 \ --allow tcp:5432 \ --source-ranges=<device-ip> |
點擊保存並繼續。
測試並創建遷移作業
最後一步是測試配置，然後保存或啟動遷移作業。雖然不強制要求，但最佳做法是測試配置。
在 Google Cloud 控制台中，點擊測試作業：
測試可能需要一段時間。
如果出現錯誤，您會看到一條定義問題的警告消息。
如需詳細瞭解如何調試錯誤，請參閱 Postgresql：連接被拒絕。
測試成功後，系統會顯示一條消息，指出“測試已成功通過！您可以創建此作業但不啟動它，也可以立即啟動。”
點擊創建作業。如果您尚未測試，系統會顯示警告：
點擊取消以取消顯示消息。
點擊創建並啟動作業。系統會顯示不同的警告消息：
如果您確定來源資料庫已準備好遷移，請點擊創建並啟動來開始遷移。
如果您不確定，或者需要進一步的準備（例如非主鍵表準備），請取消顯示此錯誤消息，點擊保存作業，然後點擊創建遷移作業對話方塊中的創建。此操作會使您返回資料庫遷移頁面，其中列出了新的遷移作業：
準備運行資料庫遷移作業
在開始資料庫遷移作業之前，您必須決定如何遷移沒有主鍵的表（非主鍵表）。此外，您還必須瞭解在遷移期間如何處理具體化視圖、架構更改以及其他方面。
接下來的部分將探討資料類型和資料庫行為，並探討如何使目標資料庫與來源資料庫 100% 一致。請跳過不適用於您的段落。
遷移沒有主鍵的表
當您啟動的遷移作業包含一個或多個沒有主鍵的表時，您會看到一條警告，其中顯示“請記住：源 PostgreSQL 資料庫上沒有主鍵限制的表都不會遷移。確定要開始執行這個作業嗎？”不過在開始後，對於沒有主鍵的表（非主鍵表），沒有其他警告或報告。請注意，Database Migration Service 不會移動沒有主鍵的表。請自行管理這些類型的表。
您必須確定手動遷移沒有主鍵的表的最佳時機。請考慮下面兩個選項：
在開始遷移作業之前準備非主鍵表。如果您知道非主鍵表在遷移完成之前不會發生變化，則可以將資料複製到具有相同列和代理主鍵的表中。此表稱為“轉移表”。這種方法會將資料移轉到轉移表中的目標資料庫。在切換之前，您可以在目標資料庫中創建相應的非主鍵表，並將轉移表中的資料複製到非主鍵表中。您可以將此方法應用於遷移期間不會更改行的所有非主鍵表。
在遷移作業執行期間遷移非主鍵表。如果您知道非主鍵表在遷移過程中會發生變化，則可以在開始遷移之前創建具有相同列和代理主鍵的轉移表。這種遷移方式有助於確保遷移作業知曉此轉移表。但是，只有在您知道非主鍵表的架構和資料不會更改時，才應將該表中的資料複製到轉移表中。要複製資料，最近的時間點是當所有資料都已遷移且在切換後不久。
以下部分簡要介紹了這兩種方法。另一種方法是在不使用 Database Migration Service 的情況下，通過 Cloud SQL 的導入工具遷移非主鍵表。
在開始資料庫遷移之前遷移非主鍵表
如需遷移來源資料庫的非主鍵表，請執行以下操作：
在 Google Cloud 控制台中，使用 SSH 連接到 Compute Engine 實例。
登錄到 PostgreSQL Shell：
sudo -u postgres psql
創建轉移表。在這種情況下，系統會為非主鍵表 notes 創建一個轉移表：
CREATE TABLE notes_transfer ( note VARCHAR(256), surrogate_id SERIAL PRIMARY KEY); |
將非主鍵表的行插入其轉移表 notes_transfer 中：
INSERT INTO notes_transfer (note) SELECT note FROM notes; |
選擇行以檢查插入是否有效：
SELECT * FROM notes;
確保遷移用戶還對此新表和序列擁有所有必要特權（使用 \dn 查找相關架構）：
GRANT SELECT on ALL TABLES in SCHEMA <schema> to dbmig; GRANT SELECT on ALL SEQUENCES in SCHEMA <schema> to dbmig; |
退出 PostgreSQL Shell：
exit;
遷移開始後，將像遷移其他具有主鍵的常規表一樣遷移轉移表。
遷移完成後，將轉移表資料插入到各種目標資料庫中，然後移除轉移表：
在 Google Cloud 控制台中，按照以下過程登錄目標副本：檢查目標實例中的遷移狀態。
非主鍵表是自動創建的，但未遷移任何資料。
將轉移表中的資料插入非主鍵表：
INSERT INTO notes (note) SELECT note FROM notes_transfer; |
移除轉移表：
DROP TABLE notes_transfer;
現在，目標資料庫中存在來源資料庫的非主鍵表中的資料。
在資料庫遷移期間遷移非主鍵表
此部分中的步驟與上一部分相同。但在遷移開始後，非主鍵表中的資料會插入到相應的轉移表中。僅當您確定非主鍵表中的資料不會更改時，才開始遷移。
如果非主鍵表中的來源資料發生更改，則可以從轉移表中刪除所有行，然後重新插入非主鍵表中的資料。通過此操作，您可以更正內容，而無需從頭開始遷移。
管理具體化視圖
Database Migration Service 會遷移資料庫中具體化視圖的架構，但不會遷移資料。如需瞭解詳情，請參閱產品文檔中的具體化視圖的要點。
如需列出所有具體化視圖名稱，請運行以下命令：
SELECT schemaname, matviewname FROM pg_matviews; |
在每個目標資料庫中每個具體化視圖的應用切換之前，請運行以下命令：
REFRESH MATERIALIZED VIEW <view_name>
此命令可確保在目標資料庫上刷新具體化視圖。
管理架構更改
Database Migration Service 不會自動將來源資料庫的架構更改遷移到目標資料庫。請手動遷移這些更改，如持續遷移期間複製哪些更改和持續遷移：PostgreSQL 中所述。
要在來源資料庫中進行架構更改，請按照以下步驟操作：
停止來源資料庫中的所有 DML（資料庫操縱語言），並等待來源資料庫中的所有資料都遷移到目標資料庫。這可確保來源資料庫和目標資料庫都處於靜默狀態。
更改來源資料庫和目標資料庫的架構。
在恢復來源資料庫上的任何 DML 之前，完成對來源資料庫和目標資料庫的更改。
您可通過以下兩種方式實現和執行 DDL（資料定義語言）語句：
使用 pglogical 命令 pglogical.replicate_ddl_command 提供的命令。如需查看示例，請參閱持續遷移：PostgreSQL。
在不使用 pglogical 命令的情況下直接執行 DML 語句。如果使用架構管理工具，則首選此方法。唯一需要注意的是，該工具需要實現相同的更改兩次：一次在來源資料庫上，一次在目標資料庫上。
在在目標資料庫上運行 DDL 之前授予角色。
如果您的表沒有主鍵，而且您採用轉移表方法，那麼對基表所做的任何更改都必須應用於轉移表。
記下來需要注意的是，與 DDL 語句的執行間接相關。在初始載入期間，如果 DDL 語句無法訪問所需的鎖，則可能會被遮罩。診斷 PostgreSQL 問題包含對來源資料庫可能發生的錯誤的詳細說明。
管理大型物件
pglogical 無法遷移大型對象。如需瞭解詳情，請參閱未遷移的內容：PostgreSQL。雖然 pglogical 不會遷移包含大型物件的表行，但目標資料庫中會創建一個表。如果您的表具有大型物件，則必須自行將其轉移到 Database Migration Service 之外。
轉移大型物件的一種方法是使用 pg_dump 匯出包含大型物件的表，並將其導入 Cloud SQL。必須為實例中的每個資料庫單獨執行此匯出。
下面概要介紹了該過程。執行這些步驟的最佳時機是在目標實例可用於導入之後且在提升之後。對於每個來源資料庫和目標資料庫，請確定所有包含大型物件的表。
如需嘗試執行此過程（若需要），請在 Google Cloud 控制台中創建一個名為 image 的示例表，其中包含一行：
CREATE TABLE image ( name text, raster oid);INSERT INTO image (name, raster) VALUES ('beautiful image', lo_import('<path>/image.jpg')); |
插入語句會向包含映射檔的表添加一行。請參閱面向 SQL 的大型物件函數，更好地瞭解用於大型物件的基本 SQL 命令。
使用 pg_dump 提取一個或多個表：
sudo pg_dump --blobs -t image -h localhost --username=postgres dmspg_1 > <path>/dmspg_1.dump
此命令會將表 image 轉儲到名為 dmspg_1.dump 的文件中。
將 dmspg_1.dump 檔從源系統轉移到 Cloud Storage 存儲桶：
sudo gsutil cp dmspg_1.dump gs://pg-objects
導入轉儲文件：
檢查表是否存在以及是否已在導入後填充內容：
select * from image;
顯示一些初始位元組並將其與目標進行比較，確保已導入映射：
select lo_get(16951, 0, 1000);
雖然此過程是手動的，且必須對每個來源資料庫和目標資料庫執行，但它允許您遷移具有大型物件的表。
您可以隨時執行轉儲和導入步驟。執行這些步驟的最安全的時間是當您知道包含大型物件的表不會更改時。
管理外部資料和擴展程式
對於您在源實例中使用的每個擴展程式，請先確保擴展程式或等效項在 Cloud SQL for PostgreSQL 中可用。如果 Cloud SQL for PostgreSQL 未提供擴展程式，則您必須檢查源實例及其應用用戶端，瞭解是否可以從源實例中移除擴展程式。
系統不會遷移由 PostgreSQL 之外的擴展程式管理的任何資料。必須由您來遷移這些資料集，與 Database Migration Service 無關。
管理序列
在 Database Migration Service 遷移序列時，目標中的序列值可能與源中的序列值不同。一般來說，目標中的序列值大於源中的序列值。
● 如需列出資料庫中的所有序列，請運行以下命令：
SELECT schemaname, sequencename FROM pg_sequences; |
● 如需檢查序列的最後一個值（此示例使用序列 public.notes_transfer_surrogate_id_seq），請運行以下命令：
SELECT "last_value", log_cnt, is_called FROM public.notes_transfer_surrogate_id_seq; |
如需在來源上選擇序列的值，請使用此命令。若要選擇目標上的值，請更改參數並再次運行該命令。如果源中的序列值與目標中的序列值必須相同，請運行最符合您的情況的 ALTER SEQUENCE 語句。
管理資料庫使用者
Database Migration Service 不會自動移動源實例和來源資料庫的資料庫使用者，如 Database Migration Service 文檔中所述。
如需列出 PostgreSQL 實例中的所有使用者，請在 PostgreSQL 命令提示符處運行以下命令：
\du
您必須在目標實例上自行創建使用者。如需查看詳細說明，請參閱創建和管理 PostgreSQL 用戶。
啟動資料庫遷移作業
確定如何遷移沒有主鍵的表後，您可以啟動遷移作業。請按照以下步驟操作：
在 Google Cloud 控制台中，轉到資料庫遷移頁面。
選擇遷移作業對應的核取方塊，從遷移作業列表中選擇遷移作業。
點擊啟動按鈕，或者從右側的下拉清單中選擇啟動。
○ 如果發生錯誤，系統會通過對話方塊說明所發生的情況。
○ 遷移開始後，系統會顯示正在啟動對話方塊。
○ 遷移開始後，系統會顯示正在運行 • 正在進行完全轉儲對話方塊。
○ 當遷移作業正在運行時，系統會顯示 正在運行 • 正在進行 CDC 對話方塊。
此時，遷移作業正在運行，並且資料正在從來源資料庫遷移到目標資料庫。
檢查目標實例中的遷移狀態
在遷移過程中，您可以連接到各種資料庫並從表中選擇資料，從而登錄到目標實例並檢查遷移進度。
在 Google Cloud 控制台中，轉到 Cloud SQL 頁面：
選擇表示目標實例的副本：
選擇名稱（在本例中為 pg-target-1）以查看實例頁面：
滾動到連接到此實例部分：
選擇使用 Cloud Shell 連接。此操作會打開 Cloud Shell。在這裡，您可發出常規命令來連接到目標實例中的資料庫。使用您在指定遷移作業的目標實例詳情時提供的 root 密碼。
在首次登錄時，您可能需要啟用 Cloud SQL Admin API。如果收到登錄錯誤，請啟用 Cloud SQL Admin API。
連接後，您可以列出資料庫、連接到這些資料庫並從各種表中選擇資料。
靜默、資料驗證、提升、應用切換和資料庫微調
如需繼續將資料更改從來源資料庫遷移到目標資料庫，必須運行遷移作業。
在某些時候，除非您希望遷移無限運行，否則必須使用目標資料庫作為新的主要資料庫。以下部分討論了實現該目標的主要步驟。
停機來進入靜默狀態和驗證資料
Database Migration Service 可以在應用使用來源資料庫時遷移資料，從而提供最短停機時間遷移。但是，如需將目標實例提升為新的主實例，您必須結束對來源資料庫的更改，以便 Database Migration Service 可遷移所有剩餘的更改。
如需停止對來源資料庫進行更改，請關閉所有用戶端。這成為使來源資料庫處於靜默狀態。在對來源資料庫所做的更改完成後，Database Migration Service 會遷移其餘的更改，從而結束遷移。
要確定所有資料都已遷移，最可靠的方法是對其中一個來源資料庫進行最後一次手動更改，然後等待更改顯示在相應的目標資料庫中。
遷移完成後，您可以驗證所有資料是否均已正確遷移。這是一個可選步驟，可能實現的方法是隨機選擇幾個表，並在源表和相應的目標表上運行計數查詢。計數必須相等。
如果您想深入瞭解，請編寫一個腳本，比較所有資料庫中所有表的計數。如果想要更進一步，您可以對包含可聚合列的表執行彙總查詢。在極端情況下，您需要檢查每個源行與目標行是否相等。
為了説明確保資料庫遷移不會意外插入違反表限制條件的行，您可驗證是否滿足所有的表限制條件。
您執行的驗證越多，源實例和目標實例不可用的時間越長。如果您不進行驗證，而是相信基於 pglogical 的複製正常運行，此時的停機時間最短。當您跨所有資料庫的所有表逐行建立對等項時，停機時間最長。
提升遷移作業
在來源資料庫處於靜默狀態且您執行計畫的所有驗證後，就可提升遷移作業。提升遷移作業會停止遷移並將目標實例從副本提升為主實例。
提升遷移作業對源實例沒有任何影響。如果由於任何原因導致源實例中任何資料庫的內容發生更改，則系統不會遷移該更改。遷移作業完成。
如需提升遷移作業，請按照以下說明操作：
在 Google Cloud 控制台中，轉到資料庫遷移頁面。
選擇遷移作業的名稱（當指針懸停在名稱上時，它會變為連結）。此時出現詳細資訊頁面：
選擇提升按鈕。此時出現一個對話方塊：
選擇提升。遷移作業的狀態會更改為正在運行 • 正在提升：
提升完成後，遷移作業會完成：
遷移作業提升會將目標實例從副本更改為常規主實例。pg-target-1 最初是 pg-target-1-master（表示源實例）的副本，而現在是獨立的主實例。
由於 pg-target-1-master 已發揮其作用，您可將它刪除。
選擇 pg-target-1-master（當指針懸停在名稱上時，它會變成連結）。您隨即會進入詳情頁面。
點擊刪除，然後按照出現的對話方塊中的說明操作。
刪除實例後，該實例會從實例清單中移除。
應用切換到新的主要資料庫
從遷移作業提升完成那一刻起，目標實例就是主實例。現在，您需要將所有應用連接到新的主實例。
原則上，遷移實例時無需遷移應用。您可在遷移實例之前、在遷移實例期間、在遷移實例之後遷移應用，或者根本不遷移應用。有不同的操作方法，具體取決於應用的複雜程度、人員可用性以及併發遷移的風險因素。
應用必須訪問新的主實例而不是源實例，這與決定何時遷移應用（或多個應用）無關。理想情況下，連接是通過更改配置（而不是更改應用代碼）實現的。
對源實例中所有用戶端的更改不會遷移到新的主實例。最佳做法是在切換之前，提前建立源實例的用戶端清單。這樣做能夠讓您確定用戶端實際上是否可配置為在新的主實例可用後使用它。
實例和資料庫微調
雖然嚴格來說不是資料庫遷移過程的一部分，但在將應用切換到目標 Cloud SQL 實例後，您可能需要微調實例。
源實例管理
遷移作業提升完成後，對源實例中任何來源資料庫所做的更改都不會遷移。
請考慮通過停用任何非讀取存取權限來管理源實例。此操作有助於確保在沒有立即檢測到的情況下出現錯誤的訪問。
例如，如果應用通過使用新的資料庫連接規範更新其設定檔來進行切換，那麼一個或多個應用可能被漏掉而不會更新。仍然連接到源實例的腳本也會發生這種情況。
停用源實例的任何非讀取存取權限（或所有存取權限）的最佳時機是靜默設置完成後。此操作有助於確保不會發生任何更改並且切換是一致的。
高可用性和災難恢復設置
使用 Database Migration Service 中的目標實例配置選項，您無法設置高可用性 Cloud SQL for PostgreSQL 實例，也無法在同一地區或不同地區創建唯讀副本。
清除資料
為避免因本教程中使用的資源導致您的 Google Cloud 帳號產生費用，請刪除包含這些資源的項目，或者保留項目但刪除各個資源。
警告：刪除項目會產生以下影響
專案中的所有內容都會被刪除。如果您將現有項目用於本教程，則在刪除該項目後，還將刪除您已在該專案中完成的任何其他工作。自訂項目 ID 丟失。創建此項目時，您可能創建了要在將來使用的自訂項目 ID。要保留使用該項目 ID 的網址（例如 appspot.com 網址），請刪除項目內的所選資源，而不是刪除整個項目。如果您打算流覽多個教程和快速入門，重複使用項目可以幫助您避免超出項目配額上限。在 Cloud Console 中，轉到管理資源頁面。
在項目列表中，選擇要刪除的項目，然後點擊刪除。
在對話方塊中輸入專案 ID，然後點擊關閉以刪除專案。
Comments