還原執行個體總覽

Cloud SQL 可讓您從備份還原執行個體，或執行時間點復原 (PITR)。您可以將備份還原至現有或新的執行個體，藉此將執行個體復原至特定時間點或時間範圍。如要還原，可以使用現有或已刪除執行個體的備份。還原作業會擷取來源執行個體的設定、資料庫和使用者，並在您選擇的目標執行個體中設定這些項目。

還原至新執行個體時，目標執行個體可以位於與來源執行個體不同的區域或專案。目標執行個體也可以使用與來源執行個體不同的核心數量或記憶體容量。

Cloud SQL 一律會將目標執行個體的儲存空間容量，設為已設定磁碟和備份磁碟大小的最大值。備份磁碟的大小與備份時的磁碟大小相同。

還原執行個體時，請注意下列事項：

  • 還原作業會覆寫目標執行個體上的所有資料。
  • 來源執行個體的旗標不會還原。還原後，先前在目標執行個體上設定的所有旗標都會保留。
  • 目標執行個體在還原作業期間將會無法連線，現有的連線也會中斷。
  • 如要還原至含有唯讀副本的執行個體，則必須刪除所有副本，並在還原作業完成後重新建立。
  • 還原作業會重新啟動執行個體。
  • 從備份還原後，目標執行個體的備份設定會設為預設值。如果來源執行個體有自訂備份設定，或使用進階級備份，則必須在還原完成後更新備份設定。

使用備份還原

Cloud SQL 可讓您使用備份還原執行個體。您可以使用現有或已刪除執行個體的備份，還原至新的或現有的執行個體。您可以使用任何可用的備份還原執行個體。如要進一步瞭解 Cloud SQL 的備份運作方式，請參閱「備份總覽」。

使用備份還原執行個體時，您可以執行下列操作：

  • 還原至新執行個體
  • 還原至現有執行個體
  • 還原至其他專案或區域中的執行個體

如果服務中斷，您仍可擷取特定專案中的備份清單，並從中還原。

如要使用備份還原執行個體，請參閱「使用備份還原執行個體」。

使用進階級備份還原已啟用 CMEK 的執行個體

如果使用已啟用 CMEK 的執行個體和進階備份，備份會受到與執行個體相同的 CMEK 保護。如果執行個體需要 CMEK 加密，這項功能可以成為備份方案的重要一環，因為這項功能會將 CMEK 加密備份保存在獨立專案中，即使原始工作負載專案遭到入侵或刪除，也能成功還原。

將已啟用 CMEK 的執行個體進階級備份還原至新執行個體時，您可以為新執行個體選擇下列任一加密選項：

  • 使用與原始執行個體相同的 Cloud KMS 金鑰。這是預設行為。
  • 為目標執行個體選取其他 Cloud KMS 金鑰。如要選取其他金鑰，請在還原指令中設定 --disk-encryption-key 旗標。
  • 將目標執行個體還原為 Google-owned and Google-managed encryption keys 。如要使用 GMEK，請在還原指令中設定 --clear-disk-encryption 旗標。

時間點復原 (PITR)

PITR 可讓您將執行個體還原至資料庫的特定時間點。舉例來說，如果發生錯誤而遺失資料，您可以將資料庫復原至錯誤發生前的狀態。與使用備份還原不同，PITR 一律會建立新的執行個體。您無法對現有執行個體執行 PITR。新的執行個體會繼承來源執行個體的設定，與建立複製版本時類似。

如果您建立 Cloud SQL Enterprise Plus 版本執行個體，系統會預設啟用 PITR。如果不想啟用這項功能，請手動停用。

如果您在 Google Cloud 控制台建立 Cloud SQL Enterprise 版本執行個體，系統會預設啟用 PITR。如果建立 MySQL 適用的 Cloud SQL 執行個體時啟用了高可用性，系統預設也會啟用 PITR。否則，如果您使用 gcloud CLI、Terraform 或 Cloud SQL Admin API 建立執行個體，PITR 預設為停用。如要為這些執行個體啟用 PITR，您必須手動啟用。

如需執行 PITR 的逐步說明，請參閱「使用時間點復原 (PITR)」。

PITR 記錄檔儲存空間

PITR 會使用二進位記錄封存記錄。使用備份還原現有執行個體時，系統會刪除這些封存記錄，因此無法執行 PITR。只有在還原完成後產生的新記錄，才能用於 PITR。

