MySQL HeatWave高可用性環境をMySQL 8.0.46からMySQL 8.4 LTSへアップグレードする

原文：Upgrading MySQL HeatWave High Availability from MySQL 8.0.46 to MySQL 8.4 LTS

原著者：Tony Darnell

本記事は、上記の英語記事をAIを使用して日本語に翻訳したものです。翻訳には誤訳や不正確な表現が含まれる可能性があります。内容の確認にあたっては英語原文を参照してください。

大規模な本番環境に向けた計画、互換性テスト、性能検証、アプリケーションの準備、ロールバック戦略

MySQL 8.0は、最終リリースであるバージョン8.0.46とともに、2026年4月に正式なサポート終了（EOL）を迎えました。ただし、ホスティング環境によっては特定のサポート延長が利用できます。オラクルはMySQL HeatWaveのMySQL 8.0インスタンスのサポートを2027年4月まで延長しており、その間、既存の8.0インスタンスはすべての機能を引き続き利用でき、重要なセキュリティ・パッチも提供されます。しかし、4月はすぐにやってきます。まだ8.0.46を使用している場合に、アップグレードに向けて検討すべき事項をご紹介します。本記事では、高可用性を利用しているMySQL HeatWaveインスタンスのアップグレードに焦点を当てます。

本番データベースを新しいメジャー・バージョンへアップグレードするには、通常のパッチ更新より入念な計画が必要です。データベースの可用性、アプリケーションの互換性、性能、ロールバック時間をすべて考慮する必要がある、大規模なMySQL HeatWave環境では特に重要です。

本記事では、Oracle Cloud Infrastructure（OCI）上のMySQL HeatWave High Availability（HA）DBシステムを、MySQL 8.0.46からMySQL 8.4 LTSへアップグレードする際の推奨アプローチを説明します。例では大規模な本番データベースとして6 TBを想定しますが、同じプロセスを小規模なHA環境にも適用できます。

執筆時点で、MySQL HeatWaveはMySQL 8.4.11 LTSをサポートしています。繰り返しになりますが、MySQL 8.0は2026年4月にEOLを迎えたため、既存の8.0環境では、8.4 LTSリリースへの移行がライフサイクル上の重要な検討事項となります。

単にデータベースのアップグレードを完了することを目標にしてはいけません。次の4つの重要な問いに答えながら、アップグレードを実施することが目標です。

1. 既存のデータベースはMySQL 8.4と互換性がありますか。
2. アプリケーションは引き続き正しく動作しますか。
3. 性能は期待する範囲に収まりますか。
4. 重大な問題が発生した場合のリカバリ手順はどうなりますか。

図1 — MySQL HeatWave 8.0から8.4 LTSへのアップグレード概要

高可用性によってアップグレードのアプローチが変わる理由

MySQL HeatWave High Availability（HA）DBシステムは、1つのプライマリと2つのセカンダリ、計3つのMySQLインスタンスで構成されます。アプリケーションはプライマリのエンドポイントに接続し、プライマリに書き込まれたデータはセカンダリにレプリケートされます。

HA DBシステムの場合、オラクルはアップグレードをローリング方式で実施します。リード・レプリカがあれば最初にアップグレードし、続いてセカンダリをアップグレードします。プライマリは最後にアップグレードします。

HA DBシステムの制御された2フェーズのアップグレードもサポートします。この機能では、既存のプライマリをオンラインに保ちながら、フェーズ1でセカンダリとリード・レプリカをアップグレードできます。その後、管理者がフェーズ2の開始時点、つまりプライマリのエンドポイントに短時間の中断が発生する時点を決定します。

フェーズ2では、プライマリへの既存接続が閉じられ、プライマリがグループから離脱し、アップグレード済みのセカンダリの1つがプライマリに昇格します。アプリケーションは新たに昇格したプライマリへ再接続する必要があります。これを短時間のダウンタイムと説明しています。

