就地升級資料庫主要版本

本頁面說明如何就地升級 Cloud SQL 執行個體,而非遷移資料,藉此升級資料庫主要版本。

簡介

資料庫軟體供應商會定期發布新的主要版本,其中包含新功能、效能改善和安全性強化。Cloud SQL 會在新版本發布後採用。Cloud SQL 支援新的主要版本後,您可以升級執行個體,讓資料庫保持在最新狀態。

您可以就地升級執行個體的資料庫版本,或遷移資料。就地升級是升級執行個體主要版本的簡便方法。您不必遷移資料或變更應用程式連線字串。就地升級可讓您在升級後,保留目前執行個體的名稱、IP 位址和其他設定。就地升級不需要移動資料檔案,而且可以更快完成。在某些情況下,停機時間會比遷移資料所需的時間短。

如果是 MySQL 8.0.15 以下版本,MySQL 就地升級作業會使用 mysql_upgrade 公用程式。如果是 MySQL 8.0.16 以上版本,MySQL 就地升級作業會由 MySQL server 程序處理。如要進一步瞭解就地升級作業,請參閱「MySQL 升級程序升級的項目」。

規劃主要版本升級

  1. 確認您具備執行主要版本升級所需的角色:Cloud SQL 擁有者或 Cloud SQL 管理員。
  2. 選擇目標主要版本。

    gcloud

    如要瞭解如何安裝及開始使用 gcloud CLI,請參閱「安裝 gcloud CLI」。如要瞭解如何啟動 Cloud Shell,請參閱「使用 Cloud Shell」。

    如要查看執行個體可就地升級的資料庫版本,請按照下列步驟操作:

    1. 執行下列指令。
    2. gcloud sql instances describe INSTANCE_NAME
         

      將 INSTANCE_NAME 替換為執行個體名稱。

    3. 在指令輸出內容中,找出標示為 upgradableDatabaseVersions 的區段。
    4. 每個子節都會傳回可升級的資料庫版本。在每個子區段中,查看下列欄位。
      • majorVersion:可就地升級的主要版本。
      • name:包含主要版本的資料庫版本字串。如果是 MySQL 適用的 Cloud SQL,這個欄位也會包含資料庫的子版本。
      • displayName:資料庫版本的顯示名稱。

    REST v1

    如要查看哪些目標資料庫版本可就地升級主要版本,請使用 Cloud SQL Admin API 的 instances.get 方法。

    使用任何要求資料之前,請先修改下列項目的值:

    • INSTANCE_NAME:執行個體名稱。

    HTTP 方法和網址:

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    請展開以下其中一個選項,以傳送要求:

    您應該會收到如下的 JSON 回覆:

    
    upgradableDatabaseVersions:
    
    {
      major_version: "MYSQL_8_0"
      name: "MYSQL_8_0_36"
      display_name: "MySQL 8.0.36"
    }
    
    

    REST v1beta4

    如要查看執行個體的主要版本就地升級有哪些可用的目標資料庫版本,請使用 Cloud SQL Admin API 的 instances.get 方法。

    使用任何要求資料之前,請先修改下列項目的值:

    • INSTANCE_NAME:執行個體名稱。

    HTTP 方法和網址:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

    請展開以下其中一個選項,以傳送要求:

    您應該會收到如下的 JSON 回覆:

    
    upgradableDatabaseVersions:
    
    {
      major_version: "MYSQL_8_0"
      name: "MYSQL_8_0_36"
      display_name: "MySQL 8.0.36"
    }
    
    

    如需 Cloud SQL 支援的資料庫版本完整清單,請參閱「資料庫版本和版本政策」。

  3. 請考量各資料庫主要版本提供的功能,並解決不相容問題。

    新的主要版本會導入不相容的變更,您可能需要修改應用程式程式碼、結構定義或資料庫設定。升級資料庫執行個體前,請先查看目標主要版本的版本資訊,判斷必須解決的不相容問題。

    升級至新版本後,部分系統變數的預設值可能會變更。舉例來說,MySQL 5.6 和 MySQL 5.7 中 character_set_server 的預設值為 utf8。升級至 MySQL 8.0 時,character_set_server 的預設值會變更為 utf8mb4。如要還原為 utf8,您必須手動將資料庫旗標值變更為舊值。詳情請參閱「設定資料庫旗標」。大部分的預設值變更都是由 MySQL Community 完成 (詳情請參閱「升級伺服器預設值」)。

  4. 執行升級預先檢查。

  5. 透過模擬測試來測試升級作業。

    在升級正式資料庫之前,請先在測試環境中模擬測試端對端升級程序。您可以複製執行個體,建立完全相同的資料副本,用來測試升級程序。

    除了驗證升級是否成功完成,也請執行測試,確保應用程式在升級後的資料庫上運作正常。

  6. 決定升級時間。

    升級期間,執行個體會暫時無法使用。請安排在資料庫活動較少的時段升級。

準備升級主要版本

升級前,請先完成下列步驟:

  1. 如果從 MySQL 8.0 升級至 MySQL 8.4,升級後建立的所有新使用者都會使用 caching_sha2_password 驗證外掛程式,而非已淘汰的 mysql_native_password 外掛程式。您也可以更新現有的使用者帳戶,改用 caching_sha2_password 驗證外掛程式。 如要將現有資料庫使用者帳戶變更為使用 caching_sha2_password 驗證外掛程式,請使用下列指令:
    ALTER USER 'username'@'%'
    IDENTIFIED WITH caching_sha2_password BY 'user_password';
         
    將 username 和 user_password 替換為要更新的內建驗證資料庫使用者帳戶值。
  2. 檢查磁碟空間和執行個體機型。

    升級主要版本時,需要額外的磁碟空間和記憶體,才能儲存升級後的資料表和新的資料字典。磁碟空間不足會導致升級失敗,並復原至原始版本。Cloud SQL 建議每個資料表至少要有 100 KB 的記憶體。

