インプレース アップグレード

このページでは、Cloud SQL インスタンスのインプレース アップグレードとダウングレードを行う方法について説明します。

Cloud SQL インスタンスをインプレースで変更する

インプレース変更を使用すると、Cloud SQL インスタンスのエディション、マシンタイプ、ストレージ タイプ、データベース バージョンをアップグレードまたはダウングレードできます。 インプレース変更は、インスタンスを再構成する最も簡単でエラーが発生しにくい方法です。

始める前に

インスタンスが MySQL バージョン 8.0.31 以降で実行されていることを確認します。

インスタンスが以前のバージョンの MySQL にある場合は、MySQL 8.0.31 以降にアップグレードする必要があります。詳細については、 データベースのメジャー バージョンをインプレースでアップグレードする とデータベースのマイナー バージョンをアップグレードするをご覧ください。

エディションごとに、異なるストレージ オプションを使用する異なるマシンタイプがサポートされています。高パフォーマンスの C4 マシンタイプと C4A マシンタイプでは、 Hyperdisk Balanced ストレージが 古いマシンタイプで使用される 永続ディスク オプションのいずれかではなく使用されます。

使用しているエディションまたはマシンタイプを変更すると、ストレージ タイプも変更される可能性があり、ダウンタイムが発生したり、ストレージ費用が変更されたりする可能性があります。Google Cloud Hyperdisk Balanced に移行する場合は、追加の構成オプションを指定できます。詳細については、 ストレージの変更をご覧ください。

PITR トランザクション ログストレージの変更に注意する

PITR に使用されるバイナリログをディスクに保存する Cloud SQL Enterprise エディションのインスタンスをアップグレードする場合は、Cloud SQL Enterprise Plus エディションへのアップグレード プロセスで、これらのログの保存場所がディスクから Cloud Storage に移動することに注意してください。インスタンスの PITR バイナリログの現在の場所を確認するには、 PITR に使用されるトランザクション ログの保存場所を確認するをご覧ください。

インプレース アップグレードがバイナリログの場所に与える影響の詳細については、 PITR のバイナリログの保存場所の変更 をご覧ください。

インスタンスのエディションをインプレースで変更する

このセクションでは、Cloud SQL インスタンスのエディションを Cloud SQL Enterprise Plus エディションにインプレースで変更する方法について説明します。Cloud SQL Enterprise Plus エディションには、Cloud SQL Enterprise エディションにはないメリットとパフォーマンスの向上がいくつかあります。Cloud SQL のエディションの詳細については、 Cloud SQL のエディションの概要をご覧ください。

Cloud SQL Enterprise Plus エディションへのアップグレードは数分で完了し、ダウンタイムはほぼゼロです。 Cloud SQL Enterprise エディションに戻すと、ダウンタイムが長くなります。 どちらのプロセスでも、アプリケーションが接続するエンドポイントを変更する必要はありません。

このセクションの手順に沿って、Cloud SQL Enterprise エディションのインスタンスを Cloud SQL Enterprise Plus エディションにアップグレードするか、Cloud SQL Enterprise Plus エディションのインスタンスを Cloud SQL Enterprise エディションにダウングレードします。

