UNABLE TO PURGE A RECORD(二)

      上一篇文章说明了bug出现的原因和原理分析，要修复bug似乎已经水到渠成了，但远没有这么简单，只因为“并发”。要修复问题，首先要做的第一件事情是稳定的复现问题。由于数据库系统是一个并发系统，并且这个bug只有一定的概率出现，更说明了多个线程在一定的执行序列情况下才会出现这个bug。在没有用户请求的情况下，mysql自身的线程就很多，比如主线程，IO线程，监控线程，监听线程等；有用户请求的情况下，还会分配工作线程为用户服务。我们只找和bug相关的线程：purge线程，IO线程，工作线程。Purge线程主要工作是执行purge操作，产生IBUF_OP_DELETE操作；工作线程则主要执行DELETE，INSERT语句，产生IBUF_OP_INSERT和IBUF_OP_DELETE_MARK操作；IO线程则是IBUF的merge操作。为达到重现bug的目的，我们需要产生IBUF_OP_DELETE_MARK，IBUF_OP_INSERT和IBUF_OP_DELETE序列。由于这里面涉及到purge线程和用户线程，因此涉及一个协同问题。如何协同？

DEBUG_SYNC

       DEBUG_SYNC是mysql源码中自带的宏，通过信号的方式实现多个线程间的同步。假设存在两个线程thread-1(A,B)，thread-2(a,b)，A,B和a,b分别是thread-1和thread-2的执行顺序。为了得到AaBb执行序列，可以通过DEBUG_SYNC实现。

1) 源代码中，设置同步点

2) Session设置

      通过在代码中设置同步点，以及在会话中设置同步关系即可以实现在并发环境下稳定地得到AaBb序列。注意到2)中的蓝色字体表示同步点，红色字体signal和 wait_for表示动作。比如“after_A signal stepA wait_for  stepa”表示执行到同步点after_A后，发出信号after_A，并且等待stepa信号的到来。另外，其中now是一个特殊的同步点，表示执行到指定的位置后等待。debug_sync似乎已经完美地解决了同步问题，但问题是，通过debug_sync同步，需要会话设置等待或发出信号动作，如果需要和后台线程同步怎么办？而这个bug恰好又需要和后台线程purge，以及IO线程同步。别着急，有需求，就一定有解，mysql还有另外一种协同方法，DBUG_EXECUTE_IF。

DBUG_EXECUTE_IF

      DBUG_EXECUTE_IF原理就很简单了，就是在某一点执行一定的操作，至于是什么操作则没有限制。显然，我们可以在某一个点执行sleep函数，虽然无法做到严格的同步，但也基本能满足需求。DEBUG_EXECUTE_IF的基本格式为：DEBUG_EXECUTE_IF(key, code)，比如为了得到AaBb序列，可以通过DBUG_EXECUTE_IF实现

1)  源代码中，设置操作点

2) Session设置

这里为了让后台线程也起作用，可以设置全局debug变量，若只想对本session起作用，可以设置会话debug变量。设置后，执行到对应的操作点时，则会额外执行DEBUG_EXECUTE_IF里面的代码。通过sleep方式来同步是一种取巧的方式，在实际情况中，需要不断调整sleep的时间，尽可能保证能按照预设的顺序执行。设置如下：红色部分是加的代码。

set global debug=”+d,before_a, after_A, after_B, after_b”;

海外公司注册、海外银行开户、跨境平台代入驻、VAT、EPR等知识和在线办理：https://www.xlkjsw.com

原标题：UNABLE TO PURGE A RECORD(二)

关键词：