搭配使用 MySQL 8.4 以上版本和 Cloud SQL Auth Proxy 的必要設定

搭配使用 MySQL 8.4 以上版本和 Cloud SQL Auth Proxy 時,必須使用 MySQL 設定 allowPublicKeyRetrieval=true 來設定應用程式資料庫。您必須先使用這項設定升級用戶端應用程式,才能升級資料庫版本。

舉例來說,如果您使用的是 mysql 用戶端,請使用 --get-server-public-key 旗標:

mysql -u username -p --get-server-public-key

如果您使用的是 Java 程式設計語言,請使用下列程式碼:

config.setJdbcUrl("jdbc:mysql://" + dbHost + ":" + dbPort + "/" + dbName);
config.addDataSourceProperty("allowPublicKeyRetrieval", "true");

評估執行個體的升級準備度

Cloud SQL 可讓您在主要版本升級前,對執行個體執行預檢。這項預先檢查是長時間執行的作業 (LRO),會檢查執行個體是否可以升級。這項功能有助於在升級前找出潛在問題,例如不相容、設定問題或資料問題。

預先檢查會執行 MySQL Shell 升級檢查工具,確認執行個體是否已準備好升級至下一個主要版本。如果執行個體尚未準備就緒,公用程式會列出您在開始升級前需要修正的問題。這些問題是由兩個主要版本之間的已知不相容性所造成。

Cloud SQL 可與工作負載平行執行預先檢查程序。在執行主要版本升級前執行預檢,有助於避免升級失敗。

執行預先檢查時,會發生下列其中一種情況:

  • 未發現任何問題:預先檢查已順利完成,未發現任何問題。
  • 發現問題:預先檢查已順利完成,但發現會阻礙升級的錯誤。請務必先解決問題,再升級。
  • 發現警告:預先檢查順利完成,但發現警告。查看警告。 建議您先解決所有問題,再繼續升級。

視預先檢查結果而定,您可以繼續升級,或先修正發現的問題再升級。

限制

使用主要版本升級預先檢查時,請注意下列限制:

  • 執行個體狀態必須設為 RUNNING。
  • 執行個體不得有任何待處理的封鎖作業。如果有待處理的封鎖作業,預先檢查會失敗,並顯示下列訊息:

    Operation failed because another operation was already in progress. Try
    your request after the current operation is complete.
    
  • 預先檢查作業必須連線至執行個體上的所有資料庫。如果資料庫無法存取、鎖定或沒有回應,預先檢查可能會失敗或顯示錯誤。建議在資料庫負載較低時執行預先檢查。

  • 預先檢查會確認 MySQL 適用的 Cloud SQL 連續主要版本之間的升級相容性。舉例來說,您可以先對 MySQL 5.7 至 MySQL 8.0 的升級作業執行預先檢查,接著對 MySQL 8.0 至 MySQL 8.4 的升級作業執行預先檢查,然後對 MySQL 8.4 至 MySQL 9.7 的升級作業執行預先檢查。

    預先檢查不支援檢查同一主要版本中的子版本升級。舉例來說,您無法對 MySQL 8.0.31 至 8.0.45 的升級作業執行預先檢查。

  • 預先檢查時間上限為三小時。如果預先檢查作業超過三小時,程序就會逾時並自動取消。

  • MySQL Shell 升級檢查工具可能無法在預先檢查程序中偵測到所有不相容問題。升級仍有可能失敗。此外,如果未處理某些警告,也可能無法升級主要版本。

事前準備

  • 確認執行個體已啟用 Cloud SQL Admin API。
  • 確認您具備 cloudsql.instances.preCheckMajorVersionUpgrade IAM 權限。

執行預先檢查

如要執行主要版本升級預先檢查,請按照下列步驟操作:

gcloud

  1. 使用 gcloud beta sql instances pre-check-major-version-upgrade 執行預先檢查:

    gcloud beta sql instances pre-check-major-version-upgrade INSTANCE_NAME \
      --target-database-version=TARGET_DATABASE_VERSION \
      --project=PROJECT_ID \
      [--async]
       

    更改下列內容:

    • INSTANCE_NAME:執行個體的名稱。
    • TARGET_DATABASE_VERSION:要將執行個體升級至的主要版本。如要查看資料庫版本,請參閱「規劃升級」。
    • PROJECT_ID: Cloud de Confiance 專案的 ID。

    選用:使用 --async 旗標,以非同步方式執行指令。

  2. 如果您使用 --async 旗標以非同步方式執行 pre-check-major-version-upgrade 指令,請執行下列操作:

    1. 取得預先檢查作業名稱:

      使用 gcloud sql operations list 指令,並加上 --instance 旗標:

      gcloud sql operations list --instance=INSTANCE_NAME

      更改下列內容:

      • INSTANCE_NAME:執行個體的名稱。
    2. 監控預先檢查狀態。

      使用 gcloud sql operations describe 指令:

      gcloud sql operations describe OPERATION_NAME

      更改下列內容:

      • OPERATION_NAME:在上一個步驟中擷取的預先檢查作業名稱。
  3. 如果您未以非同步方式執行 pre-check-major-version-upgrade 指令,請等待預先檢查完成,再查看結果。

