2010年 7月 15日
select t_b.trx_mysql_thread_id blocking_id,
t_w.trx_mysql_thread_id requesting_id,
p_b.HOST blocking_host,
p_w.HOST requesting_host,
l.lock_table lock_table,
l.lock_index lock_index,
l.lock_mode lock_mode,
p_w.TIME seconds,
p_b.INFO blocking_info,
p_w.INFO requesting_info
from information_schema.INNODB_LOCK_WAITS w,
information_schema.INNODB_LOCKS l,
information_schema.INNODB_TRX t_b,
information_schema.INNODB_TRX t_w,
information_schema.PROCESSLIST p_b,
information_schema.PROCESSLIST p_w
where w.blocking_lock_id = l.lock_id
and w.blocking_trx_id = t_b.trx_id
and w.requesting_trx_id = t_w.trx_id
and t_b.trx_mysql_thread_id = p_b.ID
and t_w.trx_mysql_thread_id = p_w.ID
order by requesting_id,
blocking_id
\G
実行結果(横)です。
+-------------+---------------+-----------------+-----------------+---------------+------------+-----------+---------+---------------+---------------------------------------------------+
| blocking_id | requesting_id | blocking_host | requesting_host | lock_table | lock_index | lock_mode | seconds | blocking_info | requesting_info |
+-------------+---------------+-----------------+-----------------+---------------+------------+-----------+---------+---------------+---------------------------------------------------+
| 8 | 9 | localhost:37001 | localhost:37002 | `scott`.`emp` | `PRIMARY` | X | 72 | NULL | update emp set sal = sal + 200 where empno = 7788 |
+-------------+---------------+-----------------+-----------------+---------------+------------+-----------+---------+---------------+---------------------------------------------------+
1 row in set (0.01 sec)
実行結果(縦)です。
*************************** 1. row ***************************
blocking_id: 8
requesting_id: 9
blocking_host: localhost:37001
requesting_host: localhost:37002
lock_table: `scott`.`emp`
lock_index: `PRIMARY`
lock_mode: X
seconds: 86
blocking_info: NULL
requesting_info: update emp set sal = sal + 200 where empno = 7788
1 row in set (0.00 sec)
ここから、
といった情報を読み取ることができます。これはOracle
Databaseと遜色のない内容になっており(参考：ロッ
クをつぶせ！ 最初に疑うべき原因（1/3） − ＠IT)、ほぼ完璧といってよいレ
ベルです。
それから、今回の例のようにデー
タベースにTCP/IP経
由で接続している場合は、TCPの
ポート番号からク
ライアントプロセスを特定することができます。
# netstat -np | grep 37001
tcp 0 0 127.0.0.1:37001 127.0.0.1:3306 ESTABLISHED 6105/mysql
tcp 0 0 127.0.0.1:3306 127.0.0.1:37001 ESTABLISHED 6000/mysqld
この例では8番のク
ライアントはmysqlコ
マンドラインツールであり、プロセスIDは6105番であることが分かります。ここまで分かればあとは該当のプロセスをkillするといった暫定
対処や、プログラムを修正するといった本格対処をとることができます。
MySQL InnoDBにおけるロック競合の解析手順 - SH2の日記
データベースの運用で避けられないのが、ロック競合によって起こるシステムトラブルへの対応です。「2時までに終わるはずのバッチ処理が朝になっても終わっていない」とか「負荷が高いわけでもないのにシステムが無応答になっている」といったトラブルが発生したとき、DBエンジニアはそれがロック競合によるものなのかどうかを切り分けて、適切に対処しなければなりません。
これまでInnoDBはロック競合に対してほとんど打つ手がなかったのですが、最近ようやく対処方法がでてきました。今日はその手順を確認していきたいと思います。
前提
今回ご紹介する手順は、MySQLの以下のバージョンを対象にしています。
* MySQL 5.1＋InnoDB Plugin 1.0
* MySQL 5.4
いきなりハードルを上げてしまって申し訳ありませんが、バージョン5.0以下や素の5.1では使えませんのでご注意ください。以降の実行例はすべてMySQL Community Server 5.1.35＋InnoDB Plugin 1.0.3で行ったものです。
というものです、
1年前 |
固定リンク | 2010年 7月 15日 |
