主從從庫(kù)MTS HANG死一列

一、故障介紹

最近遇到一個(gè)案例，以前從來(lái)沒(méi)遇到過(guò)，環(huán)境為5.7，從庫(kù)在執(zhí)行optimize table語(yǔ)句的時(shí)候，出現(xiàn)了MTS hang死的情況，并且無(wú)法自動(dòng)解鎖，只能是重啟整個(gè)數(shù)據(jù)庫(kù)(kill -9)，然后才可能恢復(fù)。模擬的截圖如下，


19df8442819b2c360f120ad73d7e17a.png

當(dāng)然線上MTS線程堵塞的比較多，但是模擬我只需要2個(gè)worker線程堵塞就可以了。這種堵塞狀態(tài)視乎沒(méi)有遇到過(guò)。因此有必要分析一下其可能的成因。相關(guān)參數(shù)，

  • binlog_transaction_dependency_tracking :COMMIT_ORDER
  • slave_parallel_type:LOGICAL_CLOCK

二、堵塞可能的分析

從紅色部分我們可以看到worker線程有這些現(xiàn)象，

  • 某個(gè)worker線程正在執(zhí)行optimize table操作，處于表級(jí)別的MDL LOCK堵塞下，也就是Waiting for table metadata lock。
  • 某個(gè)worker線程執(zhí)行完了自己的工作，但是無(wú)法獲取提交序列，也就是等待Waiting for preceding transaction to commit

并且2個(gè)worker線程無(wú)法自動(dòng)解鎖了，因此MTS整體處于hang死狀態(tài)下。那么需要達(dá)到這個(gè)狀態(tài)需要滿足幾個(gè)條件，

  1. Waiting for table metadata lock狀態(tài)是table級(jí)別的MDL LOCK，那么必須要有前置的session 獲取了testuuu表上的某種MDL LOCK，（需要注意的是optimize table和DML語(yǔ)句操作的是同一個(gè)表，這也是這個(gè)問(wèn)題中比較難以理解的地方，因?yàn)镸DL LOCK的存在很難說(shuō)它們能夠并發(fā)）因?yàn)閛ptimize table類似DDL操作因此它一定會(huì)獲取X MDL LOCK，因此只要session獲取testuuu表上的某種MDL LOCK都會(huì)堵塞
  2. Waiting for preceding transaction to commit狀態(tài)，是并發(fā)的下的一個(gè)等待，那么說(shuō)明這個(gè)時(shí)候有相關(guān)的操作和optimize table操作進(jìn)行了并發(fā)，并且了解到這個(gè)操作是DML 同表的操作，并且這個(gè)DML 操作提前來(lái)到了提交階段，但是不是自己的提交序列因此不能提交。

那么同時(shí)滿足這兩個(gè)條件的那必須是，

  1. optimize table操作和DML 操作操作了同一表。
  2. optimize table操作和DML 操作的last commit必須相同，這樣才可能并發(fā)。
  3. DML 操作的seq number必須要在optimize table操作之后，這樣才能因?yàn)閟eq number原因DML 語(yǔ)句不能提交堵塞。
  4. DML 操作和optimize table操作雖然并發(fā)了，但是DML 必須要先執(zhí)行完成，如果optimize table操作先完成則不會(huì)出堵塞。

但是這里有個(gè)明顯的問(wèn)題，DDL操作在提交時(shí)刻是上了X鎖的，他會(huì)堵塞DML 操作，那么這種情況下last commit不可能相同，而第3點(diǎn)來(lái)講這個(gè)是可以在從庫(kù)進(jìn)行控制的，主要是前面2點(diǎn)必須要達(dá)到。

三、主庫(kù)側(cè)分析

