MySQL DBA如何"土土"地利用源码解决没有遇到过的错误？

超、凢脫俗 2023-07-01 12:53 3阅读 0赞

![format_png][]

点击**蓝字**关注我们

本篇文章记录的是遇到一个未知错误的排查过程，由于本人水平有限，如有描述不正确的欢迎指正。

### 问题描述 ###

开发报错  
![format_png 1][]

MySQL error code 1615 (ER_NEED_REPREPARE): Prepared statement needs to be re-prepared

### 排查过程 ###

乍一看，没见过这个错误啊，用大腿想了下这个应该是php程序为了防止SQL注入用的prepare执行的。赶紧官方bug搜了一下，一通操作以后路由到了如下地址：https://dev.mysql.com/doc/refman/5.5/en/statement-repreparation.html

简单看了一下，大概意思就是after prepare before execute的阶段，对应的表进行了DDL或者FLUSH TABLES以后table definition cache里面的metadata信息发生了改变，需要reprepare。

接着我搜了一下源码，关键字`re-prepare`，然后我看到官方test套件里有相关的测试。  
![format_png 2][]

可以看到对应的worklog为4166  
拿到worklog id以后，我赶紧去官方的work log下搜，在High Level Architecture标签下，我注意到了下面几行：

Prepared_statement::execute_loop() -- try to execute
    a statement, reprepare in case of validation error, and try
    again until MAX_REPREPARE_ATTEMPTS has been reached.
    mysql_{sql_}stmt_execute() are changed to invoke this
    method instead of plain execute().
    Prepared_statement::reprepare() -- reprepare a prepared
    statement, called from execute_loop() in case of ER_NEED_REPREPARE
    error.

找到了对应的入口函数：  
Prepared\_statement::execute\_loop()  
主要抛出错误位置如下：

if ((sql_command_flags[lex->sql_command] & CF_REEXECUTION_FRAGILE) &&
          error && !thd->is_fatal_error && !thd->killed &&
          // reprepare观察者发现invalidated，尝试MAX_REPREPARE_ATTEMPTS后报错ER_NEED_REPREPARE
          reprepare_observer.is_invalidated() &&
          reprepare_attempt++ < MAX_REPREPARE_ATTEMPTS)
      {
        DBUG_ASSERT(thd->get_stmt_da()->mysql_errno() == ER_NEED_REPREPARE);
        thd->clear_error();
        error= reprepare();
        if (! error)                                /* Success */
          goto reexecute;
      }

注意一下观察者`Reprepare_observer`定义

/**
    Reprepare_observer观察者是用来观察某个表从上一次执行后的版本变化
    这里的"table"可以是MySQL表、临时表、视图或者information schema的表
    当我们执行prepared SQL进行打开表并加锁的时候，必须要确认表没有发生改变(DML除外)。因为如果从上次prepare后表发生了改变，那么解析树可能就失效了，例如它可能包含了基于表metadata的优化。
      @sa check_and_update_table_version() 获取版本跟踪算法
    */
    class Reprepare_observer
    {
    public:
      /**
      检查meatadata是否有变化
      */
      bool report_error(THD *thd);
      bool is_invalidated() const { return m_invalidated; }
      void reset_reprepare_observer() { m_invalidated= FALSE; }
    private:
      bool m_invalidated;
    };

注释里写的非常明显，

check_and_update_table_version() for details of the
      version tracking algorithm

所以我们主要目光聚集在函数`check_and_update_table_version`，其定义如下：

/**
    这里需要比较table definition cache中的元数据版本和之前prepare生成的parse tree中的node进行版本对比
    
    
    */
    static bool
    check_and_update_table_version(THD *thd,
                                   TABLE_LIST *tables, TABLE_SHARE *table_share)
    {
       // 如果table_id != prepare时的table id，抛出错误，如果是prepare时期，虽然也不匹配，但是这个时候并没有观察者，也就不会抛出错误，但是到execute时，已经有了观察者，这个时候不匹配的话，就会抛出错误了
      if (! tables->is_table_ref_id_equal(table_share))
      {
        Reprepare_observer *reprepare_observer= thd->get_reprepare_observer();
        if (reprepare_observer &&
            reprepare_observer->report_error(thd))
        {
          /*
            版本不匹配，抛出错误，返回TRUE
          */
          DBUG_ASSERT(thd->is_error());
          return TRUE;
        }
        /* 根据table definition cache中的table id更新，总是维护最新的 */
        tables->set_table_ref_id(table_share);
      }
      DBUG_EXECUTE_IF("reprepare_each_statement", return inject_reprepare(thd););
      return FALSE;
    }

