Cloud SQL インスタンスでのメンテナンスについて

MySQL | PostgreSQL | SQL Server

このページでは、Cloud SQL インスタンスでメンテナンスを更新する方法と、更新のタイミングを制御する方法について説明します。開始するには、メンテナンスの時間枠の検索と設定をご覧ください。

概要

Cloud SQL はマネージドサービスとして、インスタンスを自動的に更新し、基盤となるハードウェア、オペレーティングシステム、データベースエンジンの信頼性、パフォーマンス、安全、最新性を確保します。これらの更新のほとんどは、Cloud SQL インスタンスの稼働中に行われます。ただし、一部のシステム更新では短時間サービスの中断が必要になります。こうした更新はメンテナンスと呼ばれます。

メンテナンスにより、データベースエンジンが更新され、場合によっては、オペレーティングシステムも更新されます。この更新ではインスタンスの再起動が必要になるため、ダウンタイムが発生します。メンテナンス更新には次の利点があります。

Cloud SQL の機能。新しい機能をリリースするために、データベースエンジンが更新され、データベースへの新しいプラグインがインストールされます。
データベースのバージョンアップグレード。MySQL を開発しているデータベースソフトウェアプロバイダは、年に数回、新しいマイナーバージョンをリリースしています。新しいバージョンごとに、バグの修正、セキュリティパッチ、パフォーマンスの向上、新しいデータベース機能が提供されます。Cloud SQL for MySQL でサポートされている最新のマイナーバージョンを確認するには、リリースノートまたはデータベースのバージョンとバージョンポリシーをご覧ください。Cloud SQL インスタンスは、リリース直後に最新のデータベースバージョンにアップグレードされるため、最新のデータベースソフトウェアを実行できます。

MySQL 8.0 マイナーバージョンのアップグレードは手動で行う必要があります。インスタンスに MySQL マイナーバージョンを設定するをご覧ください。
オペレーティングシステムのパッチ。Google では、オペレーティングシステムに存在する新たなセキュリティ脆弱性を継続的に監視しています。こうした脆弱性が見つかると、オペレーティングシステムにパッチを適用し、新たなリスクからシステムを保護します。

メンテナンスへの影響

Cloud SQL Enterprise Plus エディションの場合、Cloud SQL では計画的メンテナンスでダウンタイムがほぼゼロになります。

Cloud SQL は通常、数か月に 1 回メンテナンス更新イベントのスケジュールを設定します。メンテナンス更新には、インスタンスごとに約 5～10 分かかることがあります。インスタンスにリードレプリカがある場合は、メンテナンス更新の全体的な時間がより長くなることがあります。ただし、メンテナンス更新イベント中、各 Cloud SQL Enterprise エディションインスタンスの接続が切断される時間は平均 60 秒未満です。メンテナンス更新イベント中に大量のアクティビティが発生しているインスタンス、または非常に大規模なデータセットを持つインスタンスの場合、ダウンタイムがより長くなる可能性があります。

メンテナンスの設定を利用したり、一時的なエラーに強いシステムに変更することで、メンテナンスによる影響を最小限に抑えることができます。

ダウンタイムがほぼゼロの計画的メンテナンス

「ダウンタイムがほぼゼロの計画的メンテナンス」を利用できる Cloud SQL Enterprise Plus エディションのインスタンスでは、高可用性が構成済みの場合に、計画的メンテナンス中に接続性が失われるのは一般的に 1 秒未満です。

メンテナンス中のアクティビティが多いインスタンスの場合はダウンタイムが長くなる可能性があります。

前提条件と制約

次のフラグを使用する場合は、デフォルト値に設定する必要があります。
- sync_binlog、値: 1
- innodb_flush_log_at_trx_commit、値: 1
- replica_skip_errors、値: OFF
- binlog_order_commit、値: ON
詳細については、データベースフラグを構成するをご覧ください。
Cloud SQL Auth Proxy または Cloud SQL 言語コネクタを使用している場合は、最新バージョンに更新されていることを確認してください。
GTID が有効になっている外部レプリカがある場合は、GTID ベースの自動配置を使用するようにこれらのレプリカを構成する必要があります。構成しないと、メンテナンス後にレプリケーションが中断されます。詳細については、GTID 自動ポジショニングをご覧ください。
MySQL サーバーの UID はメンテナンス中に変更されます。

