MySQL 主從復制：存儲引擎不一致導致從庫表丟失的排查與修復

在搭建 MySQL 主從復制時，若主從庫的 default-storage-engine 設置不同（如主庫 InnoDB、從庫 MyISAM），直接複製 data 目錄啟動從庫，會導致從庫僅有庫結構，表全部丟失，甚至 mysql 系統庫也為空。這是因為表定義（.frm）與數據/索引文件（.ibd/.MYD/.MYI）耦合，引擎不匹配會使 MySQL 無法識別表文件。

根本原因

• 主庫表為 InnoDB，數據存於共享表空間（ibdata1）或獨立表空間（.ibd）。
• 從庫預設 MyISAM，期望 .MYD/.MYI 文件。
• 直接複製文件時，InnoDB 表空間文件（ibdata1、.ibd）被帶到從庫，但從庫啟動時按 MyISAM 邏輯尋找文件，找不到對應文件，判定表不存在。
• 系統庫 mysql 同理，導致權限、元數據全失。

標準修復流程

1. 統一引擎配置：修改從庫 my.cnf/my.ini，設定 default-storage-engine=INNODB，重啟驗證。
2. 重新同步數據（推薦）：

   # 主庫
   FLUSH TABLES WITH READ LOCK;
   SHOW MASTER STATUS;  -- 記錄 File, Position
   mysqldump --all-databases --master-data=2 --single-transaction > full.sql
   UNLOCK TABLES;
   
   # 從庫
   mysql < full.sql
   CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;
   START SLAVE;
   

3. 若必須用文件複製（大數據量）：
   • 確保主從 MySQL 版本、編譯參數、存儲引擎配置完全一致。
   • 停主庫，複製整個 datadir（含 ibdata1、.ibd、redo log、binlog 等）。
   • 從庫啟動前刪除 auto.cnf（避免 UUID 衝突），調整 server-id。
   • 啟動從庫，執行 CHANGE MASTER TO ... 指向複製來的 binlog 位置。

避坑指南

• 切勿混用引擎做物理備份：邏輯備份（mysqldump）不受引擎影響，通用性最強。
• 系統庫同步：物理複製會帶走 mysql 库，若版本不一致可能導致系統表結構不兼容，建議初始化從庫後再導入主庫的用戶權限（pt-show-grants）。
• GTID 模式：MySQL 5.6+ 建議啟用 GTID，簡化故障切換與重新同步。

若已發生表丟失，且無備份，數據找回極其困難。請務必建立定期邏輯/物理備份策略，並定期演練恢復。