MySQL · 挖坑 · LOCK_active_mi/LOCK_msp_map 优化思路

背景

在MySQL中Slave相关操作一直存在一把大锁——LOCK_active_mi (5.5及之前版本,以及MariaDB),或LOCK_msp_map(5.6及之后的版本)。
在Slave操作中大家可能经常会遇到如下懵逼的操作:

  1. 线程1:STOP SLAVE;有事务要回滚,一直不结束,然后LOCK_active_mi一直被这个线程持有
  2. 线程2:SHOW SLAVE STATUS;拿不到LOCK_active_mi,无法执行。

SHOW SLAVE STATUS 经常作为监控脚本的语句被自动执行,然后就不停地被卡住,线程堆积,直到 too many connections。

等到了5.6引入了多源复制之后,这个问题就更严重了,LOCK_msr_map需要在访问任何通道时都被持有,因此操作两个不同的通道也可能冲突。

Percona曾经推出了SHOW SLAVE STATUS NO_BLOCK这样的语法,不加锁查看复制状态,但是,毕竟这不是根治之法,一方面查看的数据并不一定对,还可能Crash(例如查看过程中通道被删除了),并且需要专门的语法。

特别是5.6还支持了多线程复制,IO THREAD可以多个(多通道),SQL THREAD可以并行(并行复制),这种情况下,LOCK_msr_map这么大一把锁就更加显得格格不入了。

解决思路

我们先来分析一下,对各个Slave通道的操作到底有哪些是真的互斥。

  1. 并发读写同一个通道的运行状态:
    例如 mi->running,mi->info_thd 等,已有mi->run_lock保护IO线程,mi->rli->run_lock保护SQL线程。
  2. 并发读写同一个通道的执行数据:
    例如 mi->master_log_pos,mi->rpl_filter 等,已有mi->data_lock保护IO线程,mi->rli->data_lock保护SQL线程。
  3. 并发读写同一个通道的错误码和错误消息:
    例如 mi->last_error 等,已有mi->err_lock保护IO线程,mi->rli->err_lock保护SQL线程。
  4. 对于多源复制,增减通道:
    msr_map结构的增删改查需要保护,否则可能在遍历所有通道时有通道增加或删除,那遍历结果就不对了。这里真的需要LOCK_msr_map保护。

可见,除了msr_map的操作真的需要全局互斥以外,其他的操作其实都有Master_info内的锁可以保护,在mi内部解决矛盾就可以,根本无需全局锁。

MySQL 5.7 给了一个改进方案,是将LOCK_msr_map从mysql_mutex_t(pthread_mutex_t)改成了Checkable_rwlock。这个方案可以解决部分只读操作时可以相互并发,但是并没有解决LOCK_msr_map保护范围太广的问题。上面我们给出的STOP SLAVE卡住(wr_lock)和SHOW SLAVE STATUS执行互斥的问题就没有解决。

为了彻底解决这个问题,我们可以参考InnoDB怎么保证Buffer Pool中Page的并发性的:

  1. 每当有线程正在访问Page时,将计数器(bpage->io_fix)加一,就把这个Page Pin在内存中了。
  2. LRU淘汰Page时,看到io_fix还不是0,就不能从内存中清理,因为还有人在访问,必须等到0才能清除。
  3. 对Page内容的操作,有Latch来保证,避免同时有人修改页面。

因此我们也可以在每个Master_info中加一个计数器(mi->users),有线程要使用mi,就将计数器加一,不用了就减一,以此来代替加锁放锁,再用一个专门的锁(sleep_lock)来保护计数器就可以了。

加锁操作成了:

void Master_info::use()
{
  mysql_mutex_lock(&sleep_lock);
  users++;
  mysql_mutex_unlock(&sleep_lock);
}

放锁操作成了:

void Master_info::release()
{
  mysql_mutex_lock(&sleep_lock);
  if (!--users && killed)
    mysql_cond_signal(&sleep_cond);
  mysql_mutex_unlock(&sleep_lock);
  DBUG_VOID_RETURN;

}

每次放锁时发一个信号量,让remove_mi操作能收到信号量后再执行删除Master_info的操作。

