Posts tagged ‘崩溃’

远离故障的十大原则

 

故障是运维人员永远的痛。相信每一个运维人员的KPI中都有一项:可用性。可用性高就是不出故障,各个公司对可用性和故障评级的标准都不相同,但是避免故障的方法却是殊途同归。我们怎么避免故障,沃趣科技简单列举了以下几条,与大家共勉!
1、变更要有回滚,在同样的环境测试过
2、对破坏性的操作谨慎小心
3、设置好命令提示 
4、备份并验证备份有效性
5、对生产环境存有敬畏之心
6、交接和休假最容易出故障,变更请谨慎
7、搭建报警,及时获得出错信息。搭建性能监控,了解历史,获得趋势,预测未来
8、自动切换需谨慎
9、仔细一点,偏执一点,检查,检查,再检查
10、简单即是美。

 

第1条,变更要有回滚,在同样的环境测试过。也是运维最繁琐,最苦逼的地方,所有的变更都必须有回滚的办法,在同样的环境下测试过。没有做过的东西,总是会在你意想不到的地方给你一次痛击,在阿里巴巴的这么多年运维经验告诉我们,所有没有做过的变更,出错的概率最大。所以我们需要给变更以回滚的可能,在各个步骤可能出错的情况下,考虑回滚到最初状态。优秀的运维人员对不考虑回滚的的操作都是敬而远之的。从某种意义上来说,运维是一门经验的学科,是一门试错的学科。

 

第2条,对破坏性的操作谨慎小心。破坏性的操作有哪些列?对数据库来说有:DROP Table, Drop database, truncate table, delete all data;这些操作做完了以后几乎无法考虑怎么把数据都回滚回去了。就算回滚,代价也是非常大的。你执行这样的语句非常简单,但是回滚恢复数据缺非常困难。linux的命令rm可以-r(recursive)递归的删除某一个目录,-f(force)强制删除,但是你有没有删错过文件。我们遇到过一个文件名中末尾有空格的情况,而有的同事rm -r习惯性的会在文件名后面加*,这样就成了rm -r aa *,所有当前目录的数据都被删除掉了!经过这次故障以后我们给rm做了别名:
alias rm=’rm -i’
这样在删除数据时,rm命令会提示你,是否确认删除该文件。
同样的cp和mv也可以有同样的选项:
alias cp=’cp -i’
alias mv=’mv -i’

 

第3条,设置好命令提示。让你时刻知道你在操作哪个数据库,让你知道你在哪个目录下。mysql字符客户端允许你设置提示符,默认的提示符就是一个光秃秃的mysql >,为了让你清楚的知道你当前是以哪个用户名,哪个IP(可能是localhost,127.0.0.1或者具体的物理IP),你当前操作的是哪个schema,以及当前的时间,你可以设置数据库的提示符为:prompt=”\\u@\\h : \\d \\r:\\m:\\s> “。它可以直接写在my.cnf的[mysql]下,这样你每次连上MySQL就默认显示如下:
root@127.0.0.1 : woqutech 08:24:36>
具体prompt可以设置哪些提示,你可以参考http://dev.mysql.com/doc/refman/5.6/en/mysql-commands.html中的列表
而linux命令提示符也允许你设置的。有两个地方可以设置。第一个:PS1。这个是每次shell提示你输入命令的信息,默认为:$或者#,只会提示你是超级用户还是普通用户。有经验的运维者会设置export PS1=’\n\e[1;37m[\e[m\e[1;31m\u\e[m\e[1;31m@\e[m\e[1;31m\h\e[m \e[4mpwd\e[m\e[1;37m]\e[m\e[1;36m\e[m\n\$’。这样你就可以知道你当前的目录,登录的用户名和主机信息了,示例提示符如下:
[root@woqu-lsv-01 /home/mysql]
#
你可以查看http://www.cyberciti.biz/tips/howto-linux-unix-bash-shell-setup-prompt.html获得具体的PS1设置颜色,设置各个提示内容的介绍。
第二个提示符就是PROMPT_COMMAND。这个是设置你连到具体的数据库以后标签页标题上显示的内容,Windows用户可能会用securtCRT,Mac用户可能会用iTerm2,开多个标签页的话,如果每个标签页的标题上内容一样,我们切来切去就有可能在错误的标签页上做操作,设置了这个以后,这个问题概率就会小很多。比如我们的机器上设置为PROMPT_COMMAND=’echo -ne “\033]0;${USER}@${HOSTNAME%%.*}”; echo -ne “\007″‘对应的标签页如下图