還是接著上面的問(wèn)題，那我們猜測(cè)一下optimize table是否會(huì)出現(xiàn)提前解鎖的情況，也就是提交沒(méi)有包裹在MDL LOCK X 下面那么，就可能出現(xiàn)上面的狀態(tài)，為了驗(yàn)證這個(gè)問(wèn)題我們需要debug獲取last commit的點(diǎn)也就是Transaction_ctx::store_commit_parent函數(shù)，同時(shí)打印出release MDL LOCK的信息，optimize table 如下，

Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::SCHEMA
3: ticket->m_lock->key.db_name() = 0x7ffedc032bd5 "testslave0912"
2: ticket->m_lock->key.name() = 0x7ffedc032be3 ""
1: ticket->m_type = MDL_INTENTION_EXCLUSIVE
--- 釋放表的X鎖
Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::TABLE
3: ticket->m_lock->key.db_name() = 0x7ffedc0248d5 "testslave0912"
2: ticket->m_lock->key.name() = 0x7ffedc0248e3 "testuuu"
1: ticket->m_type = MDL_SHARED_READ
--- 釋放表上的SR鎖
Breakpoint 3, Transaction_ctx::store_commit_parent (this=0x7ffedc004880, last_arg=2) at /opt/percona-server-locks-detail-5.7.22/sql/transaction_info.h:370
370         last_committed= last_arg;
--- 注意這里釋放了table級(jí)別的MDL LOCK才獲取了last commit,那么這個(gè)時(shí)候DML是可以執(zhí)行的并且獲取last commit的。
Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_EXPLICIT, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::BINLOG
3: ticket->m_lock->key.db_name() = 0x2f9ae75 ""
2: ticket->m_lock->key.name() = 0x2f9ae76 ""
1: ticket->m_type = MDL_INTENTION_EXCLUSIVE
(gdb) c
Continuing.

看起來(lái)確實(shí)如此，optimize table語(yǔ)句在釋放了MDL LOCK后才獲取的last commit信息，并且這個(gè)時(shí)候DML語(yǔ)句也可以正常的獲取last commit信息，那么就給并發(fā)創(chuàng)造了條件，接下來(lái)是我模擬出來(lái)的optimize table和delete 語(yǔ)句相同last commit的binlog片段，大概的過(guò)程如下，

斷點(diǎn) session1 session2
Transaction_ctx::store_commit_parent
optimize table testuuu;觸發(fā)斷點(diǎn)
delete from testuuu limit 1 觸發(fā)斷點(diǎn)
session1 繼續(xù)語(yǔ)句執(zhí)行成功生成binlog
session2 繼續(xù)語(yǔ)句執(zhí)行成功生成binlog
image.png
image.png

這樣主庫(kù)生成binlog的問(wèn)題就解決了，接下來(lái)就是MTS并發(fā)了。

四、從庫(kù)側(cè)并發(fā)限制

對(duì)于這種DDL和DML語(yǔ)句混合并發(fā)的場(chǎng)景，需要考慮在MTS下是否有特殊的代碼控制流程，也就是不并發(fā)，但是翻看SQL線程分發(fā)流程，并沒(méi)有找到限制，因此我們可以將斷點(diǎn)放到GTID event的應(yīng)用上Gtid_log_event::do_apply_event，并且分析SQL線程分發(fā)流程函數(shù)Mts_submode_logical_clock::schedule_next_event，因?yàn)樵贕TID event執(zhí)行的時(shí)候是一個(gè)事物的開(kāi)始，這個(gè)時(shí)候并沒(méi)有MDL LOCK，也可以控制到底哪個(gè)事務(wù)先執(zhí)行。
這里主要就是讓delete操作的event先執(zhí)行，然后因?yàn)樗膕eq number比optimize table大，因此必然堵塞在Waiting for preceding transaction to commit狀態(tài)下，并且因?yàn)闆](méi)有提交，那么delete語(yǔ)句的MDL LOCK還持有，然后放開(kāi)執(zhí)行optimize table操作的worker線程，這個(gè)時(shí)候optimize table因?yàn)楂@取不到MDL LOCK因此就出現(xiàn)了堵塞，并且無(wú)法解決，也就是我們開(kāi)始看到的問(wèn)題。

五、optimize table和alter table engine=innodb

從我們上面的分析可以看到optimize table語(yǔ)句在5.7至少是有可能導(dǎo)致MTS從庫(kù)hang死的情況，原因是optimize table在正式提交寫(xiě)binlog之前放開(kāi)了MDL LOCK。
optimize table 在innodb引擎中實(shí)際上是重建整個(gè)表，這個(gè)和alter table engine=innodb達(dá)到的目的是一樣的，那么alter table engine=innodb語(yǔ)句會(huì)不會(huì)有同樣的問(wèn)題，使用上面的分析方法，發(fā)現(xiàn)alter table engine=innodb語(yǔ)句在獲取last commit的時(shí)候是在MDL LOCK X下面的，因此就會(huì)堵塞DML 語(yǔ)句不會(huì)出現(xiàn)問(wèn)題，如下