REST v1beta4

  1. 執行預先檢查。

    使用任何要求資料之前,請先修改下列項目的值:

    • PROJECT_ID:專案 ID
    • INSTANCE_ID:執行個體 ID
    • TARGET_DATABASE_VERSION:要升級至的主要版本。如要查看可用的資料庫版本清單,請參閱「規劃升級」。

    HTTP 方法和網址:

    POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID/preCheckMajorVersionUpgrade

    JSON 要求主體:

    {
      "preCheckMajorVersionUpgradeContext": {
        "targetDatabaseVersion": "TARGET_DATABASE_VERSION"
      }
    }
    

    請展開以下其中一個選項,以傳送要求:

    您應該會收到如下的 JSON 回覆:

    {
      "message": "Precheck description of finding",
      "message_type": "ERROR",
      "actions_required": [
        "Precheck action required to fix the finding"
      ]
    }
    
  2. 取得預先檢查作業名稱。

    請使用 GET 要求和 operations.list 方法,並將 PROJECT_ID 替換為專案 ID。

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations

    更改下列內容:

    • PROJECT_ID: Cloud de Confiance 專案的 ID。
  3. 監控預先檢查狀態。

    使用 GET 要求和 operations.list 方法:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operation/OPERATION_NAME

    更改下列內容:

    • PROJECT_ID: Cloud de Confiance 專案的 ID。
    • operation_name:在上一個步驟中擷取的預先檢查作業名稱。

查看預先檢查結果

預先檢查完成後,執行個體會準備好升級,或是有問題需要處理。

可開始升級

如果預先檢查順利完成,且 preCheckResponse 陣列為空白,表示未發現任何問題或警告。執行個體已可升級主要版本。如要繼續操作,請參閱「執行主要版本升級」。

尚未準備好升級

如果預先檢查成功執行,且 preCheckResponse 陣列包含問題,表示執行個體尚未準備好升級,需要處理。系統找出的問題不一定會阻礙升級。這些問題會記錄在 preCheckResponse 中,並顯示下列訊息類型:

類型 說明 封鎖升級?
INFO 資訊訊息。 否
WARNING 發現潛在問題。 Cloud SQL 建議您先查看並解決警告,再升級,確保完全相容。 是
ERROR 發現會阻礙升級的重大問題。這些問題可能會導致升級失敗。您必須先解決這些問題,才能升級執行個體。 是
如果執行個體只有 INFO 訊息,可以升級,但升級後可能會發生問題。建議您先查看訊息詳細資料並解決問題,再升級。如果執行個體有 ERROR 或 WARNING 訊息,請務必先解決這些問題,再升級。

每種問題類型都包含 message 和 actions_required 欄位。請查看各項問題,瞭解問題類型和解決方法。如要進一步瞭解常見問題和解決方案,請參閱「常見的主要版本升級預先檢查錯誤」。

解決問題後,請重新執行預先檢查,確認執行個體已可升級。預先檢查完成後,即可繼續升級執行個體。

取消主要版本升級預先檢查

您可以取消 MySQL 適用的 Cloud SQL 主要版本升級預先檢查作業。

事前準備

如要取消主要版本升級預先檢查,您需要預先檢查作業的 ID。您必須在 gcloud 或 REST API 指令中指定這個 ID,Cloud SQL 才能知道要取消哪項作業。

作業 ID 會在回應的 name 欄位中傳回。

您也可以在 Cloud SQL 執行個體上發出 operations.list 呼叫,找出作業 ID。

取消

您可以使用 gcloud 或 REST API 指令取消預先檢查作業。

gcloud

  1. 取得預先檢查作業 ID。

    使用 gcloud sql operations list 指令,並加上 --instance 旗標:

    gcloud sql operations list --instance=INSTANCE_NAME
    

    更改下列內容:

    • INSTANCE_NAME:執行個體的名稱。
  2. 取消預先檢查。

    使用 gcloud sql operations cancel 指令:

    gcloud sql operations cancel OPERATION_ID
    

    更改下列內容:

    • OPERATION_ID:上一個步驟中擷取的作業 ID。

REST v1beta4

  1. 取得預先檢查作業 ID。

    將 PROJECT_ID 替換為專案 ID 後,使用 operations.list 方法傳送 GET 要求。

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations
    

    更改下列內容:

    • PROJECT_ID: Cloud de Confiance 專案的 ID。
  2. 取消預先檢查。

    使用任何要求資料之前,請先修改下列項目的值:

    • PROJECT_ID: Cloud de Confiance by S3NS 專案的 ID。
    • OPERATION_ID:上一個步驟中擷取的作業 ID。

    HTTP 方法和網址:

    POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID/cancel

    請展開以下其中一個選項,以傳送要求:

    您應該會收到如下的 JSON 回覆:

    這項 REST API 呼叫不會傳回任何回應。

查看取消狀態

您可以使用 gcloud 或 REST API 指令,查看已取消的預先檢查作業狀態。

gcloud

  1. 查看取消狀態。

    使用 gcloud sql operations describe 指令:

    gcloud sql operations describe OPERATION_ID
    

    更改下列內容:

    • OPERATION_ID:已取消預先檢查的作業 ID。

REST v1beta4

  1. 查看取消狀態。

    使用 GET 要求搭配 operations.list 方法:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID
    

    更改下列內容:

    • PROJECT_ID: Cloud de Confiance 專案的 ID。
    • OPERATION_ID:已取消預先檢查的作業 ID。

排解取消問題

問題 疑難排解

錯誤訊息:You can't cancel operation OPERATION_ID because this operation isn't in progress.

您嘗試取消的預先檢查作業已完成、失敗或取消。如果作業正在執行,您可以取消。

錯誤訊息:You can't cancel operation OPERATION_ID because Cloud SQL doesn't support the cancellation of an OPERATION_TYPE operation.

