囧...执行analyze table意外导致waiting for table flush

原创
02/07 00:00
阅读数 81

作者:八怪(高鹏) 中亦科技数据库专家


一、问题描述

问题现场如下:

mysql> show processlist;
+----+-----------------+-----------+------+---------+-------+-------------------------+----------------------------------+
| Id | User            | Host      | db   | Command | Time  | State                   | Info                             |
+----+-----------------+-----------+------+---------+-------+-------------------------+----------------------------------+
|  5 | event_scheduler | localhost | NULL | Daemon  | 34025 | Waiting on empty queue  | NULL                             |
| 11 | root            | localhost | NULL | Query   |  1528 | User sleep              | select sleep(1000) from test.e01 |
| 12 | root            | localhost | NULL | Query   |     0 | starting                | show processlist                 |
| 23 | root            | localhost | NULL | Query   |    33 | Waiting for table flush | select * from test.e01           |
| 24 | root            | localhost | NULL | Query   |     7 | Waiting for table flush | select * from test.e01           |
+----+-----------------+-----------+------+---------+-------+-------------------------+----------------------------------+

乍一看来,很是奇怪,这里没有出现我们经常遇到的 flush table/flush table with read lock 堵塞,直接出现了 Waiting for table flush的堵塞,有点像

https://www.jianshu.com/p/b141585cd844

以前记录的文章中的案例2,但是其实并不一样,这里是由于analyze table语句造成的。

复现过程非常简单(必须是社区版本,我使用的8.0.21),如下:

session 1

mysql> select sleep(1000) from test.e01;(要有几条数据)
这条语句肯定结束不了

session 2

mysql> analyze table test.e01;
+----------+---------+----------+----------+
| Table    | Op      | Msg_type | Msg_text |
+----------+---------+----------+----------+
| test.e01 | analyze | status   | OK       |
+----------+---------+----------+----------+

session 3

mysql> select * from test.e01;
# 被堵塞了

此时堵塞的情形就是Waiting for table flush


二、analyze触发了什么

analyze table 除了更新我们的统计数据,实际上最后做了一个操作如下(栈):

#0  TABLE_SHARE::clear_version (this=0x7ffeec00ee38) at /opt/mysql/mysql-8.0.21/sql/table.cc:518
#1  0x0000000003680a4d in <lambda(std::unordered_map<std::__cxx11::basic_string<char>, std::unique_ptr<TABLE_SHARE, Table_share_deleter>, std::hash<std::__cxx11::basic_string<char> >, std::equal_to<std::__cxx11::basic_string<char> >, Malloc_allocator<std::pair<const std::__cxx11::basic_string<char>, std::unique_ptr<TABLE_SHARE, Table_share_deleter> > > >::iterator)>::operator()(std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::unique_ptr<TABLE_SHARE, Table_share_deleter>, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, Malloc_allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::unique_ptr<TABLE_SHARE, Table_share_deleter> > > >::iterator) const (__closure=0x7fff600ce8a0, 
    my_it=...) at /opt/mysql/mysql-8.0.21/sql/sql_base.cc:9831
#2  0x0000000003680d0c in tdc_remove_table (thd=0x7ffed8094550, remove_type=TDC_RT_REMOVE_UNUSED, db=0x7ffed80c4a08 "test", table_name=0x7ffed80c4a20 "e01", has_lock=false)
    at /opt/mysql/mysql-8.0.21/sql/sql_base.cc:9844
#3  0x0000000003d890a9 in mysql_admin_table (thd=0x7ffed8094550, tables=0x7ffed80c4cb8, check_opt=0x7ffed80ba370, operator_name=0x61c06e7 "analyze", lock_type=TL_READ_NO_INSERT, 
    open_for_modify=true, repair_table_use_frm=false, extra_open_options=0, prepare_func=0x0, operator_func=
    (int (handler::*)(handler * const, THD *, HA_CHECK_OPT *)) 0x3accc64 <handler::ha_analyze(THD*, HA_CHECK_OPT*)>, check_view=0, alter_info=0x7ffed80c4b28, 
    need_to_acquire_shared_backup_lock=true) at /opt/mysql/mysql-8.0.21/sql/sql_admin.cc:1296

