FAQ系列 | 磁盘空间满了之后MySQL会怎样

导读

当磁盘空间爆满后,MySQL会发生什么事呢?又应该怎么应对?

会发生什么事

当磁盘空间写满了之后,MySQL是无法再写入任何数据的,包括对表数据的写入,以及binlog、binlog-index等文件。
当然了,因为InnoDB是可以把脏数据先放在内存里,所以不会立刻表现出来无法写入,除非开启了binlog,写入请求才会被阻塞。

当MySQL检测到磁盘空间满了,它会:

  • 每分钟:检查空间是否得到释放,以便写入新数据。当发现有剩余空间了,就会继续写入数据,一切照旧。
  • 每十分钟:如果还是发现没剩余空间,则会在日志中写入一条记录,报告磁盘空间满(这时候只写入几个字节还是够的)。

应该怎么办

那么,当发现磁盘空间满了之后,我们应该怎么处理呢,建议:

  • 提高监控系统检测频率,预防再次发生;
  • 及时删除不用的文件,释放空间;
  • 若有线程因磁盘满的问题被阻塞了,可先杀掉,等到下一分钟重新检测时它可能又可以正常工作了;
  • 可能因磁盘满导致某些线程被阻塞,引发其他线程也被阻塞,可把导致阻塞的线程杀掉,其他被阻塞的线程也就能继续工作了。

例外

有个例外的情况是:
当执行 REPAIR TABLE 或者 OPTIMIZE TABLE 操作时,或者执行完 LOAD DATA INFILEALTER TABLE 之后批量更新索引时,这些操作会创建临时文件,当执行这些操作过程中mysqld发现磁盘空间满了,就会把这个涉及到的表标记为crashed,删掉临时文件(除了 ALTER TABLE 操作,MySQL会放弃正在执行的操作,删除临时文件,释放磁盘空间)。

备注:当执行这些命令过程中mysqld进程被意外被杀掉的话,其所生成临时文件不会自动删除,需要手工删掉才能释放磁盘空间。

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠
 
 

MySQL高可用方案选型参考

本次专题是 MySQL高可用方案选型,这个专题想必有很多同学感兴趣。

高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了,直接进入主题。

可选MySQL高可用方案

MySQL的各种高可用方案,大多是基于以下几种基础来部署的:

  1. 基于主从复制;
  2. 基于Galera协议;
  3. 基于NDB引擎;
  4. 基于中间件/proxy;
  5. 基于共享存储;
  6. 基于主机高可用;

在这些可选项中,最常见的就是基于主从复制的方案,其次是基于Galera的方案,我们重点说说这两种方案。其余几种方案在生产上用的并不多,我们只简单说下。

基于主从复制的高可用方案

双节点主从 + keepalived/heartbeat

一般来说,中小型规模的时候,采用这种架构是最省事的。
两个节点可以采用简单的一主一从模式,或者双主模式,并且放置于同一个VLAN中,在master节点发生故障后,利用keepalived/heartbeat的高可用机制实现快速切换到slave节点。

在这个方案里,有几个需要注意的地方:

  • 采用keepalived作为高可用方案时,两个节点最好都设置成BACKUP模式,避免因为意外情况下(比如脑裂)相互抢占导致往两个节点写入相同数据而引发冲突;
  • 把两个节点的auto_increment_increment(自增步长)和auto_increment_offset(自增起始值)设成不同值。其目的是为了避免master节点意外宕机时,可能会有部分binlog未能及时复制到slave上被应用,从而会导致slave新写入数据的自增值和原先master上冲突了,因此一开始就使其错开;当然了,如果有合适的容错机制能解决主从自增ID冲突的话,也可以不这么做;
  • slave节点服务器配置不要太差,否则更容易导致复制延迟。作为热备节点的slave服务器,硬件配置不能低于master节点;
  • 如果对延迟问题很敏感的话,可考虑使用MariaDB分支版本,或者直接上线MySQL 5.7最新版本,利用多线程复制的方式可以很大程度降低复制延迟;
  • 对复制延迟特别敏感的另一个备选方案,是采用semi sync replication(就是所谓的半同步复制)或者后面会提到的PXC方案,基本上无延迟,不过事务并发性能会有不小程度的损失,需要综合评估再决定;
  • keepalived的检测机制需要适当完善,不能仅仅只是检查mysqld进程是否存活,或者MySQL服务端口是否可通,还应该进一步做数据写入或者运算的探测,判断响应时间,如果超过设定的阈值,就可以启动切换机制;
  • keepalived最终确定进行切换时,还需要判断slave的延迟程度。需要事先定好规则,以便决定在延迟情况下,采取直接切换或等待何种策略。直接切换可能因为复制延迟有些数据无法查询到而重复写入;
  • keepalived或heartbeat自身都无法解决脑裂的问题,因此在进行服务异常判断时,可以调整判断脚本,通过对第三方节点补充检测来决定是否进行切换,可降低脑裂问题产生的风险。

