January 8, 2013

bug#66718 Assert from DROP TABLE concurrent with ibuf merges

http://bugs.mysql.com/bug.php?id=66718 Assert from DROP TABLE concurrent with ibuf merges A.原因: master线程发起的ibuf merge和用户线程的drop table操作可能存在竞争。 1.master线程请求文件page IO,读入内存之前,会调用buf_page_init_for_read->fil_tablespace_deleted_or_being_deleted_in_mem 如果这时候该表尚未标记为删除,那么则认为可以继续读文件Page。 2.用户线程调用fil_delete_tablespace >设置space->stop_ibuf_merges = TRUE >确认space->n_pending_ibuf_merges == 0   设置space->is_being_deleted = TRUE; >确认space->chain->n_pending为0  并且 space->n_pending_flushes = 0 继续下面的逻辑 3.master线程继续调用函数fil_io -> fil_node_prepare_for_io会递增node->n_pending++ 4.用户线程继续往下走,调用 fil_delete_tablespace->fil_space_free->fil_node_free 在这里会做断言: ut_a(node->n_pending == 0); 不过在Percona版本中,断言处就不太一样,而是: ut_a(node->n_pending == 0 || space->is_being_deleted); 因为在free node之前,我们已经设置了space->is_being_deleted为TRUE,因此不会触发断言错误。 B.总结: 根据bug描述及分析,这个bug不影响我们的线上MySQL版本。 C.其他: 我们已经确保space->n_pending_ibuf_merges为0了,为什么还会有对该表的ibuf Merge呢? […]