MySQL數據庫遷移缺少數據

我不確定這是否應該在SuperUser中發佈，因爲我們正在使用Workbench中內置的遷移向導，請讓我知道這個問題是否應該移動。MySQL數據庫遷移缺少數據

目的
我們目前正處在從一臺服務器數據庫遷移到另一個，因爲MySQL工作臺有一個內置的叫遷移向導功能，我們認爲我們將繼續我們的快樂的方式遷移它的過程。我們有16種不同的數據庫模式，需要以不同的大小進行遷移（最小爲3 MB，最大爲76 GB）。

問題
我們開始試圖遷移中到大尺寸的那些坐在14.7 GB，並開始了罰款之一，但之後它已成功遷移的表的一半在那一個我們得到的錯誤「 MySQL服務器已經消失「。確保連接穩定並連接電纜（可能是無線信號掉線？）並確保完全權限並使用root用戶進行遷移後，我們仍然得到「服務器已經消失」的錯誤。

然後我們嘗試了可以正常工作的小型數據庫，所以我們認爲這可能是一個超時問題。我們嘗試刪除超時設置，但對於較大的數據庫，我們仍然得到相同的錯誤。真正的踢球手就是我們目前正在經歷的。

當我們在150 MB數據庫上嘗試此操作時，遷移向導會正確完成遷移，而不會出現任何錯誤或警告。出於好奇，我跑了下面的代碼

SELECT table_name AS "Table", 
round(((data_length + index_length)/1024/1024), 2) "Size in MB" 
FROM information_schema.TABLES 
WHERE table_schema = "TableName" 
ORDER BY "Table";

爲了確保表的大小是正確的。令我們驚訝的是，源數據庫中的表格總和爲150 MB，但目標數據庫中的總和爲94 MB。

問題（S）
可能一些其他的原因是爲了什麼，爲什麼我們得到的超時溢出和特權除了「服務器已經走了」的錯誤？爲什麼遷移向導會說遷移沒有任何警告或錯誤就成功了，但實際上只有大約60％的數據被遷移了？遷移向導是不可信的，還是不應該被信任的表大小查詢？我們是否正在討論這個完全錯誤的問題，即，您是否推薦另一種更穩定的數據庫遷移方式？

如果需要，我很樂意提供更多信息。

編輯：
的MySQL版本：5.1.41（Ubuntu的）

我們還檢查的行數在每個表中每一個模式雖然大部分是正確的，有些翻錯了。這是數據不一致的地方。在150 MB/94 MB的例子中有25個表。在這25張桌子中，有23張是正確的，2張是不正確的。在源代碼中，其中一個表格有257萬行，但只有150萬行結束於目標表中。

編輯2：
運行相同的查詢再次，現在給我150 94 150 8 150 24，現在第四次遷移它整個數據庫。我猜這個問題位於其他地方，但不能爲我的生活找出原因。花了92分鐘遷移150 MB的數據。推斷，這將給我大約一個月的時間來遷移75 GB的數據庫 - 顯然是不正確的。

來源

2014-09-02 MagneTism

這看起來像是一個計時問題，該會話或my.cnf中交互式timout和等待超時的當前值是什麼？你測試設置爲0（無限）嗎？ – 2014-09-02 13:54:29

我們查看了my.cnf，但找不到任何看起來像交互式或等待超時的參數。我們在尋找什麼特定的參數？感謝您抽出寶貴時間。 – MagneTism 2014-09-02 14:11:12

[interactive_timeout]（http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_interactive_timeout）默認爲28800，即8小時。 – 2014-09-02 14:14:55

數據庫中的大小可能會有所不同，即使它包含相同的數據。在遷移時，您還要對數據進行碎片整理
我不會信任具有這麼多數據的遷移向導。 MySQL不能很好地處理大量數據，如果MySQL沒有以嚴格模式運行，插入和其他內容可能會以靜默方式失敗或僅在警告時失敗。
如果你正在遷移一切（也包括用戶和元數據），只需在兩個DB都關閉的情況下複製/ rsync整個mysql_data文件夾。

來源

2014-09-04 09:51:36

因爲在工作時收到低優先級而不能回覆您的道歉：S但現在我回來了！ :)我檢查了一些行數的數據，看起來在3.12百萬行中，我在mysqldump遷移過程中丟失了20 000行，所以我肯定會丟失一些數據。你知道這可能是什麼原因嗎？ – MagneTism 2014-10-02 10:34:49

MySQL數據庫遷移缺少數據

回答

相關問題