Breakpoint 3, Transaction_ctx::store_commit_parent (this=0x7ffedc004880, last_arg=7) at /opt/percona-server-locks-detail-5.7.22/sql/transaction_info.h:370
370         last_committed= last_arg;
--- 這里獲取last commit
...
Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc030a30) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::TABLE
3: ticket->m_lock->key.db_name() = 0x7ffedc0248d5 "testslave0912"
2: ticket->m_lock->key.name() = 0x7ffedc0248e3 "testuuu"
1: ticket->m_type = MDL_EXCLUSIVE
--- 這里釋放MDL LOCK X鎖

既然提交堵塞同表的DML，那么就不可能模擬出last commit相同的情況，那么從庫(kù)自然不可能并發(fā)，那么如果使用5.7的MTS 最好少執(zhí)行optimize table語(yǔ)句。 后續(xù)需要分析8.0是否可能有這種問(wèn)題，但是感覺(jué)可能性不大。

六、其他


1、制造主庫(kù)last commit一致的情況，并且DML的seq number大于DDL，目的在于DML在從庫(kù)先執(zhí)行的情況下，不能獲取到提交序列
2、從庫(kù)先啟動(dòng)IO thread，目的在于積累一下主庫(kù)過(guò)來(lái)的binlog計(jì)入relay log中，讓并行回放能夠發(fā)揮作用。
3、觀察relay log已經(jīng)傳過(guò)來(lái)了同樣last commit的DDL和MDL 并且MDL的seq number小于DDL。
4、斷點(diǎn)open table，確認(rèn)從庫(kù)先執(zhí)行的是DML語(yǔ)句先執(zhí)行，這個(gè)時(shí)候會(huì)等待提交隊(duì)列到來(lái)，但是這個(gè)時(shí)候MDL LOCK沒(méi)有釋放
5、執(zhí)行DDL語(yǔ)句，DDL語(yǔ)句必然等待在meta lock上。

#0  Logical_clock::get_timestamp (this=0x7fff992dc480) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:40
#1  0x00000000014571dc in Transaction_dependency_tracker::get_max_committed_timestamp (this=0x2cebeb0 <mysql_bin_log+5232>) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:406
#2  0x00000000017d8650 in MYSQL_BIN_LOG::commit (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, all=false) at /opt/mysql-5.7.40/sql/binlog.cc:8751
#3  0x0000000001627632 in trans_commit_stmt (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/transaction.cc:470
#4  0x000000000152c318 in mysql_execute_command (thd=0x7fff7c0010c0, first_level=true) at /opt/mysql-5.7.40/sql/sql_parse.cc:4994
#5  0x000000000152dace in mysql_parse (thd=0x7fff7c0010c0, parser_state=0x7fff992de580) at /opt/mysql-5.7.40/sql/sql_parse.cc:5589
#6  0x00000000015232cd in dispatch_command (thd=0x7fff7c0010c0, com_data=0x7fff992dece0, command=COM_QUERY) at /opt/mysql-5.7.40/sql/sql_parse.cc:1492
#7  0x0000000001522134 in do_command (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/sql_parse.cc:1031
#8  0x0000000001655dfa in handle_connection (arg=0x6db36e0) at /opt/mysql-5.7.40/sql/conn_handler/connection_handler_per_thread.cc:313
#9  0x0000000001ce8ce0 in pfs_spawn_thread (arg=0x6cdbee0) at /opt/mysql-5.7.40/storage/perfschema/pfs.cc:2197
#10 0x00007ffff7bbb764 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007ffff60ade2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