メンテナンス中、データベースログには 2 つの異なる VM からのメッセージが記録されます。
計画的メンテナンス中に DDL が発行された場合は、変更の作成または修正のタイムスタンプがメンテナンスタイムスタンプより後になることがあります。

ダウンタイムがほぼゼロの計画的メンテナンスをシミュレートする

Cloud SQL Enterprise Plus エディションのプライマリインスタンスの計画的メンテナンスのダウンタイムを、データベースインスタンスを更新することなくテストするために、ダウンタイムがほぼゼロの計画的メンテナンスをシミュレートすることができます。

これを行うには、「ダウンタイムがほぼゼロの計画的メンテナンス」の利用資格のある Cloud SQL Enterprise Plus エディションのインスタンス上で、メンテナンスイベントのシミュレーションを起動します。このシミュレーションリクエストの結果として、インスタンス更新オペレーションが行われますが、これはオペレーション前と同じメンテナンスバージョンへの更新です。

このシミュレーションは、そのインスタンスに対する保留中のメンテナンス更新がある場合でも実行できます。インスタンスのバージョンは、シミュレーションが終了するまでの間、同じままです。

ダウンタイムがほぼゼロの計画メンテナンスのイベントをシミュレートするには、次の gcloud CLI コマンドを使用します。

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

INSTANCE_NAME は、シミュレートメンテナンスイベントを実行するインスタンスの名前で置き換えてください。

メンテナンスの設定

Cloud SQL では、一連のメンテナンス設定を使用してメンテナンス更新を構成できます。

ダウンタイムを短くし、アプリケーションへの影響を最小限に抑えるようにメンテナンスを構成できます。Cloud SQL インスタンスごとに、次の構成を行うことができます。

メンテナンスのタイミング（以前の更新の順序）。Cloud SQL インスタンスを更新するロールアウト期間の週。オプションは次のとおりです。
- Any: メンテナンス更新はいつでも行われる可能性がありますが、通常は第 1 週に行われます。
- Week 1: メンテナンス通知が送信されてから 7～14 日後にメンテナンスが行われます。
- Week 2: 通知が送信されてから 15～21 日後にメンテナンス更新が行われます。
- Week 5: 通知が送信されてから 35～42 日後にメンテナンス更新が行われます。
メンテナンス更新のスケジュールは、メンテナンスの時間枠を構成するときに設定します。
メンテナンスの時間枠。Cloud SQL がメンテナンスをスケジュールする曜日と時間。メンテナンスの時間枠は 1 時間です。メンテナンスの時間枠の構成方法を確認してください。
メンテナンス拒否期間。Cloud SQL がメンテナンスをスケジュールしない日数のブロック。メンテナンス拒否期間は最長 90 日間まで設定できます。メンテナンス拒否期間の構成方法をご確認ください。

デフォルトのメンテナンスの時間枠

メンテナンスの時間枠を設定しない場合、Cloud SQL は、インスタンスのタイムゾーンに応じて、次のデフォルトの時間枠でインスタンスを更新します。

平日（月～金）: 午後 10 時～午前 6 時
週末: 金曜日の午後 10 時～月曜日の午前 6 時

メンテナンスの例

ショッピングカートサービスを管理する小売業の開発者を例に考えてみましょう。ここでは、本番環境用とステージング環境用の Cloud SQL インスタンスが 1 つずつあり、インスタンスのトラフィック処理量が最も少ない時間帯（日曜日の深夜 0 時頃）にメンテナンスを行いたいと考えています。また、年末商戦の繁忙期はメンテナンスを避ける必要があります。

この場合、本番環境のインスタンスのメンテナンスを次のように設定します。

メンテナンスの時間枠: 日曜午前 12 時～午前 1 時（米国東部時間）
メンテナンスのタイミング: Week 2
メンテナンス拒否期間: 11 月 1 日から 1 月 15 日。