然后原本需要LOCK_msr_map保护的Master_info操作,可以缩小范围,只需要在取出mi时拿锁就可以了。

Master_info *get_master_info(const char *connection_name)
{
  Master_info *mi;
  DBUG_ENTER("get_master_info");
  /* Protect against inserts into msr_map */
  mysql_mutex_lock(&LOCK_msr_map);
  if ((mi= msr_map.get_mi(connection_name)))

    mi->use();
  mysql_mutex_unlock(&LOCK_msr_map);
  DBUG_RETURN(mi);
}

再把原来需要get_mi调用的地方,全部修改为get_master_info这个调用,就可以删掉其mysql_mutex_lock(&LOCK_msr_map)加锁保护了,放锁的mysql_mutex_unlock(&LOCK_msr_map)语句全部改成mi->release()即可。这样就不存在全局锁定了。

比如启动一个通道的复制:

if ((mi= get_master_info(lex->mi.channel)))
  {
    res= start_slave(thd, mi, 1 /*net report */);
    mi->release();
}

完全不需要 mysql_mutex_lock(&LOCK_msr_map)和mysql_mutex_unlock(&LOCK_msr_map)来包住start_slave了对不对!

但这种修改就带来了另一个问题,要删除一个Master_info的时候,可能还有线程在使用这个mi。
因此在析构函数中需要增加一个等待,让这个mi的所有调用都释放了再清理这个mi。
有了计数器这个也很容易做到,每当收到计数器减一的信号时,看一下是不是计数器到0了,到0了就说明所有使用者全部释放了,就可以正常删除了。

void Master_info::wait_until_free()
{
  mysql_mutex_lock(&sleep_lock);
  killed= 1;
  while (users)
    mysql_cond_wait(&sleep_cond, &sleep_lock);
  mysql_mutex_unlock(&sleep_lock);
}

效果

这样改进以后,我们再来看最开始这个典型的案例:

  1. STOP SLAVE执行卡住,那么会导致这个mi或者所有mi的计数器加一。
  2. SHOW SLAVE STATUS执行,在这个mi或者所有mi的计数器加一。
    并不涉及到相互锁定,只是此时无法删除通道而已,这也是合理的。两个线程都能愉快的执行自己的任务。

补丁我们会在之后的AliSQL开源版本中开源,敬请期待。

时间: 2024-10-14 18:27:54

MySQL · 挖坑 · LOCK_active_mi/LOCK_msp_map 优化思路的相关文章

MySQL延迟关联性能优化方法

  这篇文章主要介绍了MySQL延迟关联性能优化方法,本文讲解了延迟关联的背景.延迟关联的分析.延迟关联的解决等内容,需要的朋友可以参考下 [背景] 某业务数据库load 报警异常,cpu usr 达到30-40 ,居高不下.使用工具查看数据库正在执行的sql ,排在前面的大部分是: 代码如下: SELECT id, cu_id, name, info, biz_type, gmt_create, gmt_modified,start_time, end_time, market_type, b

101个MySQL的调节和优化的提示

  MySQL是一个功能强大的开源数据库.随着越来越多的数据库驱动的应用程序,人们一直在推动MySQL发展到它的极限.这里是101条调节和优化 MySQL安装的技巧.一些技巧是针对特定的安装环境的,但这些思路是通用的.我已经把他们分成几类,来帮助你掌握更多MySQL的调节和优化技巧. MySQL 服务器硬件和操作系统调节: 1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中--在内存中访问文件时的速度要比在硬盘中访问时快的多. 2. 不惜一切代价避免使用Swap交换分区 – 交换时是从

秒杀系统架构优化思路

<秒杀系统架构优化思路> 上周参加Qcon,有个兄弟分享秒杀系统的优化,其观点有些赞同,大部分观点却并不同意,结合自己的经验,谈谈自己的一些看法. 一.为什么难 秒杀系统难做的原因:库存只有一份,所有人会在集中的时间读和写这些数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如12306抢票,亦与秒杀类似,瞬时流量更甚. 二.常见架构 流量到了亿级别,常见站点架构如上: 1)浏览器端,最上层,会执行到一些JS代码 2)站点层,这一层会访问后端数据,拼