2023 年 8 月 11 日，我們推出在 Cloud Storage 中儲存 PITR 交易記錄的功能。這項功能推出後，適用下列條件：

  • 所有 Cloud SQL Enterprise Plus 版本執行個體都會將用於 PITR 的二進位記錄儲存在 Cloud Storage 中。只有在 2024 年 4 月 1 日前從 Cloud SQL Enterprise 版本升級，且在 2023 年 8 月 11 日前啟用 PITR 的 Cloud SQL Enterprise Plus 版本執行個體，才會繼續將 PITR 記錄儲存在磁碟。

  • 如果 Cloud SQL Enterprise 版本執行個體是在 2023 年 8 月 11 日前建立，且已啟用 PITR，則會繼續將 PITR 記錄儲存在磁碟。

  • 如果您在 2023 年 8 月 11 日後，將儲存 PITR 交易記錄的 Cloud SQL Enterprise 版本執行個體升級至 Cloud SQL Enterprise Plus 版本，升級程序會將 PITR 交易記錄的儲存位置切換至 Cloud Storage。詳情請參閱「使用就地升級功能，將執行個體升級至 Cloud SQL Enterprise Plus 版本」。

  • 2023 年 8 月 11 日之後，您建立的所有 Cloud SQL Enterprise 版本執行個體，只要啟用 PITR，就會將 PITR 使用的記錄檔儲存在 Cloud Storage。

如果執行個體使用 Cloud Storage 儲存二進位記錄，記錄會儲存在主要執行個體所在的區域。Cloud SQL Enterprise Plus 版本的記錄最多可儲存 35 天，Cloud SQL Enterprise 版本則為 7 天，且每個執行個體不會產生額外費用。

如要進一步瞭解如何查看 PITR 交易記錄的儲存位置，請參閱「查看執行個體的交易記錄儲存位置」。

如果執行個體只將二進位記錄儲存在磁碟上，您可以使用 gcloud CLI 或 Cloud SQL Admin API，將 PITR 交易記錄的儲存位置從磁碟切換至 Cloud Storage。詳情請參閱「將交易記錄儲存空間切換至 Cloud Storage」。

為確保執行個體的記錄檔儲存在 Cloud Storage，而非磁碟，請完成下列動作：

  • 檢查執行個體的網路架構。如果執行個體採用舊版網路架構，請升級至新版網路架構。

  • 如果磁碟上的記錄大小導致執行個體效能問題，請停用 PITR 並重新啟用。這項操作可確保新的記錄會儲存在 Cloud Storage，而非磁碟。

記錄保留期限

Cloud SQL 會將交易記錄保留在 Cloud Storage 中，保留時間最長為 transactionLogRetentionDays PITR 設定中的值。Cloud SQL Enterprise Plus 版本的範圍為 1 到 35 天，Cloud SQL Enterprise 版本則為 1 到 7 天。如未設定這個參數的值，Cloud SQL Enterprise Plus 版本執行個體的預設交易記錄保留期限為 14 天，Cloud SQL Enterprise 版本執行個體則為 7 天。如要進一步瞭解如何設定交易記錄保留天數，請參閱「設定交易記錄保留」。

雖然執行個體會將用於 PITR 的二進位記錄儲存在 Cloud Storage，但也會在磁碟保留少量重複的二進位記錄，以便將記錄複製到 Cloud Storage。根據預設，建立已啟用 PITR 的執行個體時，執行個體會將 PITR 的二進位記錄儲存在 Cloud Storage。Cloud SQL 也會自動將 expire_logs_days 和 binlog_expire_logs_seconds 旗標的值設為相當於一天的值。這相當於磁碟上的一天記錄。

如果 PITR 二進位記錄檔儲存在磁碟、正在切換至 Cloud Storage，或已切換至 Cloud Storage，Cloud SQL 會保留記錄檔，保留時間為下列其中一項設定的最小值：

  • transactionLogRetentionDays 備份設定
  • expire_logs_days 或 binlog_expire_logs_seconds 旗標

如果二進位記錄儲存在磁碟上、正在切換至 Cloud Storage，或已切換至 Cloud Storage，Cloud SQL 就不會為這些旗標設定任何值。記錄檔儲存在磁碟時，修改這些旗標的值可能會影響 PITR 復原行為，以及磁碟儲存的記錄檔天數。將記錄檔儲存位置切換至 Cloud Storage 時，您無法修改旗標值。我們也不建議將任一旗標值設為 0。詳情請參閱「設定資料庫旗標」。

  • transactionLogRetentionDays 項配置設定
  • expire_logs_days 個資料庫旗標
  • binlog_expire_logs_seconds 個資料庫旗標