この2フェーズのプロセスにより、運用上有用なチェックポイントが得られます。

フェーズ1は、アップグレードを続行するか中止するかを判断する最適な時点です。

セカンダリのアップグレードが成功しない場合や、HAシステムが正常な状態に戻らない場合は、フェーズ2に進まないでください。

図2 — 高可用性アップグレードのワークフロー

MySQL 8.0と8.4の変更点を理解する

アップグレード前に、スキーマ、アプリケーション、デプロイ・ツール、運用スクリプト、クライアント・ソフトウェアに影響する可能性がある変更を確認してください。

MySQL ShellのUpgrade Checkerは多くの互換性の問題を自動検出しますが、アプリケーション・チームも主要な違いを理解しておく必要があります。

認証の変更

最も重要な変更の1つが認証に関するものです。

MySQL 8.4では、default_authentication_pluginサーバー変数が削除され、caching_sha2_passwordがデフォルトの認証方式となっています。古いmysql_native_passwordプラグインは非推奨で、デフォルトでは無効です。

MySQL HeatWaveでは、8.0から8.4へのアップグレード時に互換性を保護する仕組みがあります。既存アカウントがmysql_native_passwordを使用している場合、HeatWaveはそのプラグインを有効にし、既存ユーザーが引き続き認証できるようにします。ただし、後続のMySQLメジャー・バージョンではmysql_native_passwordが削除されるため、オラクルではそれらのアカウントをcaching_sha2_passwordに移行することを推奨しています。

アップグレード前に、アプリケーション・アカウントが使用している認証プラグインを特定します。

SELECT user, host, plugin 
FROM mysql.user 
ORDER BY plugin, user;

古いデータベース・ドライバを使用するアプリケーションは、caching_sha2_passwordとの組合せを特にテストしてください。

新しいキーワードと予約語

MySQL 8.4系列では、次を含む新しいSQLキーワードが導入されました。ただし、これらだけに限られるとは限りません。

MANUAL、PARALLEL、QUALIFY、TABLESAMPLE。

バージョン固有の重要な点があります。現在のMySQL 8.4.11リリースでは、MANUALとPARALLELは非予約語となりましたが、QUALIFYとTABLESAMPLEは引き続き予約語です。それ以前の8.4パッチ・レベルへアップグレードするアプリケーションでは動作が異なる可能性があるため、移行先のパッチ・バージョンが重要です。また、MySQL 8.0と比較して、MySQL 8.4では他にもキーワードや予約語が削除されています。一覧はこちらのリンクをご覧ください。

スキーマとアプリケーションのSQLから、これらの名前を使った識別子を検索してください。引用符で囲まれていない予約済み識別子は、構文エラーを引き起こす可能性があります。

例えば、次のSQLは、

SELECT id, qualify FROM jobs;

次のようにする必要がある場合があります。

SELECT id, `qualify` FROM jobs;

実行可能であれば、一般にオブジェクト名を変更する方が望ましい方法です。

FLOAT列とDOUBLE列のAUTO_INCREMENT

MySQL 8.4では、FLOAT列とDOUBLE列のAUTO_INCREMENTはサポートされなくなりました。

一部の互換性の違いとは異なり、この変更はアップグレードの成功を妨げる可能性があります。該当する列は、アップグレード前にすべて修正する必要があります。

次のクエリで確認します。

SELECT
TABLE_SCHEMA,
TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
EXTRA
FROM INFORMATION_SCHEMA.COLUMNS
WHERE DATA_TYPE IN ('float', 'double')
AND EXTRA LIKE '%auto_increment%';

このクエリが0行を返す状態が理想です。

標準に準拠しない外部キー

InnoDBは従来、一意でない索引や部分的な索引を参照する外部キーを許可していました。これは標準SQLに対する拡張です。

