如何診斷長時間運行的事務並在可能的情況下保存數據？

Question

我遇到了長時間運行的事務，因此阻止了對數據庫的所有寫入操作。我想知道，診斷這個問題的最佳方法是什麼，可以強制事務提交併保存當前掛起的數據？

背景信息：該應用程序使用使用pymysql在python中編寫的自定義DAO/ORM。我對這段代碼沒有太多的信心，但它已經運行了一段時間，這個問題從2天前就開始出現了。

我的嘗試：我從來沒有見過這樣的事情，所以我所嘗試的一切都基於googlefu。 我通過查看SHOW ENGINE INNODB STATUS;（我試圖忽略不相關的信息）給出的交易開始。

------------ 
TRANSACTIONS 
------------ 
Trx id counter 279345410 
Purge done for trx's n:o < 277758364 undo n:o < 0 state: running but idle 
History list length 271773 
LIST OF TRANSACTIONS FOR EACH SESSION: 
---TRANSACTION 277760341, ACTIVE 153800 sec 
28 lock struct(s), heap size 376, 49 row lock(s), undo log entries 90 
MySQL thread id 2310, OS thread handle 0x2b3044788700, query id 3783662 172.30.1.223 backers cleaned up 
---TRANSACTION 277758227, ACTIVE 153933 sec 
82 lock struct(s), heap size 376, 1452 row lock(s), undo log entries 4233 
MySQL thread id 1972, OS thread handle 0x2b3061a43700, query id 3783650 54.0.0.1 syncmachine cleaned up 

這2個交易從2個不同的databaseson在同一臺服務器2個不同的應用程序。顯然他們的運行時間比預期的要長。

接下來，我雖然有可能是一個僵局或類似的東西，所以我嘗試select trx_id,trx_state from information_schema.innodb_trx;

mysql> select trx_id,trx_state from information_schema.innodb_trx; 
+-----------+-----------+ 
| trx_id | trx_state | 
+-----------+-----------+ 
| 279387152 | RUNNING | 
| 279387149 | RUNNING | 
| 279387114 | RUNNING | 
| 279384295 | RUNNING | 
| 279381054 | RUNNING | 
| 279347599 | RUNNING | 
| 278841669 | RUNNING | 
| 277760341 | RUNNING |* 
| 277758227 | RUNNING |* 
| 277758147 | RUNNING | 
+-----------+-----------+ 
10 rows in set (0.02 sec) 

所以沒有LOCK WAIT S的我想可能是這個問題。

最後我想SELECT * FROM information_schema.innodb_trx\G

mysql> SELECT * FROM information_schema.innodb_trx\G 
*************************** 6. row *************************** 
        trx_id: 277760341 
       trx_state: RUNNING 
       trx_started: 2017-08-22 19:13:06 
    trx_requested_lock_id: NULL 
      trx_wait_started: NULL 
       trx_weight: 119 
     trx_mysql_thread_id: 2310 
       trx_query: NULL 
     trx_operation_state: NULL 
     trx_tables_in_use: 0 
     trx_tables_locked: 0 
      trx_lock_structs: 28 
    trx_lock_memory_bytes: 376 
      trx_rows_locked: 49 
     trx_rows_modified: 91 
    trx_concurrency_tickets: 0 
     trx_isolation_level: READ COMMITTED 
     trx_unique_checks: 1 
    trx_foreign_key_checks: 1 
trx_last_foreign_key_error: NULL 
trx_adaptive_hash_latched: 0 
trx_adaptive_hash_timeout: 0 
      trx_is_read_only: 0 
trx_autocommit_non_locking: 0 
*************************** 7. row *************************** 
        trx_id: 277758227 
       trx_state: RUNNING 
       trx_started: 2017-08-22 19:10:53 
    trx_requested_lock_id: NULL 
      trx_wait_started: NULL 
       trx_weight: 4315 
     trx_mysql_thread_id: 1972 
       trx_query: NULL 
     trx_operation_state: NULL 
     trx_tables_in_use: 0 
     trx_tables_locked: 0 
      trx_lock_structs: 82 
    trx_lock_memory_bytes: 376 
      trx_rows_locked: 1452 
     trx_rows_modified: 4233 
    trx_concurrency_tickets: 0 
     trx_isolation_level: READ COMMITTED 
     trx_unique_checks: 1 
    trx_foreign_key_checks: 1 
trx_last_foreign_key_error: NULL 
trx_adaptive_hash_latched: 0 
trx_adaptive_hash_timeout: 0 
      trx_is_read_only: 0 
trx_autocommit_non_locking: 0 
8 rows in set (0.01 sec) 

但trx_query是NULL兩種。那麼涉及這麼多鎖的情況如何呢？

有沒有人對診斷有任何建議？另外，有沒有辦法強制交易通過？ FLUSH TABLES會完成這個嗎？

Answer 1

您應該能夠查看交易歷史與以下： https://www.psce.com/en/blog/2015/01/22/tracking-mysql-query-history-in-long-running-transactions/ （你應該保存生成的日誌，因爲它會收回該交易丟失的數據的方式）

我不知道無論如何恢復一個會議，而不是破解 - 指向具有當前會話上下文的代碼，並嘗試從那裏進行調試。

最好的辦法是解鎖表和執行備份： https://dev.mysql.com/doc/mysql-backup-excerpt/5.7/en/backup-methods.html

審查任何新的修改代碼，也許有人忘了提交（）的地方，並有一些原因，會議沒有被斷開。後臺工作者任務可能是罪魁禍首，因爲它可以保持相同的上下文並鎖定表。這可以通過設置超時來解決： MySQL rollback on transaction with lost/disconnected connection