如果將錯誤的 OPERATION_ID 傳遞至取消指令,通常會發生這項錯誤,具體來說,就是不支援取消作業類型的 ID。確認您使用的 OPERATION_ID 與要取消的主要版本升級預先檢查相關聯。

錯誤訊息:The OPERATION_TYPE operation isn't cancelled. Wait and retry in a few seconds.

Cloud SQL 目前無法取消預先檢查作業。請稍後再試。如果問題持續發生,請與 Cloud Customer Care 團隊聯絡。

執行主要版本升級

您可以升級單一 Cloud SQL 執行個體的主要版本,也可以升級主要執行個體的主要版本,並在升級時納入所有副本,包括串連副本和跨區域副本。

升級單一執行個體的主要版本

當您為單一執行個體啟動升級作業時,Cloud SQL 會執行下列操作:

  1. 檢查執行個體的設定,確保執行個體與升級作業相容。
  2. Cloud SQL 驗證設定後,會將執行個體設為無法使用。
  3. 建立升級前備份。
  4. 對執行個體執行升級作業。
  5. 讓執行個體可供使用。
  6. 建立升級後備份。
升級至 MySQL 8.0 時,Cloud SQL 會自動在預設子版本上佈建執行個體。

控制台

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

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

  2. 點選執行個體名稱,開啟執行個體的「總覽」頁面。
  3. 按一下 [編輯]。
  4. 在「Instance info」(執行個體資訊) 區段中,按一下「Upgrade」(升級) 按鈕,然後確認要前往升級頁面。
  5. 在「Choose a database version」(選擇資料庫版本) 頁面中,按一下「Database version for upgrade」(要升級的資料庫版本) 清單,然後選取其中一個可用的資料庫主要版本。
  6. 按一下「繼續」。
  7. 在「Instance ID」(執行個體 ID) 方塊中輸入執行個體名稱,然後按一下「Start upgrade」(開始升級) 按鈕。
這項作業需要幾分鐘才能完成。

在執行個體的「Overview」(總覽) 頁面中,確認執行個體名稱下方顯示升級後的資料庫主要版本。

gcloud

  1. 開始升級。

    使用 gcloud sql instances patch 指令,並加上 --database-version 旗標。

    執行指令前,請先替換下列項目:

    • INSTANCE_NAME:執行個體名稱。
    • DATABASE_VERSION:資料庫主要版本的列舉,必須晚於目前版本。請指定資料庫版本,做為執行個體可升級的主要版本。您可以在「升級計畫」的第一個步驟中取得這個列舉。 如需資料庫版本列舉的完整清單,請參閱 SqlDatabaseEnums。
    gcloud sql instances patch INSTANCE_NAME \
    --database-version=DATABASE_VERSION

    主要版本升級作業需要幾分鐘才能完成。您可能會看到一則訊息,指出作業時間比預期長。您可以忽略這則訊息,或執行 gcloud sql operations wait 指令關閉訊息。

  2. 取得升級作業名稱。

    使用 gcloud sql operations list 指令,並加上 --instance 旗標。

    執行指令前,請先替換下列項目: * INSTANCE_NAME:執行個體的名稱。

    gcloud sql operations list --instance=INSTANCE_NAME
  3. 監控升級狀態。

    使用 gcloud sql operations describe 指令。

    執行指令前,請將 OPERATION 變數替換為上一步驟中擷取的升級作業名稱。

    gcloud sql operations describe OPERATION

REST v1

  1. 開始就地升級。

    請使用 instances:patch 方法傳送 PATCH 要求。

    使用任何要求資料之前,請先替換下列變數:

    • PROJECT_ID:專案 ID。
    • INSTANCE_NAME:執行個體名稱。

    HTTP 方法和網址:

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    JSON 要求主體:

    {
      "databaseVersion": DATABASE_VERSION
    }

    將 DATABASE_VERSION 替換為資料庫主要版本的列舉,該版本必須晚於目前版本。請指定執行個體可升級的主要資料庫版本。您可以在「升級計畫」的第一個步驟中取得這個列舉。 如需資料庫版本列舉的完整清單,請參閱 SqlDatabaseVersion。

  2. 取得升級作業名稱。

    請使用 operations.list 方法傳送 GET 要求,並將 PROJECT_ID 替換為專案 ID。

    HTTP 方法和網址:

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations
  3. 監控升級狀態。

    請使用 GET 要求和 operations.get 方法,並替換下列變數:

    • PROJECT_ID:專案 ID。
    • OPERATION_NAME:在上一個步驟中擷取的升級作業名稱。

    HTTP 方法和網址:

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

如要使用 Terraform 升級資料庫的主要版本,您必須將 google_sql_database_instance 資源定義中的 database_version 引數設為目標主要版本。您必須使用 Cloud de Confiance by S3NS 4.34.0 以上版本的 Terraform 供應商。

以下範例說明基本的 google_sql_database_instance 設定。如要升級主要版本,請將 database_version 引數設為相關的主要版本。

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
}

對 Terraform 引數進行下列變更:

  • database_version:將此值設為升級目標主要版本。
  • deletion_protection:定義根層級 Terraform 保護措施,防止執行個體遭到刪除。
    • true:防止 Terraform 刪除執行個體。任何預計刪除這項資源的 Terraform 作業都會遭到封鎖。
    • false:允許 Terraform 刪除執行個體。

查看 Terraform 計畫