ステージング環境のメンテナンスの設定も同じですが、メンテナンスのタイミングが Week 2 に設定されます。これにより、メンテナンスが本番環境にロールアウトされる 7 日前までに、メンテナンスリリースの運用承認テストを行うことができます。ステージング環境でなんらかの問題が発生した場合は、問題を診断して修正するか、本番環境に影響が及ばないようにメンテナンス拒否期間を設定します。

今後のメンテナンスに関する通知

メンテナンスが予定されている少なくとも 1 週間前に、今後のメンテナンスに関する通知をメールで受け取るよう設定できます。通知のメールフィルタを設定する場合、メールのタイトルは「Cloud SQL インスタンス（インスタンス名）の今後のメンテナンス」となります。

デフォルトでは、メンテナンス通知は送信されません。メンテナンス通知を有効にする必要があります。通知を受信するには、メンテナンスの時間枠も選択する必要があります。

通知は Google アカウントに関連付けられているメールアドレスに送信されます。チームのメールエイリアスなどのカスタムメールエイリアスは構成できません。

特定のプロジェクトで、メンテナンスの時間枠が設定されている Cloud SQL インスタンスごとに、メンテナンス通知を有効にします。インスタンスごとに 1 つの通知が届きます。リードレプリカには、今後のメンテナンス通知は送信されません。

Google Cloud Console で今後のメンテナンス情報を確認することもできます。

[インスタンス] リストの [メンテナンス] 列。メンテナンスのスケジュール設定されている場合、メンテナンスの開始日時が表示されます。「メンテナンス」という用語を使用して [インスタンス] リストをフィルタすると、メンテナンスのスケジュールが設定されているすべてのインスタンスを検索できます。[メンテナンス] 列は、プロジェクト内の 1 つ以上のインスタンスでメンテナンスがスケジュールされている場合にのみ表示されます。メンテナンスのスケジュールが設定されていない場合、この列は非表示になります。
[メンテナンス] ペインの [インスタンスの詳細] ページ。メンテナンスが予定されている場合は、[近日公開] の下にメンテナンスの開始日時が表示されます。
Google Cloud コンソールの [アクティビティ] ページでは、メンテナンスがスケジュールされているインスタンスのリストを表示できます。メンテナンスのスケジュールが設定されている場合、インスタンスの「SQL Maintenance」というメッセージと、メンテナンスの開始日時が表示されます。

注: [アクティビティ] ページに Activity information is not found on the Logs Explorer page ステータスメッセージが表示される場合は、resourcemanager.projects.get の権限が割り当てられていることを確認してください。権限の割り当ての詳細については、ロールと権限をご覧ください。

メンテナンススケジュールの再設定

インスタンスにメンテナンスの時間枠を設定している場合、メンテナンス更新実施が予定されている時刻の 24 時間前までなら、メンテナンス更新のスケジュールを変更できます。たとえば、予定しているメンテナンスの時間枠中に新しいサービスをリリースする場合は、メンテナンス更新をリリースの数日後に延期することをおすすめします。

メンテナンス更新のスケジュール変更には、いくつかの制限があります。Cloud SQL から通知メールが送信された後、Cloud SQL は次の Cloud SQL メンテナンス更新との重複を避けるために、7 週間以内にメンテナンス更新を実行します。たとえば、メンテナンスのタイミングを第 1 週または第 2 週に設定した場合は、メンテナンス更新のスケジュールを、元々予定していた日から最大 4 週間（28 日間）後まで再設定できます。インスタンスのメンテナンスのタイミングを第 5 週に設定した場合は、元の日から最大 1 週間（7 日間）後までしかメンテナンスイベントのスケジュールを変更できません。スケジュール変更されたメンテナンスイベントが、インスタンスに構成したメンテナンスのタイミングによって定義されたスケジュール変更期間内に収まる限り、メンテナンスのスケジュールは複数回変更できます。

その他の制限事項については、スケジュール変更の制限事項をご覧ください。

新しいメンテナンスの時間枠には、次のようなスケジュールのオプションがあります。

