データベースのメジャーバージョンをインプレースでアップグレードする

このページでは、データを移行するのではなく、Cloud SQL インスタンスをインプレースアップグレードでデータベースのメジャーバージョンのアップグレードを行う方法について説明します。

はじめに

データベースソフトウェアプロバイダは、新機能、パフォーマンス改善、セキュリティ強化を含む新しいメジャーバージョンを定期的にリリースしています。Cloud SQL では、新しいバージョンがリリース後に取り込まれます。Cloud SQL で新しいメジャーバージョンのサポートが提供された後、インスタンスをアップグレードして、データベースを最新の状態に保つことができます。

インスタンスのデータベースバージョンをアップグレードするには、インプレースアップグレードまたはデータの移行を行います。インプレースアップグレードは、インスタンスのメジャーバージョンをアップグレードする最も簡単な方法です。データの移行や、アプリケーション接続文字列の変更は必要ありません。インプレースアップグレードを使用すると、アップグレード後も、現在のインスタンスの名前、IP アドレス、その他の設定を維持できます。インプレースアップグレードは、データファイルを移動する必要がないため、より短時間で完了できます。場合によっては、データの移行よりもダウンタイムが短くなります。

Cloud SQL for MySQL のインプレースアップグレードでは、mysql_upgrade ユーティリティを使用します。

メジャーバージョンアップグレードの計画

対象のメジャーバージョンを選択します。

Cloud SQL でサポートされているバージョンのリストをご覧ください。
データベースの各メジャーバージョンで提供される機能を検討し、非互換性の問題を解決します。
- MySQL 8.0
- MySQL 5.7
新しいメジャーバージョンで互換性のない変更が導入され、アプリケーションコード、スキーマ、データベース設定の変更が必要になる場合があります。データベースインスタンスをアップグレードする前に、ターゲットメジャーバージョンのリリースノートで、対処の必要がある互換性の問題を確認してください。

新しいバージョンにアップグレードすると、一部のシステム変数のデフォルト値が変更される場合があります。たとえば、character_set_server MySQL 5.6 と MySQL 5.7 のデフォルト値は、utf8 です。MySQL 8.0 にアップグレードすると、デフォルト値の character_set_server が utf8mb4 に変更されます。utf8 に戻すには、データベースフラグの値を手動で古い値に変更する必要があります。詳細については、データベースフラグを構成するをご覧ください。デフォルト値の変更のほとんどは、MySQL コミュニティによって行われます（詳しくは、サーバーのデフォルトをアップグレードするをご覧ください）。

注: 現在のメジャーバージョンの次のメジャーバージョンにのみアップグレードできます。MySQL ではメジャーバージョンのスキップはサポートされていません。MySQL 5.6 から MySQL 8.0 に直接アップグレードすることはできません。
MySQL 5.7 から 8.0 にアップグレードする場合は事前チェックを行います。

MySQL 5.7 から 8.0 にアップグレードする前に事前チェックを行います。MySQL シェルで Upgrade Checker Utility を使用します。事前チェックで問題が見つかった場合は、アップグレードに進む前に問題を修正します。Cloud SQL では、メジャーバージョンのアップグレード中に事前チェックを行うことはできません。事前チェックで問題が見つかったインスタンスをアップグレードしようとしても、失敗する可能性があります。
ディスク容量とインスタンスのマシンタイプを確認します。

メジャーバージョンのアップグレードでは、アップグレードされたテーブルを格納するために、追加のリソース（ディスク容量など）が必要になります。ディスク容量が十分でない場合、アップグレードに失敗してロールバックされます。MySQL 5.7 から 8.0 にアップグレードする場合は、古いメタデータを新しいデータディクショナリに変換するため、追加のメモリが必要になります。メジャーバージョンアップグレードを実行する前に、テーブルあたり 100K より多くのメモリが使用可能であることを確認してください。マシンタイプを変更することで、一時的にメモリを増やすことができます。
MySQL 8.0 でのユーザー権限の変更を確認します。

Cloud SQL for MySQL バージョン 8.0 では partial_revokes というフラグを使用します。このフラグは、デフォルトで ON に設定されています。MySQL 5.7 とは異なり、このフラグを使用すると、データベースの GRANT コマンドでワイルドカード文字を使用できなくなります。データベースユーザーが正しいデータベーススキーマにアクセスできるようにするには、MySQL 8.0 にアップグレードする前にデータベースユーザーの権限を変更します。ワイルドカード文字を使用する代わりに、必要なデータベーススキーマの完全な名前を使用するためにユーザーの権限を更新します。