套用任何變更前,請務必執行 terraform plan 並仔細檢查輸出內容。資源名稱旁的符號代表 Terraform 套用變更的方式:

  • ~ 就地更新:這個符號表示 Terraform 會修改現有執行個體。變更 database_version 時,這是就地主要版本升級的預期安全結果。
  • +/- 重新建立 (強制替換):這個符號表示 Terraform 打算刪除目前的執行個體,並建立新的執行個體。
    • 如果將 deletion_protection 設為 true,Terraform 會顯示錯誤訊息,並禁止這項危險的替換作業。您必須在設定中明確設定 deletion_protection = false,並再次執行 terraform apply 來更新狀態,後續的 apply 才會允許刪除及重新建立。
    • 如果 deletion_protection 設為 false,terraform apply 會繼續執行,並遺失資料。

    如果設定變更,或就地修改的升級路徑不受支援,系統可能會排定更換 (刪除並重新建立) 執行個體。如果發現執行個體已排定刪除並重新建立,請立即停止並調查排定替換的原因,再繼續操作。

查看 terraform plan 輸出內容,確認輸出內容僅指出資料庫版本變更的就地更新 (~),然後套用設定

如要在 Cloud de Confiance 專案中套用 Terraform 設定,請完成下列各節的步驟。

準備 Cloud Shell

  1. 啟動 Cloud Shell。
  2. 設定要套用 Terraform 設定的預設 Cloud de Confiance 專案。

    每個專案只需執行這個指令一次,而且可以在任何目錄中執行。

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    如果您在 Terraform 設定檔中設定明確的值,環境變數就會遭到覆寫。

準備目錄

每個 Terraform 設定檔都必須有自己的目錄 (也稱為根模組)。

  1. 在 Cloud Shell 中建立目錄,並在該目錄中建立新檔案。檔案名稱必須有 .tf 副檔名,例如 main.tf。在本教學課程中,這個檔案稱為 main.tf。
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf
  2. 如果您正在進行教學課程,可以複製每個章節或步驟中的程式碼範例。

    將程式碼範例複製到新建立的 main.tf。

    您也可以從 GitHub 複製程式碼。如果 Terraform 程式碼片段是端對端解決方案的一部分,建議您採用這種做法。

  3. 請查看並修改範例參數,以便套用至您的環境。
  4. 儲存變更。
  5. 初始化 Terraform。每個目錄只需執行一次這項操作。
    terraform init

    如要使用最新版 Google 供應商,請視需要加入 -upgrade 選項:

    terraform init -upgrade

套用變更

  1. 查看設定,確認 Terraform 要建立或更新的資源符合預期:
    terraform plan

    視需要修正設定。

  2. 執行下列指令,並在提示中輸入 yes,套用 Terraform 設定:
    terraform apply

    等待 Terraform 顯示「Apply complete!」訊息。

  3. 開啟 Cloud de Confiance 專案即可查看結果。在 Cloud de Confiance 控制台的使用者介面中,前往資源頁面,確認 Terraform 已建立或更新資源。

當您提出就地升級要求時,Cloud SQL 會先執行升級前檢查。如果 Cloud SQL 判定執行個體尚未準備好升級,升級要求就會失敗,並顯示訊息,建議您如何解決問題。另請參閱「排解主要版本升級問題」。

在主要版本升級中納入副本

如果主要執行個體有副本,您可以將所有副本納入升級作業。Cloud SQL 可以升級主要執行個體的所有副本,包括跨區域副本和串聯式副本。

在主要版本升級作業中納入副本時,Cloud SQL 會執行下列操作:

  1. 檢查主要執行個體和副本的設定,確保執行個體和副本相容,可進行升級。
  2. 主要執行個體無法使用。
  3. 在升級前備份主要執行個體。
  4. 停止所有副本的複製作業。
  5. 對主要執行個體執行升級作業。
  6. 如果主要執行個體升級成功,主要執行個體就會再次可用,並重新啟動複製作業。
  7. Cloud SQL 會在升級後備份主要執行個體。
  8. Cloud SQL 會繼續升級所有副本。

即使副本的主要版本升級失敗,主要執行個體仍可繼續使用。

如要在主要版本升級中納入副本,請勿使用Cloud de Confiance 控制台或 Terraform。您只能使用 gcloud CLI 或 Cloud SQL Admin API。

gcloud

  1. 開始升級。

    使用 gcloud sql instances patch 指令,並加上 --database-version 和 --include-replicas-for-major-version-upgrade 旗標。

    執行指令前,請先替換下列項目:

    • INSTANCE_NAME:主要執行個體的名稱。
    • DATABASE_VERSION:資料庫主要版本的列舉,必須晚於目前版本。請指定資料庫版本,做為執行個體可升級的主要版本。您可以在「升級計畫」的第一個步驟中取得這個列舉。 如需資料庫版本列舉的完整清單,請參閱 SqlDatabaseEnums。
    gcloud sql instances patch INSTANCE_NAME \
      --database-version=DATABASE_VERSION \
      --include-replicas-for-major-version-upgrade

    主要版本升級作業需要幾分鐘才能完成。您可能會看到一則訊息,指出作業時間比預期長。您可以忽略這則訊息,或執行 gcloud sql operations wait 指令關閉訊息。升級副本可能需要幾分鐘才能完成。如要查看升級狀態,請按照下列步驟操作:

  2. 取得升級作業名稱。

    使用 gcloud sql operations list 指令,並加上 --instance 旗標。

    執行指令前,請將 INSTANCE_NAME 變數替換為執行個體名稱。

    gcloud sql operations list --instance=INSTANCE_NAME
  3. 監控升級狀態。

    使用 gcloud sql operations describe 指令。

    執行指令前,請將 OPERATION 變數替換為上一步驟中擷取的升級作業名稱。

    gcloud sql operations describe OPERATION