MySQL 8.4では、restrict_fk_on_non_standard_keyにより、この動作がデフォルトで制限されます。こうした関連を含む既存の8.0テーブルが、必ずしもアップグレードを妨げるわけではなく、MySQLは警告を報告します。ただし、アップグレード後にアプリケーション、ORM、デプロイ・ツールが同様の外部キーを作成しようとすると、CREATE TABLE文やALTER TABLE文が拒否される可能性があります。

そのため、ORMが生成するDDL、Liquibaseのマイグレーション、Flywayのマイグレーション、アプリケーションが作成するテーブルが、重要なテスト対象になります。

レプリケーションの用語と管理コマンド

MySQL 8.4では、MASTERとSLAVEの用語を使った複数の古いレプリケーション文が削除されます。

例は次のとおりです。

これらの変更は、Change Data Capture（CDC）製品、監視ツール、データベース管理スクリプト、独自の自動化で特に重要です。

アップグレード前に、運用用リポジトリから古いレプリケーション構文を検索してください。

権限とDEFINERの変更

非推奨のSET_USER_ID権限は、MySQL 8.4で削除されました。その代替機能では、SET_ANY_DEFINERやALLOW_NONEXISTENT_DEFINERなどの権限を使用します。

次のオブジェクトを作成するデプロイ・プロセスを確認してください。

• ストアド・プロシージャ
• 関数
• トリガー
• ビュー
• イベント

明示的なDEFINER=句を含むスクリプトには、特に注意してください。

空間索引

データベースで空間データを使用している場合、MySQLは、MySQL 8.4.4以降へのアップグレード前に空間索引を削除し、アップグレード後に再作成することを推奨しています。または、アップグレード直後、該当するテーブルを使用する前に再構築することもできます。

次のクエリで特定します。

SELECT DISTINCT
TABLE_SCHEMA,
TABLE_NAME,
INDEX_NAME
FROM INFORMATION_SCHEMA.STATISTICS
WHERE INDEX_TYPE = 'SPATIAL';

サーバーのデフォルト設定の変更

MySQL 8.4では、ワークロードの動作や性能に影響し得る複数のデフォルト設定が変更されます。例は次のとおりです。

• innodb_adaptive_hash_index: ON → OFF
• innodb_change_buffering: all → none
• innodb_io_capacity: 200 → 10000
• innodb_log_buffer_size: 16 MB → 64 MB
• temptable_max_mmap: 1 GB → 0
• temptable_max_ram: 利用可能なメモリー量に一部基づくように変更
• group_replication_consistency: EVENTUAL → BEFORE_ON_PRIMARY_FAILOVER

MySQL HeatWaveはマネージド・サービスであり、その構成が汎用MySQLのデフォルトをすべてそのまま反映するとは限りません。重要なのは、8.4サーバーが8.0とまったく同じ動作をすると想定せず、実際に有効な構成とワークロードの動作を比較することです。

これらの変更は、性能ベースラインの取得をアップグレード・プロセスに含めるべき理由の1つです。

図3 — 確認すべきMySQL 8.4の主な変更

本番環境に変更を加える前にMySQL Shell Upgrade Checkerを使用する

MySQL Shell Upgrade Checkerユーティリティは、移行の検証に使う主要ツールの1つにすべきです。

util.checkForServerUpgrade()は、指定した移行先バージョンに対する既知の互換性の問題についてMySQLインスタンスを評価し、エラー、警告、手動調査が必要となる追加チェックを報告します。アップグレード前にUpgrade Checkerを使用し、報告された問題を解消することを推奨しています。

新しいMySQL Shellリリースを使用してください。サポート対象のMySQL Serverバージョンに対して、最新のMySQL Shellを推奨しています。2026年10月時点では、MySQL Shell 26.7.1が現在の一般提供リリースで、MySQL Server 8.4.11が現在のHeatWave 8.4 LTSサーバー・リリースです。

ステップ1：開発環境またはQA環境でUpgrade Checkerを実行する

本番のスキーマ、ストアド・プログラム、アカウント、構成を代表するコピーを含む、非本番環境から始めます。