双节点主从+keepalived/heartbeat方案架构示意图见下:

MySQL双节点高可用架构
图解:MySQL双节点(单向/双向主从复制),采用keepalived实现高可用架构。

多节点主从+MHA/MMM

多节点主从,可以采用一主多从,或者双主多从的模式。
这种模式下,可以采用MHA或MMM来管理整个集群,目前MHA应用的最多,优先推荐MHA,最新的MHA也已支持MySQL 5.6的GTID模式了,是个好消息。
MHA的优势很明显:

  • 开源,用Perl开发,代码结构清晰,二次开发容易;
  • 方案成熟,故障切换时,MHA会做到较严格的判断,尽量减少数据丢失,保证数据一致性;
  • 提供一个通用框架,可根据自己的情况做自定义开发,尤其是判断和切换操作步骤;
  • 支持binlog server,可提高binlog传送效率,进一步减少数据丢失风险。

不过MHA也有些限制

  • 需要在各个节点间打通ssh信任,这对某些公司安全制度来说是个挑战,因为如果某个节点被黑客攻破的话,其他节点也会跟着遭殃;
  • 自带提供的脚本还需要进一步补充完善,当然了,一般的使用还是够用的。

多节点主从+etcd/zookeeper

在大规模节点环境下,采用keepalived或者MHA作为MySQL的高可用管理还是有些复杂或麻烦。
首先,这么多节点如果没有采用配置服务来管理,必然杂乱无章,线上切换时很容易误操作。
在较大规模环境下,建议采用etcd/zookeeper管理集群,可实现快速检测切换,以及便捷的节点管理。

基于Galera协议的高可用方案

Galera是Codership提供的多主数据同步复制机制,可以实现多个节点间的数据同步复制以及读写,并且可保障数据库的服务高可用及数据一致性。
基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster(简称PXC),目前PXC用的会比较多一些。

PXC的架构示意图见下:

pxc overview
(图片源自网络),图解:在底层采用wsrep接口实现数据在多节点间的同步复制。

 

pxc certification
(图片源自网络),图解:在PXC中,一次数据写入在各个节点间的验证/回滚流程。

PXC的优点

  • 服务高可用;
  • 数据同步复制(并发复制),几乎无延迟;
  • 多个可同时读写节点,可实现写扩展,不过最好事先进行分库分表,让各个节点分别写不同的表或者库,避免让galera解决数据冲突;
  • 新节点可以自动部署,部署操作简单;
  • 数据严格一致性,尤其适合电商类应用;
  • 完全兼容MySQL;

虽然有这么多好处,但也有些局限性:

  • 只支持InnoDB引擎;
  • 所有表都要有主键;
  • 不支持LOCK TABLE等显式锁操作;
  • 锁冲突、死锁问题相对更多;
  • 不支持XA;
  • 集群吞吐量/性能取决于短板;
  • 新加入节点采用SST时代价高;
  • 存在写扩大问题;
  • 如果并发事务量很大的话,建议采用InfiniBand网络,降低网络延迟;

事实上,采用PXC的主要目的是解决数据的一致性问题,高可用是顺带实现的。因为PXC存在写扩大以及短板效应,并发效率会有较大损失,类似semi sync replication机制。

其他高可用方案

  • 基于NDB Cluster,由于NDB目前仍有不少缺陷和限制,不建议在生产环境上使用;
  • 基于共享存储,一方面需要不太差的存储设备,另外共享存储可也会成为新的单点,除非采用基于高速网络的分布式存储,类似RDS的应用场景,架构方案就更复杂了,成本也可能更高;
  • 基于中间件(Proxy),现在可靠的Proxy选择并不多,而且没有通用的Proxy,都有有所针对,比如有的专注解决读写分离,有的专注分库分表等等,真正好用的Proxy一般要自行开发;
  • 基于主机高可用,是指采用类似RHCS构建一个高可用集群后,再部署MySQL应用的方案。老实说,我没实际用过,但从侧面了解到这种方案生产上用的并不多,可能也有些局限性所致吧;

以DBA们的聪明才智,肯定还有其他我不知道的方案,也欢迎同行们间多多交流。

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

MySQL DBA面试全揭秘

本文起源于有同学留言回复说想了解下MySQL DBA面试时可能涉及到的知识要点,那我们今天就来大概谈谈吧。