REST

  1. 開始就地升級。

    請使用 instances:patch 方法傳送 PATCH 要求。

    使用任何要求資料之前,請先替換下列變數:

    • PROJECT_ID:專案 ID。
    • INSTANCE_NAME:執行個體的名稱。

    HTTP 方法和網址:

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    JSON 要求主體:

    {
      "databaseVersion": DATABASE_VERSION
      "includeReplicasForMajorVersionUpgrade": true
    }
    • 將 DATABASE_VERSION 替換為資料庫主要版本的列舉,該版本必須晚於目前版本。請指定資料庫版本,做為執行個體可升級的主要版本。您可以在「升級計畫」的第一個步驟中取得這個列舉。 如需資料庫版本列舉的完整清單,請參閱 SqlDatabaseVersion。
    • 在「includeReplicasForMajorVersionUpgrade」欄位中指定 true。
  2. 取得升級作業名稱。

    請使用 GET 要求和 operations.list 方法,並將 PROJECT_ID 替換為專案 ID。

    HTTP 方法和網址:

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations
  3. 監控升級狀態。

    請使用 GET 要求和 operations.get 方法,並替換下列變數:

    • PROJECT_ID:專案 ID。
    • OPERATION_NAME:在上一個步驟中擷取的升級作業名稱。

    HTTP 方法和網址:

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

自動升級備份

執行主要版本升級時,Cloud SQL 會自動建立兩個隨選備份,稱為升級備份:

  • 第一個升級備份是「升級前備份」,會在升級開始前立即建立。您可以使用這個備份,將資料庫執行個體還原至先前版本的狀態。
  • 第二個升級備份是「升級後備份」,會在升級後的資料庫執行個體允許新寫入作業後立即建立。

查看備份清單時,升級備份會列為 On-demand 類型。升級備份會加上標籤,方便您快速識別。舉例來說,如果您從 MySQL 5.7 升級至 MySQL 8.0,升級前的備份會標示為 Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0.,升級後的備份則標示為 Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.。如果從 MySQL 8.0 升級至 MySQL 8.4,升級前的備份會標示為 Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4.,升級後的備份則標示為 Post-upgrade backup, MYSQL_8_4 from MYSQL_8_0.。如果從 MySQL 8.4 升級至 MySQL 9.7,升級前的備份會標示為 Pre-upgrade backup, MYSQL_8_4 to MYSQL_9_7.,升級後的備份則標示為 Post-upgrade backup, MYSQL_9_7 from MYSQL_8_4.。

與其他隨選備份一樣,升級備份會一直保留,直到您刪除備份或執行個體為止。如果啟用 PITR,就無法在保留期限內刪除升級備份。如要刪除升級備份,請停用 PITR,或等到升級備份不在保留期限內。

完成主要版本升級

完成主要執行個體升級後,請按照下列步驟完成升級:

  1. 執行驗收測試。

    執行測試,確認升級後的系統運作正常。

  2. 選用:更新使用者權限。

    MySQL 8.0 對安全性和帳戶管理系統進行了新的變更。詳情請參閱「 MySQL 8.0 的新功能」。

    MySQL 適用的 Cloud SQL 已採用這些變更,並強化與 cloudsqlsuperuser 角色相關聯的使用者權限。在 MySQL 5.7 版執行個體中建立的使用者,權限可能與直接在 MySQL 8.0 中建立的使用者不同。舉例來說,從 MySQL 5.7 升級至 MySQL 8.0 的使用者沒有 CONNECTION_ADMIN 權限。因此,他們無法對其他使用者的工作階段執行 KILL 指令。如要瞭解如何更新使用者權限,請參閱本節中的程序。

    如果從 MySQL 8.0 升級至 MySQL 8.4,使用者權限會出現其他異動,包括新增 MySQL 8.4 導入的權限,以及移除 MySQL 8.0 原有的權限。詳情請參閱 MySQL 8.4 使用者權限 (cloudsqlsuperuser)。

    您可以按照下列步驟,在 MySQL 8.0、MySQL 8.4 或 MySQL 9.7 中更新使用者權限:

    1. 建立使用者,並預設授予 cloudsqlsuperuser 角色。

    2. 使用這個使用者連線至執行個體,即可更新其他使用者的權限。

      舉例來說,如要檢查使用者擁有的權限,請執行下列指令:

      SHOW GRANTS for 'admin'@'%',

      如要將權限授予使用者,例如使用 KILL 指令結束連線的權限,請執行下列指令:

      GRANT CONNECTION_ADMIN ON *.* to 'admin'@'%';

      如要將 cloudsqlsuperuser 角色套用至 admin'@'% 使用者,請執行下列指令:

      GRANT 'cloudsqlsuperuser' to 'admin'@'%';
  3. 選用:建立備份。

    雖然 Cloud SQL 會在您升級主要執行個體後自動建立備份,但 Cloud SQL 建議您自行建立備份,以便在必要時復原資料庫。

  4. 選用:如果您已升級至 MySQL 適用的 Cloud SQL 8.4 或 MySQL 9.7,請一併將所有連接器、用戶端和 MySQL 殼層更新至 MySQL 8.4 或 MySQL 9.7。

排解主要版本升級問題

如果您嘗試執行無效的升級指令,Cloud SQL 會傳回錯誤訊息,例如執行個體包含新版本不適用的資料庫旗標。

如果升級要求失敗,請檢查升級要求的語法。如果要求結構有效,請嘗試查看下列建議。

查看錯誤記錄

如果有效的升級要求發生任何問題,Cloud SQL 會將錯誤記錄發布至 projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err。每個記錄項目都包含一個標籤,其中含有執行個體 ID,可協助您找出發生升級錯誤的執行個體。請找出這類升級錯誤並加以解決。

