改进MySQL的table_cache

*************************

FLUSH TABLE WITH READ LOCK详解,flushlock

      FLUSH TABLES WITH READ
LOCK简称(FTWRL),该命令主要用于备份工具获取一致性备份(数据与binlog位点匹配)。由于FTWRL总共需要持有两把全局的MDL锁,并且还需要关闭所有表对象,因此这个命令的杀伤性很大,执行命令时容易导致库hang住。如果是主库,则业务无法正常访问;如果是备库,则会导致SQL线程卡住,主备延迟。本文将详细介绍FTWRL到底做了什么操作,每个操作的对库的影响,以及操作背后的原因。 

FTWRL做了什么操作?

FTWRL主要包括3个步骤:

1.上全局读锁(lock_global_read_lock)
2.清理表缓存(close_cached_tables)
3.上全局COMMIT锁(make_global_read_lock_block_commit)

FTWRL每个操作的影响

   
 上全局读锁会导致所有更新操作都会被堵塞;关闭表过程中,如果有大查询导致关闭表等待,那么所有访问这个表的查询和更新都需要等待;上全局COMMIT锁时,会堵塞活跃事务提交。由于FTWRL主要被备份工具使用,后面会详细解释每个步骤的作用,以及存在的必要性。FTWRL中的第1和第3步都是通过MDL锁实现,关于MDL的实现,我之前总结了MDL锁的文章,这里主要介绍清理表缓存的流程。 

清理表缓存   

  
 每个表在内存中都有一个table_cache,不同表的cache对象通过hash链表维护。

访问cache对象通过LOCK_open互斥量保护,每个会话打开的表时,引用计数share->ref_count++,
关闭表时,都会去对引用计数share->ref_count–。

若发现是share对象的最后一个引用(share->ref_count==0),并且share有old_version,

则将table_def_cache从hash链表中摘除,调用free_table_share进行处理。关键函数close
table流程如下:

1.关闭所有未使用的表对象
2.更新全局字典的版本号
3.对于在使用的表对象,逐一检查,若表还在使用中,调用MDL_wait::timed_wait进行等待
4.将等待对象关联到table_cache对象中
5.继续遍历使用的表对象
6.直到所有表都不再使用,则关闭成功。

清理表缓存函数调用

mysql_execute_command->reload_acl_and_cache->close_cached_tables

->TABLE_SHARE::wait_for_old_version->MDL_wait::timed_wait->
inline_mysql_cond_timedwait

会话操作表流程

1.打开表操作,若发现还有old_version,则进行等待
2.share->ref_count++
3.操作完毕,检查share->ref_count–是否为0
4.若为0,并且检查发现有新版本号,则认为cache对象需要重载
5.将cache对象摘除,调用MDL_wait::set_status唤醒所有等待的线程。

关闭表对象函数调用

dispatch_command->mysql_parse->mysql_execute_command->

close_thread_tables->close_open_tables->close_thread_table->

intern_close_table->closefrm->release_table_share->my_hash_delete->
table_def_free_entry->free_table_share

关闭表导致业务库堵住的典型场景

   
 假设有3个会话,会话A执行大查询,访问t表;然后一个备份会话B正处于关闭表阶段,需要关闭表t;随后会话C也请求访问t表。三个会话按照这个顺序执行,我们会发现备份会话B和会话C访问t表的线程都处于“waiting
for table
flush”状态。这就是关闭表引起的,这个问题很严重,因为此时普通的select查询也被堵住了。下面简单解释下原因:

1.会话A打开表t,执行中……
2.备份会话B需要清理表t的cache,更新版本号(refresh_version++)
3.会话B发现表t存在旧版本(version !=
refresh_version),表示还有会话正在访问表t,
等待,加入share对象的等待队列
4.后续会话C同样发现存在旧版本(version != refresh_version),
等待,加入share对象的等待队列
……

  1. 大查询执行完毕,调用free_table_share,唤醒所有等待线程。

free_table_share //逐一唤醒所有等待的线程。
{
while ((ticket= it++))
ticket->get_ctx()->m_wait.set_status(MDL_wait::GRANTED);
}

第4步与第5步之间,所有的访问该表的会话都处于“waiting for table
flush”状态,唯有大查询结束后,等待状态才能解除。

主备切换场景

     
在生产环境中,为了容灾一般mysql服务都由主备库组成,当主库出现问题时,可以切换到备库运行,保证服务的高可用。在这个过程中有一点很重要,避免双写。因为导致切换的场景有很多,可能是因为主库压力过大hang住了,也有可能是主库触发mysql
bug重启了等。当我们将备库写开启时,如果老主库活着,一定要先将其设置为read_only状态。“set
global
read_only=1”这个命令实际上也和FTWRL类似,也需要上两把MDL,只是不需要清理表缓存而已。如果老主库上还有大的更新事务,将导致set
global read_only hang住,设置失败。因此切换程序在设计时,要考虑这一点。

关键函数:fix_read_only

1.lock_global_read_lock(),避免新的更新事务,阻止更新操作
2.make_global_read_澳门新葡亰赌995577,lock_block_commit,避免活跃的事务提交