#0  Transaction_ctx::store_commit_parent (this=0x7fff7c004a70, last_arg=4) at /opt/mysql-5.7.40/sql/transaction_info.h:398
#1  0x00000000017d8662 in MYSQL_BIN_LOG::commit (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, all=false) at /opt/mysql-5.7.40/sql/binlog.cc:8751
#2  0x0000000001627632 in trans_commit_stmt (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/transaction.cc:470
#3  0x000000000152c318 in mysql_execute_command (thd=0x7fff7c0010c0, first_level=true) at /opt/mysql-5.7.40/sql/sql_parse.cc:4994
#4  0x000000000152dace in mysql_parse (thd=0x7fff7c0010c0, parser_state=0x7fff992de580) at /opt/mysql-5.7.40/sql/sql_parse.cc:5589
#5  0x00000000015232cd in dispatch_command (thd=0x7fff7c0010c0, com_data=0x7fff992dece0, command=COM_QUERY) at /opt/mysql-5.7.40/sql/sql_parse.cc:1492
#6  0x0000000001522134 in do_command (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/sql_parse.cc:1031
#7  0x0000000001655dfa in handle_connection (arg=0x6db36e0) at /opt/mysql-5.7.40/sql/conn_handler/connection_handler_per_thread.cc:313
#8  0x0000000001ce8ce0 in pfs_spawn_thread (arg=0x6cdbee0) at /opt/mysql-5.7.40/storage/perfschema/pfs.cc:2197
#9  0x00007ffff7bbb764 in start_thread (arg=<optimized out>) at pthread_create.c:477
#10 0x00007ffff60ade2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


#0  Commit_order_trx_dependency_tracker::update_max_committed (this=0x2cebf08 <mysql_bin_log+5320>, sequence_number=6) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:165
#1  0x00000000014570d6 in Transaction_dependency_tracker::update_max_committed (this=0x2cebeb0 <mysql_bin_log+5232>, thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:374
#2  0x00000000017d930d in MYSQL_BIN_LOG::process_commit_stage_queue (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, first=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/binlog.cc:9038
#3  0x00000000017dacd6 in MYSQL_BIN_LOG::ordered_commit (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, all=false, skip_commit=false) at /opt/mysql-5.7.40/sql/binlog.cc:9762
#4  0x00000000017d8d2c in MYSQL_BIN_LOG::commit (this=0x2ceaa40 <mysql_bin_log>, thd=0x7fff7c0010c0, all=false) at /opt/mysql-5.7.40/sql/binlog.cc:8870
#5  0x0000000001627632 in trans_commit_stmt (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/transaction.cc:470
#6  0x000000000152c318 in mysql_execute_command (thd=0x7fff7c0010c0, first_level=true) at /opt/mysql-5.7.40/sql/sql_parse.cc:4994
#7  0x000000000152dace in mysql_parse (thd=0x7fff7c0010c0, parser_state=0x7fff992de580) at /opt/mysql-5.7.40/sql/sql_parse.cc:5589
#8  0x00000000015232cd in dispatch_command (thd=0x7fff7c0010c0, com_data=0x7fff992dece0, command=COM_QUERY) at /opt/mysql-5.7.40/sql/sql_parse.cc:1492
#9  0x0000000001522134 in do_command (thd=0x7fff7c0010c0) at /opt/mysql-5.7.40/sql/sql_parse.cc:1031
#10 0x0000000001655dfa in handle_connection (arg=0x6db36e0) at /opt/mysql-5.7.40/sql/conn_handler/connection_handler_per_thread.cc:313
#11 0x0000000001ce8ce0 in pfs_spawn_thread (arg=0x6cdbee0) at /opt/mysql-5.7.40/storage/perfschema/pfs.cc:2197
#12 0x00007ffff7bbb764 in start_thread (arg=<optimized out>) at pthread_create.c:477
#13 0x00007ffff60ade2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


(gdb) info b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000000e8166c in main(int, char**) at /opt/mysql-5.7.40/sql/main.cc:32
        breakpoint already hit 1 time
2       breakpoint     keep y   0x00000000017e0fe8 in Transaction_ctx::store_commit_parent(long long) at /opt/mysql-5.7.40/sql/transaction_info.h:398
        breakpoint already hit 7 times
3       breakpoint     keep y   0x00000000014572fa in Logical_clock::get_timestamp() at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:40
        breakpoint already hit 6 times
5       breakpoint     keep y   0x0000000001456a36 in Commit_order_trx_dependency_tracker::update_max_committed(long long) at /opt/mysql-5.7.40/sql/rpl_trx_tracking.cc:165
        breakpoint already hit 2 times
6       breakpoint     keep y   0x0000000001421789 in MDL_context::acquire_lock(MDL_request*, unsigned long) at /opt/mysql-5.7.40/sql/mdl.cc:3564
        breakpoint already hit 17 times
