はじめに

Google Cloud の Cloud SQL の新たなエディションの Enterprise Plus が公開された当時から待ち焦がれていた機能の、既存の Enterprise エディションからのインプレースアップグレードがついに GA されました。MySQL と Postgres ともに可能です。
当該記事では今まで可能だった方法も含めて、今回の GA により、よくなった部分を纏めます。
Cloud SQL Enterprise Plus そのものについても、記載していますので、参照いただけると嬉しいです。

今までの Enterprise Edition → Enterprise Plus Edtion

今までは以下の2つの方法で可能でした。

  • DMS を利用した移行
  • インスタンスのバックアップかリストア

ただこれらの方法では以下のような、いくつか考慮事項がありました。
特に DMS での内容の詳細は私のブログを参照いただけると嬉しいです。

  • DMS
    • DMSを利用して移行タイミングを調整しアップグレードする必要があった
    • レプリケートインスタンスが動作するので新たにレプリケート用インスタンスを起動する必要があった
    • 移行先の新たに起動するインスタンスへ、移行元で作成していたユーザを追加したり、メンテナンス時間を合わせ設定をしたりなど、既存インスタンスを踏襲した設定する必要があった
  • バックアップからのリストア
    • バックアップからリストアまでの間に、DBの更新が発生するようなサービスの場合、既存サービスが更新されると、データの差分が発生するため、既存の提供サービスの書き込みを停止する必要があった
    • 既存インスタンスを残し新規にインスタンスを起動する必要があった(既存インスタンスを踏襲した設定を行う)

これからの Enterprise Edition → Enterprise Plus Edtion

上記のような煩わしさがなく、Upgrade an instance by using in-place upgradeに記載がある通り、以下のコマンド一発で、インプレースアップグレードが可能です。

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

では実際にやってみます。

Enterprise Plus へのインプレースアップグレードを試す

身近なものが MysSQL のため、MySQL で試していきます。
公式ドキュメントに記載がある通り、以下のような形で環境に合わせて設定します。

gcloud sql instances patch h-saito-test \
  --edition=enterprise-plus \
  --tier=db-perf-optimized-N-2 \
  --project=プロジェクト名 \
  --no-enable-data-cache

※注意事項

  • インスタンスタイプは Enterprise Plus のものから適切なスペックのものを選択します。
  • デフォルトのまま実行するとデータキャッシュが有効になるため、避けたい場合、「 –no-enable-data-cache」の設定が必要です。
    • データキャッシュは公式ドキュメントの推奨事項に記載がある通り、ある推奨とされるワークロードがいくつか挙げられていますので、その場合のみに検討いただいた方がよいと思います。

実行すると以下のようにメッセージが出力されます。

The following message will be used for the patch API method.
{"name": "h-saito-test", "project": "プロジェクト名", "settings": {"dataCacheConfig": {"dataCacheEnabled": false}, "edition": "ENTERPRISE_PLUS", "tier": "db-perf-optimized-N-2"}}
WARNING: This patch modifies a value that requires your instance to be restarted. Submitting this patch will immediately restart your instance if it's running.

Do you want to continue (Y/n)?

これに対して Y で応答すると実行されます。
以下完了後の出力内容ですが、実行中は done の箇所が working だったと思います。
大体 5分ほどで done のプロンプトが返ってきます。

Patching Cloud SQL instance...done.

実行中 Cloud SQL の画面は以下のようになっており、更新中の旨、表示されます。

Cloud SQL へのアクセスを何度か試しましたが、2-3分ほどで DB 接続がある画面への Web アクセスは可能でしたが、プロンプトが 5 分で返ってきたのと同様に、ログにも 5 分ほど完了までにかかっていた記載がありました。

この後、コンソールにも反映されており、無事アップグレードが完了しています。

所感

今までは DMS 、 バックアップリストア での実施方法と比較し、インプレースアップグレードにより圧倒的にアップグレードしやすくなりました。しかもダウンタイムも少ないという点も、今後の利用が大きく進む内容だと思います。
ただ、DMS による移行については、Cloud SQL 以外からの移行などについては、今後もかなり有効ですので、今までのやり方がまったく使えないというわけではなく、移行の選択肢としては健在ですので、既存システムからの移行を行われる際には、ぜひそちらも活用ください。
今後も Cloud SQL の進化に期待したいです。