すぐに更新を適用する。定期メンテナンスの時間枠を待つのではなく、更新をすぐにインスタンスに適用できます。この場合、通常 5 分以内にメンテナンスが開始されます。
スケジュールを別の時間に変更する。スケジュールが設定されたメンテナンスイベントは、次の 2 つの方法で延期できます。
- 次回の利用可能な時間枠。このオプションでは、現在の定期メンテナンス時刻から次に利用可能なメンテナンスの時間枠までメンテナンスを延期します（通常は 1 週間後）。
- 特定の時間。このオプションでは、インスタンスに構成したメンテナンスタイミングにより定義されたスケジュール変更の期間を指定できます。
  - メンテナンスのタイミングを第 1 週または第 2 週に設定した場合は 28 日間
  - メンテナンスのタイミングを第 5 週に設定した場合は 7 日間

メンテナンスのスケジュールを変更する方法については、計画メンテナンスのスケジュールを変更するをご覧ください。

メンテナンスの仕組み

メンテナンス時間を短縮するため、Cloud SQL では、高可用性インスタンスの自動フェイルオーバーワークフローにほぼ同じメンテナンスフェイルオーバーワークフローが使用されます。

簡単に説明すると、次のような手順になります。

新しいソフトウェアで更新後の VM を設定します。
元の VM でデータベースを停止します。
ディスクと静的 IP を更新後の VM に切り替えます。
更新された VM でデータベースを起動します。

以下のタブの手順に沿って、メンテナンスの前後を含むワークフローの詳細を確認します。

メンテナンス前

メンテナンス前は、クライアントは静的 IP アドレスを使用して元の VM と通信しています。データは、元の VM にアタッチされている永続ディスクに保存されます。この例では、Cloud SQL インスタンスは高可用性で構成されています。これは、計画外の停止が発生した場合に引き継ぐために、別の VM がスタンバイ状態にあることを意味します。Cloud SQL インスタンスは、アプリケーションへのトラフィックを処理しています。

メンテナンス前の状態を示す図

ステップ 1

新しい VM を設定します。

新しい仮想マシン（VM）に、最新のデータベースソフトウェアと VM オペレーティングシステム（OS）が設定されます。更新された VM OS が起動します。この時点では、データベースエンジンはまだ起動していません。高可用性インスタンスの場合、新しいスタンバイ VM も設定されます。

元の Cloud SQL インスタンスがトラフィックを処理している間、別の VM にソフトウェアの更新をインストールすることで、合計のダウンタイムが大幅に短縮されます。

VM の設定中であることを示す図

ステップ 2

元の VM でデータベースを停止します。

データベースエンジンがシャットダウンされるため、ディスクは元の VM から切断され、更新された VM にアタッチされます。データベースエンジンは、進行中のトランザクションが commit され、既存の接続からのリクエストがドレインされるまで数秒待機してからシャットダウンされます。その後、オープンまたは長時間実行されているトランザクションはロールバックされます。データベースは新しい接続を受け付けなくなり、既存の接続は破棄されます。インスタンスが利用できなくなり、メンテナンスのダウンタイムが開始されます。

フェイルオーバー後のインスタンスを示す図

ステップ 3

更新された VM に切り替えます。

ディスクが元の VM から切断され、更新された VM にアタッチされます。更新された VM を参照するように静的 IP アドレスが再構成されます。これにより、メンテナンス後もアプリケーションは以前と同じ IP アドレスを使用できます。データベースキャッシュは元の VM で循環されます。つまり、データベースキャッシュはメンテナンス中に実質的にクリアされます。

更新された VM への切り替えを示す図

ステップ 4

更新された VM でデータベースを起動します。

更新されたデータベースエンジンがデータディスク上で起動します。共通のデータディスクを使用すると、メンテナンス前に元のインスタンスに書き込まれたすべてのトランザクションが、メンテナンス後も更新されたデータベースで維持されます。データベースのシャットダウン中に未完了のトランザクションのロールバックが完了しなかった場合、データベースは自動的にクラッシュリカバリを行い、データベースを使用可能な状態に復元します。

更新された VM の起動を示す図

メンテナンス後

