Google CloudのCloud SQLを、業務都合によって使い始めているのですが、メンテナンスのダウンタイムが気になって調べました。
エディションによるダウンタイムの違い
Cloud SQLのエディションによって、想定されるダウンタイムが異なります。
Cloud SQL Enterprise Plus に限り、ニアゼロダウンタイムで、ほぼゼロのダウンタイムです。
Cloud SQL Enterprise エディション
- 60 秒未満（MySQL）
- 30 秒未満（PostgreSQL）
- 120 秒未満（SQL Server）
Cloud SQL Enterprise Plus エディション
- 1 秒未満（MySQL）
- 1 秒未満（PostgreSQL）
- 120 秒未満（SQL Server）
やっていること
- シャドーレプリカ（アプリケーションからはアクセスしない）を作成し、メンテナンス（マイナーバージョンアップなど）を適用します。
- プライマリで新規のコネクション受付を止めて、IPアドレスをプライマリからシャドーレプリカに切り替えます。
- プライマリとシャドーレプリカ間でのレプリケーションを解消し、シャドーレプリカをプライマリへ昇格させます。
- 不要となった元々のプライマリを停止します。
シャドーレプリカとプライマリを切り替える瞬間における、僅かなダウンタイムが1秒未満であるということになります。
ニアゼロですがゼロではない
記事の内容によると、ニアゼロですがゼロではないため、その瞬間に実行されていたトランザクションは中断されます。
VMとその上で動作するデータベースエンジンが切り替わるためメンテナンス以前から確立していたコネクションは使えなくなり、その瞬間に実行されていたトランザクションは中断されます。
https://cloud.google.com/sql/docs/editions-intro?hl=ja
おそらくですが、まさに切り替え中にトランザクションを実行していた場合、コネクションエラーが発生するかも？
あとがき
ニアゼロダウンを想定したアプリケーションになっていれば、サービスをDBメンテナンス対応中に止めなくても済みます。
Google Cloud的には、瞬断で抑えるから自動復旧させるアプリケーションを組んで、ノーメンテでアップデートしてが理想なのかもしれません。 （現状そこまでできておりません。）
