MySQL 5.5 遷移至 MariaDB 10.1.14 實戰：xtrabackup 跨引擎表空間導入與多線程復制追趕

MySQL 5.5 遷移至 MariaDB 10.1.14 實戰：xtrabackup 跨引擎表空間導入與多線程復制追趕

某生產環境將核心業務庫從 MySQL 5.5 遷移至 MariaDB 10.1.14。本文記錄完整遷移路徑：xtrabackup 物理備份、表空間導入報錯處理、mysqldump 兜底、主從建立、主鍵衝突跳過、MariaDB 多線程復制參數調優追趕延遲。

一、遷移架構與步驟

1. 源庫（MySQL 5.5）xtrabackup 物理備份指定庫。
2. 目標庫（MariaDB 10.1）還原備份，建立主從復制。
3. 驗證資料一致性後，業務低峰期切換 VIP/域名解析。

二、關鍵問題與解決

1. 表空間導入需 innodb_file_per_table=ON

xtrabackup 還原單表需獨立 .ibd 檔案。發現部分 InnoDB 表仍在共享表空間 ibdata1 中。

解決：申請維護窗口，對共享表空間表執行 ALTER TABLE t ENGINE=InnoDB 重建（會自動遷移至獨立 .ibd），或 mysqldump 導出導入重建。

2. IMPORT TABLESPACE 報錯：日期/時間類型不匹配

導入 .ibd 時 MariaDB 10.1 對 DATE/DATETIME/TIMESTAMP 元資料檢查更嚴格，報 Table definition mismatch。

解決：對報錯表放棄物理導入，改用 mysqldump 邏輯導出導入，速度可接受（單表 < 1000 萬行約 10 分鐘）。

3. 主從建立時主鍵衝突（ERROR 1062）

全量備份與開啟復制間有寫入增量，從庫 START SLAVE 時主鍵重複報錯。

解決：

-- 臨時跳過主鍵衝突
SET GLOBAL sql_slave_skip_counter = 1;  -- 單條
-- 或配置檔永久跳過（謹慎）
slave_skip_errors = 1062

但發現跳過後資料缺失較多，需快速追趕。

4. 開啟 MariaDB 多線程復制（Parallel Replication）

MariaDB 10.0+ 支援 slave_parallel_mode=optimistic + slave_parallel_threads。

# 從庫配置
[mysqld]
slave_parallel_mode = optimistic
slave_parallel_threads = 6
# 追趕期臨時放寬持久化
innodb_flush_log_at_trx_commit = 0
sync_binlog = 0

觀察 SHOW PROCESSLIST 出現多個 system user 線程狀態 Waiting for work from SQL thread / apply log event，確認多線程生效。

三、驗證與切換