MySQL DBA职位最近几年特别热门,不少朋友让我帮忙推荐什么的,也有很多公司找不到合适的DBA。原因很简单,优秀的人才要么被大公司圈起来了,要么被创业公司高薪挖走,如果你既不是大公司,又不能出得起高价钱的土豪公司,想要找到优秀人才的几率堪比买彩票中奖的概率,哈哈。

本文可以作为MySQL DBA面试官,以及候选人的双向参考 :)

面试流程

接下来先说下我以往在做MySQL DBA面试时的过程(套路):

  • 1.先自我介绍后,再让候选人花2-5分钟做下自我简介

    • 有不少人可能对自我简介这个环节嗤之以鼻,觉得多此一举,尤其是技术能力相对较好的更是如此。其实不然,通过短短2-5分钟的自我简介,很快就能考察出候选人是否有用心准备本次面试,其归纳总结能力,以及个人自信心等多方面信息。
    • 因此,如果候选人看中这次面试机会的话,还请好好做下功课,做足准备。比如了解下目标公司的大致情况,主营业务,产品特色。可能的话,找同行打听可能的面试官背景信息,没准是校友、以前在同一家公司呆过、或者有其他共同点,这可能会使得面试过程更为顺利。
    • 有心的候选人在面试官自我介绍时,就可以趁机也考察对方的情况。通常第一轮面试官很可能是你未来的直接主管,从面试过程中你和对方的沟通交流是否顺利也可预见到未来工作上配合的顺利程度。
  • 2.暖身完,就开始进入主题,从候选人的简历入手,挑选其中感兴趣的关键点逐条交流,有几个要点:

    • 和应聘职位关联性较高的技术要素,需要逐个过一遍,大致了解候选人对于这些技术要素的掌握程度;
    • 挑选2-3个技术关键点,对候选人穷追猛打深入探讨,了解其真正的掌握程度,是泛泛的了解,还是知其所以然的那种,由此也可以考察候选人的学习方法、心态,是随波逐流抑或专精专注。
    • 候选人每次跳槽经历也需要关注,究竟何种原因导致跳槽,每次跳槽是否其职业层次也跟着提高。由此考擦候选人的职业规划是否清晰,是否过于随性(任性)。否则的话,可能在下一家公司也待不了多久就会因为各种原因(最常见的就是薪资、或者对主管不服气)而跳槽。
    • 候选人简历中特意提及的重点项目、事件、荣誉,也可以做深入的交流。
  • 3.重点技术要素考察完毕,可以聊聊职业发展等其他方面的话题,比如

    • 为什么选择我司;
    • 如果还有其他公司的机会,如何权衡选择哪个offer,最主要的判断标准是什么;
    • 期望什么样的工作环境,团队环境,以及哪种风格的主管;
    • 对什么事情最在乎,或最不在乎;
    • 除了薪资福利,对公司、工作的期望是怎样的。

专业技术考察

具体到技术实力考查上,通常可以关注几个要点:

基础知识考察

  1. 基础知识,尤其是一些理论知识,例如:
    • MySQL有哪些索引类型,这是个半开放式命题;
  • 数据结构角度可分为B+树索引哈希索引、以及不常用的FULLTEXT索引(现在MyISAM和InnoDB引擎都支持了)和R-Tree索引(用于对GIS数据类型创建SPATIAL索引);
  • 从物理存储角度可分为聚集索引(clustered index)非聚集索引(non-clustered index)
  • 从逻辑角度可分为主键索引普通索引,或者单列索引多列索引唯一索引非唯一索引等等。需要掌握这些不同概念之间的区别,例如主键索引和唯一索引的区别是什么
    • 为什么InnoDB表最好要有自增列做主键;
    • 为什么需要设置双1才能保证主从数据的一致性;
    • 有几种binlog格式*,及其区别是什么;
    • 如何确认MySQL replication真正的复制延迟是多少;
    • 有过哪些印象深刻的实践经验。

通过考察候选人的基础知识掌握程度,可侧面反映候选人对学习的态度,是否仅浅层面的了解。

核心技术能力考察

  1. 核心关键技术能力,例如:
    • 怎么做的MySQL备份恢复方案及策略,为什么那么做,用什么工具;
    • MySQL主从复制的具体原理是什么,实际使用过程中,遇到过哪些坑,怎么解决的;
    • 对一个大表做在线DDL,怎么进行实施的才能尽可能降低影响;
    • MyISAM和InnoDB都有哪些不同之处;
    • InnoDB的体系结构是否能讲的清楚,至少说出个大概;
    • 假设现在服务器负载很高,都有哪些性能问题排查思路,以及优化的方案;
    • 什么是死锁,什么是锁等待,如何优化;
    • 关于MySQL及InnoDB优化,讲讲自己的见解或者实践经验
    • 如何确定及实施MySQL高可用方案,不同方案的优缺点对比;
    • 一定规模的MySQL自动化运维经验如何;
    • SCHEMA设计方面的经验如何;
    • 基于MySQL所做过的一些数据库架构方案设计、实施经验。