从函数**check\_and\_update\_table\_version**中可以看出来，在prepare和execute之间这段时间内，如果table\_ref\_id（这里的table id其实就是binlog里面的table map event里面的table id，是可以变化的）如果发生了变化，那么需要reprepare。其中还有一点需要注意的是，在prepare之后，会释放对应的MDL锁，所以这个时候是可以进行DDL操作的。那么问题来了，什么情况下，这个table id会发生变化呢？

1.  DDL(包括ALTER/RENAME/TRUNCATE等)
2.  FLUSH TABLES显式地将表定义刷出缓存
3.  TABLE\_DEFINITION\_CACHE太小，导致对应的表定义缓存被刷出

以上根据自己的经验不完全统计。。。

### 关于table id ###

![format_png 3][]

用户查询一个表的数据时，首先会构造根据库名、表名等信息构造hash key，然后从table\_def\_cache这个hash map中找是否有对应表的缓存，如果存在的话，实例化TABLE\_SHARE结构体为TABLE，跟用户交互。如果不存在的话，那么会获取库名、表名等信息存入TABLE\_SHARE结构体，在这里生成table\_id。  
生成table\_id的函数如下：

static Table_id last_table_id;
    void assign_new_table_id(TABLE_SHARE *share)
    {
      DBUG_ENTER("assign_new_table_id");
      /* Preconditions */
      DBUG_ASSERT(share != NULL);
      mysql_mutex_assert_owner(&LOCK_open);
      DBUG_EXECUTE_IF("dbug_table_map_id_500", last_table_id= 500;);
      DBUG_EXECUTE_IF("dbug_table_map_id_4B_UINT_MAX+501",
                      last_table_id= 501ULL + UINT_MAX;);
      DBUG_EXECUTE_IF("dbug_table_map_id_6B_UINT_MAX",
                      last_table_id= (~0ULL >> 16););
      share->table_map_id= last_table_id++;
      DBUG_PRINT("info", ("table_id=%llu", share->table_map_id.id()));
      DBUG_VOID_RETURN;
    }

### 过程模拟 ###

本模拟案例由重庆八怪提供，非常感谢

<table> 
 <tbody> 
  <tr> 
   <td>session 1</td> 
   <td>session2</td> 
  </tr> 
 </tbody> 
 <tbody> 
  <tr> 
   <td>prepare xxx</td> 
   <td><br></td> 
  </tr> 
  <tr> 
   <td><br></td> 
   <td><img src="https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL3N6X21tYml6X2pwZy83aDRpY0o0aWNzSkJoazF4TkltQ2ljRGtBTDZQUU9JbVhGZlREWUJhV1FvU1hpYXR4NXA0M1ViWUdPYUJUT09iUWljdEJuTmljSmpxREhXRDhObjVKOE92dlFCdy82NDA?x-oss-process=image/format,png"></td> 
  </tr> 
  <tr> 
   <td><img src="https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL3N6X21tYml6X2pwZy83aDRpY0o0aWNzSkJoazF4TkltQ2ljRGtBTDZQUU9JbVhGZkFuczBpYWViRnJya2VUYU93cGN1NE55ZW93bEQ1Njc5b2hiRG9lMEhoNVFZaHhpYWlhOUFxOEtJZy82NDA?x-oss-process=image/format,png"></td> 
   <td><br></td> 
  </tr> 
 </tbody> 
</table>

调试过程：  
![format_png 4][]

这里我们只需要将reprepare\_attempt < MAX\_REPREPARE\_ATTEMPTS 改为不满足条件即可因此  
修改reprepare\_attempt变量为3则，reprepare\_attempt < MAX\_REPREPARE\_ATTEMPTS 返回false  
进入报错流程而不会重新加载table

## 总结： ##

这个问题的本质就是table share 在 prepare 和 execute 之间被重新加载了多次  
伪代码逻辑如下:

prepare:reprepare_attempt=0 MAX_REPREPARE_ATTEMPTS=3 :
    execute:
         如果table table被重置过了那么 reprepare_attempt +=1
         loop：
            重新准备 reprepare
            再次 execute
            如果table table被重置过了继续循环 reprepare_attempt +=1,如果reprepare_attempt>=MAX_REPREPARE_ATTEMPTS 这报错
            否则正常退出循环，正常执行
         end loop

实际会进行3次执行尝试，如果都失败就会报错。因此自己模拟的话还是比较难模拟的，除非直接gdb set 变量或者在线上高压力下才可能出现。

为解决上述的1615问题，可以通过以下办法：

