網(wǎng) 站的數(shù)據(jù)會(huì)定期備份，現(xiàn)在數(shù)據(jù)大了，mysqldump 方法估計(jì)是不行了，并且失敗了以后并不能接著上次的位置開(kāi)始備份。報(bào)錯(cuò)內(nèi)容：mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `table name` at row: 23699。

Lost connection to MySQL server，在使用 mysqldump 的時(shí)候（尤其是向 NFS 上備份的時(shí)候），很多人都被“mysqldump:Got error:2013: Lost connection to MySQL server during query when dumping table”的問(wèn)題困擾，在Manual中對(duì)這個(gè)問(wèn)題有一些簡(jiǎn)單的說(shuō)明。

在向NFS上備份的時(shí)候，數(shù)據(jù)的流向是這樣的：MySQL Server 端從數(shù)據(jù)文件中檢索出數(shù)據(jù)，然后分批將數(shù)據(jù)返回給mysqldump 客戶端，然后 mysqldump 將數(shù)據(jù)寫(xiě)入到NFS上。一般地，向 NFS 上寫(xiě)入數(shù)據(jù)的速度較之Server端檢索發(fā)送數(shù)據(jù)的速度要慢得多，這就會(huì)導(dǎo)致 mysqldump 無(wú)法及時(shí)的接受 Server 端發(fā)送過(guò)來(lái)的數(shù)據(jù)，Server 端的數(shù)據(jù)就會(huì)積壓在內(nèi)存中等待發(fā)送，這個(gè)等待不是無(wú)限期的，當(dāng) Server 的等待時(shí)間超過(guò) net_write_timeout（默認(rèn)是60秒）時(shí)它就失去了耐心，mysqldump 的連接會(huì)被斷開(kāi)，同時(shí)拋出錯(cuò)誤 Got error: 2013: Lost connection。

增加 net_write_timeout 可以解決上述的問(wèn)題的。在實(shí)踐中發(fā)現(xiàn)，在增大 net_write_timeout 后，Server 端會(huì)消耗更多的內(nèi)存，有時(shí)甚至?xí)?dǎo)致 swap 的使用（并不確定是不是修改 net_write_timeout 所至）。建議在mysqldump 之前修改 net_write_timeout 為一個(gè)較大的值（如1800），在 mysqldump 結(jié)束后，在將這個(gè)值修改到默認(rèn)的60。

Lost connection to MySQL server during query 錯(cuò)誤

造成這樣的錯(cuò)誤原因很多

個(gè)人經(jīng)驗(yàn)認(rèn)為先試一試這兩個(gè)參數(shù)，大部分都是這個(gè)原因引起的：

bind-address = 127.0.0.1

skip-name-resolve

這兩個(gè)參數(shù)任意一個(gè)就行。

也就是說(shuō)遇到2006,2013錯(cuò)誤就重新連接一下MySQL。

MySQL層面，需要配置一些參數(shù) my.cnf

wait_timeout = x 超時(shí)時(shí)間

max_allowed_packet = y 最大允許數(shù)據(jù)量

一般出現(xiàn)這種情況不是所有例句而是單個(gè)表，請(qǐng)你先修復(fù)表一般都能解決這類(lèi)問(wèn)題

備份不要在數(shù)據(jù)庫(kù)壓力較大的時(shí)候進(jìn)行，每天凌晨備份是比較合適的

如果是事務(wù)型引擎（InnoDB），建議使用 --single-transaction 參數(shù)，這樣可以讓鎖表時(shí)間變得很短。

上 面是做法估計(jì)是行不通了，網(wǎng)站在虛擬主機(jī)上，修改 MySQL 配置是不太可能的。MySQL 官網(wǎng)也有類(lèi)似的報(bào)告 。暫時(shí)只能使用 --ignore-table=<database>.<table> 選項(xiàng)忽略比較大的表暫時(shí)不備份吧。

更多信息請(qǐng)查看IT技術(shù)專(zhuān)欄