MySQL 8.0 のこのフラグの機能の詳細については、MySQL 8.0 の partial_revokes をご覧ください。
ドライランでアップグレードをテストします。

本番環境データベースをアップグレードする前に、テスト環境でエンドツーエンドのアップグレードプロセスのドライランを実行します。インスタンスのクローンを作成して、アップグレードプロセスのテストに使用するデータをコピーします。

アップグレードが正常に完了することを検証するだけでなく、アップグレードされたデータベースでアプリケーションが期待どおりに動作することをテストします。

注: メジャーバージョンのアップグレードを実行する前に、十分なディスク容量があることを確認してください。ストレージの自動増量を有効にしていない場合は、アップグレードしたドライランインスタンスが使用するディスクストレージをメモしておきます。これにより、アップグレード前に本番環境インスタンスのストレージ容量を増やす必要があるかどうかを判断できます。
アップグレードのタイミングを決定します。

アップグレード中は、インスタンスが一定期間使用できなくなります。データベースアクティビティが低い時間帯にアップグレードを行うように計画してください。

メジャーバージョンアップグレードを準備する

アップグレードを行う前に、次の手順を行います。

MySQL 5.7 から 8.0 へのアップグレードのみ: 事前チェックプロセスで見つかった互換性のない問題を確認して修正します。一般的な問題には、次のようなものがあります。
1. ストアドプロシージャやトリガーなどでの、RANKS、GROUPS、FUNCTION などの新しい予約済みキーワードの追加。詳細については、キーワードと予約済みの単語をご覧ください。
2. テーブル定義内の無効な UTF 文字。
3. XA COMMIT ステートメントを使用して commit、または XA ROLLBACK ステートメントを使用してロールバックする必要がある commit されていない XA の遷移。
4. 64 文字を超える名前での外部キー制約。
5. 列の混合インデックス内の空間データ型。詳細については、空間データ型をご覧ください。
詳細については、アップグレードのためのインストールの準備と MySQL 8.0 へのアップグレードをご覧ください。
ディスク容量とインスタンスのマシンタイプを確認します。

メジャーバージョンのアップグレードでは、アップグレードされたテーブルと新しいデータディクショナリを保存するために追加のディスク容量とメモリが必要になります。必要なディスク容量が不足すると、アップグレードが失敗し、元のバージョンにロールバックされます。Cloud SQL では、テーブルごとに少なくとも 100k のメモリを用意することをおすすめします。
注: メジャーバージョンのアップグレードを実行する前にマシンタイプを変更することで、一時的にメモリを増やすことができます。詳細については、マシンタイプの変更をご覧ください。
リードレプリカをアップグレードします。

