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

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

概要

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

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

• Cloud SQL の機能。新しい機能をリリースするために、データベース エンジンが更新され、データベースへの新しいプラグインがインストールされます。

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

• オペレーティング システムのパッチ。Google では、オペレーティング システムに存在する新たなセキュリティ脆弱性を継続的に監視しています。こうした脆弱性が見つかると、オペレーティング システムにパッチを適用し、新たなリスクからシステムを保護します。

メンテナンスへの影響

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

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

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

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

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

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

前提条件と制約

• Cloud SQL for PostgreSQL Enterprise Plus エディション インスタンスのリードレプリカの数は、max_wal_senders フラグと max_replication_slots フラグに設定された値よりも小さくする必要があります。詳細については、データベース フラグを構成するをご覧ください。

• Cloud SQL Auth Proxy または Cloud SQL 言語コネクタを使用している場合は、最新バージョンに更新されていることを確認してください。

• ログに記録されていないテーブルは、計画的メンテナンス後に空になります。

• メンテナンス中、データベース ログには 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」というメッセージと、メンテナンスの開始日時が表示されます。

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

インスタンスにメンテナンスの時間枠を設定している場合、メンテナンス更新実施が予定されている時刻の 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 では、高可用性インスタンスの自動フェイルオーバー ワークフローにほぼ同じメンテナンス フェイルオーバー ワークフローが使用されます。

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

1. 新しいソフトウェアで更新後の VM を設定します。
2. 元の VM でデータベースを停止します。
3. ディスクと静的 IP を更新後の VM に切り替えます。
4. 更新された 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 か月以上経過したメンテナンス リリースを実行しているインスタンスで次のメンテナンス ロールアウトが必要なことをユーザーに通知します。

• メンテナンス拒否期間が終了すると、通常のメンテナンス動作が再開されます。

• メンテナンス拒否期間は、セルフサービス メンテナンスなど、ユーザーがトリガーしたオペレーションには影響しません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ

• メンテナンス通知を設定する方法を確認する。
• メンテナンスの時間枠を設定する方法を確認する。
• メンテナンス通知を表示する方法を確認する。