从库严重严重落后于主库,读写分离业务失真,基于从库做的报表数据出不来以及基于从库做的数据探查失效。
这里只准备讨论基于 LOGICAL_CLOCK 的并发方式,而不会讨论老的基于 DATABASE 的方式,下面是我设置的参数:
发现是执行DDL操作, 状态是Waiting for table metadata lock 也就是有人拿着mdl不放.
爱可生交付服务团队北京 DBA,对数据库及周边技术有浓厚的学习兴趣,喜欢看书,追求技术。
144 Coordinator线程分发relay log中事务时发现这个事务不能执行,要等待前面的事务完成提交,所以处于waiting for dependent transaction to commit的状态。145/146线程和备份线程162形成死锁,145线程等待162线程 global read lock 释放,162线程占有MDL::global read lock 全局读锁,申请全局commit lock的时候阻塞等待146线程,146线程占有MDL:: commit lock,因为从库设置slave_preserve_commit_order=1,保证从库binlog提交顺序,而146线程执行事务对应的binlog靠后面,所以等待145的事务提交。最终形成了145->162->146->145的死循环,形成死锁。 三个线程相互形成死锁,还是很少见的。 2.2 相关参数为何未生效 --ftwrl-wait-timeout=60 指的是执行FTWRL之前,如果检测到存在长SQL,先等待指定时间(秒),如果超时后还存在长SQL,则备份报错退出。默认为0则表示立即执行。 --ftwrl-wait-threshold=5 指的是执行FTWRL之前,检测长SQL的方法,如果在执行flush前存在已经运行了超过指定时间(秒)的SQL,则将该SQL定义为长SQL,默认60s。 --kill-long-queries_timeout=0 在执行FTWRL后,如果flush操作被阻塞了N秒,则kill掉阻塞它的线程,默认0的情况就是不kill任何阻塞flush的SQL,直到该SQL执行完成。 从上面各个参数的解释,不难看出,--ftwrl-wait-*参数是针对执行FTWRL之前的长SQL检测机制,对于已执行FTWRL时无济于事,--kill-long-*参数则是设置默认值0,不起任何作用。 3. 结论与建议
这是一位朋友给我的一个截图,说show slave status一直处于Wating for Slave workers to free pending events状态,这个库是MTS从库,版本为5.7.25
爱可生服务团队成员,负责处理客户在 MySQL 日常运维中遇到的问题;擅长处理备份相关的问题,对数据库相关技术有浓厚的兴趣,喜欢钻研各种问题。
一、问题描述 [root@mysql-slave ~]# mysql -uroot -pXXX mysql: [Warning] Using a password on the command line interface can be insecure. Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 44883881 Server version: 5.7.23-log MySQL
一 简介 上一篇文章 《MetaData Lock 之一》 简单的介绍了MySQL 引入MDL 的前因后果,本文深入了解MDL的实现原理和运行机制。
获取数据库连接的时间居然超过了30秒,正常情况下一个请求的处理时间是200ms,所以觉得特别奇怪。 按说即使数据库连接数小于请求并发数,因为数据库连接是共享的,请求也可以很快地获取到数据库连接并完成请求。但是实际却超过了30秒。
一 简介 通过前面两篇文章的介绍,相信读到这里的各位对MDL 锁已经有了比较深入的了解了,本文将结合理论知识介绍几组MDL 锁的案例。 二 常见MDL 锁的场景 1 Waiting for global read lock 我们先构造一个Waiting for global read lock场景: session1: alter table t1 add c3 bigint; //大表执行需较长时间 session2: set global read only=on; //等待 查看
在线上进行DDL操作时,相对于其可能带来的系统负载,其实,我们最担心的还是MDL其可能导致的阻塞问题。
某次测试过程中,发现在 AFTER 级别下,节点故障会导致集群无法进行事务提交,同时,当事务进入提交阶段后,其它节点无法开启只读事务。整个集群无法正常提供服务,直到故障节点被踢出集群。
近期,发现一个 MySQL 从节点提示同步异常。执行 show replica status 都被挂起。
死锁其实是一个很有意思也很有挑战的技术问题,大概每个DBA和部分开发朋友都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析,希望能够对想了解死锁的朋友有所帮助。
原文链接 https://blogs.oracle.com/mysql/post/mysql-8-and-replication-observability
今天在测试MySQL事务隔离级别的时候,发现了一个有趣的问题,也参考了杨一之前总结的一篇。http://blog.itpub.net/22664653/viewspace-1612574/
create table eg_60 ( num number, txt varchar2(10) );
某用户A反馈CDB实例读业务数据库没有响应,在控制台界面看到ro节点被剔除,剔除之前数据库监控上面cpu负载正常,活跃线程数出现大量的堆积;提单后,平台紧急介入,观察到ro节点出现大量的waiting for table metadata lock的报错。
来源 |https://dev.mysql.com/blog-archive/mysql-8-and-replication-observability/
MySQL搭建主从怎么做,相信在MySQLDBA的手里是一件非常简单的工作,xtrabackup 数据库,然后恢复,在然后做主从配置,启动slave start。
最近的世界变化是快, 平行宇宙"被发现", 地球人是外星人的培育的"猿猴",到被抛弃,每天都在刷新. 前几天的MYSQL的事务错误不会滚的问题, 有同学反映没有太明白.
为了兼容 MySQL 5.6 基于库的并行复制,5.7 引入了新的变量 slave-parallel-type,其可以配置的值有:
笔者负责的一个系统最近有新功能上线后突然在预警模块不定时报出MySQL死锁导致事务回滚。幸亏,上游系统采用了异步推送和同步查询结合的方式,感知到推送失败及时进行了补偿。于是,笔者争取了一点时间详细分析了导致死锁的多个事务的执行时序,分析并且得出解决方案。
1、查看CentOS7内核 [root@Docker~]# uname -r 3.10.0-862.el7.x86_64 2、添加Docker源 [root@Docker~]# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo Loaded plugins: fastestmirror, langpacks adding repo from: https://download.docke
看到一个比较有意思的讨论,分享一下: 1.起因是有人提了个issue,压测是,出现了一个问题TransactionException LockKeyConflict异常,全局锁冲突异常:
其中ProcLastRecPtr、XactLastRecEnd更新位置XLogInsertRecord:
事务T1T2操作insert into info values (50,11)insert into info values (60,8)关联的对象表apple.info的唯一索引 uk_name表apple.info的唯一索引 uk_name持有的锁lock mode S waitingheap no 7 11,40(十六进制为8,28)lock_mode X locks rec but not gapheap no 7 11,40(十六进制为8,28)等待的锁lock mode S waitingheap no 7 11,40(十六进制为8,28)lock_mode X locks gap before rec insert intention waitingheap no 7 11,40(十六进制为8,28)
摘要: 数据库 ACID 中的持久化如何实现 数据库 ACID 里面的 D,持久化。 指的是对于用户来说提交的事务,数据是可靠的,即使数据库 crash了,在硬件完好的情况下,也能恢复回来。PostgreSQL 是怎么做到的呢,看一幅图,画得比较丑,凑合看吧。假设一个事务,对数据库做了一些操作,并且产生了一些脏数据。
以前接触到的数据库死锁,都是批量更新时加锁顺序不一致而导致的死锁,但是上周却遇到了一个很难理解的死锁。借着这个机会又重新学习了一下mysql的死锁知识以及常见的死锁场景。在多方调研以及和同事们的讨论下终于发现了这个死锁问题的成因,收获颇多。虽然是后端程序员,我们不需要像DBA一样深入地去分析与锁相关的源码,但是如果我们能够掌握基本的死锁排查方法,对我们的日常开发还是大有裨益的。
目前需要搭建一个从库,由于单表数据量较大,时间比较有限,考虑到导入导出的时间,并且GreatSQL支持并行load data的功能,能够加速数据的导入,因此决定使用 select into outfile 和 load data 的方式进行数据的迁移;
如果有一天业务系统需要增大一个字段长度,能否在线上直接修改呢?在回答这个问题前,我们先来看一个案例:
粉丝表示对Java中的死锁还是略知一二的,但是突然用SQL写死锁的案例之前还真没遇到过,这个问题没答上来。所以今天就带大家一起来看下怎么用SQL让数据库中产生死锁。
Waiting for table metadata lock 这个mdl锁,我们最常见,这篇先拿它开刀。
作者:高鹏(八怪),《MySQL 主从原理》作者,深入透彻理解 MySQL 主从,GTID 相关技术知识。
在MySQL中,SQL优化是很常见的一种需求,我自己这方面的经验也不是特别充足,在我自己的认知中,通常情况下,会通过下面的步骤去优化一个慢日志较多MySQL服务。
相信 slave 延迟是MySQL dba 遇到的一个老生长谈的问题了。我们先来分析一下slave延迟带来的风险
上篇文章介绍了如何在多数据中心部署多套MGR集群,并构建集群间的复制通道。这样一旦主AZ不可用时,在校验完数据后,就可以切换到备用AZ的MGR集群,非常方便。
一 前言 死锁其实是一个很有意思也很有挑战的技术问题,大概每个DBA和部分开发朋友都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析,希望能够对想了解死锁的朋友有所帮助。 二 背景知识 2.1 insert 锁机制 在分析死锁案例之前,我们先学习一下背景知识 insert 语句的加锁策略。我们先来看看官方定义:
ERROR NO 是1756,而且只是 Slave_SQL_Running 停了。
对于数据库系统来说在多用户并发条件下提高并发性的同时又要保证数据的一致性一直是数据库系统追求的目标,既要满足大量并发访问的需求又必须保证在此条件下数据的安全,为了满足这一目标大多数数据库通过锁和事务机制来实现,MySQL数据库也不例外。尽管如此我们仍然会在业务开发过程中遇到各种各样的疑难问题,本文将以案例的方式演示常见的并发问题并分析解决思路。
在业务低峰通过pt-osc在线做DDL期间出现死锁,导致业务的SQL被回滚了,对应用不友好。 本案例死锁发生的场景:pt-osc拷贝最后一个chunk-size并且期间其它事务有对原表做insert操作,才会出现本案例的死锁。
InnoDB ReplicaSet在 MySQL 8.0.19 版本之后开始支持;本文将针对 InnoDB ReplicaSet这一新特性做一些测试,包括环境部署,在线主从切换、故障切换等;
领取专属 10元无门槛券
手把手带您无忧上云