例：

mysqlsh -- util check-for-server-upgrade \
  upgradecheck@qa-host:3306 \
  --target-version=8.4.11 \
  --output-format=JSON \
  > qa_upgrade_check_8_4.json

移行先バージョンは、アップグレード時点でHeatWave DBシステムに提供されている、具体的な8.4 LTSリリースと一致させてください。

まずQA環境で検出事項を解消します。その後、8.4環境に対して通常のアプリケーション回帰テストを実行します。

CRUD操作だけでなく、ストアド・プロシージャ、定期ジョブ、レポート処理、スキーマ移行、認証、接続プーリング、ETL処理、管理ツールもテストしてください。

ステップ2：本番環境でUpgrade Checkerを再実行する

QAテストが成功したら、本番の8.0.46 DBシステムに対して同じUpgrade Checkerを実行します。

例：

mysqlsh -- util check-for-server-upgrade \
  upgradecheck@production-host:3306 \
  --target-version=8.4.11 \
  --output-format=JSON \
  > production_upgrade_check_8_4.json

本番環境には、QA環境にないオブジェクト、ユーザー、ストアド・プログラム、スキーマ変更が存在することが多いため、この2回目のチェックが重要です。

大規模な本番データベースの場合は、適切な運用時間帯にCheckerを実行し、実行中のシステム負荷を監視してください。

本番環境の最終互換性チェックが完了した後は、アップグレードまでの不要なDDL、アカウント変更、構成変更を最小限にし、検証したシステムがチェック時の構成から大きく変わらないようにしてください。

図4 — MySQL Shellによるアップグレード前の検証

データベースだけでなくアプリケーション・スタックも検証する

データベースがUpgrade Checkerを通過しても、アプリケーションの問題が発生する場合があります。アプリケーションのランタイム、データベース・ドライバ、接続プール、ORM、TLS実装、生成されるSQLを、すべてテスト対象に含めてください。

Pythonアプリケーション

MySQL Serverをアップグレードするからといって、Pythonやその他のプログラミング言語自体のアップグレードが必ず必要になるわけではありません。

通常、重要なコンポーネントはデータベース・コネクタです。アプリケーションは次のものを使用している可能性があります。

• mysql-connector-python
• PyMySQL
• SQLAlchemy
• aiomysql
• asyncmy

あるいは、その他のデータベース・コネクタやドライバを使用している場合もあります。

例えば、オラクルは、サポート対象のMySQL Serverバージョンと、最新のMySQL Connector/Pythonリリースを組み合わせることを推奨しています。Connector/PythonがサポートするPythonランタイムのバージョンも時間とともに変わるため、このプロジェクトの一環でコネクタを更新する場合は、アプリケーションの既存のPythonバージョンが、そのコネクタ・リリースでサポートされていることを確認してください。

Pythonなどのアプリケーションでは、次の要素について、本番環境と完全に同じ組合せをテストしてください。

新しい開発者用ノートPCの構成でアプリケーションを検証し、古い本番ランタイムでも同じ動作になると考えてはいけません。

認証の互換性

コネクタがcaching_sha2_passwordをサポートしていることを確認してください。

caching_sha2_passwordのパスワード交換には、セキュアな接続、またはサポート対象のRSAベースのパスワード交換が必要です。

これは、mysql_native_passwordが一般的だった時期に導入されたレガシー・アプリケーションで特に重要です。

TLSの互換性

MySQL 8.4は、暗号化接続でTLS 1.2とTLS 1.3をサポートします。古いクライアント・ランタイム、OpenSSL実装、明示的に構成した暗号リストは、データベース自体のアップグレードが成功しても接続の問題を引き起こす可能性があります。

本番用の接続文字列、証明書の検証、CAファイル、TLSバージョン、暗号の構成をQA環境でテストしてください。

接続プールとHAフェイルオーバー