prompt_command

 

 

 

 

第4条,备份并验证备份有效性。是人总会出错,是机器总可能会有突然崩溃的那一天。怎么办-我们需要准备备份。

备份的学问很大。按照不同的纬度可以分为:冷备份和热备份;实时备份和非实时备份;物理备份和逻辑备份。

互联网企业为了提供7*24小时不间断的服务,数据库就需要有实时热备份。在主库出现问题的情况下能够由备库提供服务。备库时候有效,数据是否一致,主库出现问题的时候怎么切换都需要运维人员认真考虑。

是不是有了这些就够了列?不行,应用程序也是人写的,曾经出现过程序一不小心delete语句没有带任何条件,导致一个表中所有的数据都被删除的惨状。所以你除了实时的备份,还需要有非实时的备份,在你的数据出现逻辑错误之后能够从备份数据中恢复出来。现在很多人在研究MySQL模仿oracle的flashback功能,利用binlog来恢复数据。但是这样的话,binlog_format必须设置为row并且对于DDL操作也无法回滚。它是为快速解决部分数据被错误删除的解决方案,但是无法代替非实时备份的作用。

非实时备份有可以分为在线延时备份和离线备份。在线延时备份是搭建数据库的一定时间延迟的热备份,比如MySQL就可以搭建一个延迟一天的slave,一直保持着备库与主库的延迟在一天。可以利用pt-slave-delay工具来实现这个功能。另外,离线备份是目前大家用的比较多的,可以利用mysqldump进行逻辑备份或者xtrabackup进行物理备份。为了空间的原因和快速恢复考虑,你还可以利用xtrabackup进行增量的物理备份。

备份有了,是否就可以高枕无忧了?还是不行。你需要验证备份的有效性。没有一个备份能够保证它备份出来的数据能够100%恢复出正确的数据,特别是物理备份的概率相对来说,更低,xtrabackup备份一个月总有那么几次来大姨妈,不能给你很好的服务。所以,备份并不只是备份,它还包括备份的验证,它如果不能恢复出正确的数据,就只是浪费空间而已。备份的验证最简单的就是找一个空闲的库,来恢复出来,mysql启动以后检查部分数据。如果不需要这么严谨,对于xtrabackup来说,你至少得验证它–apply-log能够恢复上去吧?同样,备库的数据一致性也需要经常检查一下,mysql的replication并不保证100%的数据一致性,你可以去翻翻mysql statement复制的bug列表,有些数据在主备不同的环境上分别执行,数据就会不一样。可以考虑用percona的工具pt-table-checksum来检查主备不一致,用pt-table-sync来同步主备数据。

 

 

第5条,对生产环境存有敬畏之心。这应该是运维者进入行业首先需要具备的素质。但是我们还是需要把它拿出来强调一下。

有机会的话,你可以梳理一下:

  • 你的生产环境上有哪些账户,这些账户是否都确实需要登录到机器上来?这些账户即包括linux用户还包括数据库账户。
  • 你的root用户是否开放给了某些用户,这些用户安全吗?
  • 你的用户密码是否经常修改,是否加密不让具体的操作人员直接看到,密码强度时候足够,密码重试次数达到一定次数是否黑名单;
  • 你的生产环境和线下环境是否隔离,数据库是否和外网隔离?
  • 是否一些工作明明能够在开发库和测试库做,却被放到生产环境上去了。
  • 是否有专门的人负责线上应用的发布,从而避免开发人员直接接触生产环境

这些都是你避免出现csdn密码泄漏,在业界的名声一落千丈的法宝。

 

 

第6条,交接和休假最容易出故障,变更请谨慎。这个是经验之谈。我们在总结故障的情况时,发现在公司部门有变化时,工作交接(不管是休假,工作职责变化还是离职),故障的出现频率会比正常情况下多50%以上。有人说,这是因为机器或者应用是有感情的,舍不得离开的运维者。

