導入從源中排除表的數據庫 mysqldump 是否會保留目標中的表？

Question

將數據庫 ( db1 ) 從一台服務器移動到另一台服務器，並且有一個表 ( big_table ) 如此之大，以至於導入目標所需的時間比我們首選的維護 window 所以我們保持應用程序與源數據庫服務器通信，而目的地繼續進口。

現在我們要重做該過程以通過兩個步驟獲取更改的內容：

對於第一步，這是否可以在重新創建所有其他表時保留目標中的db1和db.big_table ？

mysqldump -h host1 db1 --ignore-table=db1.big_table --no-create-db | mysql -h host2 db1

對於第二步，如果我知道自已知時間戳以來big_table中沒有更新且只有新記錄，這會起作用嗎？

mysqldump -h host1 db1 big_table --no-create-info --where "timestamp > '${LAST_EXPORTED_TIMESTAMP}'" | mysql -h host2 db1

我試圖了解自第一次導入目標以來對源更改的這些“補丁”嘗試中的每一個是否都沒有嘗試刪除/創建db1或db1.big_table而是僅捕獲和導入除big_table之外的所有表和僅新記錄在big_table中，因為一個已知的時間戳。

有沒有比我起草的更好的方法來做到這一點？

Answer 1

mysqldump 沒有一張那么大的表（big_table）；
你可以使用 meb 或 xtrabackup

Answer 2

更好的方法是使用 MySQL 復制。

對源實例進行完整備份。 您可以使用 mysqldump，但使用像 Percona XtraBackup 這樣的物理備份工具會更快。 確保在備份時捕獲二進制日志坐標（在 XtraBackup 中默認啟用）。
將備份還原到新服務器。 在此過程中，您的應用程序可能會繼續使用舊服務器。
將新服務器配置為舊服務器的副本，即其源。
開始復制，讓所有表的所有更改都復制到新服務器，直到全部趕上。 這可能需要幾分鍾到幾小時，但需要多長時間並不重要，因為在同步時應用程序仍應使用舊服務器。
采取非常短暫的中斷來切換應用程序以使用新服務器。 如果您的流量非常繁忙，您可能希望在讓應用程序將其用於讀寫流量之前特別確保它已完全趕上。 但這很可能只需要幾秒鍾。

Answer 3

盡管比爾提出的不同路徑是從頭到尾利用內置復制的更優雅的解決方案，但我正在回答實際問題，即是否已經開始嘗試從源遷移到目標（使用 mysqldump 和定向輸出）並嘗試使用從源頭開始的更改來修補（選擇性地重做）它，我能否確保不會覆蓋或刪除已經在目的地的大表。

我最初計划嘗試忽略big_table並只執行big_table中的行並寫入文件並檢查結果，以確保沒有任何語句會導致任何創建、刪除或其他我沒有在何時何地創建想要它。 為了確定，我還准備了目標的/var/lib/mysql的備份副本。

我為這個“追趕”采取的路徑只需要停止應用程序一小段時間，即使包含完整big_table的原始導入嘗試花費了相當長的時間（小時）。

通過重做完整轉儲來更新主db1數據庫（省略big_table時這並沒有花費太多時間，因為相比之下其他所有內容都很小）：
```
 mysqldump -h host1 db1 --ignore-table=db1.big_table --no-create-db | mysql -h host2 db1
```

因為我知道big_table中沒有更新，只有新記錄（重要的區別在於這很簡單，因為不需要更新）並且 id 是增量的，我能夠：

獲取目的地的最后一個 id：

 mysql -h host2 -ve "SELECT id FROM db1.big_table ORDER BY id DESC LIMIT 1"

然后提取並僅將新記錄從源加載到目標（假設上面的id為 4567890）：

 mysqldump -h host1 db1 big_table --no-create-info --where "id > 4567890" | mysql -h host2 db1

它運行良好，完成了我在這項工作和用例中所需要的。 如果要再次執行此操作，或者使用更復雜的表進行更新，而不是僅使用新記錄或多個像這樣非常大的表，我可能會調查 Bill 提出的使用復制的路徑，並讓 mysql 完成繁重的工作。