爱可生 DBA 团队成员,负责客户的数据库故障处理以及调优。擅长故障排查及性能优化。对数据库相关技术有浓厚的兴趣,喜欢分析各种逻辑。
MySQL 主从复制功能可以搭建从库来为 MySQL 创建一套在线的备份系统,但是自身不能独立实现切换;需要借助第三方高可用工具。然而当自身有大事务在运行时会阻塞一些 show 语句;例如“show master status”,造成误判。
我们码农平时大多数时间都在撸码或者撸码的路上,很少关注mysql的一些底层原理,当出现问题时没能力第一时间解决问题,出现问题后不去层层剖析问题产生的原因,后续也就可能无法避免或者绕开同类的问题。因此不要单纯做Ctrl+c和Ctrl+V,而是一边仰望星空(目标规划),一边脚踏实地去分析每个问题。 在mysql系列专栏里面,我深入浅出的总结了mysql相关知识,感兴趣的话可以去阅读,有问题就可以随时相互交流学习。
事情是这样子的,由于公司要推行降本增效,尽量使得服务器能满负载的去工作,我负责的项目由于对数据库的使用比较轻度,所以就降低配置去使用。而一个新的需求,需要稍微复杂一点的业务逻辑,所以需要对数据库增加一个字段,且增加一个索引,也就是做一点DDL语句的操作,但是由于表的数据量也不小(最大的一张表差不多800多万行,最少也有几百万条数据),所以在此之前,对大表加字段,加索引做了一个比较深入的学习。
本文讲述了在使用Nginx+Lua+MySQL实现高并发请求时,遇到的“消失的记录”问题。通过分析问题原因,发现原来是Nginx+Lua环境下,使用阻塞的HTTP请求库导致连接池被污染,进而引发事务问题。最终通过采用非阻塞的HTTP请求库,解决了问题,但修改量较大,需要一定时间来完成。
在mysql调优的过程中发现,mysql的默认隔离级别是可重复读(repeatable read),其他几类关系型数据库pg,以及sybase,oracle,sqlserver的默认的隔离级别都是读已提交(read committed)。
我们经常发现,往往执行一条简单的查询语句,但是很长时间都没有返回,今天我们看看是什么原因导致的
我们先输入 info thread,拿到 MySQL 的线程表,找到负责刷脏页的线程在 gdb 中对应的 ID,是第 13 号线程:
行锁变表锁,是福还是坑?如果你不清楚MySQL加锁的原理,你会被它整的很惨!不知坑在何方?没事,我来给你们标记几个坑。遇到了可别乱踩。通过本章内容,带你学习MySQL的行锁,表锁,两种锁的优缺点,行锁变表锁的原因,以及开发中需要注意的事项。还在等啥?经验等你来拿!
【温馨提示】由于公众号更改了推送规则,不再按照时间顺序排列,如果不想错过测试开发技术精心准备的的干货文章,请将测试开发技术设为“星标☆”,看完文章在文尾处点亮“在看”!
在上文我们曾小小的提到过,在索引失效的情况下,MySQL会把所有聚集索引记录和间隙都锁上,我们称之为锁表,或叫行锁升表锁.
由于用户同时访问线上的下订单接口,导致在扣减库存时出现了异常,这是一个很典型的并发问题,本篇文章为解决并发问题而生,采用的技术为Redis锁机制+多线程的阻塞唤醒方法。
表级锁:一次性插入和更新较多数据时,当很多操作都是读表时可以选择。但当select语句时间过长或者update和delete语句短而且次数多时,不适用,会各种锁冲突。 行级锁:在很多线程请求不同记录时减少冲突锁。事务回滚时减少改变数据。使长时间对单独的一行记录加锁成为可能。比页级锁和表级锁消耗更多的内存。当需要频繁对大部分数据做 GROUP BY 操作或者需要频繁扫描整个表时不适合。
这个问题之前遇到过一次,但是由于不知道导致锁表的原因,也没细想,就知道表被锁了,然后让别人把表给解锁了。但是前天的一次操作,让我亲眼见证了导致锁表的过程,以及如何给lock的表解锁。
与慢速设备通讯异步化方案.pdf像MySQL、被对接的银行系统等,都可称作慢速设备。它们的共同特点是只提供了同步调用接口,而且响应通常会比较慢。
最近遇到一个由于唯一性索引,导致并发插入产生死锁的场景,在分析死锁产生的原因时,发现这一块还挺有意思的,涉及到MySql中不少的知识点,特此总结记录一下。
导读:MySQL 的 DDL(Data Definition Language) 包括增减字段、增减索引等操作。在 MySQL 5.6 之前,MySQL 的 DDL 操作会按照原来的表复制一份,并做相应的修改。
看到许多写select for update是行锁还是表锁的文章,但每篇文章的结论好像都不太一样。同时,是行锁还是表锁的问题直接影响着系统的性能,所以特意为大家调研一番,也就有了本篇文章,一共为大家汇总验证了20个场景下的结论。
在 mysql 上执行了一句 drop database 半天没有完成,详细的慢查询日志如下,那当时MySQL 在做什么呢?
对MySQL进行alter table等DDL操作时,有时会发现对某个表的任何操作都被阻塞,包括读,报错如下图所示
前阵子参与了字节跳动后端青训营,其中大项目编写涉及到数据持久化一般选择使用MySQL。由于时间原因,数据库使用我选择了无脑三板斧:1. 建立了索引加速查询、2. 关闭自动提交事务、3. 在需要确保原子性的数据库操作之间手动创建和提交事务。
Started: 俗话说一年之计在于春,一天之计在于晨,当我起床的时候,看见表正指向九点钟,十一点下班,十点上班,这是我现在的工作节奏。来北京马上就一个月了,近二十多天里,每天的天气都非常的妩媚,但是工作原因,只能困在办公室里,真是太遗憾了。 看到MSDN的这篇文章【http://msdn.microsoft.com/zh-cn/library/dd764564.aspx#Y300】好像是今年2月份,快过年的样子。记得HM还特蛋疼的研究了一下lamada的汇编实现。当时看到Visual S
2018年5月18日 记录: 数据库持久连接: 1.持久的数据库连接是指在脚本结束运行时不关闭的连接。当收到一个持久连接的请求时。PHP 将检查是否已经存在一个(前面已经开启的)相同的持久连接。如果存在,将直接使用这个连接;如果不存在,则建立一个新的连接。所谓“相同”的连接是指用相同的用户名和密码到相同主机的连接。 2.第一种方法是将 PHP 用作一个单独运行的语言解释器(CGI Wapper)。在这种情况下,使用持久连接和非持久连接没有任何区别——因为PHP脚本本身的执行不是持久的。 3.把 PHP
项目中的技术栈一定要搞清楚,用到了xx技术,要知道为什么要用它,同时还要结合你的业务场景来说。很多人就是把之前的项目忘了,更不用说xx技术在项目中是用来干什么了。
遇到bug不要慌,先把bug找出来。 怎么找MySQL出的bug呢?有 mysql_errno,可以看一下这篇,我把模板给出了(自取可用): C++ 操作 MySQL模块更新
小胖真的让人不省心。继上次小胖误删数据之后,这次这货直接给我把整个表锁住了。页面无响应,用户疯狂投诉,我特么脸都绿了。。。
MySQL 中的锁还是蛮多的,在之前的文章中,松哥和大家介绍过 MySQL 中的 MDL 锁(为什么执行 alter 更新表要慎重?),今天我们再来看看 MySQL 中比较重要的两个锁:S 锁和 X 锁。 1. S 锁 S 锁,英文为 Shared Lock,中文译作共享锁,有时候我们也称之为读锁,即 Read Lock。S 锁之间是共享的,或者说是互不阻塞的。 当事务读取一条记录时,需要先获取该记录的 S 锁。 举个例子: 事务 T1 对记录 R1 加上了 S 锁,那么事务 T1 可以读取 R1 这一行记
某银行客户在从Oracle迁移到MySQL的开发中,MySQL在READ-COMMITTED隔离级别下,出现了insert阻塞update的情况,但同样的情况下,Oracle的insert则不会阻塞update。本文通过复现该问题,分析MySQL的锁信息,确认是MySQL与Oracle在并发事务处理上的差异,在进行数据库迁移改造的程序开发应予以关注。
学习Mysql, 总会有一座绕不过去的大山, 那就是锁。理论上,锁的花样再多,也超不出操作系统课上讲的那些范畴,但是Mysql锁让我翻车了。
Tomcat是这个系统的核心组成部分, 每当有用户请求过来,Tomcat就会从线程池里找个线程来处理,有的执行登录,有的查看购物车,有的下订单,看着属下们尽心尽职地工作,完成人类的请求,Tomcat就很有成就感。
我们在上篇文章中提到了记录锁(行锁)、间隙锁和临键锁,后台有小伙伴催我更新一下其他的锁。拖延症又犯了,趁周末,今天我们来总结一下MyISAM和InnoDB引擎下锁的种类及使用方法。
日常开发我们对一条DML语句较为熟悉,很多开发人员都了解sql的执行过程,比较熟悉,但是DDL是如何执行的呢,大部分开发人员可能不太关心,也认为没必要了解,都交给DBA吧。其实不然,了解一些能尽量避开一些ddl的坑,那么下面带大家一起了解一下DDL执行的方式,也算抛砖引玉吧。如有错误,还请各位大佬们指正。
好几年没写技术博客了,今天写一个小的技术点给大家分享,关于MySQL JDBC StreamResult的原理分享,难度不大,就当程序员的闲聊。
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. 结论与建议
上述这个错误,接触 MySQL 的同学或多或少应该都遇到过,专业一点来说,这个报错我们称之为锁等待超时。
在 MySQL 的实际使用中,常常会遇到一条 SQL 执行非常慢的情况,此前我们总结了一系列博客来排查相关的问题:
线上给某个表执行新增索引SQL, 然后整个数据CPU打到100%, 连接数暴增到极限, 最后导致所有访问数据库的应用都奔溃.
升级完成之后,放业务请求进来,没到一分钟就开始出现慢查询,然后,慢查询越来越多,业务 SQL 出现堆积。
在数据库中,除传统的计算资源的争用以外,数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的问题,锁冲突也是影响数据库并发访问性能的一个重要的因素。
MyISAM 存储引擎只支持表锁,这也是MySQL 开始几个版本中唯一支持的锁类型。
| 作者 王文安,腾讯CSIG数据库专项的数据库工程师,主要负责腾讯云数据库 MySQL 的相关的工作,热爱技术,欢迎留言进行交流。 ---- 在日常工作中,有时候会发现 MySQL 的状态不太对劲,这时候就会看看监控指标,可能会发现:写入 QPS 开始出现毛刺,或者 IO 的指标很高。这时候该怎么办呢? 本文会从 Linux 层面入手,根据不同的 IO 特点来分析 MySQL 数据库可能遇到的问题,并给出一些可参考的优化/缓解思路。 一、怎么看懂 IO 指标? 检查 IO 的问题会使用iostat这
死锁是指两个或更多的事务在执行过程中,因争夺资源而造成的一种相互等待的现象。每个事务都持有一个资源并等待获取另一个事务已占有的资源,从而形成了一个循环等待的情况。除非有外部干预,否则这些事务都将无法向前推进。
是的,他的昵称真的就叫图灵,一开始我以为是图灵出版社的人...他是《PHP网络编程》的阅读者,由于比较读的比较认真仔细,所以他问了一些问题,你们感受一下。
昨天项目中遇到部分服务一直是pending状态,排查了代码和重启了服务都没能解决问题,于是从数据库开始排查。
1. 背景 在使用MySQL时,如果有大表的存储引擎是InnoDB,并且系统参数innodb_file_per_table设置为1,即每个文件对应一个独立的表空间,当对这些大表进行DROP TABLE时,有时会发现整个数据库系统的性能会有显著下降,包括一些只涉及几行数据的简单SELECT查询和DML语句,而且这些语句和正在删除的大表没有关系。造成这种现象的原因是什么呢?通过什么方式能缓解和避免这个问题呢? 2. 已知的瓶颈 Percona曾经在MySQL官方5.5.23之前的版本中遇到过这个问题,并且提供
第三方平台调用我方平台接口后导致服务不可用,数据库大量sleep线程,请求数据库无响应;数据库及代码无任何报错,无法定位问题。第三方接口首次请求并不会触发该问题。
领取专属 10元无门槛券
手把手带您无忧上云