我们不谈感情,简单的理性分析一下。公司或者部门难免会做一些调整,变化是世界上唯一不变的事情。而运维人员是一线做事情的人,部门调整或者领导的更换可能导致工作的着重点不同,做事的方式和评测的标准变了,适应过程中难免会出现一些考虑不周到的地方,出故障也是情理之中了。

而工作交接,对运维人来说,其实是一个非常费时费力的事情,你需要把所有平常做的工作都梳理清楚,甚至包括你的一些经意不经意的操作习惯,这样的话,下一个人才可能接手的下来。比如:你可能认为备库正常情况下没有访问,于是让某些并不重要的任务(一个月一次抽取部分数据到线下测试?)直接连备机IP进行操作。下一个人接手,认为备机就是备机,操作起来不会有任何问题,结果下一次任务抽取就是一个故障出来了。再举一个我们遇到了事例吧:同事A出国休假了,休假期间估计联系不上,他留了文档,并告诫说某几个库和表是比较核心和容易出问题的,没有特殊情况最好等他回来再做变更。正好,休假期间,开发人员找到同事B,要求他重置一个字段的某一位(bit),并打包票说这个bit没有用,同事B拒绝,并背上了不配合的骂名。同事A回来吓了一身冷汗,原来这个字段已经被另外一个离职的开发使用了。

所以,运维部门和运维人员对变化需要尽量放平心态;接手别人的工作要一而再,再而三的确认变更方案。请教人并不见得就是能力不行的表现;休假前最好各种可以做好的事情,最好能够准备一份文档,指明在什么情况下怎么做和联系哪些人。在别人放假的时候接手工作,“能拖则拖”,实在需要执行:必须不厌其烦的跟原运维者确认各个操作细节。 

 

 

第7条,搭建报警,及时获得出错信息。搭建性能监控,了解历史,获得趋势,预测未来。运维的最高境界不是故障来了,泰山崩于前而不惊,苍老师勾引你而抗日;而是没有故障,让故障消失在萌芽之中。请给那些默默无闻,每天想着我们的系统还存在哪些隐患,怎么解决,怎么及早发现的运维人员鼓掌。他们是最可爱的人。而他们赖以生存的工具就是报警和监控。Oracle发展了这么多年,awr和相关的性能参数都相对比较全;MySQL现在也已经迎头赶上,配套的工具越来越多。

报警可以让你及时知道系统出现了什么异常。比如slave io报警,在数据库replication异常的时候就会提醒你:IO线程出现了问题,可能是网络问题,主数据库问题等,slave sql报警会提醒你replication的SQL线程出现了问题,可能是主备不一致,slave被停掉了,存储过程在备机有异常或者其他问题。这样你收到报警就可以及时跟进,而不至于主备长时间不一致,主库坏掉了想要切换到备库的时候却不能切换。

性能监控可以让你了解系统的历史性能信息。分析故障发生时的各种现象,确认故障的真正原因;了解变化趋势,发现故障的苗头,及早优化和调整。比如你如果使用了PCI-E的Flash卡,你可以监控logical_written_bytes,logical_read_bytes,physical_written_bytes,physical_read_bytes以便获得flash卡的每秒的逻辑读写和物理读写字节数。对于MySQL你可以监控Com_delete+Com_delete_multi, Com_insert+Com_insert_select,Com_update+Com_update_multi,Com_select来获得每秒的MySQL DML删除,插入,更新和查询的次数。

报警和性能监控其实不不完全独立的,很多性能的监控项也可以报警出来。比如linux的iostat中的await_time可以作为性能监控采集起来获得系统IO响应时间的变化曲线,当该值达到20以上的时候,也可以报警出来,让运维人员跟进是磁盘阵列中坏了一块,还是异常的数据拷贝影响了系统的IO性能等。

