mysqldump引發的一系列問題
問題背景
- 生產環境數據異常，需要批量執行sql進行修復。修復之前需要把生產數據導入測試環境數據庫，先對測試環境數據進行修復驗證。
解決過程
- 第一步：首先徵求項目經理意見，允許將生產環境數據導入到測試環境數據庫。
- 第二步：生產數據導出，我選擇的是通過mysqldump命令：
mysqldump -h10.11.20.98 -P3306 -uweifan -pweifan aipc --skip-lock-tables --skip-add-locks > D:\aipc_prd.dump
- 第三步：將生產數據導入測試環境數據庫，我選擇的是通過mysql命令：
mysql -h172.30.1.75 -P3306 -uaipc -pweifan aipc-uat < D:\aipc_prd.dump
執行mysql導入命令，報錯：
ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
最直觀的翻譯是說權限的問題，一般是mysql的用戶創建後沒給權限；但也可能是其他原因！！！
問題1
- 用編輯器打開dump文件（其實是想定位第18行內容），意外發現導出的dump文件中，全是亂碼！
解決
- 使用mysqldump命令時，增加參數：–default-character-set=utf8：
mysqldump -h10.11.20.98 -P3306 -uweifan -pweifan aipc --skip-lock-tables --skip-add-locks --default-character-set=utf8 > D:\aipc_prd.dump
再次執行數據導出，發現dump文件依舊亂碼！！！
- 究其原因發現，數據庫中表字段使用了blob類型，在面對BINARY, VARBINARY, BLOB, BIT類型時，mysqldump只能導出爲“亂碼”，可以使用參數：–hex-blob 避免
mysqldump -h10.11.20.98 -P3306 -uweifan -pweifan aipc --skip-lock-tables --skip-add-locks --default-character-set=utf8 --hex-blob > D:\aipc_prd.dump
- 再次執行mysqldump命令，成功導出無亂碼dump文件。
問題2
- 用編輯器打開dump文件，定位到18行顯示的是一個這樣的語句： SET @@SESSION.SQL_LOG_BIN= 0；
解決
- 手動將dump文件的第18行內容刪除，並將SET @@ 格式內容一併刪除，再執行mysql導入命令，確實可以成功導入，但是dump文件一旦過大，不可能採用此手動刪除方式去解決問題。
- 究其根本原因：如果數據庫用GTID模式，在mysqldump數據時，應該加上參數–set-gtid-purged=OFF，此時導出的sql文件將不會包含SET @@等內容
mysqldump -h10.11.20.98 -P3306 -uweifan -pweifan aipc --skip-lock-tables --skip-add-locks --default-character-set=utf8 --hex-blob --set-gtid-purged=OFF > D:\aipc_prd.dump
- 到此，mysqldump導出可執行的dump文件已經結束。
- 再次執行mysql導入命令：
mysql -h172.30.1.75 -P3306 -uaipc -pweifan aipc-uat --default-character-set=utf8 < D:\aipc_prd.dump
因爲導出的時候指定了字符集，導入時也需要指定字符集。
總結
- 本來以爲很簡單的mysql數據導出導入，引發了一系列問題，對mysql數據庫加深了認識。技術的領域博大精深，任何小問題都會引出一堆未知領域的問題，比如：Mysql GTID。