MySQL复制slave服务器死锁案例

原文:MySQL复制slave服务器死锁案例

MySQL复制刚刚触发了一个bug，该bug的触发条件是slave上Xtrabackup备份的时候执行flushs tables with read lock和show slave status有可能和SQL Thread形成死锁。

该bug在MySQL5.6.23上已修复, https://bugs.mysql.com/bug.php?id=70307

15:24分开始收到报警，这台slave上发生阻塞，并发线程升高，下面描述下死锁和阻塞是如何形成的

1、slave上sql thread执行SQL，还未提交

这是当时抓取到的事务信息，63就是sql thread，活动的事务运行了479S，可以计算出这个事务开始的时间约在2018-06-08 15:15:42

2、Xtrabackup进程执行flush tables with read lock

3、sql thread执行commit，被blocked，Waiting for commit lock (holding rli->data_lock, waiting for MDL_COMMIT)

4、Xtrabackup进程执行show slave status被block (holding LOCK_active_mi and mi->data_lock, waiting for rli->data_lock)，形成死锁

5、其他大部分事务都在等待Waiting for global read lock，形成阻塞，并发线程数升高

6、kill掉sql thread后，阻塞消失

原文地址：https://www.cnblogs.com/lonelyxmas/p/9825430.html

时间： 2024-10-05 10:04:40

MySQL复制slave服务器死锁案例的相关文章

Mysql复制-Slave库设置复制延迟

mysql> stop slave; mysql> change master to master_delay=10;#单位是秒 mysql> start slave; mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event ... SQL_Delay: 10 S

无法用指定MySQL客户端登陆服务器的案例分析

习惯了二进制安装MySQL,今天心血来潮想装个RPM包的MySQL玩玩,没想到一装还真碰到了点问题,下面把碰到的问题分享一下首先去官网下载安装包,地址是:http://downloads.mysql.com/archives/community/ 根据自己的系统版本和平台选择要安装的包,我的测试机是32 bit的 RHEL 5.3 我选择的是5.0.96,挺老的版本了,需要下载一个server包和一个client包,分别为: MySQL-server-community-5.0.96-1.rh

MySQL主从延迟复制实践及生产故障案例恢复实践

1.1 MySQL主从延迟复制介绍从MySQL5.6开始支持了主从延迟复制,这个功能主要解决的问题是,当主库有逻辑的数据删除或错误更新后,所有的从库都会进行错误的更新,从而导致所有的数据库数据异常,即使有定时的备份数据可以用于数据恢复,特别是数据库数据量很大时,恢复时间会很长,再恢复期间数据库数据被删或错误数据影响正常的访问体验. 而延迟复制就可以较好的解决这个问题.例如,可以设定某一个从库和主库的更新延迟1小时,这样主库数据出问题以后,1个小时以内发现,可以对这个从库进行无害恢复处理,使之依

Mysql复制（Master/Slave实现）

1.Mysql复制方式: * 基于行的复制(5.1中引入) * 基于语句的复制注:都是通过在主库上记录binlog.在备库上重放日志的方式来实现异步的数据复制的.这意味着,在同一时间点备库上的数据可能与主库存在不一致性,并且无法保证主备之间的延迟. 2.应用场景: * 数据分布: Mysql复制通常不会对带宽造成很大的压力,但是基于行的复制会比传统的基于语句复制模式的带宽压力更大些. * 负载均衡: 通过Mysql复制可以装读操作分布到多个服务器上,实现对读密集型应用的优化,并且实现方便,通过

MySQL 复制过滤器、监控维护及主从复制的读写分离

MySQL 复制过滤器.监控维护及基于SSL的主从复制 =============================================================================== 概述: 本章将主要介绍MySQL复制中如何过滤,监控维护,以及基于SSL的主从复制,具体内容如下: MySQL 复制过滤器 ·从服务器库级别过滤 MySQL 清理日志:PURGE 复制监控 ·Master ·Slave 如何确定主从节点的数据是否一致 MySQL基于SSL的主从复制(

Mysql 复制工具(percona-toolkit)

Mysql 复制工具 1.percona-toolkit简介 percona-toolkit是一组高级命令行工具的集合,用来执行各种通过手工执行非常复杂和麻烦的mysql和系统任务,这些任务包括: 检查master和slave数据的一致性有效地对记录进行归档查找重复的索引对服务器信息进行汇总分析来自日志和tcpdump的查询当系统出问题的时候收集重要的系统信息 percona-toolkit源自Maatkit 和Aspersa工具,这两个工具是管理mysql的最有名的工具,现在Maat

MySQL Innodb表导致死锁日志情况分析与归纳

发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志案例描述在定时脚本运行过程中,发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志.两个sql语句如下:(1)insert into backup_table select * from source_table(2)DELETE FROM source_table WHERE Id>5 AND titleWeight<32768 AND

mysql复制(高可用架构方案的基础)

mysql复制:把一个数据库实例上所有改变复制到另外一个数据库库服务器实例的过程特点:1.没有改变就无所谓复制 ;改变是复制的根本与数据源2.所有的改变:是指可以复制全部改变,也可以复制部分改变可以在全部改变中根据业务需求选择部分库和部分表的复制复制的场景: 1.数据库容灾 2.需求:创建一个从数据服务器,做数据的测试和分析 3.负载均衡 4.复制时高可用架构方案的基础 mysql高可用架构特点1.数据库故障的检测与排除2.主从数据库的切换3.数据的备份和保护 mysql高可用架构常用方案1.

MySQL复制 -- binlog(2)

MySQL复制是使用最为广泛的一套组建,上一节已经简单说了一下复制的一些用途和复制的原理,知道了这些我们能够快速的搭建起复制的平台,但是仅知道这些还是不够的,很多时候并不是一帆风顺的,总会有那么一小段时间,或者总会有那么几次会出现各种各样的问题.当出现问题我们应该怎么去解决呢? 下面我们先来看看MySQL复制常见的一些问题,以及对应的解决办法:更进一步的我们是否可以考虑做的更好,提供自动化或者半自动化的工具来帮助我们更快更好的解决问题呢? OK,首先我们先来看看我们经常在复制中会遇到的问题吧.