コンソール

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

    Cloud SQL の [インスタンス] に移動

  2. インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
  3. [編集] をクリックします。
  4. In the [Choose a Cloud SQL edition] section, click [Upgrade] if your instance is using the Cloud SQL Enterprise edition, or [Switch to Enterprise] if your instance is using Cloud SQL Enterprise Plus edition.
  5. 表示されたパネルを使用して、新しいエディションを使用してインスタンスの構成を指定します。 [インプレース変更を行う際のオプション](#change-options) をご覧ください。
  6. インスタンス ID を入力して選択内容を確認し、アップグレードまたはダウングレードに応じて [エディションをアップグレード] または [エディションを切り替える] をクリックします。

インスタンスの [アクション] 列で [編集] を選択すると、[インスタンス] ページでエディションの変更を開始することもできます。

また、インスタンスが Cloud SQL Enterprise エディションにある場合は、インスタンス ページの [構成] セクションのエディション フィールドの横にある [アップグレード] リンクをクリックしてアップグレードを開始できます。

gcloud

次の [`gcloud sql instance patch`](/sdk/gcloud/reference/sql/instances/patch) コードサンプルは、インスタンスを Cloud SQL Enterprise Plus エディションにアップグレードする方法を示しています。

gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise-plus \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID

次のように置き換えます。

  • PROJECT_ID: アップグレードするインスタンスのプロジェクト ID。
  • INSTANCE_ID: アップグレードするインスタンスの名前。
  • MACHINE_TYPE: アップグレードするインスタンスのマシンタイプ。 Cloud SQL Enterprise Plus エディションのマシンタイプの詳細については、 Cloud SQL Enterprise Plus エディション インスタンスのマシンタイプをご覧ください。

REST

次のコマンドは、インスタンスを Cloud SQL Enterprise Plus エディションにアップグレードし、 再起動オペレーションをトリガーします。

リクエストのデータを使用する前に、 次のように置き換えます。

  • PROJECT_ID: アップグレードするインスタンスのプロジェクト ID。
  • INSTANCE_ID: アップグレードするインスタンスのインスタンス ID。
  • MACHINE_TYPE: アップグレードするインスタンスのマシンタイプ。Cloud SQL Enterprise Plus エディションのマシンタイプの詳細については、Cloud SQL Enterprise Plus エディション インスタンスのマシンタイプをご覧ください。

HTTP メソッドと URL:

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

リクエストの本文（JSON）: 

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

リクエストを送信するには、次のいずれかのオプションを展開します。

次のような JSON レスポンスが返されます。

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

次のコマンドは、インスタンスを Cloud SQL Enterprise Plus エディションにアップグレードし、 再起動オペレーションをトリガーします。

リクエストのデータを使用する前に、 次のように置き換えます。

  • PROJECT_ID: アップグレードするインスタンスのプロジェクト ID。
  • INSTANCE_ID: アップグレードするインスタンスのインスタンス ID。
  • MACHINE_TYPE: アップグレードするインスタンスのマシンタイプ。Cloud SQL Enterprise Plus エディションのマシンタイプの詳細については、Cloud SQL Enterprise Plus エディション インスタンスのマシンタイプをご覧ください。

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

リクエストの本文（JSON）: 

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

リクエストを送信するには、次のいずれかのオプションを展開します。

次のような JSON レスポンスが返されます。

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

インプレース変更のオプション

Cloud SQL インスタンスのエディションを変更するには、マシンシリーズの変更が必要になる場合があります。これにより、ストレージ タイプに影響します。

マシンの変更

エディションを変更する場合は、マシンタイプも変更する必要があります。Cloud SQL でサポートされているマシンシリーズの詳細については、 マシンシリーズを選択するをご覧ください。

Cloud SQL Enterprise エディションから Cloud SQL Enterprise Plus エディションにアップグレードする場合は、 N2、 C4A、および C4 のマシンシリーズから選択できます。

Cloud SQL Enterprise Plus エディションから Cloud SQL Enterprise エディションにダウングレードする場合は、 汎用専用コアと N4 マシンシリーズから選択できます。

エディションを変更せずにマシンタイプを変更することもできます。インスタンスの編集を選択したら、[インスタンスをカスタマイズ] 領域の [マシンの構成] の [マシン] サブセクションに移動します。 プルダウンを使用して、別のマシンタイプを選択できます。必要に応じて、別の数の vCPU を選択し、 データ キャッシュを有効または無効にすることもできます。

一般的な情報については、 Compute Engine ドキュメントで N2、 C4A、 C4、 N4 マシンシリーズもご覧ください。

ストレージの変更

汎用または N2 マシンシリーズから N4、 C4A、C4 マシンシリーズに変更すると、ストレージが ソリッド ステート ドライブ（SSD） から Google Cloud Hyperdisk Balanced ストレージに移行されます。通常、このアップグレードに必要なダウンタイムは最小限です。

Google Cloud Hyperdisk Balanced ストレージは、次の設定を行うことでユースケースに合わせてカスタマイズできます。

  • ストレージ容量
  • プロビジョニングされた IOPS
  • プロビジョニングされたスループット

Google Cloud Hyperdisk Balanced は、インスタンスの構成（マシンタイプやストレージ容量など）に基づいて、デフォルトの IOPS 値とスループット値、上限を設定します。ストレージ容量によってデフォルト値の上限が決定され、マシンタイプによって IOPS とスループットの両方の最大値が設定されます。詳細については、 ストレージ オプションを選択する をご覧ください。

PITR のバイナリログの場所の変更

Cloud SQL Enterprise エディションのインスタンスがディスクに PITR のトランザクション ログを保存している場合、Cloud SQL Enterprise Plus エディションへのアップグレード プロセスを開始すると、これらのログの保存場所が Cloud Storage に切り替わります。

場所の変更には、次の条件が適用されます。

  • このプロセスでは、Cloud Storage への切り替えが完了するまで、およそ transactionLogRetentionDays で PITR 構成設定の期間がかかります。
  • インスタンスで expire_logs_days フラグまたは binlog_expire_logs_seconds フラグの値が設定されている場合、その値は保持されます。
  • Cloud Storage への切り替え中は、インスタンスの expire_logs_days フラグまたは binlog_expire_logs_seconds フラグの値を変更できません。
  • Cloud Storage への切り替え中は、transactionLogRetentionDays PITR 構成設定を変更しないことをおすすめします。transactionLogRetentionDays を増やしても、バイナリログは Cloud SQL Enterprise エディション インスタンスのデフォルト値である 7 日間を超えてディスクに保持されません。
  • 切り替えの進行中、Cloud SQL はディスク上のログを次のいずれかの最小値に保持します。
    • 切り替え前の transactionLogRetentionDays PITR 構成設定（デフォルトは 7 日間）。
    • インスタンスに手動で設定された expire_logs_days フラグまたは binlog_expire_logs_seconds フラグ。
  • 切り替え後、Cloud SQL は、インスタンスに expire_logs_days フラグまたは binlog_expire_logs_seconds フラグを設定していない限り、切り替え前と同じ量のバイナリログをディスクに保持します。 これらのフラグを設定した場合、Cloud SQL は transactionLogRetentionDays 構成設定の最小値またはフラグの値に基づいて、バイナリログをディスクに保持します。

Cloud SQL Enterprise Plus エディションのバックアップとログストレージのデフォルト

インスタンスの Cloud Storage への切り替えが完了しても、Cloud SQL はレプリケーション用にバイナリログのコピーをディスクに保持します。mysqlbinlog ユーティリティでバイナリログを参照する場合は、ディスクにバイナリログを保存すると便利です。

アップグレード前にインスタンスで expire_logs_days フラグと binlog_expire_logs_seconds フラグを構成した場合、構成済みの値はそのまま残ります。

切り替え後、PITR の実行に使用されるバイナリログが Cloud Storage に保存されるため、フラグの値が、想定どおりにディスク上のトランザクション ログの保持を反映するようにします。Cloud SQL は、ディスク上のログを次のいずれかの最小値に保持します。

  • 切り替え前の transactionLogRetentionDays PITR 構成設定（デフォルトは 7 日間）
  • インスタンスに手動で設定された expire_logs_days フラグまたは binlog_expire_logs_seconds フラグ

ディスク容量を節約する場合は、アップグレードが完了した後、expire_logs_days フラグまたは binlog_expire_logs_seconds フラグの値を 1 日分に構成すれば、割り当てられたディスクサイズとディスク ストレージの費用を削減できます。トランザクション ログストレージと PITR の詳細については、PITR のログストレージをご覧ください。

Cloud SQL Enterprise Plus エディションへのアップグレードが完了すると、アップグレードされたすべてのインスタンスのデフォルトのトランザクション ログ保持期間が 14 日に延長されます。この延長と、トランザクション ログ保持期間に対して構成するその他の延長について、PITR の全保持期間が適用されるには、新たに延長された値分の日数が必要です。たとえば、トランザクション ログの保持期間の古い値が 7 日で、新しい値が 14 日に延びた場合、アップグレード後の最初の 7 日間の PITR の保持期間は 7 日間のみです。8 日目には PITR の期間が 8 日間になり、9 日目には 9 日間になり、14 日目には保持期間が 14 日間に延長されます。

また、自動バックアップのデフォルト数は 8 から 15 に増加します。

メジャー バージョンのアップグレード後に Cloud SQL Enterprise Plus エディションにアップグレードすると、メジャー バージョンのアップグレードより前の時点に PITR を実行できなくなります。この制限は、保持期間がその期間に該当する場合にも適用されます。 インスタンスは、メジャー バージョンのアップグレードを開始した後の特定の時点に復元できます。