MySQLレプリは混在OK?バージョン互換の現実

MySQLのレプリケーションはバージョン混在できるのか

「新しいMySQLにしたいが、いきなり切り替えるのは怖い」
このとき多くの現場で選ばれるのが、レプリケーションを使った段階移行です。

古いMySQLをマスター、新しいMySQLをスレーブにして同期させ、追いついたら切り替える。
いわゆるローリングアップデートです。

ではここで疑問が出ます。

MySQLのレプリケーションはバージョン混在できるのか。

答えは「条件付きで可能」です。
そしてこの“条件”を理解していないと、移行直前にレプリケーションが停止します。

レプリケーションの仕組みを整理する

MySQLのレプリケーションは、データをコピーしているわけではありません。
コピーしているのは更新履歴です。

マスターは更新をバイナリログ(binlog)に記録します。
スレーブはそれを読み、同じ操作を再実行します。

つまりスレーブは

「同じSQLをもう一度実行している」

のに近い動きをしています。

ここがバージョン混在で問題になります。

原則:上位互換のみ安全

基本ルールがあります。

  • 新しいMySQL → 古いMySQL:ほぼ不可
  • 古いMySQL → 新しいMySQL:可能なことが多い

理由は単純です。
新しいバージョンが出力するbinlogを、古いバージョンは理解できないからです。

したがって移行時は

旧サーバ(旧バージョン)をマスター
新サーバ(新バージョン)をスレーブ

の構成にします。

逆にすると、レプリケーションはほぼ確実に止まります。

それでも止まる理由

ここからが実務です。
上位互換でもレプリケーションは普通に止まります。

主な原因は3つあります。

1. SQLモードの違い**

MySQLはバージョンごとにデフォルトのSQLモードが変わります。
代表例が STRICT モードです。

旧サーバでは通るINSERTが、新サーバではエラーになります。

結果:

スレーブでSQLエラー → レプリ停止

2. 文字コードと照合順序**

8.0以降では照合順序が変わっています。
特に utf8mb4 の扱いです。

同じ文字列でも比較結果が変わると、UNIQUE制約違反が発生します。
これもレプリケーション停止の原因になります。

3. binlog形式の違い**

binlogには形式があります。

形式 特徴
STATEMENT SQLを記録
ROW 変更された行を記録
MIXED 状況で切替

バージョン差がある場合、STATEMENTは危険です。
関数の挙動や日時の扱いが変わると、結果が一致しません。

SET GLOBAL binlog_format = ROW;

移行前にROWにしておかないと、追従中に不整合が発生します。

実際に起きる事故

典型的なケースです。

移行直前まで順調に追従していた。
切り替え直前、突然レプリケーションが停止。

ログを見ると

Duplicate entry
Data truncated
Incorrect datetime value

といったエラーが出ます。

原因はアプリではなく、バージョン差による解釈の違いです。

そして一番困るのは、発覚が「切り替え直前」になることです。
普段は使われないテーブルの更新が、そのタイミングで初めて流れるためです。

事前に必ず確認すること

最低限、移行前に確認します。

  • SQL_MODE
  • character_set_server
  • collation_server
  • binlog_format
SHOW VARIABLES LIKE 'sql_mode';
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';
SHOW VARIABLES LIKE 'binlog_format';

ここが一致していないと、レプリケーションは安定しません。

切り替え手順の重要なポイント

安全な手順はこうなります。

1. 新MySQLをスレーブとして接続
2. 数日〜数週間追従させる
3. Seconds_Behind_Master が0を維持するか確認
4. 書き込み停止
5. スレーブを昇格

短期間の確認だけで切り替えると、後からレプリ停止が発覚します。

最後に

MySQLレプリケーションは「コピー機能」に見えますが、実際は「再実行機能」です。
同じデータを送っているのではなく、同じ操作を別の環境で行っています。

だからバージョンが違うと結果も変わります。

レプリケーションが組めた時点で成功ではありません。
「止まらずに追従し続けるか」を確認して初めて移行準備が整います。

段階移行の本当の作業は、接続ではなく“観察期間”を確保することです。
この期間を省くと、最も困るタイミングでレプリケーションが止まります。