MySQL熱遷移是指在數據庫運行過程中，將數據從一臺MySQL服務器遷移到另一臺MySQL服務器。這種遷移可以實現零停機時間，對于需要 24x7 運行的線上環境，特別有意義。

熱遷移的過程中，需要將數據從源服務器同步到目標服務器。常見的同步方法有以下幾種：

a. 基于 mysqlbinlog 工具做增量同步
b. 基于 GTID 協議做增量同步
c. 使用三方工具，如 CanaKit 等做增量同步
d. 停止應用訪問數據庫，使用 xtrabackup 工具做全量拷貝

其中，a/b/c 三種方案是熱遷移的核心。這三種方案的優缺點分別如下：

a. 優點：原生 MySQL 支持，操作簡單；缺點：對 MySQL 版本有要求（不同版本的 binlog 格式不同），同步速度不是很快
b. 優點：保證同步的連續性，即使中途出現網絡故障，也能從故障處繼續同步；缺點：需要修改 MySQL 配置、管理 GTID
c. 優點：支持異構數據源（比如從 MySQL 到 Oracle 的遷移）；缺點：需要額外安裝、配置、調試

綜合來看，使用 mysqlbinlog 方案是最為常見的。但對于版本不同、數據庫很大的情況，需要借助 xtrabackup 做全量備份，再使用 incr 選項做增量備份。

熱遷移的另一個要點是如何保持應用無感知。這里，有兩個問題需要考慮：如何保證目標服務器的任何事務操作不在源服務器被執行，以及如何保證應用不切換數據源。

對于第一個問題，我們可以使用 VIP（Virtual IP）方案。在熱遷移前，我們將源服務器的 VIP 轉移到目標服務器，并將目標服務器加入到源服務器的互信白名單中。這樣，我們就能保證同一個事務只在一個服務器上執行。

對于第二個問題，我們可以基于連接池實現。在實際應用中，每個（Web）連接池都會有一些連接在運行。將所有的連接都重置，并替換數據源為目標服務器，可以實現無感知遷移。當然，在遷移后，切換回源服務器也需要同樣的操作。