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

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

概要

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

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

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

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

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

メンテナンスへの影響

メンテナンス イベント中の Cloud SQL for PostgreSQL インスタンスの平均切断時間は 30 秒未満です。

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

メンテナンス中のアクティビティが多いインスタンスや、非常に大規模なデータセットを持つインスタンスの場合、ダウンタイムが長くなる可能性があります。Cloud SQL は通常、数か月に一度の頻度でメンテナンスを行います。

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

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

「ダウンタイムがほぼゼロの計画的メンテナンス」を利用できる 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 がメンテナンスをスケジュールする曜日と時間。メンテナンスの時間枠は 1 時間です。メンテナンスの時間枠の構成方法を確認してください。

  • 更新の順序。Cloud SQL インスタンスの更新順序を、同じリージョン内の他のインスタンスとの相対的な順序で設定します。更新の順序は、AnyEarlierLater のいずれかに設定できます。Later インスタンスは、同じリージョンで同じメンテナンスの時間枠を持つ Earlier インスタンスから 1 週間後に更新されます。更新の順序は、メンテナンスの時間枠を構成する際に設定します。

  • メンテナンス拒否期間。Cloud SQL がメンテナンスをスケジュールしない日数のブロック。メンテナンス拒否期間は最長 90 日間まで設定できます。メンテナンス拒否期間の構成方法をご確認ください。

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

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

  • 平日(月~金): 午後 10 時~午前 6 時
  • 週末: 金曜日の午後 10 時~月曜日の午前 6 時

メンテナンスの例

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

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

  • メンテナンスの時間枠: 日曜午前 12 時~午前 1 時(米国東部時間)
  • 更新の順序: Later
  • メンテナンス拒否期間: 11 月 1 日から 1 月 15 日。

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

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

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

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

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

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

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

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

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

インスタンスのメンテナンスの時間枠が設定されている場合、メンテナンスが現在スケジュールされている時刻以前に、いつでもメンテナンスのスケジュールを変更できます。たとえば、現在スケジュールされているメンテナンス時間内に新しいサービスをリリースする場合は、メンテナンスの時間枠をリリースの数日後に変更することをおすすめします。

元のスケジュール日時から 28 日以内であれば、メンテナンスのスケジュールを複数回変更できます。

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

  • すぐに更新を適用する。定期メンテナンスの時間枠を待つのではなく、更新をすぐにインスタンスに適用できます。この場合、通常 5 分以内にメンテナンスが開始されます。
  • スケジュールを別の時間に変更する。スケジュールが設定されたメンテナンス イベントは、次の 2 つの方法で延期できます。

    • 次回の利用可能な時間枠。このオプションでは、現在の定期メンテナンス時刻から次に利用可能なメンテナンスの時間枠までメンテナンスを延期します(通常は 1 週間後)。
    • 特定の時間。このオプションでは、元の定期メンテナンス時刻から 28 日以内の特定の時間を選択できます。

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

メンテナンスの仕組み

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

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

  1. 新しいソフトウェアで更新後の VM を設定します。
  2. 元の VM を停止します。
  3. ディスクと静的 IP を更新後の VM に切り替えます。
  4. 更新された 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 つのインスタンスのみです(スケジュールの一括変更は使用できません)。

  • 再スケジューリングの期限内(28 日間)であれば、メンテナンスのスケジュールを、メンテナンス拒否期間だけでなくメンテナンスの時間枠外にも変更できます。

  • メンテナンス オペレーションが進行中の場合は、再スケジュールはそのオペレーションが完了するまで延期されます。

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

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

  • インスタンスにメンテナンスの時間枠が構成されていない場合でも、メンテナンス拒否期間を設定できます。メンテナンス拒否期間は 1~90 日の範囲で設定できます。

  • メンテナンス拒否期間は、予定されたメンテナンスの時間枠よりも優先されます。メンテナンスの時間枠のタイミングとメンテナンス拒否期間の間に矛盾がある場合は、メンテナンスの時間枠よりもメンテナンス拒否期間が優先されます。

  • メンテナンス拒否期間と相対スケジューリングは独立した機能です。Earlier インスタンスで指定されたメンテナンス拒否期間は、Later インスタンスのスケジュール決定には影響しません。メンテナンスのスケジュールが Earlier インスタンスまたは Later インスタンスのメンテナンス拒否期間内である場合、通知は送信されません。

  • プライマリ インスタンスで拒否期間が設定されている場合、プライマリ インスタンスに関連付けられたすべてのレプリカのメンテナンスも拒否されます。たとえば、リージョン A に配置されたプライマリ インスタンスに 3 つのリードレプリカがあるとします(リージョン A に 2 つ、リージョン B に 1 つ)。プライマリ インスタンスで拒否期間が設定されている場合、リージョン B のレプリカを含む各レプリカのメンテナンスは、プライマリ インスタンスの拒否期間が終了するまで拒否されます。

  • メンテナンス スケジュールが設定された後にメンテナンス拒否期間が設定され、メンテナンスの拒否期間がスケジュールされたメンテナンス時間と重複している場合、更新はスキップされます。

  • 開始日時と終了日のパラメータに年を含めることなく、毎年のメンテナンス拒否期間を設定できます。年を指定すると、その年だけメンテナンス拒否期間が設定されます。

  • 1 年間にメンテナンス拒否期間を複数設定できます。拒否期間を連鎖させ、スケジュールされたメンテナンス イベントを連続してスキップしないことをおすすめします。Cloud SQL のメンテナンスを最新の状態に保つことは、インスタンスを確実に動作させるうえで重要です。通常、Cloud SQL のメンテナンスは数か月に 1 回スケジュールされます。

  • サービスの信頼性を確保するために、Cloud SQL は、12 か月以上経過したメンテナンス リリースを実行しているインスタンスで次のメンテナンス ロールアウトが必要なことをユーザーに通知します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