以零/最少的停機時間將數據庫從一個實例實時遷移到另一個實例

有 2 個 MySQL 實例：MA 和 MB。它們彼此完全分開（它們之間沒有複製）。每個實例包含多個數據庫：

• MA 服務於 db1、db2
• MB 服務於 db3、db4

我想在不停機的情況下將 db1 遷移到 MB，因此結果將是：

• MA 服務於 db2
• MB 服務於 db1、db3、db4

我可以指示應用層暫停向 MA 寫入事務一段時間（< 10 秒）。假設 MA 和 MB 之間的複制延遲（如果已設置）可能小於 10 秒。

當然，最明顯的方法是：

1. 暫停對 db1 的寫入（“停機時間”開始）
2. mysqldump db1 並應用於 MB
3. 移動應用層設置以將 MB 用於 db1
4. 取消暫停對 db1 的寫入（“停機時間”結束）

但是，當 mysqldump/apply 對於較大的數據庫需要很長時間（> 10 秒）時，上述方法是不可接受的。我在https://exotel.com/blog/engineering/mysql-database-migration-with-zero-downtime/中看到了該方法，但我認為它僅在移動實例中的所有數據庫時才有效，但就我而言，有MA 中的 db2 仍然需要始終線上。

我試圖擺弄特定於數據庫的複制，但我認為它效果不佳（我可以猜測它可能適用於 MySQL 8.0 過濾複製功能，但我們在 5.7 並且不期待更新）。

你知道有什麼方法可以做到這一點嗎？

現在可以使用 Ghostferry 之類的工具：https ://github.com/Shopify/ghostferry

這將需要一些停機時間。想一想：

1. 應用程序寫入節點 A
2. 對節點 A 的更改以最終一致的方式複製到節點 B
3. 應用程序突然將寫入切換到節點 B -> 從節點 A 複製和來自應用程序的更新現在同時發生 -> 幾乎可以保證衝突

您不能保證從 A 到 B 的複制是即時的。在開始寫入 B 之前，您需要停機時間才能完成從 A 到 B 的複制。停機時間的長短取決於應用程序的寫入密集程度以及複製的速度。

引用自：https://dba.stackexchange.com/questions/197253