リードレプリカを使用する場合は、プライマリインスタンスをアップグレードする前に、すべてのリードレプリカをアップグレードする必要があります。レプリカがアップグレードされてもプライマリインスタンスがアップグレードされない場合、レプリカが使用する MySQL の新しいバージョンでサポートされなくなったステートメントや関数をプライマリが使用すると、レプリケーションが中断する可能性があります。このような問題を回避するために、Cloud SQL では次のことをおすすめします。
1. レプリカをアップグレードした直後にプライマリをアップグレードします。
2. アップグレードが正常に完了するまで、プライマリインスタンスで新しいバージョンと互換性のないクエリを実行しないでください。
3. （省略可）アップグレードが正常に完了するまで、プライマリインスタンスに対するすべての WRITE ステートメントを一時停止します。
4. （省略可）プライマリをアップグレードする前にすべてのレプリカを削除し、アップグレードが完了したらレプリカを再作成します。
レプリケーションが中断された場合、レプリカはプライマリインスタンスのバージョンにロールバックされます。レプリカを再度アップグレードできますが、問題が解決しない場合は、[よくある質問](#faqs) をご覧ください。

データベースのメジャーバージョンをインプレースでアップグレードする

アップグレードを開始すると、Cloud SQL は、最初にインスタンスの構成をチェックしてアップグレードの互換性を確認します。構成を確認すると、Cloud SQL は、インスタンスを利用不可にして、アップグレード前のバックアップを作成します。その後、アップグレードを実行し、インスタンスを使用可能にして、アップグレード後のバックアップを作成します。

MySQL 8.0 にアップグレードすると、Cloud SQL では、インスタンスがデフォルトのマイナーバージョンに自動的にプロビジョニングされます。

コンソール

Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

Cloud SQL の [インスタンス] に移動
インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
[編集] をクリックします。
[インスタンスの情報] セクションで [アップグレード] ボタンをクリックし、アップグレードページに移動します。
[データベースのバージョンを選択] ページで [アップグレード後のデータベースバージョン] リストをクリックし、使用可能なデータベースのメジャーバージョンの 1 つを選択します。
[次へ] をクリックします。
[インスタンス ID] ボックスにインスタンスの名前を入力し、[アップグレードを開始] ボタンをクリックします。

処理が完了するまでに数分かかります。

アップグレード後のデータベースのメジャーバージョンが、インスタンスの概要ページのインスタンス名の下に表示されていることを確認します。

gcloud

アップグレードを開始する

gcloud sql instances patch コマンドに --database-version フラグを指定します。

コマンドを実行する前に、次のように置き換えます。
- INSTANCE_NAME: インスタンスの名前。
- DATABASE_VERSION: データベースのメジャーバージョンの列挙型。これは、現在のバージョンより大きくする必要があります。利用可能なデータベースバージョンの列挙型をご覧ください。
```
gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION
```
メジャーバージョンのアップグレードが完了するまで数分かかります。オペレーションに予想より時間がかかっていることを示すメッセージが表示される場合があります。このメッセージは無視するか、gcloud sql operations wait コマンドを実行してメッセージを閉じます。
アップグレードオペレーション名を取得します。

gcloud sql operations list コマンドに --instance フラグを指定します。

コマンドを実行する前に、INSTANCE_NAME 変数をインスタンス名に置き換えます。
```
gcloud sql operations list --instance=INSTANCE_NAME
```
アップグレードのステータスをモニタリングします。

gcloud sql operations describe コマンドを使用します。

コマンドを実行する前に、OPERATION 変数を前の手順で取得したアップグレードオペレーション名に置き換えます。
```
gcloud sql operations describe OPERATION
```

REST v1

インプレースアップグレードを開始します。

PATCH リクエストで instances:patch メソッドを使用します。

リクエストデータを使用する前に、次の変数を置き換えます。
- project_id: プロジェクトの ID。
- instance_name: インスタンスの名前。
HTTP メソッドと URL:
```
POST https://sqladmin.googleapis.com/sql/v1/projects/project-id/instances/instance_name
```
JSON 本文のリクエスト
```
{
  "databaseVersion": enum DATABASE_VERSION
}
```
DATABASE_VERSION は、データベースのメジャーバージョンの列挙型に置き換えます。これは、現在のバージョンよりも大きいものにする必要があります。利用可能なデータベースバージョンの列挙型をご覧ください。

curl または PowerShell を使用してリクエストを送信します。インスタンスの編集をご覧ください。
アップグレードオペレーション名を取得します。

project_id をプロジェクトの ID に置き換えて、operations.list メソッドを含む GET リクエストを送信します。

HTTP メソッドと URL:
```
GET https://sqladmin.googleapis.com/sql/v1/projects/project-id/operations
```
アップグレードのステータスをモニタリングします。

次の変数を置き換えて、operations.get メソッドを含む GET リクエストを送信します。
- project_id: プロジェクトの ID。
- operation_name: 前の手順で取得したアップグレードオペレーション名。
HTTP メソッドと URL:
```
GET https://sqladmin.googleapis.com/sql/v1/projects/project-id/operation/operation_name
```

Terraform

データベースのバージョンを更新するには、Terraform リソースと Google Cloud の Terraform プロバイダのバージョン 4.34.0 以降を使用します。

cloud_sql/mysql_database_instance/main.tf

GitHub で表示フィードバック

resource "google_sql_database_instance" "instance" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

変更を適用する

Google Cloud プロジェクトで Terraform 構成を適用するには、次のセクションの手順を完了します。

Cloud Shell を準備する

Cloud Shell を起動します。
Terraform 構成を適用するデフォルトの Google Cloud プロジェクトを設定します。

このコマンドは、プロジェクトごとに 1 回だけ実行する必要があります。これは任意のディレクトリで実行できます。
```
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
```
Terraform 構成ファイルに明示的な値を設定すると、環境変数がオーバーライドされます。

ディレクトリを準備する

Terraform 構成ファイルには独自のディレクトリ（ルートモジュールとも呼ばれます）が必要です。

Cloud Shell で、ディレクトリを作成し、そのディレクトリ内に新しいファイルを作成します。ファイルの拡張子は .tf にする必要があります（例: main.tf）。このチュートリアルでは、このファイルを main.tf とします。
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
チュートリアルを使用している場合は、各セクションまたはステップのサンプルコードをコピーできます。

新しく作成した main.tf にサンプルコードをコピーします。

必要に応じて、GitHub からコードをコピーします。Terraform スニペットがエンドツーエンドのソリューションの一部である場合は、この方法をおすすめします。
環境に適用するサンプルパラメータを確認し、変更します。
変更を保存します。
Terraform を初期化します。これは、ディレクトリごとに 1 回だけ行います。
```
terraform init
```
最新バージョンの Google プロバイダを使用する場合は、-upgrade オプションを使用します。
```
terraform init -upgrade
```

変更を適用する

構成を確認して、Terraform が作成または更新するリソースが想定どおりであることを確認します。
```
terraform plan
```
必要に応じて構成を修正します。
次のコマンドを実行します。プロンプトで「yes」と入力して、Terraform 構成を適用します。
```
terraform apply
```
Terraform に「Apply complete!」というメッセージが表示されるまで待ちます。
Google Cloud プロジェクトを開いて結果を表示します。Google Cloud コンソールの UI でリソースに移動して、Terraform によって作成または更新されたことを確認します。

変更を削除する

変更を削除するには、次の手順を行います。

削除の保護を無効にするには、Terraform 構成ファイルで deletion_protection 引数を false に設定します。
```
deletion_protection =  "false"
```
次のコマンドを実行します。プロンプトで「yes」と入力して、更新された Terraform 構成を適用します。
```
terraform apply
```

次のコマンドを実行しています。プロンプトで「yes」と入力して、以前に Terraform 構成で適用されたリソースを削除します。
```
terraform destroy
```

インプレースアップグレードリクエストを行うと、Cloud SQL はまずアップグレード前のチェックを行います。Cloud SQL でインスタンスのアップグレードの準備ができていないと判断された場合、アップグレードリクエストは失敗し、問題に対処する方法を提案するメッセージが表示されます。メジャーバージョンアップグレードのトラブルシューティングもご覧ください。

自動アップグレードのバックアップ

メジャーバージョンアップグレードを実行すると、Cloud SQL は 2 つのオンデマンドバックアップ（アップグレードバックアップ）を自動的に作成します。

最初のアップグレードバックアップは、アップグレード前のバックアップで、アップグレードの直前に作成されます。このバックアップは、データベースインスタンスを以前のバージョンの状態に復元するために使用できます。
2 番目のアップグレードバックアップは、アップグレード後のバックアップで、アップグレードされたデータベースインスタンスへの新しい書き込みが許可された直後に作成されます。

バックアップのリストを表示すると、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. が付きます。

他のオンデマンドバックアップと同様に、アップグレードバックアップは、それを削除するかインスタンスを削除するまで残ります。PITR が有効になっていると、保持期間中のアップグレードバックアップは削除できません。アップグレードバックアップを削除する必要がある場合は、PITR を無効にするか、アップグレードバックアップの保持期間が終了するまで待つ必要があります。

メジャーバージョンアップグレードを実行する

プライマリインスタンスのアップグレードが終了したら、次の手順でアップグレードを実行します。

承認テストを実行します。

テストを実行して、アップグレードしたシステムが期待どおりに動作することを確認します。
（省略可）ユーザーの権限を更新します。

MySQL 8.0 にアップグレードした場合、MySQL によってセキュリティとアカウント管理のシステムが変更されている点に注意してください。詳細については、MySQL 8.0 の新機能をご覧ください。

これにより、MySQL 5.7 バージョンのインスタンスで作成されたユーザーが、MySQL 8.0 で直接作成されたユーザーと同じ権限を持たないことがあります。たとえば、MySQL 5.7 からアップグレードされたユーザーには、CREATE ROLE 権限と DROP ROLE 権限がない可能性があります。MySQL 5.7 にはこれらの権限が存在しなかったためです。Cloud SQL では、バージョンをアップグレードした後にユーザー権限をリセットして、ユーザー権限に関連する問題を修正することをおすすめします。

ユーザー権限をリセットするには、次の手順を行います。
1. cloudsqlsuperuser ロールが付与されたユーザーを作成します。
2. 作成したユーザーを使用して、以下を以て、アップグレードされたユーザーの以前のすべての権限を取り消します。
```
REVOKE ALL PRIVILEGES ON *.* FROM user@host
```
3. アップグレードしたユーザーに適切な権限を付与します。
（省略可）バックアップを作成します。

Cloud SQL では、プライマリインスタンスをアップグレードすると、自動的にバックアップが作成されますが、必要に応じてデータベースを復元できるように、自分でバックアップを作成することをおすすめします。

メジャーバージョンアップグレードのトラブルシューティング

無効なアップグレードコマンド（インスタンスに新しいバージョンの無効なデータベースフラグが含まれている場合など）を試行すると、Cloud SQL はエラーメッセージを返します。

アップグレードリクエストが失敗した場合は、アップグレードリクエストの構文を確認してください。リクエストに有効な構造がある場合は、次の推奨事項を確認してください。

アップグレードログを表示する

有効なアップグレードリクエストでエラーが発生した場合、Cloud SQL はエラーログを projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err に公開します。各ログエントリには、インスタンス ID のラベルが付いているため、アップグレードエラーが発生したインスタンスを識別できます。このようなアップグレードエラーを見つけて解決します。

エラーログを表示するには、次の手順を行います。

Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

Cloud SQL の [インスタンス] に移動
インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
インスタンスの [概要] ページの [オペレーションとログ] ペインで、[MySQL のエラーログを表示] リンクをクリックします。

[ログエクスプローラ] ページが開きます。
次のようにログを表示します。
- プロジェクト内のエラーログすべてを一覧表示するには、ログ名を選択して、ログ名でフィルタリングします。
クエリフィルタの詳細については、高度なクエリをご覧ください。
- 単一のインスタンスのアップグレードエラーログをフィルタリングするには、DATABASE_ID を次のように置き換えてから、[すべてのフィールドを検索] ボックスに次のクエリを入力します。
プロジェクト 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"
 ```
```

以前のメジャーバージョンに戻す

アップグレードしたデータベースシステムが期待どおりに機能しない場合は、インスタンスを以前のバージョンに復元しなければならないことがあります。その場合は、アップグレード前のバックアップを Cloud SQL のリカバリインスタンスに復元します。これは、アップグレード前のバージョンを実行する新しいインスタンスです。

以前のバージョンに復元する手順は次のとおりです。

アップグレード前のバックアップを特定します。

自動アップグレードバックアップをご覧ください。
復元インスタンスを作成します。

アップグレード前のバックアップの作成時に Cloud SQL で実行されていたメジャーバージョンを使用して、新しい Cloud SQL インスタンスを作成します。元のインスタンスと同じフラグとインスタンスの設定を使用します。
アップグレード前のバックアップを復元します。

アップグレード前のバックアップをリカバリインスタンスに復元します。完了には数分かかる場合があります。
リードレプリカを追加します。

複数のリードレプリカを使用していた場合は、それらを個別に追加します。
アプリケーションを接続します。

データベースシステムをリカバリしたら、リカバリインスタンスとそのリードレプリカの詳細でアプリケーションを更新します。アップグレード前のバージョンのデータベースでトラフィックの処理を再開できます。

制限事項

Cloud SQL for MySQL のインプレースメジャーバージョンアップグレードに影響する制限事項を確認します。以下の制限事項は、現在確認中です。

MySQL 5.7 から 8.0 へのインスタンスのアップグレードで、512,000 個を超えるテーブルがあると長い時間がかかりタイムアウトする可能性があります。

よくある質問

データベースのメジャーバージョンをアップグレードするときは、次のような疑問が生じることがあります。

アップグレード中はインスタンスを使用できませんか？: はい。Cloud SQL がアップグレードを実行する間、インスタンスは一定期間使用できません。

アップグレードにはどれくらい時間がかかりますか？

通常、1 つのインスタンスのアップグレードには 10 分もかかりません。インスタンス構成で使用されている vCPU またはメモリが少ない場合、アップグレードに時間がかかることがあります。

インスタンスでホストされているデータベースやテーブルが多すぎる場合や、データベースが非常に大きい場合は、アップグレードに数時間がかかったりタイムアウトになることがあります。これは、アップグレード時間がデータベース内のオブジェクト数と対応するためです。アップグレードが必要なインスタンスが複数ある場合は、それに比例してアップグレードの合計時間が長くなります。

アップグレードプロセスの各ステップをモニタリングできますか？: Cloud SQL ではアップグレードオペレーションが進行中かどうかモニタリングできますが、アップグレードの個々のステップを追跡することはできません。

開始後にアップグレードをキャンセルできますか？: いいえ、アップグレードを開始すると、キャンセルはできません。アップグレードに失敗すると、Cloud SQL は以前のバージョンのインスタンスを自動的に復元します。

アップグレード中に設定はどうなりますか？

インプレースのメジャーバージョンアップグレードを実行すると、Cloud SQL はインスタンス名、IP アドレス、明示的に構成されたフラグ値、ユーザーデータなどのデータベース設定を保持します。ただし、システム変数のデフォルト値は変更されることがあります。たとえば、MySQL 5.7 の character_set_server フラグのデフォルト値は utf8 です。MySQL 8.0 にアップグレードすると、フラグのデフォルト値は utf8mb4 に変更されます。utf8 に戻すには、フラグの値を前の値に設定します。

詳細については、データベースフラグを構成するをご覧ください。特定のフラグまたは値がターゲットバージョンでサポートされなくなった場合、Cloud SQL はアップグレード中にフラグを自動的に削除します。

レプリカをアップグレードした後にレプリケーションが中断された場合、どうすればよいですか？

レプリカのアップグレード後にレプリケーションが中断すると、プライマリインスタンスの MySQL バージョンにロールバックされます。レプリカは再度アップグレードできますが、問題が解決していないと、レプリケーションが再び中断する可能性があります。

レプリカがロールバックされない場合は、次の 2 つの方法があります。

壊れたレプリカを削除し、新しいレプリカを作成して、その新しいレプリカをアップグレードします。

アップグレードが再び失敗した場合は、アップグレード時に互換性のない変更がプライマリに追加されたことにより失敗した可能性があります。アップグレードで問題を特定し、プライマリインスタンスを修正して、レプリカをアップグレードしてみてください。詳細については、トラブルシューティングをご覧ください。
プライマリインスタンスをアップグレードします。

レプリカスレッドが機能していない場合、プライマリインスタンスのアップグレードオペレーションでレプリカが再作成されます。

アップグレードしたレプリカが古いバージョンにロールバックされたのはなぜですか？

アップグレードに失敗すると、レプリカは、プライマリインスタンスのバージョンにロールバックされます。レプリカを再度アップグレードすることは可能ですが、問題が解決しない場合は、レプリカの mysql.err ログを確認して原因を突き止めることができます。[REPL]... failed executing transaction.... end_log_pos...; Failure Reason などのキーワードを検索してください。

エラーメッセージにユーザー権限の変更を伴う Access denied for AuthId.... が含まれている場合は、mysql と sys スキーマで MySQL 5.7 のユーザー権限を使用してクエリが実行されている可能性があり、MySQL 8.0 のセキュリティおよびアカウント管理システムの変更により失敗する可能性があります。この問題を解決するには、プライマリインスタンスを新しいバージョンにアップグレードする前に、プライマリインスタンスのクエリを停止し、レプリカのアップグレードを再試行する必要があります。Cloud SQL では、同様の問題を引き起こす可能性があるため、新しいバージョンにアップグレードする前に、プライマリインスタンスでも、そのようなクエリすべてを一時的に停止することをおすすめします。

MySQL ログに Access denied for AuthID.... などの失敗理由が表示されない場合は、レプリカがアップグレードされた後にプライマリインスタンスに追加された、互換性のない新しいデータが問題の原因である可能性があります。アップグレードする前に、非互換の問題の修正に関して、メジャーバージョンアップグレードの準備をご覧ください。

データベースのメジャー バージョンをインプレースでアップグレードする

はじめに

メジャー バージョン アップグレードの計画

メジャー バージョン アップグレードを準備する

データベースのメジャー バージョンをインプレースでアップグレードする

コンソール

gcloud

REST v1

Terraform

変更を適用する

Cloud Shell を準備する

ディレクトリを準備する

変更を適用する

変更を削除する

自動アップグレードのバックアップ

メジャー バージョン アップグレードを実行する

メジャー バージョン アップグレードのトラブルシューティング

アップグレード ログを表示する

以前のメジャー バージョンに戻す

制限事項

よくある質問

次のステップ

データベースのメジャーバージョンをインプレースでアップグレードする

メジャーバージョンアップグレードの計画

メジャーバージョンアップグレードを準備する

データベースのメジャーバージョンをインプレースでアップグレードする

メジャーバージョンアップグレードを実行する

メジャーバージョンアップグレードのトラブルシューティング

アップグレードログを表示する

以前のメジャーバージョンに戻す