MySQL 適用的 Cloud SQL 災難復原：完整的備援和備援程序

階段 1：為 DR 設定 HA 資料庫執行個體

以下階段 (1-3) 會逐步引導您完成容錯移轉和回復程序。您將使用 Cloud Shell 中的 gcloud 指令執行所有指令。為簡化程序，本教學課程會盡可能使用預設設定 (例如預設的 Cloud SQL 版本)。在正式環境中，您可能會新增其他設定。

設定環境變數

本節提供環境變數範例，定義在本教學課程中執行的指令所需的各種名稱和區域。您可以視需求調整這些範例變數。

下表說明本教學課程中，每個 DR 和回復程序階段的執行個體名稱、角色和部署區域。你也可以提供自己的名稱和區域。

上表中的執行個體名稱並未以角色編碼。在 DR 情況下，執行個體的功能可能會變更，例如副本可能會成為主要執行個體。如果新主網域名稱包含「replica」一詞，可能會造成混淆和衝突。因此，建議您不要使用執行功能或角色對執行個體名稱進行編碼。

上表列出待命執行個體的名稱。雖然本教學課程不會練習 HA 容錯移轉，但為了完整起見，教學課程會包含待命執行個體的名稱。

在回溯階段，系統會在相同的原始區域中，重新建立初始階段的原始部署作業。不過，在備援時，執行個體的名稱必須變更，因為即使刪除原始執行個體，原始名稱也不會立即可用。為支援在備用階段快速建立執行個體，您應使用與初始階段所用名稱不符的執行個體名稱。

• 在 Cloud Shell 中，根據上表中的規格設定環境變數：

  export primary_name=instance-1
  export primary_tier=db-n1-standard-2
  export primary_region=us-west1
  export primary_root_password=my-root-password
  export primary_backup_start_time=22:00
  export cross_region_replica_name=instance-3
  export cross_region_replica_region=us-west2
  

  如要為主要執行個體使用不同層級，請列出可用的層級，然後為 primary_tier 指派不同的值：

  gcloud sql tiers list
  

  如需可部署 Cloud SQL 的區域清單，請參閱執行個體設定。

建立主要資料庫執行個體

1. 在 Cloud Shell 中，建立單一 Cloud SQL 執行個體：

   gcloud sql instances create $primary_name \
       --tier=$primary_tier \
       --region=$primary_region
   

   gcloud 指令會暫停，直到執行個體建立完成為止。

2. 設定根密碼：

   gcloud sql users set-password root \
       --host=% \
       --instance $primary_name \
       --password $primary_root_password
   

建立主要資料庫

1. 在 Cloud Shell 中登入 MySQL Shell，並在提示中輸入根密碼：

   gcloud sql connect $primary_name --user=root
   

2. 在 MySQL 提示中，建立資料庫並上傳測試資料：

   CREATE DATABASE guestbook;
   
   USE guestbook;
   
   CREATE TABLE entries (guestName VARCHAR(255), content VARCHAR(255), entryID INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(entryID));
   
   INSERT INTO entries (guestName, content) values ("first guest", "I got here!");
   INSERT INTO entries (guestName, content) values ("second guest", "Me too!");
   

3. 確認資料是否已成功提交：

   SELECT * FROM entries;
   

   確認系統傳回兩列資料。

4. 結束 MySQL 殼層：

   exit;
   

此時，您有一個資料庫，其中包含資料表和一些測試資料。

將主要執行個體變更為高可用性資料庫執行個體

您只能將 Cloud SQL 設定為區域 HA 系統，無法設定為跨區域系統。(設定跨區域唯讀備用資源與將 Cloud SQL 設定為跨區域系統不同)。詳情請參閱在執行個體上啟用及停用高可用性。

• 在 Cloud Shell 中，建立啟用高可用性的 Cloud SQL 執行個體：

  gcloud sql instances patch $primary_name \
      --availability-type REGIONAL \
      --enable-bin-log \
      --backup-start-time=$primary_backup_start_time
  

新增跨區域唯讀備用資源，以自動更新的方式進行災害復原