舉例來說，為避免效能問題，請在幾天內每天將旗標值減少一天。因此，Cloud SQL 不會同時清除所有二進位記錄。

如果是啟用客戶自行管理加密金鑰 (CMEK) 的執行個體，二進位記錄會使用最新版本的 CMEK 加密。如要執行還原作業，retained-transaction-log-days 參數中保留的所有天數都必須使用最新金鑰版本。

記錄和磁碟用量

系統會定期產生記錄，並使用儲存空間。二進位記錄會與相關聯的自動備份一併刪除，這會在達到 transactionLogRetentionDays 設定的值後發生。

如要瞭解二進位記錄使用的磁碟空間，請查看執行個體的 bytes_used_by_data_type 指標。binlog 資料類型的值會傳回磁碟上的二進位記錄大小。如果執行個體將用於 PITR 的交易記錄儲存在磁碟上，Cloud SQL 會每天從磁碟清除資料，以符合 transactionLogRetentionDays PITR 設定，詳情請參閱「自動備份和交易記錄保留」。不過，如果將 expire_logs_days 或 binlog_expire_logs_seconds 旗標設為低於交易記錄保留天數的值，Cloud SQL 就能提早清除二進位記錄。

如果二進位記錄的大小導致執行個體發生問題：

如要進一步瞭解 PITR，請參閱「時間點復原 (PITR)」。

將交易記錄的儲存位置切換至 Cloud Storage 後，您可以降低 expire_logs_days 或 binlog_expire_logs_seconds 旗標的值，釋出磁碟空間。如要查看切換狀態，請參閱「查看用於 PITR 的交易記錄儲存位置」。如要讓磁碟提供更多記錄，例如使用 mysqlbinlog 公用程式瀏覽二進位記錄，請提高這些旗標的值。Cloud SQL 會將二進位記錄保留在磁碟上，保留時間至少為交易記錄保留天數，或旗標設定的值。如要進一步瞭解切換後 PITR 記錄的儲存方式，以及如何釋出磁碟空間，請參閱「切換至 Cloud Storage 後的記錄」。

時間點復原功能的限制

如果執行個體啟用 PITR，且磁碟上的交易記錄大小導致執行個體發生問題，則會受到下列限制：

  • 您可以停用 PITR 並重新啟用，確保 Cloud SQL 將記錄儲存在與執行個體相同區域的 Cloud Storage 中。不過，Cloud SQL 會刪除所有現有記錄，因此您無法在重新啟用 PITR 之前執行 PITR 作業。
  • 您可以增加執行個體儲存空間大小，但交易記錄大小增加的磁碟用量可能只是暫時的。
  • 為避免發生非預期的儲存空間問題，建議您啟用自動增加儲存空間功能。只有在執行個體啟用 PITR，且記錄檔儲存在磁碟上時，這項建議才適用。
  • 如要刪除記錄並復原儲存空間，可以停用 PITR，而不重新啟用。不過，減少儲存空間用量並不會縮減為執行個體佈建的磁碟大小。

  • 記錄檔每天會清除一次，而非持續清除。如果將記錄保留期限設為兩天，代表系統至少會保留兩天的記錄，最多保留三天的記錄。建議您將備份數量設為記錄保留天數加一。

    舉例來說，如果您為 transactionLogRetentionDays 參數的值指定 7，則請將 backupRetentionSettings 參數的 retainedBackups 數量設為 8。

如需執行 PITR 的逐步說明，請參閱「[使用時間點復原 (PITR)][perform-pitr]」。

還原無法使用的執行個體

您可以使用 PITR 還原無法使用的 Cloud SQL 執行個體。PITR 的復原點目標 (RPO) 通常不超過五分鐘。

如果執行個體無法使用，您可以使用 API 取得最早和最晚復原時間，將執行個體還原至該時間點，並執行復原作業。如果無法存取執行個體設定的可用區，您可以提供偏好的可用區值，將執行個體還原至其他主要或次要可用區。