7       breakpoint     keep y   <MULTIPLE>         
        breakpoint already hit 13 times
7.1                         y     0x000000000142295a in MDL_context::release_lock(enum_mdl_duration, MDL_ticket*) at /opt/mysql-5.7.40/sql/mdl.cc:4286
7.2                         y     0x0000000001422cd2 in MDL_context::release_lock(MDL_ticket*) at /opt/mysql-5.7.40/sql/mdl.cc:4417
(gdb) d 6
#240918 11:29:49 server id 322  end_log_pos 28019 CRC32 0xecee4a11      GTID    last_committed=81       sequence_number=82      rbr_only=no
SET @@SESSION.GTID_NEXT= 'ec9f995d-e5a1-11ee-900b-000c2963503f:104'/*!*/;
# at 28019
#240918 11:29:49 server id 322  end_log_pos 28133 CRC32 0x7aba525e      Query   thread_id=4     exec_time=1     error_code=0
SET TIMESTAMP=1726630189/*!*/;
optimize table testuuu
/*!*/;
# at 28133
#240918 11:29:55 server id 322  end_log_pos 28198 CRC32 0x6b33d92a      GTID    last_committed=81       sequence_number=83      rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ec9f995d-e5a1-11ee-900b-000c2963503f:105'/*!*/;
# at 28198
#240918 11:29:55 server id 322  end_log_pos 28279 CRC32 0x76c956ab      Query   thread_id=5     exec_time=0     error_code=0
SET TIMESTAMP=1726630195/*!*/;
BEGIN
/*!*/;
# at 28279
#240918 11:29:55 server id 322  end_log_pos 28330 CRC32 0xb13102e7      Rows_query
# delete from testuuu limit 1
# at 28330
#240918 11:29:55 server id 322  end_log_pos 28389 CRC32 0x621ca080      Table_map: `testslave0912`.`testuuu` mapped to number 117
# at 28389
#240918 11:29:55 server id 322  end_log_pos 28429 CRC32 0x98691042      Delete_rows: table id 117 flags: STMT_END_F

BINLOG '
M0nqZh1CAQAAMwAAAKpuAACAABtkZWxldGUgZnJvbSB0ZXN0dXV1IGxpbWl0IDHnAjGx
M0nqZhNCAQAAOwAAAOVuAAAAAHUAAAAAAAEADXRlc3RzbGF2ZTA5MTIAB3Rlc3R1dXUAAQMAAYCg
HGI=
M0nqZiBCAQAAKAAAAA1vAAAAAHUAAAAAAAEAAgAB//4BAAAAQhBpmA==
'/*!*/;
### DELETE FROM `testslave0912`.`testuuu`
### WHERE
###   @1=1 /* INT meta=0 nullable=1 is_null=0 */
# at 28429
#240918 11:29:55 server id 322  end_log_pos 28460 CRC32 0x9a4c1bbd      Xid = 126
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;



Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000000eb13ac in main(int, char**) at /opt/percona-server-locks-detail-5.7.22/sql/main.cc:25
        breakpoint already hit 1 time
3       breakpoint     keep y   0x00000000017efb70 in Gtid_log_event::do_apply_event(Relay_log_info const*) at /opt/percona-server-locks-detail-5.7.22/sql/log_event.cc:13859
        breakpoint already hit 2 times
5       breakpoint     keep y   0x0000000001877113 in Mts_submode_logical_clock::wait_for_last_committed_trx(Relay_log_info*, long long, long long) at /opt/percona-server-locks-detail-5.7.22/sql/rpl_mts_submode.cc:456
(gdb) d 3


Mts_submode_logical_clock::wait_for_last_committed_trx


Transaction_ctx::store_commit_parent(long long)


alter table engine=innodb;

