十年網(wǎng)站開發(fā)經(jīng)驗(yàn) + 多家企業(yè)客戶 + 靠譜的建站團(tuán)隊(duì)
量身定制 + 運(yùn)營(yíng)維護(hù)+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
mysql導(dǎo)入sql文件報(bào)錯(cuò)的原因
專注于為中小企業(yè)提供成都做網(wǎng)站、網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)博樂免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動(dòng)了上千多家企業(yè)的穩(wěn)健成長(zhǎng),幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
1.在討論這個(gè)問題之前,先介紹一下什么是“大數(shù)據(jù)量sql文件”。
導(dǎo)出sql文件。
導(dǎo)入mysql sql文件出錯(cuò)的原因,導(dǎo)入數(shù)據(jù)庫出錯(cuò)的原因。
選擇數(shù)據(jù)庫-右鍵單擊并選擇轉(zhuǎn)儲(chǔ)SQL文件-選擇結(jié)構(gòu)和數(shù)據(jù)。保存文件db_mras.sql文件。
2.導(dǎo)入sql文件。在MYSQL中新建一個(gè)數(shù)據(jù)庫db_mras。
導(dǎo)入mysql sql文件出錯(cuò)的原因,導(dǎo)入數(shù)據(jù)庫出錯(cuò)的原因。
選擇database——右擊并選擇“運(yùn)行SQL文件”——選擇文件db_mras.sql并運(yùn)行它。
現(xiàn)在發(fā)現(xiàn)操作失敗,提示錯(cuò)誤“MySQL服務(wù)器已經(jīng)不在了”。為了解決這個(gè)問題,提出了以下解決方案:
這個(gè)錯(cuò)誤意味著客戶端和mysql之間的鏈接斷開了,通常是因?yàn)閟ql運(yùn)行時(shí)間太長(zhǎng)或者sql文件太大。
排除問題原因:
(1)mysql服務(wù)宕機(jī)。
運(yùn)行命令:顯示全局狀態(tài),如“正常運(yùn)行時(shí)間”;如果uptime的值很大,說明最近沒有重啟mysql服務(wù)。如果日志中沒有相關(guān)信息,說明服務(wù)沒有重啟,可以排除這種可能。
(2)mysql鏈接超時(shí)
運(yùn)行命令:顯示像“% timeout”這樣的全局變量;檢查運(yùn)行結(jié)果中wait_timeout的值,一般為28800。意味著mysql鏈接在誤操作28800秒后會(huì)被關(guān)閉。
(3)mysql文件過大
運(yùn)行命令:顯示像“max _ allowed _ packet”這樣的全局變量;檢查max_allowed_packet的值作為運(yùn)行結(jié)果。如果太小,就需要調(diào)整。
解決方法:
在mysql的my.ini文件末尾添加以下文字:wait _ timeout = 2880000interactive _ time = 2880000max _ allowed _ packet = 16M
其中max_allowed_packet表示控制緩沖區(qū)的最大長(zhǎng)度。wait_timeout表示無操作環(huán)節(jié)的等待時(shí)間。
修改以上參數(shù)后重啟mysql服務(wù)。
檢查修改是否成功:運(yùn)行命令:顯示' % timeout '之類的全局變量;顯示全局變量,如“max _ allowed _ packet”;
如果找不到my.ini文件,可以運(yùn)行命令:MySQL–help | grep my . ini查找文件路徑。
如果以上方法不能解決你的問題,你還需要檢查一下你的mysql文件安裝盤是否有足夠的空間。
如果從庫上表 t 數(shù)據(jù)與主庫不一致,導(dǎo)致復(fù)制錯(cuò)誤,整個(gè)庫的數(shù)據(jù)量很大,重做從庫很慢,如何單獨(dú)恢復(fù)這張表的數(shù)據(jù)?通常認(rèn)為是不能修復(fù)單表數(shù)據(jù)的,因?yàn)樯婕暗礁鞅頎顟B(tài)不一致的問題。下面就列舉備份單表恢復(fù)到從庫會(huì)面臨的問題以及解決辦法:
場(chǎng)景 1
如果復(fù)制報(bào)錯(cuò)后,沒有使用跳過錯(cuò)誤、復(fù)制過濾等方法修復(fù)主從復(fù)制。主庫數(shù)據(jù)一直在更新,從庫數(shù)據(jù)停滯在報(bào)錯(cuò)狀態(tài)(假設(shè) GTID 為 aaaa:1-100)。
修復(fù)步驟:
在主庫上備份表 t (假設(shè)備份快照 GTID 為 aaaa:1-10000);
恢復(fù)到從庫;
啟動(dòng)復(fù)制。
這里的問題是復(fù)制起始位點(diǎn)是 aaaa:101,從庫上表 t 的數(shù)據(jù)狀態(tài)是領(lǐng)先其他表的。aaaa:101-10000 這些事務(wù)中只要有修改表 t 數(shù)據(jù)的事務(wù),就會(huì)導(dǎo)致復(fù)制報(bào)錯(cuò) ,比如主鍵沖突、記錄不存在(而 aaaa:101 這個(gè)之前復(fù)制報(bào)錯(cuò)的事務(wù)必定是修改表 t 的事務(wù))
解決辦法:?jiǎn)?dòng)復(fù)制時(shí)跳過 aaaa:101-10000 這些事務(wù)中修改表 t 的事務(wù)。
正確的修復(fù)步驟:
1. 在主庫上備份表 t (假設(shè)備份快照 GTID 為 aaaa:1-10000),恢復(fù)到從庫;
2. 設(shè)置復(fù)制過濾,過濾表 t:
CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t');
3. 啟動(dòng)復(fù)制,回放到 aaaa:10000 時(shí)停止復(fù)制(此時(shí)從庫上所有表的數(shù)據(jù)都在同一狀態(tài),是一致的);
START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000';
4. 刪除復(fù)制過濾,正常啟動(dòng)復(fù)制。
注意事項(xiàng):這里要用 mysqldump --single-transaction --master-data=2,記錄備份快照對(duì)應(yīng)的 GTID
場(chǎng)景 2
如果復(fù)制報(bào)錯(cuò)后,使用跳過錯(cuò)誤、復(fù)制過濾等辦法修復(fù)了主從復(fù)制。主、從庫數(shù)據(jù)一直在更新。
修復(fù)步驟:
在主庫上備份表 t (假設(shè)備份快照 GTID為 aaaa:1-10000);
停止從庫復(fù)制,GTID為 aaaa:1-20000;
恢復(fù)表 t 到從庫;
啟動(dòng)復(fù)制。
這里的問題是復(fù)制起始位點(diǎn)是 aaaa:20001,aaaa:10000-20000 這些事務(wù)將不會(huì)在從庫上回放,如果這里面有修改表 t 數(shù)據(jù)的事務(wù),從庫上將丟失這部分?jǐn)?shù)據(jù)。
解決辦法:從備份開始到啟動(dòng)復(fù)制,鎖定表 t,保證 aaaa:10000-20000 中沒有修改表 t 的事務(wù)。
正確修復(fù)步驟:
對(duì)表 t 加讀鎖;
在主庫上備份表 t;
停止從庫復(fù)制,恢復(fù)表 t;
啟動(dòng)復(fù)制;
解鎖表 t。
如果是大表,這里可以用可傳輸表空間方式備份、恢復(fù)表,減少鎖表時(shí)間。
轉(zhuǎn)載:
wordpress官方的相關(guān)說明是只要在數(shù)據(jù)庫支持utf8mb4的時(shí)候會(huì)把部分?jǐn)?shù)據(jù)表的編碼升級(jí)為utf8mb4,如果不支持就不會(huì)轉(zhuǎn)化為utf8mb4編碼(wordpress 4.4版本支持mysql 5.0+)。
解決方法:
方法一:替換編碼
使用代碼編輯器打開導(dǎo)出的sql數(shù)據(jù)文件;
先查找:
utf8mb4_unicode_ci
替換為:
utf8_general_ci
再查找
utf8mb4
替換為
utf8
注意:一定要按照上面的順序進(jìn)行替換,否則不能替換成功。
PS:博客吧通過該方法導(dǎo)入成功,暫時(shí)沒有發(fā)現(xiàn)有問題,但還是要先備份好數(shù)據(jù)再進(jìn)行操作。
方法二:把網(wǎng)站要用的mysql數(shù)據(jù)庫升級(jí)到5.5.3以上版本。