FLUSH TABLES WITH READ LOCKをバックグラウンドで実行する処理がある場合に、
長時間実行しているバッチなどの処理があると、後から実行されるQueryが待たされるケースがある。
そんな、話を多からず、少なからず質問頂くので一応メモとして動作を記録。

通常は、データベース側の処理はDurationは短いので問題無いですが。。。
長時間バッチが実行されるような処理がある場合を避けて、FLUSH TABLES WITH READ LOCKを含む処理を実行するのが良さそうです。
MyISAMが全て無くなればまた、少しだけ選択肢が増えそうです。

http://dev.mysql.com/doc/mysql-enterprise-backup/3.9/en/backup-capacity-options.html#option_meb_no-locking

http://dev.mysql.com/doc/mysql-enterprise-backup/3.7/en/backup-partial-options.html#option_meb_only-innodb

処理1

select * from actor where (select sleep(30));

処理2

mysql> FLUSH TABLES WITH READ LOCK;

処理3

mysql> insert into sakila.city(city,contry_id) values('Tokyo',00);

処理1が終わるまで全てGlobalロックによって待たされる。
処理1をKillすると処理2が瞬時に完了するので。以下のコマンドでUnlockしてあげると待たされていた処理が全て完了する。

処理4

UNLOCK TABLES

WorkbenchとShow Processlistで確認
wait

waitquery

以下sysスキーマで待機時間の長いQueryを確認
sys_schema

参考: 13.3.5 LOCK TABLES and UNLOCK TABLES Syntax

Comments are closed.

Post Navigation