#0  Transaction_ctx::store_commit_parent (this=0x7ffedc004880, last_arg=5) at /opt/percona-server-locks-detail-5.7.22/sql/transaction_info.h:370
#1  0x0000000001815f5e in MYSQL_BIN_LOG::commit (this=0x2dc09e0 <mysql_bin_log>, thd=0x7ffedc000b70, all=false) at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:8889
#2  0x0000000000f54824 in ha_commit_trans (thd=0x7ffedc000b70, all=false, ignore_global_read_lock=false) at /opt/percona-server-locks-detail-5.7.22/sql/handler.cc:1830
#3  0x0000000001676337 in trans_commit_stmt (thd=0x7ffedc000b70) at /opt/percona-server-locks-detail-5.7.22/sql/transaction.cc:458
#4  0x0000000001570408 in mysql_execute_command (thd=0x7ffedc000b70, first_level=true) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5293
#5  0x0000000001571bed in mysql_parse (thd=0x7ffedc000b70, parser_state=0x7fffec1255b0) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5901
#6  0x000000000156673d in dispatch_command (thd=0x7ffedc000b70, com_data=0x7fffec125d90, command=COM_QUERY) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1490
#7  0x00000000015655c5 in do_command (thd=0x7ffedc000b70) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1021
#8  0x00000000016a635c in handle_connection (arg=0x64c3f10) at /opt/percona-server-locks-detail-5.7.22/sql/conn_handler/connection_handler_per_thread.cc:312
#9  0x00000000018ce0f6 in pfs_spawn_thread (arg=0x6554610) at /opt/percona-server-locks-detail-5.7.22/storage/perfschema/pfs.cc:2190
#10 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#11 0x00007ffff66008dd in clone () from /lib64/libc.so.6

optimize table 提前釋放了MDL LOCK



Breakpoint 2, MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
4350      MDL_lock *lock= ticket->m_lock;
4: ticket->m_lock->key.mdl_namespace() = MDL_key::TABLE
3: ticket->m_lock->key.db_name() = 0x7ffedc0248d5 "testslave0912"
2: ticket->m_lock->key.name() = 0x7ffedc0248e3 "testuuu"
1: ticket->m_type = MDL_EXCLUSIVE
(gdb) bt
#0  MDL_context::release_lock (this=0x7ffedc000c08, duration=MDL_TRANSACTION, ticket=0x7ffedc032e90) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4350
#1  0x0000000001464bf1 in MDL_context::release_locks_stored_before (this=0x7ffedc000c08, duration=MDL_TRANSACTION, sentinel=0x0) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4521
#2  0x00000000014653c5 in MDL_context::release_transactional_locks (this=0x7ffedc000c08) at /opt/percona-server-locks-detail-5.7.22/sql/mdl.cc:4805
#3  0x0000000001776fa8 in mysql_admin_table(THD *, TABLE_LIST *, HA_CHECK_OPT *, const char *, thr_lock_type, bool, bool, uint, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *), struct {...}, int (*)(THD *, TABLE_LIST *)) (thd=0x7ffedc000b70, tables=0x7ffedc006588, check_opt=0x7ffedc0036a0, operator_name=0x21fcdf0 "optimize", lock_type=TL_WRITE, open_for_modify=false, 
    repair_table_use_frm=false, extra_open_options=0, prepare_func=0x0, operator_func=
    (int (handler::*)(handler * const, THD *, HA_CHECK_OPT *)) 0xf5ca60 <handler::ha_optimize(THD*, st_ha_check_opt*)>, view_operator_func=0x0)
    at /opt/percona-server-locks-detail-5.7.22/sql/sql_admin.cc:830
#4  0x000000000177861d in Sql_cmd_optimize_table::execute (this=0x7ffedc006b20, thd=0x7ffedc000b70) at /opt/percona-server-locks-detail-5.7.22/sql/sql_admin.cc:1272
#5  0x000000000156fb51 in mysql_execute_command (thd=0x7ffedc000b70, first_level=true) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5117
#6  0x0000000001571bed in mysql_parse (thd=0x7ffedc000b70, parser_state=0x7fffec1255b0) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5901
#7  0x000000000156673d in dispatch_command (thd=0x7ffedc000b70, com_data=0x7fffec125d90, command=COM_QUERY) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1490
#8  0x00000000015655c5 in do_command (thd=0x7ffedc000b70) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1021
#9  0x00000000016a635c in handle_connection (arg=0x659fa40) at /opt/percona-server-locks-detail-5.7.22/sql/conn_handler/connection_handler_per_thread.cc:312
#10 0x00000000018ce0f6 in pfs_spawn_thread (arg=0x6594e50) at /opt/percona-server-locks-detail-5.7.22/storage/perfschema/pfs.cc:2190
#11 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff66008dd in clone () from /lib64/libc.so.6
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。