运维多年经验详谈MySQL数据应该如何优化

数据库的设计可能只会根据当时的业务需求来设计,可能当时并不需要高可用.高伸缩等特性的,但是随着业务及用户量的增加,基础架构才逐渐完善.这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段: 1.数据库表设计项目立项后,开发部根据产品部需求开发项目,开发工程师工作其中一部分就是对表结构设计.对于数据库来说,这点很重要,如果设计不当,会直接影响访问速度和用户体验.影响的因素很多,比如慢查询.低效的查询语句.没有适当建立索引.数据库堵塞(死锁)等.

总结的 MySQL 的调节和优化的提示 101 条【老师不会告诉你的】

MySQL是一个功能强大的开源数据库.随着越来越多的数据库驱动的应用程序,人们一直在推动MySQL发展到它的极限.这里是101条调节和优化 MySQL安装的技巧.一些技巧是针对特定的安装环境的,但这些思路是通用的.我已经把他们分成几类,来帮助你掌握更多MySQL的调节和优化技巧. MySQL 服务器硬件和操作系统调节: 1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中--在内存中访问文件时的速度要比在硬盘中访问时快的多. 2. 不惜一切代价避免使用Swap交换分区 ? 交换时是从硬盘

闪存存储特性以及数据库相关优化思路

闪存存储当前越来越多的应用于企业级环境,特别是提升数据库性能方面.本次分享主要介绍闪存的特性,闪存的劣势及其解决机制,以及采用闪存存储时数据库的一些优化思路. 目录 闪存的特性 闪存的劣势及其解决机制 数据库场景测试 一.闪存的特性 凡是采用Flash Memory的存储设备,可以统称为闪存存储.我们经常谈的固态硬盘(SSD),可以由volatile/non-volatile memory构成,其实固态硬盘的范畴是大于闪存的,只是当前的固态硬盘大多数采用闪存介质,所以很多时候我们默认固态硬盘就是

101个MySQL的配置和优化的提示_Mysql

MySQL是一个功能强大的开源数据库.随着越来越多的数据库驱动的应用程序,人们一直在推动MySQL发展到它的极限.这里是101条调节和优化 MySQL安装的技巧.一些技巧是针对特定的安装环境的,但这些思路是通用的.我已经把他们分成几类,来帮助你掌握更多MySQL的调节和优化技巧. MySQL 服务器硬件和操作系统调节: 1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中--在内存中访问文件时的速度要比在硬盘中访问时快的多.2. 不惜一切代价避免使用Swap交换分区 – 交换时是从硬盘读

谈谈:特殊类网站的核心优化思路

特殊类网站指的是哪些呢? 特殊类网站是指商城.论坛.电影.小说.门户等普遍性不是非常高的网站.像博彩.代孕.传播不良信息的网站 下面南平seo与大家分享特殊类网站的优化思路的核心要点. 商城类网站优化思路: 商城类网站主要由商品页面构成,那么我们优化核心就很简单了.用户需要的是产品页面的内容,所以我们的优化核心就是产品页面.那么我们该如何优化呢? 第一,我们首先需要增加产品的信息丰富度,文字信息.图片信息相结合,满足用户对于这个产品的需求. 第二,为我们的产品加上附加价值, 那怎么样才算给我们的

浅析:新站上线我的优化思路

众所周知,新站上线其优化手法和思路往往和老站有着巨大的差别,主要在于新站本身根本没权重,上线之后第一道关就是要经过百度的考核,在百度考察的过程中,我们网站没排名,甚至很长时间收录都不会变化,这个时候也是最容易浮躁和出问题的时候,笔者自己的西安橱柜网上线一周左右,正常工作日每天更新,目前的状况是收录2篇,现在笔者分享下后一阶段我对于这个站的优化思路,大家先看看图示.   第一,网站关键词的布局分析.新站上线之后关键词的布局和分析是基础,企业网站导航一般是公司简介.产品展示之类的,布置关键词一般三大