MySQLでダンプ移行とレプリケーション移行の違い
MySQLのサーバを入れ替えるとき、最初に決めるべきなのは「いつ切り替えるか」ではありません。
どうやってデータを移すかです。
MySQLの移行方法は大きく2つあります。
- ダンプ移行（mysqldump / logical backup）
- レプリケーション移行（replication）
どちらも「データを新サーバへコピーする」点では同じです。
しかし性質はまったく違います。
この違いを理解していないと、移行当日にトラブルになります。
ダンプ移行とは何か
ダンプ移行は、現在のデータベースをSQLとして書き出し、新しいサーバで復元する方法です。
mysqldump -u root -p --single-transaction mydb > dump.sql mysql -u root -p mydb < dump.sql
最もシンプルで、最も広く使われている移行方法です。
メリットは明確です。
- 構成が単純
- バージョン差に比較的強い
- 切り戻しが容易
- 小規模なら短時間
しかし重大な欠点があります。
移行中に発生した更新が反映されません。
つまりダンプ取得から切り替えまで、データがズレます。
そのため通常は「メンテナンス停止」を伴います。
レプリケーション移行とは何か
レプリケーション移行は、現在のサーバ（マスター）から新サーバ（スレーブ）へ、変更ログを継続的に送り続ける方法です。
仕組みはバイナリログ（binlog）です。
新サーバは、マスターの更新を追従し続けます。
最終的に差分が0になった瞬間に切り替えます。
メリットは大きいです。
- ダウンタイムがほぼ不要
- データ不整合が起きにくい
- 大規模データでも可能
つまり「サービスを止めずに移行」できます。
ただし、こちらも万能ではありません。
一番の違い：時間の扱い
ダンプ移行は「静止したデータのコピー」です。
レプリケーション移行は「時間を追いかけるコピー」です。
この違いがトラブルの原因になります。
| 移行方式 | 特徴 | 問題が出る場面 |
| ダンプ移行 | ある時点の完全コピー | 書き込みが止められないサービス |
| レプリ移行 | 更新を追従 | 設定ミス・遅延・ログ管理 |
ダンプはシンプルですが、切り替え時にアプリ停止が必要です。
レプリは無停止ですが、運用の理解が必要です。
実務で起きる事故
ダンプ移行で起きる典型例です。
- ダンプ中に更新が入る
- 切り替え後にデータが戻る
- ユーザーの投稿が消える
原因は「取得時点のデータしか持っていない」からです。
一方、レプリケーション移行では別の事故が起きます。
- レプリケーションが止まっていた
- 遅延していた
- 切り替えたら古いデータだった
これはbinlog位置の管理ミスです。
つまり、
ダンプ移行は時間差の事故、
レプリケーション移行は状態管理の事故が起きます。
バージョンアップ時の注意
MySQL移行で多いのが、同時にバージョンアップを行うケースです。
ここで差が出ます。
ダンプ移行は論理データなので、新バージョンへ持ち込みやすいです。
一方、レプリケーションは互換性の影響を受けます。
- binlog形式
- 文字コード
- SQLモード
が一致しないと、レプリケーションは止まります。
つまり、バージョン差が大きいほどレプリ移行は難しくなります。
どちらを選ぶべきか
判断基準はシンプルです。
| 条件 | 向いている移行方法 |
| 書き込み停止できる | ダンプ移行 |
| 24時間稼働サービス | レプリケーション移行 |
| データ小規模 | ダンプ移行 |
| 大規模データ | レプリケーション移行 |
ダンプは安全、レプリは無停止。
どちらが優れているという話ではありません。
最後に重要なこと
移行トラブルの多くは「コピーしたから同じはず」という思い込みから起きます。
MySQL移行はファイルコピーではありません。
データは同じでも、環境が変われば挙動は変わります。
移行の本当の作業は、コピーではなく「差が出る前提で確認すること」です。
どの方式を選んでも、切り替え前に読み書きのテストを行うだけで、事故の確率は大きく下がります。
