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

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

概要

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

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

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

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

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

メンテナンスへの影響

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

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

メンテナンスの設定

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 コンソールで今後のメンテナンス情報を確認することもできます。

• [インスタンス] リストの [メンテナンス] 列。メンテナンスのスケジュール設定されている場合、メンテナンスの開始日時が表示されます。「メンテナンス」という用語を使用して [インスタンス] リストをフィルタすると、メンテナンスのスケジュールが設定されているすべてのインスタンスを検索できます。[メンテナンス] 列は、プロジェクト内の 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 は、メンテナンス更新を数か月ごとにスケジュールして、最新ソフトウェアの使用を保証しますが、次の場合は、セルフサービスのメンテナンスでインスタンスを最新の状態に保つことができます。

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

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

メンテナンスの制限事項

このセクションでは、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 つだけに対してセルフサービス メンテナンスを実施できますか？

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

次のステップ

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