1.  增加table\_definition\_cache，防止表定义被刷出缓存
2.  增加MAX\_REPREPARE\_ATTEMPTS次数，但是这个属于hard code，没法通过参数修改
3.  没事别FLUSH TABLES...(如备份，包括extrabackup和mysqldump获取一致性位点都会做FTWRL，因此建议专门的从库做备份)

--------------------

最后，广告是不能少滴。

叶老师新课程《**MySQL性能优化**》已经在腾讯课堂发布，本课程讲解读几个MySQL性能优化的核心要素：**合理利用索引，降低锁影响，提高事务并发度**。下面是报名小程序码，厚着脸皮请求大家推荐给需要的小伙伴们。

![format_png 5][]

下面是本课程内容目录

![format_png 6][]

扫码加入MySQL技术Q群

**（群号：****650149401）**

![format_png 7][]

点“在看”给我一朵小黄花![format_png 8][]

![format_png 9][]

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL3N6X21tYml6X3BuZy83aDRpY0o0aWNzSkJnc1E0Y2liU3Jobm8xZ3FrSHBIRUtIS0lwaGJabE9jUXVGWFZ4ZXJtUFBGelUwaWMxZlllc1l3cXJPRUNESDM1QTIwVFhxZXY3elMwU0EvNjQw?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL3N6X21tYml6X2pwZy83aDRpY0o0aWNzSkJoazF4TkltQ2ljRGtBTDZQUU9JbVhGZjh3REFhQWxNbUVsQk5IazJVNkxpY2d1SERZZDRhc2dRYkl3OTFNUmRpYmgyczd5WGxFWjhVUlZnLzY0MA?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL3N6X21tYml6X2pwZy83aDRpY0o0aWNzSkJoazF4TkltQ2ljRGtBTDZQUU9JbVhGZktrNkpZVVZDaWNjZGdYVmZBV2xmVndSdFhmdm1vaWJJTzNkUjI4a3ptckhVU1FpY2FuMWljTnRxZ3cvNjQw?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL3N6X21tYml6X2pwZy83aDRpY0o0aWNzSkJoazF4TkltQ2ljRGtBTDZQUU9JbVhGZnFNSURJeGNlTWtkNENGS2VXOWFXUGdXdUxubmMyZTVqME4yR2JBcTg4VXdmeUwzRjROUTJpYkEvNjQw?x-oss-process=image/format,png
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL3N6X21tYml6X2pwZy83aDRpY0o0aWNzSkJoazF4TkltQ2ljRGtBTDZQUU9JbVhGZlpEN2liOGVTaWEzb0toMXRtRUlpY1NwWnZ5ektWNTltODNaSk90VTBKYlZaamNpYmt2SkJpYjJISmJRLzY0MA?x-oss-process=image/format,png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9udHM1Mm5IaGVUeUE0TWRFaWF1UDBlR1lMdVlXNXhORU9tdzNHeHlkWGxiRGcyS0Rrd2liU2lhS0lZS1Y2aFQ5MDNvcnhERmliOVZSYzFTWkRQVXUxTmJvWUEvNjQw?x-oss-process=image/format,png
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9udHM1Mm5IaGVUeUE0TWRFaWF1UDBlR1lMdVlXNXhORU9QcmRJZXpLRm1wZm1XNWIwQXNVUmxEdnFIOFJUZWliOWY2YjJYRVg0NXZQaWF2UDAxQmZHOHZoUS82NDA?x-oss-process=image/format,png
[format_png 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy83aDRpY0o0aWNzSkJqZHlLNEFBWDhDcWhuSkluc0szOGlheGpiaWI5NGF4SlA0Y3NXaWJUdDRwNGJuM2p6SFNLY3RHV3AxaWFpYnIxaWFGVUtiMU9rMUJJbFJ3UmpBLzY0MA?x-oss-process=image/format,png
[format_png 8]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL3N6X21tYml6X2dpZi83aDRpY0o0aWNzSkJnZUQyQ2pNaWJ0VThQRXROcW5wSGFpY3FKZHlIUFE0VWxBa1Y4aWF6b1BsRDJITEFOaWFZMWNMN2pVOUtuekhiNFVPNGszOThLazBUdDViQS82NDA?x-oss-process=image/format,png
[format_png 9]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL3N6X21tYml6X3BuZy83aDRpY0o0aWNzSkJnZUQyQ2pNaWJ0VThQRXROcW5wSGFpY3FqSGtXWHBPcGttZG5HMlFXSWxPbjJVeE9KUkNFdDNTVWdGY1FiVTlvNFdHc1p2OTVvRGhZMVEvNjQw?x-oss-process=image/format,png