通过考察候选人对这些核心关键技术的掌握程度,可知晓候选人对深层次知识的掌握情况,除了实践,理论方面掌握了多少。

潜力考察

  1. 发展潜力以及学习能力,例如:
    • Linux的掌握程度,以及ShellPythonPerl等常用运维开发语言的掌握程度;
    • 对服务器硬件设备,存储设备的了解程度;
    • 信息安全,网络知识的了解程度;
    • 其他语言,例如CC++JAVAPHPGO是否有所了解。

这些知识对一般的DBA可能不太重要,但想要成为资深DBA或数据库架构师的话,这些知识是必不可少的。

先啰嗦说这么多吧,希望对有志成为DBA的同学有些帮助,加油加油↖(^ω^)↗

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

[MySQL FAQ]系列 — 不同复制模式下,如何忽略某些binlog事件

导读

在MySQL复制中,如何忽略slave节点上发生的主键冲突、数据不存在等错误。

在MySQL复制中,如果slave节点上遇到错误,比如数据不存在或者主键冲突等错误时,想要忽略这些错误,可以采用以下几种方法:

1、未启用GTID模式时

只需通过设定 SQL_SLAVE_SKIP_COUNTER 的值,即可忽略一些复制事件。例如:

#需要先关闭SLAVE服务
root@imysql.com [test]> STOP SLAVE;

#忽略N个事件(event),通常一个SQL是一个事件
root@imysql.com [test]> SET SQL_SLAVE_SKIP_COUNTER=N;

#再次启动SLAVE服务
root@imysql.com [test]> START SLAVE;

2、启用GTID模式时

启用GTID,想要忽略某些错误事件就稍微麻烦一点点了。
首先,我们需要先查看当前SLAVE复制的进度:

mysql> SHOW SLAVE STATUS\G

从中看到,当前SLAVE复制的GTID进展是:

Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_Errno: 1062
Last_Error: …Duplicate…key ‘PRIMARY’, Error_code: 1062;…
Master_UUID: f2b6c829-9c87-11e4-84e8-deadeb54b599
Retrieved_Gtid_Set: 3a16ef7a-75f5-11e4-8960-deadeb54b599:1-283,f2b6c829-9c87-11e4-84e8-deadeb54b599:1-33
Executed_Gtid_Set: 3a16ef7a-75f5-11e4-8960-deadeb54b599:1-283,f2b6c829-9c87-11e4-84e8-deadeb54b599:1-31
Auto_Position: 1

从上面的信息可以看到,当前从MASTER取到了1-33的事务列表,并且已执行(看Executed_Gtid_Set)到了31这个事务GTID位置,在这下一个位置(32)上发生错误。

这时候,我们需要手工调整SLAVE已清除的GTID列表 GTID_PURGED,人为通知SLAVE哪些事务已经被清除了,后续可以忽略:

root@imysql.com [test]> STOP SLAVE;
root@imysql.com [test]> RESET MASTER;
root@imysql.com [test]> SET @@GLOBAL.GTID_PURGED = “3a16ef7a-75f5-11e4-8960-deadeb54b599:1-283,f2b6c829-9c87-11e4-84e8-deadeb54b599:1-32”;
root@imysql.com [test]> START SLAVE;

上面这些命令的用意是,忽略 f2b6c829-9c87-11e4-84e8-deadeb54b599:32 这个GTID事务,下一次事务接着从 33 这个GTID开始,即可跳过上述错误。

3、无论是否启用GTID,使用pt-slave-restart工具

首先不得不说,percona toolkit工具集对DBA而言实在太方便了。pt-slave-restart工具的作用是监视某些特定的复制错误,然后忽略,并且再次启动SLAVE进程(Watch and restart MySQL replication after errors)。
简单用法示例:

#忽略所有1062错误,并再次启动SLAVE进程
[yejr@imysql.com ]# pt-slave-resetart -S./mysql.sock —error-numbers=1062

#检查到错误信息只要包含 test.yejr,就一概忽略,并再次启动 SLAVE 进程
[yejr@imysql.com ]# pt-slave-resetart -S./mysql.sock —error-text=”test.yejr”

综上,我们虽然可以利用工具来快速忽略复制错误,但还是要掌握如何人为忽略复制错误的方法,在没有工具的时候也能了然于胸。

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