ステップ 4 を完了すると、Cloud SQL インスタンスで接続が許可され、アプリケーションへのトラフィック処理に戻ります。

アプリケーションから見ると、ソフトウェアが更新された点を除いて Cloud SQL インスタンスはまったく同じように見えます。アプリケーションは前と同じ静的 IP アドレスを使用して Cloud SQL インスタンスに接続し、更新された VM は元の VM と同じゾーンで実行されます。元のデータベースに書き込まれたデータはすべて保持されます。

メンテナンス後の図

メンテナンスの影響を最小限に抑える

一般に、Google Cloud では、クラウドでアプリケーションを実行しているユーザーは、一時的なエラー（一時的な使用不能状態による一時的なサービス間通信の問題）に対するシステムの復元力を高めることをおすすめします。時折発生する一時的なエラーはクラウドでは回避できません。

メンテナンス中に発生する一時的なエラーには、接続の切断や処理中のトランザクションの失敗などがあります。一時的なエラーが発生しても復元できるようにシステムが設計されるとともにアプリケーションが調整されている場合は、データベースのメンテナンスによる影響を最小限に抑えられる状態にあるといえます。

接続の切断による影響を最小限に抑えるには、接続プールを使用します。プーラーとデータベースの間の接続はメンテナンス中に切断されますが、アプリケーションとプーラーの間の接続は保持されます。これにより、接続の再確立がアプリケーションに対して透過的になり、接続プーラーにオフロードされます。

長時間実行トランザクションの数を制限することで、トランザクションの失敗を減らすことができます。クエリを小さくして、より効率的に書き換えることで、メンテナンスのダウンタイムが短縮されるだけでなく、データベースのパフォーマンスと信頼性も向上します。

接続の切断やトランザクションエラーから効率的に復旧するには、効率的にデータベース接続を管理します。指数バックオフを使用して、アプリケーションと接続プーラーに接続とクエリの再試行ロジックを構築できます。クエリが失敗した場合、または接続が切断された場合、システムは再試行の前に待機期間を設定します。待機時間は、後続の再試行ごとに増加します。たとえば、最初の再試行ではシステムは数秒しか待機しませんが、4 回目の再試行では最大で 1 分間待機する場合があります。このパターンに従うことで、サービスに過大な負荷をかけることなく、これらの問題を確実に修正できます。

また、スクリプトを使用したメンテナンス後のデータベースキャッシュのウォーミングや、データベース内のテーブル数の合理化など、その他のクリエイティブなソリューションにより、メンテナンスの影響を最小限に抑えることもできます。メンテナンスがスムーズに行われるように、データベース管理のベストプラクティスとオペレーションガイドラインをご確認ください。

時間的制約のあるメンテナンス

ごくまれに、Cloud SQL のメンテナンスをユーザー設定のメンテナンス期間外にスケジュールすることが必要になります。その目的は、時間的制約のある重大な安定性の問題や脆弱性にパッチを適用することです。このような更新はすみやかに配信され、Cloud SQL の SLA に対するダウンタイムとしてカウントされます。

セルフサービスメンテナンス

Cloud SQL のソフトウェアの改善とセキュリティ脆弱性に対するパッチは、定期的に新しいメンテナンスバージョンとしてリリースされており、ユーザーはこれをインスタンス上にインストールできます。Cloud SQL では、データベースエンジンのメジャーバージョンごとに Cloud SQL メンテナンス変更履歴が保持されます。詳細については、Cloud SQL メンテナンス変更履歴をご覧ください。

Cloud SQL は、最新のメンテナンスバージョンを確実にお届けするため、数か月に 1 回の頻度でメンテナンス更新を実施していますが、次の場合はセルフサービスのメンテナンスでインスタンスを最新の状態に保つことができます。

次回の定期メンテナンスイベントよりも前に更新が必要な場合。
直近のメンテナンス更新をスキップして、最新のソフトウェアを取得した場合。

リードレプリカを使用している場合は、セルフサービスメンテナンスを使用してすべてのリードレプリカを更新できます。プライマリインスタンスを指定してすると、メンテナンスリクエストにより、プライマリインスタンスのすべてのリードレプリカが指定されたメンテナンスバージョンに更新されます。その後に、プライマリインスタンスがメンテナンスバージョンに更新されます。