下列步驟足以為本教學課程建立跨區域唯讀副本：

1. 在 Cloud Shell 中設定跨區域唯讀備用資源：

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

2. (選用) 如要檢查資料庫是否已複製，請前往 Cloud SQL 執行個體頁面。Google Cloud

   前往「Instances」(執行個體) 頁面

   

   Google Cloud 控制台會顯示主要執行個體 (instance-1) 已啟用高可用性，且存在跨區域唯讀備用資源 (instance-3)。

3. 使用主要資料庫的相同根密碼，登入跨區域唯讀副本：

   gcloud sql connect $cross_region_replica_name --user=root
   

4. 在 MySQL 提示中選取資料，確保複製作業正常運作：

   USE guestbook;
   
   SELECT * FROM entries;
   

5. 結束 MySQL 殼層：

   exit;
   

如要瞭解如何設定完整的跨區域唯讀備用資源，請參閱 Cloud SQL 說明文件

如果是實際工作環境中的大型資料庫，建議您備份主要資料庫，並從備份建立跨區域唯讀備用資源。這個步驟有助於縮短讀取副本與主要資料庫同步處理所需的時間。下一節將說明這項程序。不過，您可以選擇略過這個步驟，繼續進行第 2 階段。

根據傾印檔案新增跨區域唯讀備用資源

如要盡量縮短建立跨區域讀取副本的時間，可以從較早且一致的主要資料庫狀態同步副本，而不是在存取新的主要資料庫時同步。這項最佳化作業需要建立傾印檔案，供副本做為起始狀態。

如要瞭解如何根據傾印檔案建立副本，請參閱「從外部伺服器複製到 Cloud SQL (v1.1)」。這個方法有助於處理大型正式版資料庫。不過，由於測試資料集夠小，可完整複製，因此本教學課程會略過這個步驟。

階段 2：模擬災害 (區域服務中斷)

在這個階段中，您會讓主要資料庫無法使用，藉此模擬實際工作環境中的主要區域中斷情形。

檢查跨區域唯讀備用資源的延遲時間

在下列步驟中，您會判斷跨區域唯讀副本的複製延遲：

1. 前往 Google Cloud 控制台的 Cloud SQL「Instances」(執行個體) 頁面。

   前往「Instances」(執行個體) 頁面

2. 按一下唯讀備用資源 (instance-3)。

3. 在指標下拉式清單中，按一下「複寫延遲」：

   

   指標會變更為「複寫延遲」。圖表顯示沒有延遲：

   

理想情況下，主要區域發生中斷時，複製延遲為零，因為零延遲可確保所有交易都會複製。如果不是零，表示部分交易可能未複製。在這種情況下，跨區域讀取副本不會包含主要副本上提交的所有交易。

讓主要執行個體無法使用

在下列步驟中，您將停止主要執行個體，模擬發生災害。如果主要執行個體已附加跨區域唯讀備用資源，您必須先分離備用資源，否則無法停止 Cloud SQL 執行個體。

1. 在 Cloud Shell 中，從主要執行個體移除跨區域唯讀備用資源：

   gcloud sql instances patch $cross_region_replica_name \
       --no-enable-database-replication
   

   系統提示時，請接受繼續操作的選項。

2. 停止主要資料庫執行個體：

   gcloud sql instances patch $primary_name --activation-policy NEVER
   

實作 DR

1. 在 Cloud Shell 中，將跨區域唯讀備用資源升級為獨立執行個體：

   gcloud sql instances promote-replica $cross_region_replica_name
   

   系統提示時，請接受繼續操作的選項。在 Cloud SQL「Instances」(執行個體) 頁面中，您會看到先前的跨區域唯讀備用資源 (instance-3) 成為新的主要執行個體，而先前的主要執行個體 (instance-1) 則已停止運作：

   

   將跨區域唯讀備用資源升級為新的主要資源後，您就可以啟用高可用性功能。最佳做法是使用適當的命名方式更新環境變數。

