測試環(huán)境:
MySQL?5.5.14
在數(shù)據(jù)庫testdb01下有表tb1001,當前表中存有兩條數(shù)據(jù):
##=========================================================##
發(fā)現(xiàn)竟然返回的是空集,沒有任何報錯。
這也就合理解釋我同事操作的現(xiàn)象:在mysqldump過程中,修改表結構,修改操作沒有被阻塞,mysqldump操作也”正常完成“。
由于SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb1001`操作沒有返回錯誤也沒有返回數(shù)據(jù),mysqldump進程會將tb1001當做一個空表來處理,然后繼續(xù)導出后面的表直至導出所有的表然后返回執(zhí)行成功的狀態(tài)。但導出的備份已經缺失tb1001的數(shù)據(jù),如果恰好采用該備份去恢復數(shù)據(jù),那么必然最終導致“數(shù)據(jù)丟失”。
解決辦法:
在對MySQL 5.5版本進行修改表操作前,先檢查當前服務器是否在進行mysqldump操作,避免兩者并行執(zhí)行。
如果對mysqldump已經導出過的表進行修改操作,修改操作會被阻塞,直到mysqldump結束,該情況與MySQL 5.6版本一致。
總結:
對于MySQL 5.5版本,mysqldump與表修改操作同時執(zhí)行:
如果修改表操作在 ”mysqldump開啟后但還未導出修改表數(shù)據(jù)前“ 的時間段內開始,則修改表操作成功完成,而mysqldump不會執(zhí)行失敗,但是無法正常導出修改表的數(shù)據(jù);
如果修改表操作在 “mysqldum已導出修改表數(shù)據(jù)但還未結束mysqldump操作前”的時間段內開始,則修改表操作被阻塞,mysqldum能成功完成,在mysqldump操作完成后修改表操作方可正常執(zhí)行。
對于MySQL 5.5版本,應該避免mysqldump和修改表操作同時進行,以避免備份丟失修改表的數(shù)據(jù),造成數(shù)據(jù)不一致!