FTWRL与备份

     
Mysql的备份方式,主要包括两类,逻辑备份和物理备份,逻辑备份的典型代表是mysqldump,物理备份的典型代表是extrabackup。根据备份是否需要停止服务,可以将备份分为冷备和热备。冷备要求服务器关闭,这个在生产环境中基本不现实,而且也与FTWRL无关,这里主要讨论热备。Mysql的架构支持插件式存储引擎,通常我们以是否支持事务划分,典型的代表就是myisam和innodb,这两个存储引擎分别是早期和现在mysql表的默认存储引擎。我们的讨论也主要围绕这两种引擎展开。对于innodb存储引擎而言,在使用mysqldump获取一致性备份时,我们经常会使用两个参数,–single-transaction和–master-data,前者保证innodb表的数据一致性,后者保证获取与数据备份匹配的一致性位点,主要用于搭建复制。现在使用mysql主备集群基本是标配,所以也是必需的。对于myisam,就需要通过–lock-all-tables参数和–master-data来达到同样的目的。我们在来回顾下FTWRL的3个步骤:

  1. 上全局读锁
  2. 清理表缓存
  3. 上全局COMMIT锁

第一步的作用是堵塞更新,备份时,我们期望获取此时数据库的一致状态,不希望有更多的更新操作进来。对于innodb引擎而言,其自身的MVCC机制,可以保证读到老版本数据,因此第一步对它使多余的。第二步,清理表缓存,这个操作对于myisam有意义,关闭myisam表时,会强制要求表的缓存落盘,这对于物理备份myisam表是有意义的,因为物理备份是直接拷贝物理文件。对于innodb表,则无需这样,因为innodb有自己的redolog,只要记录当时LSN,然后备份LSN以后的redolog即可。第三步,主要是保证能获取一致性的binlog位点,这点对于myisam和innodb作用是一样的。

   
 所以总的来说,FTWRL对于innodb引擎而言,最重要的是获取一致性位点,前面两个步骤是可有可无的,因此如果业务表全部是innodb表,这把大锁从原理上来讲是可以拆的,而且percona公司也确实做了这样的事情,具体大家可以参考blog链接。此外,官方版本的5.5和5.6对于mysqldump做了一个优化,主要改动是,5.5备份一个表,锁一个表,备份下一个表时,再上锁一个表,已经备份完的表锁不释放,这样持续进行,直到备份完成才统一释放锁。5.6则是备份完一个表,就释放一个锁,实现主要是通过innodb的保存点机制。相关的bug可以参考链接:http://bugs.mysql.com/bug.php?id=71017。

参考文献

https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/

https://www.percona.com/blog/2012/03/23/how-flush-tables-with-read-lock-works-with-innodb-tables/

http://bugs.mysql.com/bug.php?id=71017

http://www.cnblogs.com/bamboos/p/3458233.html

 

http://www.bkjia.com/Mysql/1022575.htmlwww.bkjia.comtruehttp://www.bkjia.com/Mysql/1022575.htmlTechArticleFLUSH TABLE WITH READ LOCK详解,flushlock FLUSH
TABLES WITH READ
LOCK简称(FTWRL),该命令主要用于备份工具获取一致性备份(数据与binlog位点匹配)。
由于…

将占位符链到open tables list上:

在table
cache的hash中创建一个placeholder(占位符):table_cache_insert_placeholder

 

**********************************************

 

    {

free_cache_entry  //释放一个表的内存。

 

创建一个新的table实例,并插入到open cache中

 

        thd->open_tables= table;

hash_prev:

      c2: open t1; — blocks

      refresh_version from the moment when this table was

      order mismatch with some other thread:

      c2: open t2;      — sort of shared lock

  {

3)从链表中删除item:

table_cache_insert_placeholder

             hash_delete(&open_cache,(uchar*)
unused_tables);            


 

       table= (TABLE*) hash_next(&open_cache, (uchar*) key,
key_length,

 

{

 

 

!………………………..!head!…………………….!

       table && table->in_use ;

*******

error= open_unireg_entry(thd, table, table_list, alias, key,
key_length,

 

        return table

 

    mysql_ha_flush(thd);  
//刷新(关闭并标记为re-open)所有需要reopen的表

reopen_name_locked_table  //重新打开表,保持链表结构

 

head的右边为占用的item链表

 Normally, table->s->version contains the value of

 

      If we do not back off now, we may dead lock in case of lock

以下为本人在工作中的碎碎念,记录的比较凌乱……

    for (table=thd->open_tables; table ; table=table->next)

 

  {                              // Using table locks

 


************

!这些操作都需要全局锁:LOCK_open,来保护table cache和磁盘上的表定义

if (!table_list->skip_temporary)

所有item通过hash_prev和hash_next进行双向指针

while (open_cache.records > table_cache_size &&
unused_tables)         //当cache满时,从中释放未使用的TABLE实例

目前refresh_version只会被FLUSH TABLES命令改变

1)插入新空闲item:在head节点前加入

增加3个指针:

 

 

                                 &state))

}

**************

else

如果是视图or error < 0 释放内存,返回;

    

如果这是该query打开的第一个表:设置thd->version =
refresh_version,这样,当我们打开剩余表的过程中,如果version发生了变化,则需要back
off,关闭所有已经打开的并重新打开表

 

}

 

全局锁:lock_open

**********************************

正常情况:

        table->next= thd->open_tables;

        table->open_placeholder= 1;

      c1: name lock t1; — sort of exclusive lock

2)插入新的被占用item:在head后面加入

 

hash_head:

patch:http://bugs.mysql.com/bug.php?id=33948

2) 检测head是否in_use,为False则table = head, true则找到table =
head->prev

   —若该item为head,修改head右侧的item的hash_head指向head->next

首先,我们分析一下mysql在打开一个表时如何工作:

if (table)

 

my_hash_insert(&open_cache,(uchar*) table)

  1. table_cache key (见create_table_def_key)

 

      statement, refresh_version has been increased.

必要的检查:线程栈是否足够,thd是否被kill

***********

hash_next: always point to used table cached items