Cloud SQL インスタンスでのメンテナンスの概要

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

メンテナンスとは

Cloud SQL インスタンスでは、バグの修正、セキュリティ侵害の防止、アップグレードの実施のために更新情報が必要です。更新を適用すると、Cloud SQL でインスタンスが再起動され、サービスが中断される可能性があります。メンテナンス中、HA プライマリ インスタンスがスタンバイ インスタンスにフェイルオーバーすることはありません。

本番環境の更新の詳細については、リリースノートをご覧ください。

メンテナンスの時間枠とは

メンテナンスの時間枠とは、Cloud SQL でこのメンテナンスの実行スケジュールを設定する時間のブロックのことです。

今後のメンテナンスの更新情報に関する通知を受け取るには、次の両方を行う必要があります。

優先される時間枠を指定しない場合は、いつでも中断更新が発生する可能性があります(ただし、発生頻度は通常、数か月ごとです)。

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

ほとんどのメンテナンス オペレーションでは、お客様が定義したメンテナンスの時間枠を確認できますが、時間的制約のある脆弱性に対するパッチなどの重要なサービスの更新は確認できない可能性があります。こうした更新はすぐにロールアウトされ、Cloud SQL では SLA に対するダウンタイムとしてカウントされるためです。

インスタンスで優先されるメンテナンスの時間枠を設定するにはどうすればよいですか?

選択した曜日と時間、インスタンスの更新順序でメンテナンスのスケジュールが設定されます。これらのオプションは、[優先ウィンドウ] と [更新の順序] の設定を使用してインスタンスで構成します。

インスタンスに対して [優先ウィンドウ] を構成すると、Cloud SQL で時間枠以外の時間にそのインスタンスに対する更新を開始しません。メンテナンスは数か月ごとに行われ、通常数分以内に完了します。優先ウィンドウ以外の時間枠では開始されないことが保証されます。メンテナンスが優先ウィンドウ内で完了するとは限りません。優先ウィンドウは UTC で定義されます。そのため、夏時間の変更は優先ウィンドウに適用されません。ローカル時間の変更を確認するには、優先ウィンドウを再構成する必要があります。

更新の順序の構成時に、ダウンタイムを引き起こす可能性のあるインスタンス更新の相対的なタイミングが設定されます。タイミング オプションは、[おまかせ]、[早め]、[遅め] です。すべてのインスタンスがまったく同じ更新を受け取ります。違いは、遅めのインスタンスは、早めのインスタンスが更新されてから 1 週間後に更新を受け取ることです。単一のインスタンスで早めに更新を受け取ると、残りのインスタンスを更新する前に、更新を適用したアプリケーションをテストできます。

更新の相対的なタイミングは、プロジェクト間やリージョン間では認識されません。そのため、タイミング設定が早めになっているインスタンスがタイミング設定が遅めになっているインスタンスとは別のプロジェクトまたは別のロケーション(別のリージョンなど)に属している場合、Cloud SQL では、タイミング設定が早めになっているインスタンスの更新が先に行われるとは限りません。

更新の順序を設定しない場合、インスタンスに対する更新のタイミングは Cloud SQL により選択されます(優先ウィンドウが指定されている場合はその範囲内で)。

[更新の順序] の設定内容によって、インスタンスに適用されるソフトウェア バージョンが変わることはありません。

メンテナンスの優先ウィンドウを設定するには、インスタンスの優先されるメンテナンスの時間枠を設定するをご覧ください。

メンテナンスはリードレプリカやフェイルオーバー インスタンスにどのように影響しますか?

リードレプリカは、メンテナンス更新時には停止されます。更新が行われるタイミングは保証されておらず、更新はプライマリ インスタンスの更新と重複したり、非常に近いタイミングで行われたりすることがあります。フェイルオーバー インスタンスは、メンテナンス更新のために停止されます。フェイルオーバー インスタンスは、プライマリ インスタンスの直前にメンテナンス更新を受け取ります。フェイルオーバー インスタンスは、プライマリ インスタンスのメンテナンスの時間枠を共有するため、メンテナンスの時間枠を直接設定できません。

メンテナンス シャットダウンを処理するための推奨設計はありますか?