メンテナンスの制限事項

このセクションでは、Cloud SQL メンテナンスの制限事項について説明します。

再スケジュールの制限事項

スケジュールの変更については、次の点にご注意ください。

元の定期メンテナンスイベントが発生する 24 時間以上前にメンテナンスのスケジュールを変更する必要があります。
プロジェクトの 1 つまたは複数のインスタンスに対してメンテナンスのスケジュールを変更できます。ただし、一度に変更できるのは 1 つのインスタンスのみです（スケジュールの一括変更は使用できません）。
スケジュール変更の期間が、インスタンスに構成したメンテナンスのタイミングにより定義された期間内であれば、メンテナンスのスケジュールをメンテナンス拒否期間内だけでなくメンテナンスの時間枠外の時間にも変更できます。
メンテナンスオペレーションが実行中の場合、オペレーションが完了するまで再スケジュールが遅延します。

メンテナンス拒否期間の制限

メンテナンス拒否期間について、次のことを知っておく必要があります。

インスタンスにメンテナンスの時間枠が構成されていない場合でも、メンテナンス拒否期間を設定できます。メンテナンス拒否期間は 1～90 日の範囲で設定できます。
メンテナンス拒否期間は、予定されたメンテナンスの時間枠よりも優先されます。メンテナンスの時間枠のタイミングとメンテナンス拒否期間の間に矛盾がある場合は、メンテナンスの時間枠よりもメンテナンス拒否期間が優先されます。
メンテナンス拒否期間とメンテナンスタイミングは独立した機能です。Week 1 のメンテナンスのタイミングを持つインスタンスにメンテナンス拒否期間を作成しても、Week 2 のメンテナンスのタイミングを持つインスタンスのスケジュール設定された更新の判断には影響しません。スケジュール設定されたメンテナンス更新がメンテナンス拒否期間内にある場合、Cloud SQL は、メンテナンスのタイミングを構成したインスタンスに通知を送信しません。
プライマリインスタンスで拒否期間が設定されている場合、プライマリインスタンスに関連付けられたすべてのレプリカのメンテナンスも拒否されます。たとえば、リージョン A に配置されたプライマリインスタンスに 3 つのリードレプリカがあるとします（リージョン A に 2 つ、リージョン B に 1 つ）。プライマリインスタンスで拒否期間が設定されている場合、リージョン B のレプリカを含む各レプリカのメンテナンスは、プライマリインスタンスの拒否期間が終了するまで拒否されます。
メンテナンススケジュールが設定された後にメンテナンス拒否期間が設定され、メンテナンスの拒否期間がスケジュールされたメンテナンス時間と重複している場合、更新はスキップされます。
開始日時と終了日のパラメータに年を含めることなく、毎年のメンテナンス拒否期間を設定できます。年を指定すると、その年だけメンテナンス拒否期間が設定されます。
1 年間にメンテナンス拒否期間を複数設定できます。拒否期間を連鎖させ、スケジュールされたメンテナンスイベントを連続してスキップしないことをおすすめします。Cloud SQL のメンテナンスを最新の状態に保つことは、インスタンスを確実に動作させるうえで重要です。通常、Cloud SQL のメンテナンスは数か月に 1 回スケジュールされます。
サービスの信頼性を確保するために、Cloud SQL は、12 か月以上経過したメンテナンスリリースを実行しているインスタンスで次のメンテナンスロールアウトが必要なことをユーザーに通知します。
メンテナンス拒否期間が終了すると、通常のメンテナンス動作が再開されます。
メンテナンス拒否期間は、セルフサービスメンテナンスなど、ユーザーがトリガーしたオペレーションには影響しません。

メンテナンスに関するよくある質問

