大數據量場景下，mysqldump 導出導入耗時過長，直接拷貝 datadir 成為常用遷移手段。但看似簡單的文件級遷移，隱藏著參數不匹配導致啟動失敗的風險。本文記錄一次真實遷移故障及解決方案。
datadirFLUSH TABLES WITH READ LOCK → 拷貝整個 datadir 到目標服務器my.cnf 中 datadir 指向新路徑InnoDB: Error: log file ./ib_logfile0 is of different size 0 63963136 bytes
InnoDB: than specified in the .cnf file 0 6291456 bytes!
換算：63963136 bytes = 61MB，6291456 bytes = 6MB
根因：源服務器 innodb_log_file_size=61M，目標服務器默認 6M，Redo Log 文件大小不匹配導致 InnoDB 拒絕啟動。
# 目標服務器 my.cnf 同步參數
[mysqld]
innodb_log_file_size = 61M # 必須與源服務器 ib_logfile 實際大小一致
innodb_log_files_in_group = 2 # 組文件數也需一致修改後啟動成功。
| 參數 | 說明 | 驗證方式 |
|---|---|---|
| datadir | 數據目錄路徑 | SHOW VARIABLES LIKE 'datadir' |
| innodb_log_file_size | Redo Log 文件大小 | ls -lh datadir/ib_logfile* 實測 |
| innodb_log_files_in_group | Log 組文件數 | 同左 |
| innodb_page_size | 頁大小（默認 16KB） | SHOW VARIABLES LIKE 'innodb_page_size' |
| character_set_server | 服務端字符集 | 源/目標 SHOW VARIABLES LIKE 'character_set%' 全量對比 |
| collation_server | 服務端校對規則 | 同左 |
| default_storage_engine | 默認存儲引擎 | 同左 |
| sql_mode | SQL 模式 | 極易導致遷移後行為差異，必須完全一致 |
CHECK TABLE tbl_name 核心表檢查SELECT COUNT(*) FROM core_tables 行數核對| 方案 | 適用場景 | 優點 | 缺點 |
|---|---|---|---|
| 物理文件拷貝 | TB 級、停機窗口允許 | 速度最快、保留所有統計信息 | 版本/參數強綁定、需停機 |
| XtraBackup 熱備份 | 不允許長時間停機 | 在線、非阻塞、支持增量 | 需額外工具、恢復需 prepare |
| mysqldump 邏輯備份 | 小數據量、跨版本升級 | 版本無關、可壓縮、可選表 | 慢、鎖表（MyISAM）、丟失統計信息 |
| 主從同步切換 | 高可用架構、極短停機 | 平滑遷移、可回滾 | 架構複雜、需提前部署從庫 |
物理遷移核心原則：版本一致、參數同步、文件完整、驗證閉環。任何參數差異都可能導致啟動失敗或數據損壞。