メンテナンス シャットダウンなどでインスタンスに短時間アクセスできなくなる状況に対処できるようにアプリケーションを設計することをおすすめします。メンテナンス シャットダウン中にアプリケーションの動作をテストするには、インスタンスを再起動してください。一般に、短時間だけ有効な接続と、拒否された接続を再試行するための指数的バックオフを使用することをおすすめします。

詳しいガイダンスについては、接続を管理するにはどうすればよいですか?をご覧ください。

メンテナンス通知を受け取るにはどうすればよいですか?

メンテナンス通知はデフォルトでは送信されません。メンテナンス通知を受け取るには、Cloud Console の [通信] ページで [Cloud SQL] の [メンテナンスの時間枠] オプションを設定し、[メール] で [オン] を選択する必要があります。通知はメールでのみ受信できます。また、通知を受信するには、メンテナンスの時間枠も選択する必要があります。

メンテナンス通知は、インスタンス レベルではなくプロジェクト レベルで設定されます。メール通知は Google アカウントに関連付けられているメールアドレスに送信されます。チームのメール エイリアスなどのカスタムメール エイリアスは構成できません。

メンテナンス通知を受け取るには、メンテナンス通知をオプトインするをご覧ください。

今後のメンテナンスについての詳細はどこで確認できますか?

メールでのメンテナンス通知の受信に登録すると、通知はメンテナンス予定日の 1 週間前にメールで送信されます。通知のメールフィルタを設定する場合、メールのタイトルは「Cloud SQL インスタンス(インスタンス名)の今後のメンテナンス」となります。

また、インスタンスの更新スケジュールが設定されているかどうかは、Console 内の次の場所で確認できます。

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

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

Cloud SQL でメンテナンス イベントがキャンセルされると、メンテナンスがキャンセルされたという通知を受け取ります。まれに、Cloud SQL で事前にキャンセル通知が送信されないことがあります。この場合、スケジュールが設定されているメンテナンスの時間枠が経過した後、メンテナンスが適用されなかったことが通知されます。

メンテナンス イベントのスケジュールが変更されると、新しいメンテナンス通知を受け取ります。

メンテナンスのスケジュールを変更するにはどうすればよいですか?

メンテナンス通知を受け取ったら、メンテナンスの時間枠を変更することもできます。たとえば、サービス リリースの開始が予定されている場合、リリース前後の数日間にメンテナンスの時間枠を変更できます。

メンテナンスのスケジュールを変更するには、[インスタンス] リストページをご覧ください。[メンテナンス] 列には、定期メンテナンスの日時が表示されます。同じ列には、メンテナンスのスケジュール変更に使用する [日時を変更] ボタンがあります。

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

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

    • 次回の利用可能な時間枠。これにより、メンテナンスの時間枠は一度に 1 週間移動し、メンテナンスのスケジュール変更はイベントごと、インスタンスごとに最大 1 回です。
    • 特定の時間。このオプションでは、元の定期メンテナンスの 1 週間以内の新しい時間を選択できます。

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

  • 元の定期メンテナンス イベントが発生する 24 時間以上前にメンテナンスのスケジュールを変更する必要があります。

  • プロジェクトの 1 つまたは複数のインスタンスに対してメンテナンスのスケジュールを変更できます。ただし、一度に変更できるのは 1 つのインスタンスのみです(スケジュールの一括変更は使用できません)。

  • 変更をすぐに適用する場合など、メンテナンスの時間枠を複数回変更することはできません。

  • 時間が 1 週間の再スケジューリングの制限範囲内であれば、メンテナンスのスケジュールを、メンテナンス不要期間だけでなくメンテナンスの時間枠外にも変更できます。

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

メンテナンス期間を拒否する

メンテナンス期間を拒否すると、特定の期間の自動メンテナンスを回避できます。たとえば、年末年始のホリデー シーズンは、負荷がピークに達する時期であり、多くの小売業のインフラストラクチャの安定性に重点を置く必要があります。これらの企業は、10 月中旬から 1 月中旬までのメンテナンス拒否期間を設定することで、1 年で最も忙しい時期に Cloud SQL から計画されたアップグレードを拒否できます。

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

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

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

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

メンテナンス拒否期間を構成する方法をご確認ください。

次のステップ