---

MySQL HeatWaveのメンテナンス概要

MySQL HeatWaveではセキュリティやパフォーマンス・安定性維持のため、基本的に1ヶ月に1回のメンテナンスが実施されます。

このメンテナンスでは、以下のような作業が行われます。

• OSへのパッチ適用
• データベース・バージョンのアップグレード（設定条件にマッチした場合）
• ハードウェア/仮想マシン・ハイパーバイザのファームウェア更新

これらはHeatWaveクラスタを有効にしているかどうかに関係なく実施されます。

なお、メンテナンス中は高可用性構成でも短時間のダウンタイムが発生します。

メンテナンス通知について

メンテナンスがある場合、約半月前にOCIから通知が届きます。

実はこの通知、2種類あるんです。以下にその2種類の通知のキャプチャを示します。

1つ目の通知は、お知らせサービスでサブスクリプションを作成している場合に届くお知らせの抜粋です。

メンテナンス期間が1週間示され、「この期間のうち、メンテナンス・ウィンドウで設定されている時間帯にメンテナンスが実施されますよ」という形の通知になっています。

2つ目の通知は、MySQL HeatWave側で通知を設定している場合に届くお知らせです。

こちらはメンテナンス・ウィンドウの時間も考慮して「この時間にメンテナンスが実施されますよ」という形の通知になっています。

MySQL HeatWave側の通知の方がメンテナンス実施時間まで記載があり親切かつ見やすいのでおすすめですが、逆にメンテナンス期間がメールに表示されていないという欠点もあります。

ただしOCIコンソールログイン後にお知らせを確認すればメンテナンス期間は確認できるため、運用方針によって「MySQL HeatWave側の通知のみ受信」or「両方受信」を使い分けるのがいいかもしれません。

MySQL HeatWave側の通知設定方法ですが、既存のDBシステムの場合は、OCIコンソールのDBシステム詳細画面で[顧客の連絡先] の [管理]から遷移する画面で[連絡先の追加]を選択しメールアドレスを登録すればOKです。

新規DBシステム作成時は[運用上の通知およびお知らせ用の連絡先を指定してください]という項目でメールアドレスを入力し追加すればOKです。

※最大10件のメールアドレスを登録可能です。

設定後すぐに、登録したメールアドレス宛に確認メールが送付されます。

[Subscribe]を押下して[Successfully subscribed!]と表示されれば設定は完了です。

データベース・バージョンのアップグレードについて

MySQL HeatWaveでは、メンテナンス時にデータベース・バージョンのアップグレードが実行される場合があります。 アップグレードの有無は、利用中のMySQLバージョンの状態とアップグレード・ポリシーの設定によって決まります。

バージョンの状態によるアップグレード

利用中のMySQLバージョンが Oracle により 「使用不可（Disabled）」 と判定された場合、 アップグレード・ポリシーの設定に関わらず、 次回のメンテナンス時にサポートされているバージョンへアップグレードされます。

各データベース・バージョンのサポート状況や、使用不可となる日付については、 公式ドキュメントの サポートスケジュール をご確認ください。

アップグレード・ポリシーによる制御

2025年10月のアップデート以降、MySQL HeatWaveでは アップグレード・ポリシーを細かく設定できるようになりました。

アップグレード・ポリシーで設定できるコンポーネントは以下のとおりです。

• スケジュール・タイプ

早期 / 定期（デフォルト）から選択できます。

「早期」を選択した場合と、「定期」を選択した場合で、バージョンアップのタイミングが異なります。

スケジュール・タイプ	バージョンアップのタイミング
早期	データベース・バージョンが「非推奨（Deprecated）」 となった時点
定期	データベース・バージョンが「使用不可（Disabled）」 となった時点

• バージョン・プリファレンス

最新 / 2番目に新しい / 最古（デフォルト）から選択できます。 選択したバージョン・トラック内で、指定した条件に合致する データベース・バージョンへアップグレードされます。

• バージョン・トラック・プリファレンス

革新 / 長期サポート / フォロー（デフォルト）から選択できます。 指定したバージョン・トラックに基づいて、 アップグレード先のデータベース・バージョンが決定されます。

※本番環境では、意図しないタイミングでの自動アップグレードを避けるため、事前検証用の環境でアップグレードを試したうえでポリシーを有効化する運用を推奨します。

通常、非推奨→使用不可になるまでは2〜3ヶ月の猶予がありますので、例えば、以下のように環境ごとにスケジュール・タイプをずらして設定することで「検証先行 → 本番追従」の流れを実現できます。

• 検証環境：スケジュール・タイプを「早期」に設定
  新バージョンをいち早く試してアプリケーション互換性を確認
• 本番環境：スケジュール・タイプを「定期」に設定（デフォルト）
  検証完了後に安全にアップグレード

このようにアップグレード・ポリシーを適切に設定することで、どのバージョン・トラックの、どこまで新しいバージョンに、どのタイミングでアップグレードを実施するかを制御できます。 運用方針に合わせて設定を見直しておくことが重要です。

メンテナンスの終了を通知で受け取る

メンテナンス後にはシステムの動作確認を行うという運用をされている方も多いかと思います。

また、時折予定されていたメンテナンスがリスケジュールされる場合もあります。

そんな場合にはメンテナンスの終了（メンテナンス期間の終了ではなく、メンテナンス自体の終了）を通知で受け取る設定をしておくと便利です。

設定はとても簡単で、イベント・サービスで

com.oraclecloud.mysqlaas.upgradedbsystem.end

というタイプのイベントを拾って通知に流してあげるだけです。

※メンテナンスの開始を通知したい場合は

com.oraclecloud.mysqlaas.upgradedbsystem.begin

に対して同様に設定すればOKです。

さいごに

今回は、MySQL HeatWaveのメンテナンスにフォーカスしてTipsを紹介していきましたが、いかがでしたでしょうか。

ご紹介した中には多少マニアックな情報もありますが、覚えておいて損はないと思います。

特にアップグレード・ポリシーについては直近のアップデートで追加された機能なので知らずに全てデフォルトで運用されている方も多いのではないでしょうか。

ぜひ適切に設定し、運用負荷を少しでも減らしていただければと思います。

以上、最後までご覧いただきありがとうございました。