このページでは、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 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 では、高可用性インスタンスの自動フェイルオーバー ワークフローにほぼ同じメンテナンス フェイルオーバー ワークフローが使用されます。
簡単に説明すると、次のような手順になります。
- 新しいソフトウェアで更新後の VM を設定します。
- 元の VM でデータベースを停止します。
- ディスクと静的 IP を更新後の VM に切り替えます。
- 更新された VM でデータベースを起動します。
以下のタブの手順に沿って、メンテナンスの前後を含むワークフローの詳細を確認します。
メンテナンス前
メンテナンス前は、クライアントは静的 IP アドレスを使用して元の VM と通信しています。データは、元の VM にアタッチされている永続ディスクに保存されます。この例では、Cloud SQL インスタンスは高可用性で構成されています。これは、計画外の停止が発生した場合に引き継ぐために、別の VM がスタンバイ状態にあることを意味します。Cloud SQL インスタンスは、アプリケーションへのトラフィックを処理しています。
ステップ 1
新しい VM を設定します。
新しい仮想マシン（VM）に、最新のデータベース ソフトウェアと VM オペレーティング システム（OS）が設定されます。更新された VM OS が起動します。この時点では、データベース エンジンはまだ起動していません。高可用性インスタンスの場合、新しいスタンバイ VM も設定されます。
元の Cloud SQL インスタンスがトラフィックを処理している間、別の VM にソフトウェアの更新をインストールすることで、合計のダウンタイムが大幅に短縮されます。
ステップ 2
元の VM でデータベースを停止します。
データベース エンジンがシャットダウンされるため、ディスクは元の VM から切断され、更新された VM にアタッチされます。データベース エンジンは、進行中のトランザクションが commit され、既存の接続からのリクエストがドレインされるまで数秒待機してからシャットダウンされます。その後、オープンまたは長時間実行されているトランザクションはロールバックされます。データベースは新しい接続を受け付けなくなり、既存の接続は破棄されます。インスタンスが利用できなくなり、メンテナンスのダウンタイムが開始されます。
ステップ 3
更新された VM に切り替えます。
ディスクが元の VM から切断され、更新された VM にアタッチされます。更新された VM を参照するように静的 IP アドレスが再構成されます。これにより、メンテナンス後もアプリケーションは以前と同じ IP アドレスを使用できます。データベース キャッシュは元の VM で循環されます。つまり、データベース キャッシュはメンテナンス中に実質的にクリアされます。
ステップ 4
更新された 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 か月以上経過したメンテナンス リリースを実行しているインスタンスで次のメンテナンス ロールアウトが必要なことをユーザーに通知します。
メンテナンス拒否期間が終了すると、通常のメンテナンス動作が再開されます。
メンテナンス拒否期間は、セルフサービス メンテナンスなど、ユーザーがトリガーしたオペレーションには影響しません。
メンテナンスに関するよくある質問
- メンテナンスによるダウンタイムは SLA の対象になりますか？
- メンテナンスはリードレプリカにどのように影響しますか？
- 定期メンテナンスをキャンセルできますか？
- メンテナンス イベントがキャンセルされた場合はどうなりますか？
- Cloud SQL のメンテナンスは累積的ですか？
- 定期メンテナンスによる更新中にインスタンスが停止した場合はどうなりますか？
- プライマリ インスタンスのリードレプリカすべてのセルフサービス メンテナンスにかかる時間はどれくらいですか？
- プライマリ インスタンスのリードレプリカが複数ある場合に、リードレプリカ 1 つだけに対してセルフサービス メンテナンスを実施できますか？
メンテナンスによるダウンタイムは SLA の対象になりますか？
通常のメンテナンスによるダウンタイムは SLA の対象になりません。ただし、Cloud SQL では、時間的制約のあるメンテナンスによるダウンタイムが SLA の対象となります。
メンテナンスはリードレプリカにどのように影響しますか？
- Cloud SQL は、プライマリ インスタンスの前にリードレプリカを常に保持します。プライマリ インスタンスにメンテナンスの時間枠がある場合、リードレプリカは同じメンテナンスの時間枠に従います。
- プライマリ インスタンスに複数のリードレプリカがある場合、Cloud SQL は一部のレプリカを同時に更新することがあります。
- リードレプリカは、プライマリ インスタンスに対して設定されているメンテナンス拒否期間に従います。
定期メンテナンスをキャンセルできますか？
スケジュール設定されたメンテナンスの時間枠はキャンセルできませんが、スケジュールの変更は可能です。また、定期メンテナンスと重複するメンテナンス拒否期間を構成すると、メンテナンスを効果的にスキップできます。
メンテナンス イベントがキャンセルされた場合はどうなりますか？
Cloud SQL でメンテナンス イベントがキャンセルされると、可能であれば事前に、メンテナンスがキャンセルされたという通知がユーザーに送られます。
メンテナンス イベントのスケジュールが変更されたときは、次回のメンテナンスについての新しい通知がユーザーに送られます。
Cloud SQL のメンテナンスは累積的ですか？
メンテナンス更新は累積的です。実施しなかった可能性のある各メンテナンスの更新を適用する必要はありません。次回の定期メンテナンス更新で、最新のメンテナンス バージョンが適用されます。または、セルフサービス メンテナンスを使用して最新のメンテナンス更新を適用することもできます。
定期メンテナンスによる更新中にインスタンスが停止した場合はどうなりますか？
定期メンテナンスによる更新中にインスタンスが停止した場合、Cloud SQL はメンテナンス更新をスキップします。ただし、次回インスタンスを再起動したときに、Cloud SQL は最新のメンテナンス更新でインスタンスを自動的に更新します。
プライマリ インスタンスのリードレプリカすべてのセルフサービス メンテナンスにかかる時間はどれくらいですか？
セルフサービス メンテナンス更新の所要時間は、プライマリ インスタンスのリードレプリカの総数によって異なります。セルフサービス メンテナンス更新の所要時間を短縮するには、いくつかのリードレプリカを個別に更新してから、プライマリ インスタンスの更新を実行することによって、残りのリードレプリカを更新します。
2 回目の更新では、ターゲット メンテナンス バージョンがすでに適用されているレプリカはスキップされます。
プライマリ インスタンスのリードレプリカが複数ある場合に、リードレプリカ 1 つだけに対してセルフサービス メンテナンスを実施できますか？
はい。セルフサービス メンテナンスは個々のリードレプリカ インスタンスに対して実施できます。ただし、残りのリードレプリカとプライマリ インスタンスも、その後すぐに同じメンテナンス バージョンに更新することをおすすめします。すべてのリードレプリカとプライマリ インスタンスを、同一のメンテナンス バージョンで運用することをおすすめします。
次のステップ
- メンテナンス通知を設定する方法を確認する。
- メンテナンスの時間枠を設定する方法を確認する。
- メンテナンス通知を表示する方法を確認する。