如要查看錯誤記錄,請使用 Cloud de Confiance by S3NS控制台:

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

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

  2. 點選執行個體名稱,開啟執行個體的「總覽」頁面。
  3. 在執行個體「Overview」(總覽) 頁面的「Operations and logs」(作業和記錄) 窗格中,按一下「View MySQL error logs」(查看 MySQL 錯誤記錄) 連結。

    「Logs Explorer」頁面隨即開啟。

  4. 查看記錄檔,步驟如下:

    • 如要列出專案中的所有錯誤記錄,請在「Log name」(記錄檔名稱) 記錄檔篩選器中選取記錄檔名稱。

    如要進一步瞭解查詢篩選器,請參閱「進階查詢」。

    • 如要篩選單一執行個體的升級錯誤記錄,請在「Search all fields」(搜尋所有欄位) 方塊中輸入下列查詢,並將 DATABASE_ID

    格式如下:project_id:instance_name。

    resource.type="cloudsql_database"
    resource.labels.database_id="DATABASE_ID"
    logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err"

    舉例來說,如要依據在 buylots 專案中執行的 shopping-db 執行個體篩選升級錯誤記錄,請使用下列查詢篩選器:

     resource.type="cloudsql_database"
     resource.labels.database_id="buylots:shopping-db"
     logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"

    您可以查看指定時間範圍內回報的所有記錄,也可以依嚴重性篩選記錄。排解問題時,常見的做法是選取下列篩選條件:

    • 緊急
    • 快訊
    • 重大
    • 錯誤

    從 MySQL 5.7 版升級至 MySQL 8.0 時,您可能會在預先檢查和升級期間遇到一些已知問題。如需排解這些問題的相關說明,請參閱「排解就地升級至 MySQL 8.0 主要版本的問題」。

MVU 作業執行時間較長

主要版本升級作業包含兩項基本工作:

  • 預先檢查作業:如果未在三小時內完成,則會傳回逾時錯誤。
  • 升級作業:如果未在六小時內完成,則會傳回逾時錯誤。

如果執行個體持續執行 MAJOR_VERSION_UPGRADE 作業的時間超過預期,請調查 MySQL 錯誤記錄。這可能是由常見問題所造成,例如:

  • 資料表、檢視表或索引數量過多
  • CPU 或記憶體等資源不足
  • 重大交易阻擋資料庫關閉,導致升級程序無法開始。您可以使用 Cloud de Confiance 控制台查看目前的程序。

常見的主要版本升級前檢查錯誤

從 MySQL 5.7 升級至 MySQL 8.0 時,常見問題包括:

  • 在預存程序、觸發條件和其他資料庫物件中,新增 RANKS、GROUPS、FUNCTION 等保留關鍵字。詳情請參閱「關鍵字和保留字」。
  • 資料表定義含有無效的 UTF 字元。
  • 未修訂的 XA 轉換,必須修訂 (使用 XA COMMIT 陳述式) 或復原 (使用 XA ROLLBACK 陳述式)。
  • 名稱長度超過 64 個字元的外鍵限制。
  • 資料欄混合索引中的空間資料類型。詳情請參閱「空間資料類型」。

如需 MySQL 5.7 至 MySQL 8.0 預先檢查期間的錯誤和已知問題疑難排解說明,請參閱「對 MySQL 8.0 的就地主要版本升級作業進行疑難排解」。如要進一步瞭解常見的 MySQL 問題,請參閱「準備安裝升級」和「升級至 MySQL 8.0?」。

從 MySQL 8.0 升級至 MySQL 8.4 時,常見問題包括:

  • 過時的複製術語。MySQL 8.4 已完全移除 MASTER 和 SLAVE 這兩個詞。

    如果您仍在使用含有這些字詞的指令或設定,請務必替換或移除。如要進一步瞭解這些字詞的移除和替換,請參閱「MySQL 8.4 自 MySQL 8.0 以來的新功能」。

從 MySQL 8.4 升級至 MySQL 9.7 時,常見問題包括:

  • 如果執行個體已啟用 cloudsql_vector,則在升級前,含有 Cloud SQL 向量嵌入的資料欄不得有次要非向量索引。您可能會收到下列錯誤訊息:

    Non-vector secondary indexes are disallowed on vector columns when cloudsql_vector is enabled.

    如要解決這個問題,請先捨棄次要索引,再升級至 MySQL 9.7。

  • Cloud SQL 8.4 資料庫中已有向量嵌入,但您已將 cloudsql_vector 設為 off。升級至 MySQL 9.7 時,所有向量資料都會遷移至社群 MySQL 格式,而非 MySQL 適用的 Cloud SQL 8.4 和更早版本資料庫使用的 VARBINARY 格式。為確保向量資料正確遷移,您可以將 cloudsql_vector 旗標更新為 on,然後繼續升級至 MySQL 9.7。升級程序會將向量資料遷移至社群格式。或者,您也可以將 cloudsql_vector 旗標設為 off,並在升級前手動刪除 MySQL 8.4 資料庫中的向量資料。
  • 您還有其他內建資料庫使用者帳戶使用 mysql_native_password 外掛程式。MySQL 適用的 Cloud SQL 9.7 則完全移除這個外掛程式。如果任何使用者帳戶使用 mysql_native_password 外掛程式,則這些帳戶無法連線至資料庫。升級至 MySQL 9.7 適用的 Cloud SQL 前,請務必將所有剩餘帳戶改為使用 caching_sha2_password 外掛程式。

將主要執行個體還原至先前的主要版本

