| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
meng_xiaozhun
5年前发布

myrocks复制中断问题排查

   <h3><strong>背景</strong></h3>    <p>mysql可以支持多种不同的存储引擎,innodb由于其高效的读写性能,并且支持事务特性,使得它成为mysql存储引擎的代名词,使用非常广泛。随着SSD逐渐普及,硬件存储成本越来越高,面向写优化的rocksdb引擎逐渐流行起来,我们也是看中了rocksdb引擎在写放大和空间放大的优势,将其引入到mysql体系。两种引擎的结构B-Tree(innodb引擎)和LSM-Tree(rocksdb引擎)很好地形成互补,我们可以根据业务类型来选择合适的存储。一般mysql默认是mysql+innodb引擎,而mysql+rocksdb引擎称之为myrocks。今天要讨论的就是myrocks复制中断问题,案例来源于真实的业务场景。</p>    <h3><strong>问题现象</strong></h3>    <p style="text-align:center"><img src="https://simg.open-open.com/show/fe9c74be9389648ed2aade61d87b3a2e.png"></p>    <p>复制过程中,出现了1756错误,根据错误日志和debug确认是slave-sql线程在更新slave_worker_info表时出错导致,堆栈如下:</p>    <pre>  <code class="language-cpp">#7  0x0000000000a30104 in Rpl_info_table::do_flush_info (this=0x2b9999c9de00, force=<optimized out>) at /home/admin/95_20161208115448428_15352432_code/rpm_workspace/sql/rpl_info_table.cc:171  #8  0x0000000000a299b1 in flush_info (force=true, this=<optimized out>) at /home/admin/95_20161208115448428_15352432_code/rpm_workspace/sql/rpl_info_handler.h:92  #9  Slave_worker::flush_info (this=0x2b9999f80000, force=<optimized out>) at /home/admin/95_20161208115448428_15352432_code/rpm_workspace/sql/rpl_rli_pdb.cc:318  #10 0x0000000000a29d95 in Slave_worker::commit_positions (this=this@entry=0x2b9999f80000, ev=ev@entry=0x2b9999c9ab00, ptr_g=ptr_g@entry=0x2b9999daca00, force=<optimized out>)      at /home/admin/95_20161208115448428_15352432_code/rpm_workspace/sql/rpl_rli_pdb.cc:582  #11 0x00000000009d61f0 in Xid_log_event::do_apply_event_worker (this=0x2b9999c9ab00, w=0x2b9999f80000) at /home/admin/95_20161208115448428_15352432_code/rpm_workspace/sql/log_event.cc:74</code></pre>    <p>这里简单介绍下复制相关的位点表,在并行复制模式下,参与复制的主要有三个角色,slave_io线程负责将主库的binlog拉取到本地;slave_sql线程读取binlog并根据一定的规则分发给各个slave_worker;slave_worker线程回放主库的操作,达到与主库同步的目的。slave_io线程和slave_sql线程分别只有一个,而worker线程可以有1个或多个,可以依据参数slave_parallel_workers设置。如果将slave_parallel_workers设置为0,则表示关闭并行复制,slave_sql线程承担回放的工作。位点表主要有3张,包括slave_worker_info,slave_relay_log_info和slave_master_info表。slave_io线程更新slave_master_info表,更新拉取的最新位置;slave_sql线程更新slave_relay_log_info表,更新同步位点;而slave_worker线程更新slave_worker_info,每个worker线程在该表中都对应一条记录,每个worker各自更新自己的位点。</p>    <p>Slave_worker的工作流程如下:</p>    <p>1) 读取event,调用do_apply_event进行回放;</p>    <p>2) 遇到xid event(commit/rollback event),表示事务结束,调用commit_positions更新位点信息;</p>    <p>3) 调用do_commit提交事务。</p>    <p>从我们抓的堆栈来看,是worker线程在执行执行第2步出错,现在我们得到了初步的信息,更新位点表失败直接导致了错误。</p>    <h3><strong>问题定位与分析</strong></h3>    <p>接下来,我们要看看最终是什么导致了更新位点表失败?根据最后的错误码,我们调试时设置了若干断点,最终得到了如下堆栈</p>    <pre>  <code class="language-cpp">#0  myrocks::Rdb_transaction::set_status_error (this=0x2b99b6c5b400, thd=0x2b99b6c51000, s=..., kd=std::shared_ptr (count 18, weak 0) 0x2b997fbd7910,      tbl_def=0x2b9981bc95b0) at /home/admin/95_20161208115448428_15352432_code/rpm_workspace/storage/rocksdb/ha_rocksdb.cc:1460  #1  0x0000000000a6da28 in myrocks::ha_rocksdb::check_and_lock_unique_pk (this=this@entry=0x2b997fbb3010, key_id=key_id@entry=0, row_info=...,      found=found@entry=0x2b9a58ca77ef, pk_changed=pk_changed@entry=0x2b9a58ca782f)      at /home/admin/95_20161208115448428_15352432_code/rpm_workspace/storage/rocksdb/ha_rocksdb.cc:7092  #2  0x0000000000a6e8a8 in myrocks::ha_rocksdb::check_uniqueness_and_lock (this=this@entry=0x2b997fbb3010, row_info=..., pk_changed=pk_changed@entry=0x2b9a58ca782f)      at /home/admin/95_20161208115448428_15352432_code/rpm_workspace/storage/rocksdb/ha_rocksdb.cc:7250  #3  0x0000000000a7386a in myrocks::ha_rocksdb::update_write_row (this=this@entry=0x2b997fbb3010, old_data=old_data@entry=0x0</code></pre>    <p>通过代码分析得到了如下信息:</p>    <p>更新位点表之所以失败是因为更新记录时发现已经存在了一条记录,这条记录的sequnceNumber比当前快照获取的sequnceNumber大,所以报错。这里简单介绍下sequenceNumber,sequenceNumber是全局递增的,内部存储为一个7字节的整数,Rocksdb依赖sequenceNumber实现MVCC。每条记录有一个唯一的sequenceNumber,rocksdb利用sequenceNumber进行可见性判断。事务在提交时,获取当前最大的sequenceNumber,并按照先后顺序为事务中的每条记录分配一个sequenceNumber,然后写入memtable。同一个key的多个不同的sequenceNumber记录按照逆序存放,即sequenceNumber最大的key放在最前面,最小的放在最后面。表1中key-n,key表示key值,n表示key对应sequenceNumber,假设key1<key2<key3<key4,则存储顺序如下:</p>    <table cellspacing="0">     <tbody>      <tr>       <td> <p>Key1-100</p> </td>       <td> <p>Key1-50</p> </td>       <td> <p>Key2-120</p> </td>       <td> <p>Key2-80</p> </td>       <td> <p>Key3-70</p> </td>       <td> <p>Key4-150</p> </td>      </tr>      <tr>       <td> <p>ValueA</p> </td>       <td> <p>ValueB</p> </td>       <td> <p>ValueC</p> </td>       <td> <p>ValueD</p> </td>       <td> <p>ValueE</p> </td>       <td> <p>ValueF</p> </td>      </tr>     </tbody>    </table>    <p>进行读取时,会利用sequenceNumber建立一个快照,读取快照发生前的已经存在的记录,系统之后的变更与本快照无关。假设快照的sequenceNumber是150,执行get(key2)时,会找到(key2-120,ValueC);而如果快照sequenceNumber是100,执行get(key2)时,则会找到(key2-80,ValueD)。</p>    <p>回到问题本身,看看与问题相关的更新流程:</p>    <p>1.尝试对更新key加锁,如果没有并发更新,上锁成功 //TryLock</p>    <p>2.利用当前最大的sequenceNumberA生成快照</p>    <p>3.检查快照生成后,key是否被修改 // ValidateSnapshot</p>    <p>1)再次获取最大sequenceNumberB,构造key进行查找 // GetLatestSequenceForKey</p>    <p>2)查找是否存在相同的key的记录</p>    <p>4.若相同key的记录存在,且key的sequnceNumber大于sequenceNumberA,则认为有写冲突,报错。</p>    <p>我们碰到的错误正好就是遇到了写冲突报错,那么现在问题来了,明明这个key已经上锁了,并且获取了最新的sequencNumberA,为什么仍然会读到相同的key,且对应的seqeunceNumber比sequencNumberA大?结合之前分析的slave_worker_info表,我们可以作出以下猜测</p>    <p>大胆猜测:</p>    <ol>     <li>行级锁并发没有控制好,导致多个线程同时更新</li>     <li>某些路径下,快照的sequenceNumber比较旧,不是最新</li>     <li>slave_worker线程并发没有控制好,多个worker同时更新一条记录</li>    </ol>    <p>小心求证:</p>    <p>现象看起来是这么的不合理,所有的假设感觉都是不攻自破,但是事实如此,唯有通过更多的信息来辅佐我们进一步判断。结合代码,我们对于上面怀疑的几个点,在相关路径下进行埋点验证。埋点主要为了得到以下信息:</p>    <ol>     <li>具体哪个worker出错了,出错的是哪个key,sequence是多少?</li>     <li>worker与key的映射关系</li>     <li>这个key在出错前被谁更新过?</li>     <li>每个事务包含的记录个数是多少?</li>    </ol>    <p>获得日志如下:</p>    <pre>  <code class="language-cpp">Resource busy: seq:38818368818, key_seq:38818368817, index number is 0-0-1-2, pk is 0-0-0-10, thread is 46983376549632    映射关系:  worker id is 10, thread is 46983367104256  //写memtable线程  worker id is 9, thread is 46983376549632   //出错线程  worker id is 11, thread is 46983359772416  //事务提交线程    写memtable线程:  2016-12-19 16:42:06 53743 [ERROR] LibRocksDB:In Memtable, index_num is 0-0-1-2, pk is 0-0-0-10, seq is 38818368818, thread is 46983367104256    2016-12-19 16:42:06 53743 [ERROR] LibRocksDB:In Memtable, index_num is 0-0-1-2, pk is 0-0-0-4, seq is 38818368665, thread is 46983367104256    2016-12-19 16:42:06 53743 [ERROR] LibRocksDB:In Memtable, index_num is 0-0-1-2, pk is 0-0-0-3, seq is 38818368675, thread is 46983367104256    提交线程:  type is commit, write_start, thread is 46983359772416,   seq is 38818368817  type is commit, write_end, thread is 46983359772416,   seq is 38818368818, count is 1</code></pre>    <p>报错的直接原因就是 已存在相同key的sequenceNumber 38818368818大于快照的squenceNumber 38818368817。这个冲突的key由worker 10写入memtable,但是由worker 11提交,并不是出错的线程。总结下来, 我们发现几个奇怪的现象:</p>    <p>1. 存在多个线程写一个key的情况,比如worker10曾经写过key为10,4,和3的记录</p>    <p>2. 对于出错的sequenceNumber(38818368818)的key,为什么会被worker11提交</p>    <p>3. 日志中发现SequenceNumber不连续,存在跳跃的现象</p>    <p>前两个问题很容易让我们陷入误区,存在多个worker写同一个key的情况,而事实上这两个问题都是源于group-commit机制,其它线程可能会代替你提交,导致你会看到同一个worker写不同key的现象。这里的group-commit包括两个层次,server层group-commit和rocksdb引擎的group-commit。</p>    <p style="text-align:center">  <img src="https://simg.open-open.com/show/971f0ee451fd8807b90f5207c8e73540.png"></p>    <p>从图中可以看出,在server层group-commit机制下,流入到rocksdb引擎层commit接口的都是串行的,既然是串行的,为什么sequenceNumber会存在跳跃呢?这时候我想到了binlog_order_commits参数,之前为了提高性能,关闭了该参数,也就是在提交的最后一阶段,多个事务并发在引擎层提交,会不会与并发写memtable有关,因为在之前复现的过程中,我们发现关闭并发写memtable特性(rocksdb_allow_concurrent_memtable_write=0),问题不会复现。</p>    <p>但令人失望的是,在并发写memtable情况下,即使打开了binlog_ordered_commit(server层串行commit),事务串行在引擎层提交仍然会出现同样的问题。</p>    <p>到这里似乎陷入了死胡同,引擎层永远只有一个事务进来,为啥开启并发写memtable会影响正确性呢?因为一个事务没法并发。不知什么时候灵光一现,prepare阶段和commit阶段并发。因为rocksdb最终提交接口WriteImpl是prepare和commit公用的,通过传入的参数来区别。prepare阶段写wal日志,commit阶段写memtable和commit日志。那我们就重点来看prepare和commit并发进入WriteImpl时SequenceNumber相关的代码,果然发现了问题。这里我简单介绍下开启并发写memtable选项时,事务的提交逻辑。</p>    <p>1.每个事务都对应一个write-batch</p>    <p>2.第一个进入WriteImpl函数的线程为leader,其它线程为follower</p>    <p>3.leader和follower根据先后顺序串成一个链表</p>    <p>4.对于并发写memtable的情况,leader根据每个事务write-batch的count,计算每个事务的start-sequenceNumber。</p>    <p>5.leader写完wal日志后,follower根据各自start-sequenceNumber,并发写memtable</p>    <p>6.所有事务都写完memtable后,leader更新全局的sequenceNumber。</p>    <p> </p>    <p>问题主要发生在第4个步骤,计算start-sequenceNumber时,忽略了prepare事务的判断,导致在prepare事务与commit事务成为一个group时,commit事务的sequence出现跳跃,而全局的sequenceNumber只统计了commit事务,最终导致了写入memtable的sequenceNumber比全局sequenceNumber大的现象,进而发生了后续的错误。下面列举一个错误的例子,假设slave_worker1和slave_worker2分别执行完事务trx1和trx2操作,更新位点后开始事务提交,trx1处于prepare阶段,trx2处于commit阶段,trx1和trx2组成一个commit-group, trx1是leader,trx2是follower,current_sequence 是101。</p>    <pre>  <code class="language-cpp">trx1: prepare phase, batch count is 3  put(user_key1,v1);  put(user_key2,v2);  put(user_key3,v3);    trx2: commit phase, batch count is 2  put(user_keyA,v1);  put(user_keyB,v2);</code></pre>    <p>trx1是leader,因此trx2的start sequence 是101+3=104,写入memtable中的user_keyA的sequence是104,user_keyB的sequence是105。Current sequence推进到103。这个group结束后,对于新事务trx3, 如果Current sequnce为已经推进到120(全局任何事务提交都会推进sequence),trx3更新user_keyA,就会发现已经存在(user_keyA, 104),也就是我们遇到的错误;而另外一种情况,假设current Sequence没有推进,仍然为103,则会发生更新丢失,因为查不到(user_keyA,104)这条记录。这正好解释了,为啥我们在同步过程中,会发生丢失更新的问题。</p>    <pre>  <code class="language-cpp">while (w != pg->last_writer) {  // Writers that won't write don't get sequence allotment  if (!w->CallbackFailed()) {  sequence += WriteBatchInternal::Count(w->batch); # // BUG HERE: not check w-> ShouldWriteToMemtable, sequence out of bound.  }    w = w->link_newer;  w->sequence = sequence;  w->parallel_group = pg;  SetState(w, STATE_PARALLEL_FOLLOWER);  }</code></pre>    <h3><strong>小插曲</strong></h3>    <p>到这里,我们已经回答了之前的所有疑问,问题也最终定位。但万万没想到,修改代码提交后,复制问题依旧存在,我感叹是不是不只一个bug。于是继续查,看了下日志,已经不是之前的slave_worker_info表出错了,而是一张业务表。后来才发现是因为替换mysqld后隔离级别没有设置,重启实例后,隔离级别变为Read-Repeatable级别导致。这里简单说下RR隔离下,并行复制下,导致上述错误的原因。首先明确一点,RR隔离是在事务的第一个语句获取快照,以后事务中所有语句都使用这个快照,而RC隔离级别则是事务的每个语句会单独获取快照。在并行复制模式下,假设这样一种情况:</p>    <table cellspacing="0">     <tbody>      <tr>       <td> <p>时间轴</p> </td>       <td> <p>Trx1</p> </td>       <td> <p>Trx2</p> </td>      </tr>      <tr>       <td> <p>1</p> </td>       <td> <p>Begin</p> </td>       <td> <p>Begin</p> </td>      </tr>      <tr>       <td> <p>2</p> </td>       <td> <p>Update t1 set v=? where k=1</p> </td>       <td> </td>      </tr>      <tr>       <td> <p>3</p> </td>       <td> </td>       <td> <p>Update t2 set v=? where k=1</p> </td>      </tr>      <tr>       <td> <p>4</p> </td>       <td> </td>       <td> <p>commit</p> </td>      </tr>      <tr>       <td> <p>5</p> </td>       <td> <p>Update t2 set v=? where k=1</p> </td>       <td> </td>      </tr>     </tbody>    </table>    <p>RR隔离级别下,trx1会在第一个update语句获取快照,更新t2表时,仍然使用之前的快照,而在这期间,t2表的k=1对应的记录可能被修改,导致记录的sequenceNumber大于trx1快照的sequenceNumber,进而导致更新t2失败。而如果是RC级别,trx1执行更新t2表时则会重新获取快照,不会存在问题。</p>    <h3><strong>问题解决</strong></h3>    <p>处理sequenceNumber逻辑不正确主要会导致两个问题,备库丢失更新和备库复制中断。定位到问题原因,并且对所有疑问都有合理的解释后,修改就比较简单了,在计算start-sequenceNumber函数LaunchParallelFollowers中,添加prepare事务的判断即可,随后还需要编写测试用例稳定复现,并进行回归测试才算是最终修复这个补丁。</p>    <h3><strong>总结</strong></h3>    <p>整个排查过程还是比较曲折,因为这个bug涉及到并发,并且是特定参数组合的并发才会出问题,所以对于这种复杂的场景,通过合理假设与日志埋点能逐步得到一些结论和依据,最后抽丝剥茧获取与问题相关的信息,才最终解决问题。我们在测试验证中过程中不断发现很多看似与预期不符的日志,也正是这些日志让我们把整个流程弄透彻,离解决问题越来越近,总之不要放过任何一个疑点,因为要坚信日志不会骗人,而代码逻辑可能因为你忽略了某些分支,导致会有错误的推断。</p>    <p> </p>    <p>来自:http://www.cnblogs.com/cchust/p/6231510.html</p>    <p> </p>    
 本文由用户 meng_xiaozhun 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1482980645978.html
RocksDB MySQL 数据库服务器