大概看一下做了什么,如下:
    if (share->ref_count() > 0) {
      
      if (remove_type != TDC_RT_REMOVE_NOT_OWN_KEEP_SHARE)
        share->clear_version();
      table_cache_manager.free_table(thd, remove_type, share);
    }

这里判断了是否当前table share正在使用,如果正在使用(很显然我们这个table share是不能直接释放的,因为有select一直持有它),那么将share版本的设置为0(share->clear_version()。

实际上这个版本由全局变量refresh_version初始化),目的在于下次如果有使用表定义的时候需要重新打开table share。

然后释放了当前没有使用的table cache(类型TDC_RT_REMOVE_UNUSED)。


三、再次访问表堵塞

当再次访问表的时候(open_table),会去判断如下是否有老的table share存在,如果存在则需要等待释放:

share_found:
  if (!(flags & MYSQL_OPEN_IGNORE_FLUSH)) {
    if (share->has_old_version()) {  
      
      release_table_share(share);
...
      wait_result =
          tdc_wait_for_old_version(thd, table_list->db, table_list->table_name,
                                   ot_ctx->get_timeout(), deadlock_weight);

首先如果存在判断是否存在的老版本,判断是通过table share的版本和当前全局版本refresh_version进行比对。

前面我们知道这里table share的版本已经设置为0,因此这里必然进入release_table_share环节,然后等待持有者的释放(案例窗口1的select查询),然后再次获取table share。

等待栈如下:

(gdb) bt
#0  tdc_wait_for_old_version (thd=0x7ffed8094550, db=0x7ffed802e5c0 "test", table_name=0x7ffed802e5d8 "e01", wait_timeout=31536000, deadlock_weight=0)
    at /opt/mysql/mysql-8.0.21/sql/sql_base.cc:2705
#1  0x0000000003671d7e in open_table (thd=0x7ffed8094550, table_list=0x7ffed802e7c8, ot_ctx=0x7fff600cf1a0) at /opt/mysql/mysql-8.0.21/sql/sql_base.cc:3280
#2  0x0000000003675c36 in open_and_process_table (thd=0x7ffed8094550, lex=0x7ffed80b9fe0, tables=0x7ffed802e7c8, counter=0x7ffed80ba038, prelocking_strategy=0x7fff600cf2b8, 
    has_prelocking_list=false, ot_ctx=0x7fff600cf1a0) at /opt/mysql/mysql-8.0.21/sql/sql_base.cc:5000
#3  0x0000000003677102 in open_tables (thd=0x7ffed8094550, start=0x7fff600cf260, counter=0x7ffed80ba038, flags=0, prelocking_strategy=0x7fff600cf2b8)
    at /opt/mysql/mysql-8.0.21/sql/sql_base.cc:5664
#4  0x0000000003678993 in open_tables_for_query (thd=0x7ffed8094550, tables=0x7ffed802e7c8, flags=0) at /opt/mysql/mysql-8.0.21/sql/sql_base.cc:6515


四、Percona修复该问题

Percona在上文中已经提到问题如下:

一个关键的修改点如下

官方版本:

Percona版本:

如此修改后analyze不会进入tdc_remove_table函数,那么table share的版本不会设置为0。因此如果使用官方版本小心本问题。

最后说下,官方版本测试到8.0.21依旧存在这个问题,而Percona已经修复了,详情见下

https://www.percona.com/blog/2018/03/27/analyze-table-is-no-longer-a-blocking-operation/


全文完。

Enjoy MySQL :)

扫码添加作者微信



本文分享自微信公众号 - 老叶茶馆(iMySQL_WX)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部