網(wǎng) 站的數(shù)據(jù)會定期備份，現(xiàn)在數(shù)據(jù)大了，mysqldump 方法估計是不行了，并且失敗了以后并不能接著上次的位置開始備份。報錯內(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 的時候（尤其是向 NFS 上備份的時候），很多人都被“mysqldump:Got error:2013: Lost connection to MySQL server during query when dumping table”的問題困擾，在Manual中對這個問題有一些簡單的說明。

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

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

Lost connection to MySQL server during query 錯誤

造成這樣的錯誤原因很多

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

bind-address = 127.0.0.1

skip-name-resolve

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

也就是說遇到2006,2013錯誤就重新連接一下MySQL。

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

wait_timeout = x 超時時間

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

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

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

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

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

更多信息請查看IT技術(shù)專欄