HAアップグレードのフェーズ2では、アップグレード済みのセカンダリを昇格する際に、既存のプライマリ接続が閉じられます。

したがって、アプリケーションは一時的なデータベースの切断に耐え、新しい接続を確立する必要があります。

接続プールでは、すべての接続が無期限に有効であると想定しないでください。次を検証します。

• 自動再接続の動作
• 再試行ロジック
• 接続タイムアウトの設定
• 無効になった接続の処理
• トランザクション再試行の動作
• データベースのエンドポイントが短時間利用できなくなった場合のアプリケーションの応答

例えば、SQLAlchemyアプリケーションでは、再利用前に無効なプール接続を検出するため、pool_pre_pingなどの接続検証機構がよく使用されます。具体的な方法は、アプリケーションのフレームワークとトランザクションの意味付けによって異なります。

データベースのHAアーキテクチャは、アプリケーションも短時間のデータベース接続中断に耐えられるように設計されている場合に、最も効果を発揮します。

図5 — アプリケーションとドライバの考慮事項

アップグレード前に性能ベースラインを確立する

互換性はアップグレード検証の半分にすぎません。

正しい結果を返し続けるクエリでも、アップグレード後に別の実行計画を使う場合があります。そのため、アプリケーションは機能的に正しくても、明らかに遅くなる可能性があります。

アップグレード開始前に、代表的な本番ワークロードの実行中にベースラインを取得してください。

OCIはMySQL HeatWaveのサービス・メトリクスを自動的に公開します。また、Database Managementは、文のレイテンシや詳細なSQL統計など、追加のデータベース性能情報を提供します。

アップグレード時に特に有用なメトリクスは次のとおりです。

OCI Database Managementは、CPU、ディスク使用率、IOPS、スループット、接続数、終了した接続数、文のレイテンシ、行の読取り、行の書込みなど、MySQLメトリクスのグラフを提供します。Full monitoringでは、バイナリ・ログのI/O統計を含む、さらに高度なメトリクスが加わります。

同等のワークロードの時間帯を比較する

任意の期間同士を比較するのは避けてください。例えば、平日の午前10時から午後2時がデータベースのピーク時間帯であれば、次を比較します。

MySQL 8.0.46 — 火曜日の午前10時～午後2時

比較対象は、

MySQL 8.4 — 火曜日の午前10時～午後2時

というアップグレード後の時間帯です。

意味のある比較にするため、ワークロード量は十分に近い必要があります。

レイテンシが大きい上位のSQL文には、特に注意してください。CPUやメモリーの全体的な使用率が正常に見えても、少数のオプティマイザ・プランの変更がアプリケーション性能に影響することがあります。

Performance Hubは、アップグレード後に実行レイテンシが変化したSQL文の特定に役立ちます。

メンテナンス中の監視の制限

HAシステムの監視には、重要な注意点があります。

高可用性のMySQL HeatWave DBシステムでは、HeatWaveのサービス・メトリクスはプライマリMySQLインスタンスを表します。セカンダリは、それらのメトリクスに個別には表されません。

また、MySQL HeatWave Serviceはメンテナンスの実行中、サービス・メトリクスを監視しません。

したがって、アップグレード中は次の両方を使用してください。

メンテナンス中のメトリクスの欠落を、データベース性能の問題と解釈しないでください。

図6 — アップグレード前後に注視するメトリクス

メンテナンス時間帯の前にロールバック戦略を準備する

高可用性はアップグレードのダウンタイムを減らし、プライマリのアップグレード前に優れたチェックポイントを提供します。しかし、HAにはMySQL 8.4からMySQL 8.0へのインプレース・ダウングレード機能はありません。

DBシステムを低いMySQLバージョンにダウングレードできないことを明記しています。必要に応じて元のバージョンで新しいDBシステムを復元できるよう、アップグレード前のバックアップ取得を推奨しています。

そのため、大規模な本番データベースのロールバック計画は、フェーズ1の前に開始する必要があります。

