Uzun açık transaction'lar ve history list length (purge gecikmesi)

Komut

-- Purge edilmeyi bekleyen undo kayitlari (milyonlar = sorun)
SELECT NAME, COUNT AS history_list_length
FROM information_schema.INNODB_METRICS WHERE NAME = 'trx_rseg_history_len';

-- En eski transaction'lar, sahibi ve son SQL'i
SELECT trx.trx_id, trx.trx_mysql_thread_id AS conn_id, trx.trx_state,
       TIMESTAMPDIFF(SECOND, trx.trx_started, NOW()) AS age_sec,
       trx.trx_rows_modified, trx.trx_rows_locked, trx.trx_isolation_level,
       p.USER, p.HOST, p.COMMAND, p.TIME AS state_sec,
       LEFT(COALESCE(trx.trx_query, esc.SQL_TEXT), 80) AS current_or_last_sql
FROM information_schema.INNODB_TRX trx
JOIN performance_schema.processlist p ON p.ID = trx.trx_mysql_thread_id
LEFT JOIN performance_schema.threads th ON th.PROCESSLIST_ID = trx.trx_mysql_thread_id
LEFT JOIN performance_schema.events_statements_current esc ON esc.THREAD_ID = th.THREAD_ID
ORDER BY trx.trx_started
LIMIT 10;

Ne yapar?

Purge'ün ne kadar geride olduğunu (history list length) ve purge'ü tutan en eski transaction'ları; sahibini, yaşını, değiştirdiği satır sayısını ve çalıştırdığı son SQL'i gösterir.

Ne zaman kullanılır?

Undo tablespace büyüdüğünde, aynı sorgular zamanla yavaşladığında (eski satır versiyonlarını taradıkları için) veya disk alanı alarmında.

Dikkat

En yaygın neden Sleep durumunda ama transaction'ı açık bir oturum veya REPEATABLE READ'de unutulmuş consistent snapshot'tır (ör. yarıda bırakılmış bir mysqldump / rapor). KILL sonrası rollback, transaction'ın değiştirdiği satır kadar sürer; trx_rows_modified yüksek bir transaction'ı öldürmek uzun ve IO yoğun bir rollback demektir, restart da bu süreyi kısaltmaz. Undo, purge ilerledikçe kendiliğinden truncate edilir (innodb_undo_log_truncate=ON).