MySQL 8.4はLTS（Long Term Support）として位置づけられており、8.0系からの移行先として検討されるケースが増えています。一方で、8.4 ではセキュリティや仕様の明確化を目的として、いくつかの重要な変更が行われています。これらは単なる新機能追加ではなく、既存の運用や自動化に影響を与える可能性があります。
本稿では、MySQL 8.0から8.4へアップグレードする際に特に注意すべき変更点と、ダウングレードを含めた移行戦略、事前チェックの考え方について整理します。
MySQL 8.4での主な注意点
mysql_native_password認証プラグインの無効化
MySQL 8.4では、mysql_native_password認証プラグインが、デフォルトでは無効化されています。これはセキュリティ強化の一環ですが、既存環境からの移行時には注意が必要です。
特に、論理バックアップを用いてユーザーを含めて移行する場合、バックアップ元でmysql_native_passwordを利用して作成されたユーザーは、8.4環境ではそのままでは利用できません。そのため、一時的にmysql_native_passwordを有効化する対応が必要になることがあります。
有効化する場合は設定ファイルの[mysqld]セクションに以下を記載します。
[mysqld]
mysql_native_password=on
この設定を行うことで、移行作業自体は可能になります。ただし、mysql_native_passwordは9.0で廃止されており、恒久的に利用することは推奨されません。caching_sha2_passwordといったより安全な認証プラグインへ切り替えるのが望ましいでしょう。
Master / Slave構文の廃止
MySQL 8.4では、MASTER/SLAVEという用語を用いた構文が廃止され、SOURCE / REPLICAへと置き換えられています。これにより、CHANGE MASTER TOなどの構文は使用できなくなります。
問題となるのは、運用スクリプトや自動化ツールが旧構文を前提としている場合です。MySQL 8.0と8.4の両対応が必要な期間では、サーバのバージョンを判定して構文を切り替える分岐処理が必要になります。
これはSQLの互換性だけでなく、運用コードの保守性にも影響するため、事前に影響範囲を洗い出しておくことが重要です。
Master / Slave構文の廃止についてはこの連載の以下の記事でも取り扱っています。
MySQL 8.4で厳格化された外部キー制約仕様
MySQL 8.4では、外部キー制約に関する仕様が厳格化されています。これまでMySQL 8.0では警告扱い、あるいは暗黙的に許容されていた定義が、8.4では明確にエラーとして拒否されます。
デフォルトでは外部キーが参照する親テーブル側のカラムが、非一意キー（ユニークインデックスまたは主キーではないキー）の場合にDDLが失敗します。
この変更は、新規作成時だけでなく、既存スキーマを再適用するマイグレーション手順において問題になりやすい点です。8.0で長年運用されてきたスキーマほど、暗黙の不整合を抱えていることが多く、8.4移行時に初めてエラーとして顕在化します。
詳細は以下の記事をご覧ください。
SET_USER_ID権限の削除と新しい権限モデル
MySQL 8.4では、従来存在していたSET_USER_ID権限が削除され、新たに追加されたSET_ANY_DEFINER権限とALLOW_NONEXISTENT_DEFINER権限に分かれました。8.4にインプレースアップグレードを行うと、SET_USER_ID権限を持つユーザには新しいSET_ANY_DEFINER/ALLOW_NONEXISTENT_DEFINER権限が付与されます。
注意が必要なのは、MySQL 8.0と8.4が混在するレプリケーション構成です。たとえば8.4側で新しい権限をGRANTやREVOKEした場合、その権限は8.0側には存在しないため、レプリケーション中に権限関連のSQLが適用できず、レプリケーションエラーが発生します。逆方向も同様で、8.0側でSET_USER_IDへの操作を行うと、8.4側でレプリケーションエラーが生じます。
このため、8.0/8.4混在期間が発生する構成では、権限変更を極力避ける、もしくは事前に適用範囲を限定した運用設計が必要です。
ダウングレード手段を考慮したアップグレード設計
安全策としてまず考えられるのは、MySQL 8.4から8.0へ向けたレプリケーション構成を事前に用意しておく方法です。8.4を先行して昇格させ、必要に応じて8.0側へ切り替えることで、迅速なロールバックが可能になります。
ただし、前述の権限や構文差異があるため、混在期間中の運用制約を十分に理解した上で設計する必要があります。
MySQL 8.0.35以降では、同一LTS内、もしくは特定のLTS間でのインプレースダウングレードがサポートされるようになりました。8.0.34以前では、インプレースダウングレードはサポートされておらず、ロールバックを考慮すると採用に難がありました。
この変更により、インプレースアップグレードを選択しやすくなったと言えます。ダウングレード手段が公式に用意されたことで、インプレースアップグレードの心理的ハードルが下がった点は大きな変化です。
アップグレード前のチェック
MySQL Shellに含まれるUpgrade Checker Utilityは、8.0 →8.4アップグレード前の事前チェックとして非常に有用です。非互換なSQL、非推奨設定、スキーマ上の問題などを静的に検出できます。
ただし、このツールで検出できるのはあくまで一部です。実データに依存する外部キー制約違反や、運用スクリプトの構文差異などは検出できません。そのため、Upgrade Checkerは「入口」と位置づけ、実環境相当の検証と併用することが重要です。
Upgrade Checker Utility の詳細については、ドキュメントをご覧ください。
まとめ
MySQL 8.0から8.4へのアップグレードは、単なるバージョン更新ではなく、仕様や運用を見直す機会でもあります。特に、権限モデル、外部キー制約、認証方式、レプリケーション構文といった基盤部分の変更は、影響範囲が広く、事前理解が不可欠です。
ダウングレード手段を含めた設計と、十分な事前チェックを行うことで、8.4 LTSへの移行はより安全になるでしょう。
MySQL 8.0から8.4への変更点についての詳細は以下のドキュメントをご確認ください。