手動の完全バックアップを取得する

計画したアップグレードの直前に手動の完全バックアップを作成し、正常に完了したことを確認してください。Oracle CloudのWebコンソール、またはOracle Command Line Interfaceを使用してバックアップを実行します。

例えば、OCI CLIを使用する場合は次のとおりです。

oci mysql backup create \
  --db-system-id <DB_SYSTEM_OCID> \
  --backup-type FULL \
  --display-name pre-8.4-upgrade-backup \
  --retention-in-days 30 \
  --soft-delete ENABLED

MySQL HeatWaveは手動の完全バックアップをサポートしており、DBシステムのアップグレード前に完全バックアップを実行することを推奨しています。

6 TBの本番環境では、アップグレード・プロジェクトに先立ち、代表的なバックアップの復元をテストすることも有益です。想定の復元時間に頼らず、実際のリカバリ手順と現実的な復旧時間の見込みを確立できます。

フェーズ1を主要なロールバックのチェックポイントとする

プロセスを停止する最も安全な時点は、セカンダリのアップグレード後、フェーズ2の開始前です。

この時点では、次の状態です。

• プライマリ = MySQL 8.0.46
• セカンダリ1 = MySQL 8.4
• セカンダリ2 = MySQL 8.4

本番アプリケーションは、引き続き8.0のプライマリに対して動作しています。

次を確認します。

• アップグレード済みの両セカンダリが正常である
• HA DBシステムが期待する状態に戻っている
• レプリケーションと追いつき処理が完了している
• 重大なアップグレード・エラーがない
• 既存のプライマリ上のアプリケーション性能が正常である

重大な問題がある場合は、フェーズ2を開始しないでください。本番プライマリをMySQL 8.0.46のまま維持しながら、問題を調査します。これは、制御されたHAアップグレード・プロセスを使う大きな利点の1つです。

フェーズ2の前後でアプリケーションの書込みを制御する

特に重要なシステムでは、フェーズ2の切替直前に、アプリケーションの書込みを停止または最小化することを検討してください。

その後、プライマリのアップグレードとフェイルオーバーを実行し、通常の書込みトラフィックを再開する前に、重点的なスモーク・テストを実施します。

スモーク・テストでは、認証、接続プーリング、代表的な読取り、制御された挿入と更新、ストアド・プロシージャ、API、定期処理など、アプリケーションの特に重要な操作を確認してください。

次も確認します。

• アプリケーション・ログ
• データベースのエラー・ログ
• 失敗した接続
• 文のレイテンシ
• CPU
• メモリー
• I/O
• HAの正常性

テストが成功したら、通常のアプリケーション・トラフィックを再開します。

この方法により、環境の検証が終わる前にMySQL 8.4で作成される新しいデータを減らせます。

フェーズ2の後のロールバック

フェーズ2が完了すると、本番プライマリはMySQL 8.4で動作しています。

この時点では、HAシステムをMySQL 8.0.46へ戻すボタンはありません。

重大な非互換性のため8.0に戻す必要がある場合のリカバリ手順は次のとおりです。

HeatWaveのバックアップを復元すると、OCIは新しいDBシステムを作成します。より高いバージョンを選択しない限り、復元されたDBシステムはデフォルトでバックアップのデータベース・バージョンを維持します。HA DBシステムのバックアップは、別のHA DBシステムに復元できます。

復元先は新しいDBシステムになるため、アプリケーションの接続先をどう切り替えるかを計画してください。元のDBシステムとまったく同じIPアドレスの維持に依存するロールバック手順は避けてください。

アプリケーション構成、サービス・ディスカバリ、管理されたDNSによる抽象化を利用すると、この接続先の切替を大幅に簡単にできます。

切替後に書き込まれたトランザクションはどうなるか

これはロールバックで最も重要な考慮事項です。