2. 更新環境變數：

   export former_primary_name=$primary_name
   export primary_name=$cross_region_replica_name
   export primary_tier=db-n1-standard-2
   export primary_region=$cross_region_replica_region
   export primary_root_password=my-root-password
   export primary_backup_start_time=22:00
   export cross_region_replica_name=instance-5
   export cross_region_replica_region=us-west3
   

3. 啟動新的主要伺服器：

   gcloud sql instances patch $primary_name --activation-policy ALWAYS
   

4. 將新的主要執行個體啟用為 HA 區域執行個體：

   gcloud sql instances patch $primary_name \
       --availability-type REGIONAL \
       --enable-bin-log \
       --backup-start-time=$backup_start_time
   

5. 在第三個區域中建立跨區域唯讀備用資源：

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

   在先前的步驟中，您已將 cross_region_replica_region 環境變數設為 us-west3。

   容錯移轉完成後， Google Cloud 控制台中的 Cloud SQL「執行個體」頁面會顯示新的主要執行個體 (instance-3) 已啟用高可用性，且具有跨區域唯讀副本 (instance-5)：

   

6. (選用) 如果您定期備份，請按照上述程序，將新的主要版本與最新備份版本同步。

7. (選用) 如果您使用 Cloud SQL Proxy，請設定 Proxy 使用新的主要資料庫，以便繼續處理應用程式。

處理短期區域服務中斷

觸發容錯移轉的中斷問題可能在容錯移轉完成前就已解決。在這種情況下，取消容錯移轉程序，並繼續使用發生中斷的區域中原始的主要 Cloud SQL 執行個體，可能比較合理。

視容錯移轉程序的具體狀態而定，跨區域讀取副本可能已升級。在這種情況下，您必須刪除該備用資源，然後重新建立跨區域唯讀備用資源。

刪除原始主要節點，避免核心分裂情況

為避免核心分裂情況，您必須刪除原始主要節點 (或讓資料庫用戶端無法存取)。

容錯移轉後，如果用戶端同時寫入原始主要資料庫和新的主要資料庫，就可能發生核心分裂的情況。在本例中，兩個資料庫的內容不一致。容錯移轉後，原始主要資料庫會過時，不得接收任何讀取或寫入流量。

• 在 Cloud Shell 中，刪除原始主要執行個體：

  gcloud sql instances delete $former_primary_name
  

  系統提示時，請接受繼續操作的選項。

  在 Google Cloud 控制台中，Cloud SQL「執行個體」頁面不再將原始主要執行個體 (instance-1) 顯示為部署作業的一部分：

  

階段 3：實作備援機制

如要在原始區域 (R1) 恢復運作後，實作備援至原始區域的機制，請按照第 2 階段所述的相同程序操作。該程序摘要如下：

1. 在原始區域 (R1) 中建立第二個跨區域唯讀備用資源。此時，主要執行個體有兩個跨區域讀取備用資源，分別位於 R3 和 R1 區域。

2. 將 R1 中的跨區域唯讀備用資源升級為最終主要資源。

3. 為最終主要節點啟用高可用性。

4. 在 us-west2 中，為最終主要執行個體建立跨區域唯讀備用資源。

5. 為避免核心分裂情況，請刪除所有不再需要的執行個體 (原始主要執行個體和 R3 中的跨區域唯讀備用資源)。

如先前所述，最佳做法是建立初始備份，其中包含新主要資料庫的定義開始狀態。

最終部署作業現在會有高可用性主資料庫 (名稱為 instance-6) 和跨區域讀取備用資源 (名稱為 instance-8)。

比較手動與自動 DR 的優缺點

下表說明手動或自動實作 DR 程序的優點和缺點。我們的目標不是判斷方法是否正確，而是提供判斷標準，協助您找出最符合需求的方法。

建議您先手動實作，然後定期 (最好是在實際執行環境中) 自願執行實作作業，確保手動程序運作正常，且所有團隊成員都瞭解自己的角色和責任。建議您在逐步程序文件中定義手動程序。每次導入後，您都應確認或修正程序文件。

微調程序並確認可靠性後，再決定是否要自動執行程序。如果您選取並導入自動化程序，請務必定期在正式環境中測試程序，確保能可靠地導入。