如果升級後的資料庫系統效能不如預期,您可能需要將主要執行個體還原至先前的版本。方法是將升級前的備份還原至 Cloud SQL 復原執行個體,也就是執行升級前版本的新執行個體。

如要將主要執行個體還原至先前的版本,請按照下列步驟操作:

  1. 找出升級前的備份。

    請參閱「自動升級備份」。

  2. 建立復原執行個體。

    使用 Cloud SQL 在建立升級前備份時執行的主要版本,建立新的 Cloud SQL 執行個體。設定與原始執行個體相同的旗標和執行個體設定。

  3. 還原升級前的備份。

    將升級前的備份還原至復原執行個體。這項作業可能需要幾分鐘才能完成。

  4. 新增唯讀副本。

    如果使用唯讀副本,請個別新增。

  5. 連結應用程式。

    復原資料庫系統後,請更新應用程式,加入復原執行個體及其唯讀副本的詳細資料。您可以繼續在升級前的資料庫版本上提供流量。

限制

本節列出就地升級主要版本的限制。

  • 您無法對外部副本執行就地主要版本升級。
  • 如果執行個體有超過 512,000 個資料表,從 MySQL 5.7 升級至 MySQL 8.0 可能會耗費較長時間,並發生逾時。
  • 如果執行個體有超過 512,000 個資料表,從 MySQL 8.0 升級至 MySQL 8.4 可能需要較長時間,且會逾時。
  • 從 MySQL 8.0 升級至 MySQL 8.4 時,如果已將副本升級至 MySQL 8.4,但未升級主要執行個體,則可在未升級的主要執行個體上,使用已淘汰的 mysql_native_password 驗證外掛程式建立新的使用者帳戶。為避免這種情況,請務必在升級副本後立即升級主要執行個體,或使用下列指令,只在主要執行個體上建立新的使用者帳戶。

    CREATE USER 'USERNAME'@'%' IDENTIFIED WITH caching_sha2_password BY 'PASSWORD';

    將 USERNAME 和 PASSWORD 替換為適當的值。

常見問題

升級資料庫主要版本時,可能會遇到下列問題。

升級期間是否無法使用執行個體?
可以。Cloud SQL 執行升級作業期間,執行個體會暫時無法使用。
升級需要多久時間?

升級單一執行個體通常會在 10 分鐘內完成。 如果執行個體設定的 vCPU 或記憶體數量較少,升級可能需要較多時間。

如果執行個體託管過多資料庫或資料表,或是資料庫非常龐大,升級作業可能需要數小時,甚至逾時,因為總升級時間與資料庫中的物件數量相對應。如果有多個執行個體需要升級,升級時間會按比例增加。如果升級作業包含副本,則可能需要一小時才能完成,具體時間取決於主要執行個體的副本數量。

我可以監控升級程序的每個步驟嗎?
雖然 Cloud SQL 可讓您監控升級作業是否仍在進行中,但您無法追蹤各項升級作業的個別步驟。
升級後可以取消嗎?
不行,升級作業一旦開始就無法取消。如果升級失敗,Cloud SQL 會自動將執行個體復原至先前的版本。
升級期間,我的設定會受到什麼影響?

執行就地主要版本升級時,Cloud SQL 會保留資料庫設定,包括執行個體名稱、IP 位址、明確設定的旗標值和使用者資料。不過,系統變數的預設值可能會變更。舉例來說,MySQL 5.7 中 character_set_server 旗標的預設值為 utf8。升級至 MySQL 8.0 後,旗標的預設值會變更為 utf8mb4。如要還原為 utf8,請將旗標值設回先前的值。

詳情請參閱「設定資料庫旗標」。如果目標版本不再支援特定旗標或值,Cloud SQL 會在升級期間自動移除該旗標。

如果升級副本後複製作業中斷,該怎麼辦?

如果升級副本後複製作業中斷,Cloud SQL 會將副本復原至主要執行個體的 MySQL 主要版本。您可以再次升級副本,但如果問題持續發生,複製作業可能會再次中斷。因此,建議您在執行主要版本升級時納入副本,而非個別升級每個副本。

如果副本未復原至與主要執行個體相同的主要版本,您有兩種選擇:

  1. 刪除損壞的副本,建立新副本,然後升級新副本。

    如果升級再次失敗,可能是因為主要執行個體在升級時新增了不相容的變更。排解升級問題,找出問題所在,修正主要執行個體,然後嘗試升級副本。詳情請參閱「疑難排解」。

  2. 升級主要執行個體

    如果副本執行緒無法運作,主要執行個體的升級作業會重新建立副本。

為什麼升級後的副本會復原至先前的主要版本?

如果升級失敗,副本會復原至主要執行個體的版本。您可以再次升級副本,但如果問題持續發生,可以查看副本上的 mysql.err 記錄檔,找出來源。搜尋關鍵字,例如 [REPL]... failed executing transaction.... end_log_pos...; Failure Reason。

如果錯誤訊息包含 Access denied for AuthId....,且使用者權限有所變更,則可能是使用 MySQL 5.7 使用者權限對 mysql 和 sys 結構定義執行查詢,且可能因 MySQL 8.0 的安全性和帳戶管理系統變更而失敗。如要解決這個問題,請先停止主要執行個體上的查詢,再將主要執行個體升級至新版本,然後重新嘗試升級副本。Cloud SQL 建議您在升級至新版本前,也暫時停止主要執行個體中的所有這類查詢,因為這可能會導致類似問題。

如果 MySQL 記錄中未顯示失敗原因 (例如 Access denied for AuthID....),則問題可能是因為副本升級後,主要執行個體中新增了不相容的新資料。請參閱「準備主要版本升級」一文,瞭解如何修正不相容問題,再重新升級。

後續步驟