web-dev-qa-db-ja.com

percona再生を介してログを再生する際の奇妙なロックの問題

ログの再生中に問題が発生する

私は新しいDBノード（最後の仕様）のベンチマークを行っている最中で、いくつかの奇妙な動作に遭遇しました：

説明したように ここ i：

  • ダンプを作成しました（innobackupex ftw）
  • すべてのクエリを1時間ログに記録しました
  • 新しいデータベースをセットアップします（ライブデータベースと同じmy.cnfで、より高いinnodb_buffer_pool_size）
  • 遅いクエリログの再生を開始しました

ドキュメントによると：

percona-playback --mysql-Host=127.0.0.1\
--mysql-user=root --mysql-schema=my_db\
--query-log-file=slow.log

これは約15分間正常に機能し、その後、奇妙なロックの問題が発生し始めます。

Error during query: Lock wait timeout exceeded; try restarting transaction, number of tries 0

データベースの現在の負荷のデバッグを開始しましたが、実行されているクエリは1つだけでした。

（innodb statusから取得）

---TRANSACTION 1C5264768, ACTIVE 44 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 4289, OS thread handle 0x7f7fb0779700, query id 77515 localhost     127.0.0.1 root update
insert into sessions (a, b, c, d, e, e, f, g, h, i, j, k, l, m, n, o, p, q) values (0, 682,
------- TRX HAS BEEN WAITING 44 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 4549 page no 7875876 n bits 104 index `PRIMARY` of table `production`.`sessions` trx id 1C5264768 lock_mode X insert intention waiting
------------------
TABLE LOCK table `production`.`sessions` trx id 1C5264768 lock mode IX
RECORD LOCKS space id 4549 page no 7875876 n bits 104 index `PRIMARY` of table `production`.`sessions` trx id 1C5264768 lock_mode X insert intention waiting
---TRANSACTION 1C526475D, ACTIVE (PREPARED) 452 sec
2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 1722, OS thread handle 0x7f7fb083d700, query id 77311 localhost 127.0.0.1 root
Trx read view will not see trx with id >= 1C526475E, sees < 1C525BA04
TABLE LOCK table `production`.`sessions` trx id 1C526475D lock mode IX
RECORD LOCKS space id 4549 page no 7875876 n bits 104 index `PRIMARY` of table `production`.`sessions` trx id 1C526475D lock_mode X
----------------------------
END OF INNODB MONITOR OUTPUT

そして、開いているテーブルは1つだけです。

mysql> SHOW OPEN TABLES from production where In_use != 0;
+----------------------+--------------+--------+-------------+
| Database             | Table        | In_use | Name_locked |
+----------------------+--------------+--------+-------------+
| production           | sessions     |      1 |           0 |
+----------------------+--------------+--------+-------------+
1 row in set (0.00 sec)

この状況は約3〜4分間このままで、その後突然再生が続行されます。

これらの問題はライブデータベースでは発生しません。ロックにいくつかの問題がありますが、innodb_lock_wait_timeoutの値を超えたことはありません。

私はおそらく明らかな何かを見逃している可能性がありますが、私の人生ではそれを理解することはできませんが、なぜリプレイがそのようにハングするのでしょうか、それでもmysqlがこのロック状態のままになるのはなぜですか？

遅いログの関連エントリは、jeeサーバーからのものです。

XA START 0xbe681101606ce8d1676630322c7365727665722c5035313337,0x676630322c7365727665722c50353133372c00,0x4a5453;
insert into sessions (a, b, c, d, e, e, f, g, h, i, j, k, l, m, n, o, p, q) values (0, 682, ...);
XA END 0xbe681101606ce8d1676630322c7365727665722c5035313337,0x676630322c7365727665722c50353133372c00,0x4a5453;

Hibernateのトランザクション処理は、ロックが生成されて閉じられない方法と関係がありますか？

サーバーの仕様

  • Ubuntu 12.04.2 LTS
  • percona-server-server-5.5バージョン5.5.32-rel31.0-549.precise

関連する構成：

max_connections         = 1500
sort_buffer_size        = 1M
thread_cache_size       = 1000
max_heap_table_size     = 512M
tmp_table_size          = 512M
join_buffer_size        = 67108864
expand_fast_index_creation = ON
open_files_limit        = 65535
table_definition_cache  = 4096
table_open_cache        = 262144
max_allowed_packet      = 16M
thread_stack            = 192K
query_cache_limit       = 1M
query_cache_size        = 512M
thread_concurrency      = 8
query_cache_type        = 1
long_query_time         = 2
log_slave_updates       = 1
expire_logs_days        = 10
max_binlog_size         = 100M

Innodb構成：

default_storage_engine   = InnoDB
innodb_file_per_table    = 1
innodb_old_blocks_time   = 1000
innodb_buffer_pool_size  = 163456M
innodb_log_file_size     = 256M
innodb_flush_method      = O_DIRECT
innodb_read_io_threads   = 4
innodb_write_io_threads  = 4
innodb_doublewrite       = FALSE
innodb_flush_log_at_trx_commit = 2

この分野での助けや経験に感謝します！

編集

私はいくつかのinnodb変数で遊んでいて、 innodb_show_verbose_locks の助けを借りてもう少し決定することができました。この例では：

---TRANSACTION 1C52D8AB4, ACTIVE 49 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 18602, OS thread handle 0x7f007a4a0700, query id 624263 localhost 127.0.0.1 root update
INSERT INTO `images` (A,B,C...) VALUES (....)
------- TRX HAS BEEN WAITING 49 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 51 page no 16791 n bits 152 index `PRIMARY` of table `production`.`images` trx id 1C52D8AB4 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

------------------
TABLE LOCK table `production`.`images` trx id 1C52D8AB4 lock mode IX
RECORD LOCKS space id 51 page no 16791 n bits 152 index `PRIMARY` of table `production`.`images` trx id 1C52D8AB4 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

---TRANSACTION 1C52D8AA9, ACTIVE 151 sec
2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 18460, OS thread handle 0x7f007454e700, query id 624243 localhost 127.0.0.1 root
TABLE LOCK table `production`.`images` trx id 1C52D8AA9 lock mode IX
RECORD LOCKS space id 51 page no 16791 n bits 152 index `PRIMARY` of table `production`.`images` trx id 1C52D8AA9 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

トランザクション1C52D8AA9と1C52D8AB4の両方に、アドレス73757072656d756dのIXロックがあります。 innodbはMGLロックを使用しているため、 この投稿 から収集しても問題ありません。ただし、フォローアップXロック（ここに表示： "id 1C52D8AB4 lock_mode X挿入意図待機中"）がありません。

mysqlmysql-5.5perconapercona-toolspercona-server
2
tnosaj

私は答えを見つけたようです...少なくともそれはうまくいきます。

数時間の試行錯誤の末、問題は遅いログのトランザクションにあるように見えました。これをサポートするドキュメントが見つからなかったので、ツールを間違って使用しているだけなのかどうかはまだわかりません。

私はすべてコメントしました：

  • XAスタート
  • XA END
  • XA COMMMIT
  • XA準備
  • ベギン;
  • コミット;

私のログからの行、そしてそれは単一のロックなしで機能しました。

2
tnosaj