假設 Cloud SQL 執行個體在美國東部時間下午 4 點無法使用，如果最新復原時間是美國東部時間下午 3 點 55 分，則您最多可以將執行個體復原至這個時間。

使用 PITR 還原已刪除的執行個體

您可以使用 PITR 還原已刪除的 Cloud SQL 執行個體。如要使用這項功能，執行個體必須在刪除前啟用時間點復原和保留備份。啟用後，刪除執行個體時會保留 PITR 記錄。

執行個體刪除後，PITR 記錄仍會遵循執行個體運作時定義的保留設定。執行個體刪除後，PITR 記錄會根據保留設定，以滾動方式到期。滾動週期是根據執行個體刪除前設定的時間點復原保留期限定義。舉例來說，如果 Cloud SQL Enterprise Plus 版本執行個體的時間點復原保留期限設為 14 天，則最新時間點復原記錄會在執行個體刪除後 14 天刪除。PITR 記錄到期後即無法復原。

在 Cloud SQL 中刪除執行個體後，執行個體名稱可以重複使用，因此保留的 PITR 記錄可在 Google Cloud 中透過下列欄位識別：

  • instance_deletion_time
  • log_retention_days

這些欄位可讓您判斷 PITR 記錄是否屬於已刪除的執行個體。

PITR 復原時間範圍是指使用 PITR 還原執行個體的最早和最晚復原時間。如要查看已刪除執行個體的最早和最晚復原時間，請參閱「取得最早和最晚復原時間」。

如要在刪除執行個體後使用 PITR 還原執行個體，請參閱「對已刪除的執行個體執行 PITR」。

還原至新執行個體的相關規定

將執行個體還原至新執行個體時，請注意下列規定：

  • 目標執行個體的資料庫版本，必須與備份來源執行個體相同。

  • 建立新執行個體時，系統預設會啟用 storageAutoResize 功能。之後建立的任何備份都會沿用相同的 storageAutoResize 設定。這表示無論是將備份還原至新的或現有的執行個體，執行個體都會視需要自動調整儲存空間容量。舊版執行個體未啟用這項功能。如要查看執行個體設定，請參閱「查看執行個體設定」。

  • 目標執行個體必須處於 RUNNABLE 狀態。

還原頻率限制

每項專案中，每個區域的每個執行個體每 30 分鐘最多可執行三次還原作業。如果還原作業失敗，則不會計入這項配額。如果達到上限，作業就會失敗，並顯示錯誤訊息，告知您何時可以再次執行作業。

Cloud SQL 會使用 bucket 中的權杖，判斷任何時間點可執行的還原作業數量。每個備份作業都會為各個目標專案和目標區域建立一個 bucket。如果位於相同區域，則來自相同專案的目標執行個體會共用一個 bucket。每個 bucket 最多可有三個權杖，可用於還原作業。每 10 分鐘，系統就會在 bucket 中新增一個權杖。如果值區已滿，權杖就會溢出。

每次發出還原作業時，系統都會從 bucket 授予權杖。如果作業成功，權杖就會從 bucket 中移除。如果失敗，權杖會傳回值區。下圖說明這項機制的運作方式：

權杖的運作方式

舉例來說，在下圖中，Backup1、Backup2 和 Backup3 是來自相同來源執行個體的備份。

還原作業頻率限制的權杖

  • 每個備份 (Backup1、Backup2 和 Backup3) 都有自己的權杖 bucket，用於還原作業，目標是區域 A 中專案 1 的不同執行個體 (Bucket11A、Bucket21A 和 Bucket31A)。由於每個備份都有專屬 bucket，因此每 30 分鐘可將各個備份還原至同一個執行個體三次。
  • 每個備份都有一個 bucket，用於不同的專案和區域。舉例來說，如果某個區域有五個專案，該區域就會有五個備份 bucket，每個專案各有一個。在上圖中，區域 A 有兩個專案：專案 1 和專案 n。
    • Backup1 有兩個權杖 bucket，用於區域 A 的還原作業。一個用於專案 1 (Bucket11A)，另一個用於專案 n (Bucket1nA)。
    • 同樣地，Backup3 有兩個 bucket，用於在區域 A 執行還原作業。一個用於專案 1 (Bucket31A)，另一個用於專案 n (Bucket3nA)。
  • Backup3 在區域 B 有一個 bucket，用於 Project1，因為相同目標專案和相同目標區域中的所有執行個體都共用一個 bucket。

後續步驟