メンテナンスは従来の HA フェイルオーバーインスタンスにどのように影響しますか？
メンテナンスによるダウンタイムは SLA の対象になりますか？
メンテナンスはリードレプリカにどのように影響しますか？
定期メンテナンスをキャンセルできますか？
メンテナンスイベントがキャンセルされた場合はどうなりますか？
Cloud SQL のメンテナンスは累積的ですか？
定期メンテナンスによる更新中にインスタンスが停止した場合はどうなりますか？
プライマリインスタンスのリードレプリカすべてのセルフサービスメンテナンスにかかる時間はどれくらいですか？
プライマリインスタンスのリードレプリカが複数ある場合に、リードレプリカ 1 つだけに対してセルフサービスメンテナンスを実施できますか？

メンテナンスは従来の HA フェイルオーバーインスタンスにどのように影響しますか？

従来の HA フェイルオーバーインスタンスはメンテナンス更新のために停止されます。フェイルオーバーインスタンスは、プライマリインスタンスの直前にメンテナンス更新を受け取ります。従来の HA フェイルオーバーインスタンスは、プライマリインスタンスのメンテナンスの時間枠を共有するため、メンテナンスの時間枠を直接設定できません。

メンテナンスによるダウンタイムは SLA の対象になりますか？

通常のメンテナンスによるダウンタイムは SLA の対象になりません。ただし、Cloud SQL では、時間的制約のあるメンテナンスによるダウンタイムが SLA の対象となります。

メンテナンスはリードレプリカにどのように影響しますか？

Cloud SQL は、プライマリインスタンスの前にリードレプリカを常に保持します。プライマリインスタンスにメンテナンスの時間枠がある場合、リードレプリカは同じメンテナンスの時間枠に従います。
プライマリインスタンスに複数のリードレプリカがある場合、Cloud SQL は一部のレプリカを同時に更新することがあります。
リードレプリカは、プライマリインスタンスに対して設定されているメンテナンス拒否期間に従います。

定期メンテナンスをキャンセルできますか？

スケジュール設定されたメンテナンスの時間枠はキャンセルできませんが、スケジュールの変更は可能です。また、定期メンテナンスと重複するメンテナンス拒否期間を構成すると、メンテナンスを効果的にスキップできます。

メンテナンスイベントがキャンセルされた場合はどうなりますか？

Cloud SQL でメンテナンスイベントがキャンセルされると、可能であれば事前に、メンテナンスがキャンセルされたという通知がユーザーに送られます。

メンテナンスイベントのスケジュールが変更されたときは、次回のメンテナンスについての新しい通知がユーザーに送られます。

Cloud SQL のメンテナンスは累積的ですか？

メンテナンス更新は累積的です。実施しなかった可能性のある各メンテナンスの更新を適用する必要はありません。次回の定期メンテナンス更新で、最新のメンテナンスバージョンが適用されます。または、セルフサービスメンテナンスを使用して最新のメンテナンス更新を適用することもできます。

定期メンテナンスによる更新中にインスタンスが停止した場合はどうなりますか？

定期メンテナンスによる更新中にインスタンスが停止した場合、Cloud SQL はメンテナンス更新をスキップします。ただし、次回インスタンスを再起動したときに、Cloud SQL は最新のメンテナンス更新でインスタンスを自動的に更新します。

プライマリインスタンスのリードレプリカすべてのセルフサービスメンテナンスにかかる時間はどれくらいですか？

セルフサービスメンテナンス更新の所要時間は、プライマリインスタンスのリードレプリカの総数によって異なります。セルフサービスメンテナンス更新の所要時間を短縮するには、いくつかのリードレプリカを個別に更新してから、プライマリインスタンスの更新を実行することによって、残りのリードレプリカを更新します。

2 回目の更新では、ターゲットメンテナンスバージョンがすでに適用されているレプリカはスキップされます。

プライマリインスタンスのリードレプリカが複数ある場合に、リードレプリカ 1 つだけに対してセルフサービスメンテナンスを実施できますか？

はい。セルフサービスメンテナンスは個々のリードレプリカインスタンスに対して実施できます。ただし、残りのリードレプリカとプライマリインスタンスも、その後すぐに同じメンテナンスバージョンに更新することをおすすめします。すべてのリードレプリカとプライマリインスタンスを、同一のメンテナンスバージョンで運用することをおすすめします。