最近業務高峰期間經常會有開發跳起來說應用連接數據庫超時了！ 我們來看下mysql的運行狀態 Waiting for release of readlock：等待釋放全局鎖 The thread is waiting for a global read lock obtained by another thread (with FLUSH TABLES WITH READ LOCK) to be released.This state was removed in MySQL 5.5.8; Waiting for global read lock or Waiting for commit lock are used instead. Waiting for table：等待表 Waiting for tables, Waiting for table, Waiting for table flush The thread got a notification that the underlying structure for a table has changed and it needs to reopen the table to get the new structure. However, to reopen the table, it must wait until all other threads have closed the table in question. This notification takes place if another thread has used FLUSH TABLES or one of the following statements on the table in question: FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, or OPTIMIZE TABLE. In MySQL 5.5.6, Waiting for table was replaced with Waiting for table flush. 線程獲得一個通知，底層表結構已經發生變化，它需要重新打開表來獲取新的結構。然而，重新打開表，它必須等到所有其他線程關閉這個有問題的表。 這個通知產生通常因為另一個線程對問題表執行了FLUSH TABLES或者以下語句之一：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, or OPTIMIZE TABLE. 查看crontab，每天定時執行備份任務

/usr/local/mysql/bin/mysqldump?--user=$bakuser?--patestdbword=$bakpwd?--skip-opt?--master-data=2?--single-transaction?--add-drop-table?--create-options?--quick?--extended-insert?--set-charset?--disable-keys?--triggers?-R?--flush-logs?--databases?testdb?>?testdb.sql?

--master-data[=#]???This?causes?the?binary?log?position?and?filename?to?be?

??????????????????????appended?to?the?output.?If?equal?to?1,?will?print?it?as?a?

??????????????????????CHANGE?MASTER?command;?if?equal?to?2,?that?command?will?

??????????????????????be?prefixed?with?a?comment?symbol.?This?option?will?turn?

??????????????????????--lock-all-tables?on,?unless?--single-transaction?is?

??????????????????????specified?too?(in?which?case?a?global?read?lock?is?only?

??????????????????????taken?a?short?time?at?the?beginning?of?the?dump;?don't?

??????????????????????forget?to?read?about?--single-transaction?below).?In?all?

??????????????????????cases,?any?action?on?logs?will?happen?at?the?exact?moment?

??????????????????????of?the?dump.?Option?automatically?turns?--lock-tables??off.?

這個參數會運行--lock-all-tables，將master的binlog和postion信息寫入SQL文件的頭部，除非結合--single-transaction（但并不是說就完全的不會鎖表了，執行的時候也會添加短暫的全局讀鎖） ====================================================================================== 我們來重現一下這個場景

/usr/local/mysql/bin/mysqldump?-u?root?-p??--skip-opt?--master-data=2?--single-transaction?--add-drop-table?--create-options?--quick?--extended-insert?--set-charset?--disable-keys?--triggers?-R?--flush-logs?--databases?testdb?>?testdb.sql?

執行插入

mysql>?call?insT1(10000000);?

30s后執行【如果同時執行，效果不明顯】

/usr/local/mysql/bin/mysqldump?-u?root?-p??--skip-opt?--master-data=2?--single-transaction?--add-drop-table?--create-options?--quick?--extended-insert?--set-charset?--disable-keys?--triggers?-R?--flush-logs?--databases?testdb?>?testdb1.sql?

執行插入

mysql>?call?insT2(1000000);?

等待刷表 不使用--single-transaction 等待全局讀鎖釋放 不使用--master-data，再跑上面的2個場景，mysql不會加鎖，所以SQL很快執行完成 結論：因為選用--master-data參數在SQL文件的頭部會寫入binlog和position信息，所以在執行備份前mysql需要執行flush tables，搭建過從庫的同學都了解，我們在獲取完整備份前都要執行FLUSH TABLES WITH READ LOCK;來獲取這些主庫當前信息，這里也是這樣。 生產環境還是復雜的，大家會注意到我們同時使用了--msater-date和--single-transation但還是出現了全局讀鎖，可是在測試環境，只有不加--single-transation的時候才會出現。 解決方法： 1.如果你只需要文件備份，不需要經常建立從庫，那么可以去掉--master-data。 2.如果你的數據量很大 or 備份時的master信息非常需要，那么可以調整備份周期，避開兩次備份出現重疊的情況。

轉載于:https://blog.51cto.com/mckobe23/1155139

總結

以上是生活随笔為你收集整理的mysqldump重叠备份带来的锁表问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。