アップグレード前のバックアップを午後10時に作成し、午前0時にフェーズ2が完了し、午前0時15分に通常の書込みを再開した後、午前1時に重大な問題が見つかったとします。

午後10時のバックアップを復元しても、切替後に書き込まれたトランザクションが自動的に含まれるわけではありません。

これらのトランザクションには、データを整合させるための戦略が必要です。

そのため、最も安全な順序は次のとおりです。

検証時間を短く保ち、制御することで、ロールバックを大幅に簡単にできます。

図7 — 高可用性環境のロールバック戦略

推奨するアップグレードの全体手順

大規模なMySQL HeatWave HA本番システムの全体手順は、次のようにまとめられます。

1. MySQLバージョン、スキーマ、ユーザー、ストアド・プログラム、ドライバ、ORM、連携、運用スクリプトを含む本番環境の構成を把握します。
2. 本番性能のベースラインを確立します。
3. 本番を代表する開発環境またはQA環境を構築・更新します。
4. 最新のMySQL Shell Upgrade CheckerをQA環境に対して実行します。
5. すべての阻害要因を解消し、警告を調査します。
6. QA環境をMySQL 8.4 LTSにアップグレードします。
7. アプリケーション、ドライバ、ORM、SQL、連携、性能の完全なテストを実行します。
8. 本番の8.0.46 DBシステムに対してUpgrade Checkerを実行します。
9. 不要なスキーマ変更と構成変更を凍結します。
10. 本番環境の手動完全バックアップを取得し、確認します。
11. アプリケーションの再試行とフェイルオーバーの動作を確認します。
12. HAの制御されたアップグレードのフェーズ1を開始します。
13. セカンダリとリード・レプリカをアップグレードし、検証します。
14. DBシステムが完全に正常でなければ停止します。
15. フェーズ2の切替を計画します。
16. 運用上可能であれば、アプリケーションの書込みを停止または最小化します。
17. フェーズ2を開始し、アップグレード済みのセカンダリをプライマリにします。
18. トラフィックを完全に戻す前に、アプリケーションのスモーク・テストを実行します。
19. 通常の書込みを再開します。
20. 8.4のメトリクスと重要なSQLの性能を、8.0のベースラインと比較します。
21. 代表的なピーク負荷の時間帯を通じて、強化した監視を続けます。
22. 組織のロールバックおよび保存ポリシーに従い、アップグレード前のバックアップを保持します。

結論

MySQL HeatWaveをMySQL 8.0.46からMySQL 8.4 LTSにアップグレードすることは、単なるデータベースのバージョン変更ではありません。認証方式、SQLキーワード、外部キーの動作、権限、レプリケーション・コマンド、コネクタの互換性、デフォルト構成、クエリ実行の動作は、いずれも既存アプリケーションに影響し得ます。

大規模な本番環境では、高可用性が運用上の大きな利点をもたらします。オラクルの制御された2フェーズのアップグレードでは、8.0のプライマリを利用可能なまま維持しながら先にセカンダリをアップグレードでき、最終的なプライマリ切替の前に、検証と続行可否判断の自然なチェックポイントを設けられます。

最も安全な戦略は、複数の保護策を組み合わせることです。

MySQL Shell Upgrade Checker → QA環境でのアプリケーション・テスト → 本番の互換性検証 → アップグレード前バックアップ → HAフェーズ1 → 続行可否の検証 → 制御されたフェーズ2 → スモーク・テスト → 性能比較

高可用性はアップグレードに伴う中断を最小限に抑えますが、ロールバック戦略の代わりにはなりません。検証済みのアップグレード前バックアップ、切替時のアプリケーション書込みの制御、テスト済みの復元手順、アップグレード前後の包括的な監視は、特に複数テラバイトの本番データベースでは、引き続き不可欠です。

これらの制御を整えることで、MySQL 8.0から8.4 LTSリリースへの移行を、単なるメンテナンス作業ではなく、計画的で測定可能、かつ復旧可能な本番変更として進められます。