nagios和cacti是目前MySQL领域使用最广泛的报警和性能展示系统。percona最新推出percona-monitor-plugins(http://www.percona.com/software/percona-monitoring-plugins)就是基于他们俩的。

 

 

第8条:自动切换需谨慎。现在数据库的HA很多都是进行自动切换的,这样运维人员深夜起来手工切换到备库的机会就会少很多。切换也会快速很多。但是,它带来的副作用也不容忽视。

现在业界使用的HA软件非常多,heartbeat由于很多SA兼作DBA的运维比较熟悉,在MySQL自动切换也是不少的。一般来说,它会通过mysqladmin ping来探测MySQL是否存活,如果发现异常,那么他就会切换VIP和MySQL资源到备库。但是此时备库的数据延迟是否为0,主库crash之后binlog的数据是否全部都同步到备库上去了,备库的read_only是否关闭,这些heartbeat都不管。我们想象一下,主库上应用提交了一笔订单,结果发生了切换,这笔订单没有同步到备库上,卖家也就损失了一个销售单,对客户,对公司都是非常大的影响。

当然,自动切换也不能全盘否定,它能够更快速的将应用切换到新的热备份备库上,应用的不可用时间大大缩短。只是我们要好好利用这一把双刃剑,仔细评估它的影响,降低或者去除副作用,让它为我们服务。

 

 

第9条,仔细一点,偏执一点,检查,检查,再检查。之前我跟一个资深的运维学习线上操作的时候,觉得这家伙有点变态,他在做一个变更的时候,会先提前一两周发送邮件并电话手机的通知相关人;在测试机上写好脚本,召集大家review操作步骤和脚本;测试完成以后拷贝到生产环境;登录对应机器,“打开,关闭,打开,关闭”该脚本;跟相关人员再次确认执行的操作,顺序,时间点,可能的影响和回滚是否都准备好了;执行前还要退出这个机器,然后再登录进去,“打开,关闭”脚本;最后才在后台运行脚本,在另外一个窗口登录着,随时ps和查看结果输出。期间姿势端正,呼吸急促而均匀,眼神凝重。操作的人不觉得累,倒是一边学习的人很累。

当我做到一定程度,我也开始这样了。医学上,这种好像叫做强迫症。唉…,提前通知会让大家都有准备,也避免了临时相关人员过来说这个操作和其他操作有依赖需要调整操作时间的问题; 召集大家review步骤和脚本是为了让大家一起来看看整个过程中还有哪些依赖没有考虑到或者哪些细节没有注意到,三个臭皮匠顶一个诸葛亮在运维来说是金科玉律;“打开,关闭,打开,关闭”是为了一再确认脚本拷贝过来是否正确,目录时候正确,思考在测试环境运行和在生产环境运行有什么不一样的;退出再登录机器是为了确认我登录的机器确实没有错;在后台运行是担心网络突然中断,我的脚本运行到一半怎么办;调整呼吸和端正姿势是为了对这个操作的敬重,对自己工作和运维工作的尊重。

以MySQL 使用flash卡为例吧。flash算是一个比较新的事务,提供的IO比普通磁盘是几个数量级的提升。要想在生产环境使用,首先我们需要对他进行详尽的评估和破坏性测试,设置各种参数,考虑他们在各种场景下使用的配置;24小时不间断的进行半个月读写操作,中途突然掉电;高并发,高吞吐量下的测试;温度湿度极限测试;预留空间释放测试等等。然后我们会尝试在测试库上部署试用,收集和修改各个配置已达到最稳定,最高性能的配置;运行稳定以后我们才考虑在线上备库使用,并且主备要求异构;适当的时机切换为使用新的flahs卡为主库,万一出现了问题,还可以切换回原主机。

这里也跟大家简单介绍一下screen命令,这个命令会在服务器段开启一个session,就算你的网络断掉了,你的脚本也会自动在后台运行。screen -S woqutech可以开启一个woqutech命令的后台session;如果你的网络断掉了,你可以用screen -dr woqutech连上之前的session继续进行操作。IBM的文档库中有一个非常靠谱的文档:http://www.ibm.com/developerworks/cn/linux/l-cn-screen/

 

第10条,简单即是美。最后一条有点禅的意境了。它和Unix的思想不谋而合。我们总是面临着各种诱惑:新的系统架构,新的更智能的命令和工具,最新的硬件平台,功能更全的HA软件等。他们总是以各种各样的方式吸引我们,most exciting,unbelievable,让你欲罢不能。你可以在线下安装,测试,怎么搞都行。但是如果想要在生产环境下使用起来,那就得经过非常详细,非常漫长,各种方式验证其稳定性的过程。

能够使用系统内置命令的话,就不用考虑其他要专门下载安装的软件了;脚本本身就能完成的功能,就没有必要专门找一个功能丰富的软件来做;linux本身自带的字符界面比那些复杂的图形界面要简洁方便;MySQL的一些分区,生僻函数,没有必要的话不要使用。

 

最后祝大家运维的运维工作一帆风顺,多福多寿,不出故障。

参考:http://feedproxy.google.com/~r/iheavy/~3/sRnyFPA0R9E/

MySQL事务和MVCC简介-update流程

最近在学习和研究MySQL的MVCC和事务相关机制。
简单整理一下,希望够通俗易懂了啊。
不过读本文之前,推荐先阅读

  • 《MySQL数据库InnoDB存储引擎Log漫游》 三篇系列文章:http://www.mysqlops.com/2012/04/06/innodb-log1.html

这三篇文章通俗易懂的介绍了MySQL本身undo和redo的结构和相关概念。

  • 《MySQL Innodb日志机制深入分析》http://blog.csdn.net/yah99_wolf/article/details/6567869

这篇文章主要介绍了check_point,lsn等相关redo文件位置的概念。

 

如果你对b-tree等MySQL基础的索引结构不了解的话,请详细阅读:

  • 《由浅入深理解索引的实现》 http://www.mysqlops.com/2011/11/24/understanding_index.html

另外,说一句,上面的两个系列文章都是sleebin9的作品,这家伙技术牛逼,文字功底和逻辑思维能力也太牛了,非池中物啊!

 

  • 如果想了解MySQL文件io相关的资料和参数,请参考淘宝丁奇的ppt:http://www.slideshare.net/mryufeng/mysqlio-12891332

文章中有任何错漏之处,麻烦各位大牛及时指出。

 

 

update流程事务相关介绍

假设现在有一个事务,需要执行以下的一条update语句。
那么在MySQL上,它是怎么完成的列。
begin
update test set c1=1 where id =5
commit
注:原c1=3

本文主要关注undo,redo等涉及事务信息,对细节和锁的详情不详细深入。
锁的情况可以参考:《MySQL数据库InnoDB存储引擎中的锁机制》http://www.mysqlops.com/2012/05/19/locks_in_innodb.html#more-3169

 

 

begin:
根据事务隔离级别,可能要记录read view等信息。

update 语句:
1、走btree找到id=5的叶子节点。这里走到页一级以后,该页需要加入buffer pool,并根据访问频率调整它在LRU list中的位置。
2、由于是update,他需要更新该行记录。所以需要获得X锁。注意,我们这里修改的只是非主键。如果修改主键值,(比如 update test set id=1 where id=5)那么MySQL对应的会在新主键页上插入一行(id=1),并将原主键行(id=5)处标记为已删除。如果新增的行导致页分裂,那么Innodb在现有的版本上还需要锁定上层的中间节点。目前Innodb在所有中间节点上只有一个锁,如果还有其他节点需要分裂,那就只能等待这个唯一的锁了。
3、获得undo slot。在目前的版本中,只有一个undo segment,每个undo segment包含有效的undo slot只有1023个(新版本中应该有128*1023个)。每个线程可能有一个或者两个undo slot。insert undo slot(insert语句需要申请)或者update undo slot(delete和update申请update undo slot)。所以并发的写线程太多,在MySQL来说目前还是有问题的,MySQL有可能会报undo slot槽不够了。每个undo slot对应一个线程,用完了需要归还的。为了实现MVCC,MySQL使用了review。这里还有一个read view的问题。MySQL支持四种事务隔离级别 Serial 本文后面简称SER, Read Repeatable 本文后面简称RR, Read Commit 本文后面简称RC, Read Uncommit 本文后面简称RU。read view是在每个事务或者query开始的时候保存起来的当前事务最小和最大事务号,根据会话的事务隔离级别不同而在不同层次上保存。在走到页节点查询数据的时候可以用这两个事务号来对比,以确定对应数据对本事务是否可见。例如,在RC下是为每个Query保存了一个read view,这样其他的事务提交了,本事务在query开始前保存的read review就大于已提交的事务,可以读已提交事务的数据。而在RR下,read view是在事务开始前保存的,那么read view事务号就小于那些在本事务开始后提交的事务,也就无法看到在本事务开始后其他事务提交的数据了,保证了可重复读。
4、按照日志先行的策略,需要把日志写进去才能做具体的操作,那么这里我们要写undo,也需要先把undo 的redo写好。所以MySQL会先在redo中记录undo的space_id,page_id,trx_id。redo为物理页记录方式。为crash恢复做准备。
5、在undo中记录c1=3。undo是用逻辑方式记录的。undo slot记录了c1=3的信息。
6、日志先行,我们现在需要修改具体的数据了,先记录redo。c1=1的物理页
7、真正的修改id=5这一行。对应行的undo ptr指向c1=3的undo slot。修改了数据以后,该页为脏页,由mysql的master thread来

commit:
8、写binlog buffer,根据sync_binlog来判断是否要刷盘。
9、确认是否能够释放undo slot。如果是insert 的话,undo slot可以立即释放,因为它的undo 信息不被其他线程所需要(其他线程不会去访问一个不存在的数据)。否则不能清理的话,转到undo history里面去。
10、根据innodb_flush_log_at_trx_commit的设置判读是否需要刷buffer和刷盘。
11、在iblog中记录事务提交信息。这个信息只保存在redo log的第一个文件头上。返回用户事务执行成功。

 

 

 

 

crash recovery:
crash recovery主要是基于check point来使数据达到一致性状态的。
对应的在前面介绍的场景下恢复分为以下几种情况:
这里有几个关键节点:
a、第4步:undo的redo写入磁盘。
b、第6步:数据变更的redo写入磁盘。
c、checkpoint大于第6步写入磁盘的lsn。

 

  • 在第4步以前,如果crash掉了。那么MySQL重启以后,读redo也无法得到任何改事务的操作信息。不过幸运的是,数据库也没有返回给应用程序说操作成功。应用程序进行异常处理就行了。
  • 如果b之前crash,由于undo的信息写入了redo里面,MySQL读取redo以后,会构建undo信息。但是此时checkpoint肯定还没有赶上(参考《MySQL Innodb日志机制深入分析》)。此时数据没有被修改,通过检查页上最新的修改trx_id就可以判断回滚策略了。这里也就是说数据不用修改。由于MySQL也没有返回给用户成功的信息,所以也没有问题。
  • 下面就要分两种情况了。第一种情况:如果应用程序收到了操作成功的信息,但是checkpoint没有赶上。crash恢复的时候,在checkpoint之后提交的事务全部要回滚,redo恢复的时候不是把undo信息恢复出来了吗,根据undo信息和页上最新修改trx_id,就可以将数据页恢复到c1=3。这里应用程序收到了update成功的消息,但是实际上数据却恢复为c1=3,就相当于数据丢失了。另外,因为binlog此时有可能已经生成并传给备机(这里有可能在本地还没有落到磁盘,还在buffer里面,就通过网络上传输到备机了,我就遇到过很多次),那么备机有可能已经接收并应用成功了。这种情况下主备机的数据都不一致了。
  • 另外一种情况,checkpoint赶上来了。那么皆大欢喜,redo恢复完了以后,这个undo可以直接丢掉。并且数据保持为c1=1

 

 

 

MVCC多版本介绍

上面是undo,redo和crash recovery的一些内容。

跟MVCC关系不大,我们再简单说说此时有并发读的情况
如果在此时有select * from test where id=5的读过来。
根据事务隔离级别有SER,RR,RC,RU几种区别。在各个隔离级别下有不同的read view。
注意:MySQL的每一行都记录了最新操作它的trx_id

 

  • 序列SER:由于没有并发,所以读到的数据肯定是之前commit好的,放心读吧。

其他的情况下:MySQL首先会判读read view。

  • 可重复读RR:小于read view最小的trx_id的,这一行已经是事务开始之前commit的,那么可以放心大胆的读。大于read view最小的trx_id,为了保证可重复读,那么就需要根据undo ptr找到最新但是trx_id小于本事务trx_id的版本。Read view是在事务开始的时候建立的。
  • 读提交过的数据RC:跟RR不同,read view是query开始的时候建立的。小于read view最小的trx_id的,这一行已经是事务开始之前commit的,那么可以放心大胆的读。大于read view最小的trx_id,为了保证读已提交的,只需要找到最新的已经提交的版本(如果有trx操作了它,但是在做其他的update之类的,那么这个版本就需要忽略,继续回溯)
  • 读未提交的数据RU:看到什么读什么,管你有没有提交。