Strani problemi di bloccaggio durante la riproduzione di registri per percona

Question

Problema durante la riproduzione dei registri

Sono in fase di benchmarking di un nuovo nodo DB (specifiche alla fine) e ho incontrato uno strano comportamento:

Come descritto qui io:

• Creato una discarica (innobackupex ftw)
• Ho registrato tutte le mie domande per un'ora
• Imposta il mio nuovo db (stesso my.cnf come db dal vivo solo con un superiore innodb_buffer_pool_size)
• Ha iniziato il replay del mio registro di query lento

Secondo la documentazione:

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

Funziona bene per circa 15 minuti, quindi inizio a ottenere strani problemi di bloccaggio:

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

Ho iniziato a eseguire il debug del mio carico attuale sul DB e ho scoperto che era in esecuzione una sola query:

(preso da Stato innodB)

---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

E solo una tabella aperta:

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)

Questa situazione rimane così per circa 3-4 minuti e poi improvvisamente la riproduzione continua.

Questi problemi non si verificano sul DB live: abbiamo alcuni problemi con il blocco ma non abbiamo mai superato il innodb_lock_wait_timeout valore.

Molto probabilmente mi sto perdendo qualcosa di ovvio, ma per la mia vita non riesco a capirlo, ma perché il replay dovrebbe rimanere così o meglio ancora perché Mysql dovrebbe rimanere in questo stato di blocco?

Le voci pertinenti nel registro lento provengono dal nostro server 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;

La gestione delle transazioni di Hibernate ha qualcosa a che fare con il modo in cui il blocco viene generato e non chiuso?

Specifiche del server

• Ubuntu 12.04.2 LTS
• Percona-Server-Server-5.5 Versione 5.5.32-Rel31.0-549.Precise

Relavent Config:

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

Configurazione 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

Grazie per qualsiasi aiuto o esperienza in questo settore!

Modificare

Ho giocato con alcune delle variabili innodb e con l'aiuto di innodb_show_verbose_locks sono stato in grado di determinare un po 'di più. In questo esempio:

---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;;

Entrambe le transazioni 1C52D8AA9 e 1C52D8AB4 Avere un blocco IX sull'indirizzo 73757072656d756d che va bene mentre mi raccolgo da questo post Poiché INNODB utilizza il blocco MGL. Tuttavia il follow -up X Bloccamento (Visto qui: "ID 1C52D8AB4 Lock_Mode X Inserisci Intenzione in attesa") Manca.