新年假期前后警惕那些数据库假期综合症
在新年到来之际,我们除了要恭祝大家新年快乐之外,还要警示大家,加强管理,防范问题,本文精选了过去我们看到、遇到、分享的一些案例,在轻松而愉悦的学习之后,别忘了低头看一看自己的系统。
我们都知道,很多客户和企业经常选择在节假日进行数据库或系统维护,而工程师也很容易在假期前后产生“假期松懈症”,所以通常假期附近总是企业运维事故多发期,而如果节假日又赶上了月初月末,则问题发生的概率就更高了。墨菲定律无处不在,不要以为那些小概率事件不会发生,它们只是在积蓄力量。
在生产实践中,如果没有完善的流程、规范,并且进行规范化的审核,那么什么故障都可能发生,人、流程和工具,必须要互相匹配,完美结合才能发挥最佳效应,而运维就是要疯狂躲避各种坑,并不断通过产品去完善和改变工程师的世界。
故事一:戏剧性的转折
多年前这个案例让我记忆犹新,这个故事告诉我们无论何时,做事都要谨慎用心,一时马虎将是行业传说:
最惨的一次(经历)是和公司的一个哥们一起出差,那个哥们不知道出于什么考虑,将主服务器和备份服务器的IP反了一下,但是tnsnames没做修改,我准备重做备服的时候,使用了drop user cascade,把所有的用户都干了一遍。
刚刚干完,所有科室上夜班的护士小妹妹都给我打电话,说科室里的电脑全部不能用了,当时急的不行了,还好习惯还不错,来的前一天做了一个全库冷备,立刻进行了恢复,不过也丢失了一整天的数据。
一个小时以后,所有的院领导以及信息科的工作人员都出现在我的面前,并质问我原因,我只能一脸无奈的告诉他们刚刚来了只熊猫,那只熊猫烧了把香,然后数据就全丢了。
然后给了他们一个卖瑞星的兄弟的电话,那个兄弟连夜驱车200公里赶到目的地,到场以后首先确实了一下那个烧香的熊猫的存在,然后指出了那只熊猫的巨大危害性,最后建议他们购买一套全院级的杀毒软件。
大院长听取汇报后当即指示,立刻购买一套全院级的杀毒软件,第二天一早就在购买合同上签字盖章。
这个事情造成四个后果,
第一,我在所有删除性操作以前都要核实一下对象的准确性,
第二,我从此拒绝和那个哥们一起出差,
第三,那个卖杀毒软件的兄弟会经常联系我,看看我有没有犯类似的错误。
第四,兄弟越多越好
富有戏剧性效果的案例,说出一个心酸的真实故事,但愿我们都不要通过跌倒去收获经验,而是通过严谨去防止错误吧。
故事二:一个空格引发的血案
系统运维从来就是一个精细化的工作,除了规则与规范的约束之外,运维人员的严谨、谨慎也必不可少,有时候一个简单的错误就会导致一场灾难,小到一个字符,一个空格。本文的案例就是因为一个空格导致的,Oracle RAC遭遇故障重启。
故障现象:客户10.2.0.4 RAC for Solaris 10环境突然出现了实例重启。
故障过程:数据库正常运行到下午3点左右,随后两个节点分别重启,其中一个节点上的实例无法自动启动。检查两个实例的告警日志发现,在节点重启前,两个节点都出现了明显的ORA-27504错误。
错误信息:
ORA-27504: IPC error creating OSD context
ORA-27300: OS system dependent operation:
requested interface 192.168.168.3 NOT found.
CHECK output FROM ifconfig command
注意,这里的错误信息提示已经比较明确,请求的IP地址不存在,需要检查ifconfig的输出。接下来就是IPC超时:
Wed Apr 10 15:08:16 2013
IPC Send timeout detected.Sender: ospid 25748
Receiver: inst 2 binc 430164 ospid 11890
再然后实例驱逐不可避免:
Wed Apr 10 15:16:40 2013
Waiting FOR instances TO leave: 2
导致问题的原因根据错误信息很容易分析出来,节点2上的IP地址被修改,导致心跳通信出现了异常,而节点1试图将节点2踢出集群,但是由于无法和节点2之间进行通信,因此只有等待节点2重启。
检查节点2的操作系统日志,获得如下主要信息:
Apr 10 15:00:04 ip: [ID 482227 kern.notice] ip_arp_done: init failed
Had[4135]: [ID 702911 daemon.notice] VCS CRITICAL
CPU usage ON bj-sst IS 92%
sshd[13485]:error: Failed TO allocate internet-DOMAIN X11 display socket.
在15点04秒时出现的ip_arp_done: init failed信息,说明设置网卡接口时使用了主机名信息,且主机的IP地址被在线修改。
最后根据HISTORY确认,发现有人通过root登录系统:
执行ifconfig –a6来检查IPV6的地址,但是命令敲错
执行了ifconfig –a 6,在a和6之间多了一个空格
导致主机所有的IP地址被设置成0.0.0.0
于是导致了上面的整个故障,一个空格导致整个集群瞬间崩溃,这就是一个空格引发的血案。
这个案例给我们的教训是,对于特权用户,任何一个操作,具体到命令级别,也需要小心谨慎,DBA用户和ROOT用户都在此列。
故事三:那些运维中的匆匆乱
分享几则我们遇到过的客户恢复故障,与大家共为警醒,注意这些都是真实的案例,种种小疏忽,导致大事件:
服务器找不到了
某次客户找我们恢复数据库,说某个数据库出现故障,原本以为不再需要了,现在还需要其中的数据,可能是时间太久远了,工程师到现场后,客户说服务器找不到了,就算了。
三个月后,客户来电说,服务器找到了,我们又去帮用户恢复了数据。
1.服务器搬走了
某次客户数据库故障,检查发现,是RAC的某个节点服务器被搬走了,以为不用了,郁闷的是,断电还导致了ASM磁盘头损坏,还好11g修复ASM磁盘头很简单,迅速帮助用户恢复了数据库运行,再搬回服务器,加入节点。
2.磁盘搬走了
也是今年的某个客户,新上线服务器,客户找了一块以为不用的磁盘,强制拉过来格式化,发现另外一个业务库应声倒下了。
3.DBA走了
最近提到过的一个客户,因为把DBA解雇掉了,结果,DBA偷偷上来把整个库给删除掉了,业务挂了很久很久。
4.网线拔了
这是2015的案例,在业务高峰,新上一个交换机,网络运维把生产数据库的网线拔了,影响业务10分钟。这是金融业务,据说客户的人都跑到机房,机房满员。
5.磁盘故障
这也是2015年的新案例,客户的存储工程师划分给数据库ASM的磁盘小于请求容量,数据库文件扩展时越界产生了故障,金融客户的大事故,这是队友埋的坑。
Oracle数据库是非常坚强的,但是这个坚强是构建在稳定的基础架构之上的,运行基础决定上层建筑。数据安全是脆弱的,警惕随时可能发生的故障,不断强化数据安全,加强运维规范化,如何强调都不为过。
故事四:某年元旦数据库的种种
在某个元旦假期中,我们就收到了很多的紧急援助请求,这其中大多是熟悉的问题,包括:
1.数据库回滚段问题导致的ORA-01555错误;
2.SYSTEM表空间坏块导致的BootStrap失败,2662错误;
3.误删除导致的数据丢失;
4.空间不足导致的归档挂起;
阳光之下,并无新事,这些问题大都是我们以前曾经面对过的,然而我想重复的,DBA至关重要的一项素质是:严谨。在面对重要操作时的小心谨慎,反复确认;在可能损坏数据操作时心怀警惕,确认无误;唯有充分重视这份数据工作,才能在实践中履险如夷,达成使命。
比如误删除操作这样的事故,直至今天,在很多用户环境中仍然屡见不鲜。
上周在微信大讲堂中还有人提问:是否可以用update user$的方式更改Oracle数据中的用户名?
最近有客户遇到了一则数据库故障,起因是当进行一个数据表创建时遭遇到限制约束,Oracle的表名不能超过30个字符(12.2扩展了),这是数据库的内在限制。然后如何解决呢?应该说是数据库知识已经足够普及了,程序员们找到了数据字典表,将限制字段的长度改掉了。
大家能够评估后果么?数据字典被修改,整个数据库开始出现ORA-600错误,就此触发一次故障。
很多时候我们说,无知者无畏,当动手能力太过于强大时,也会使数据库遭遇不测。而对于企业数据库环境来说,内部的风险往往大于外部。
不以规矩,不成方圆。做任何事都要遵循一定的守则和规范。
故事五:某年中秋数据库的种种
在中秋节前,我们一共接手了3则数据恢复案例,我和大家分享一下案例概要,与大家共为警示。
1.磁盘故障导致数据库损毁
用户的磁盘组一共8块硬盘,做的RAID5,由于是制造企业,对于IT的了解和认识有限,可以一直侥幸的认为系统是足够安全的,每日进行逻辑导出备份,但是备份同样存储在一个存储设备上。忽然之间,整个RAID组中同时损坏了两块硬盘。一切数据荡然无存。
对于这种情况,只能从幸存的6块盘上进行数据扫描,抽取完好的数据,尽量以最大限度的恢复其中完好的数据内容,当然如果另外两块硬盘有任何一块还可以离线读取,那么事情就会变得简单。
无数事实给我们的警告是:备份重于一切。注意还需要是:分离存储的备份重于一切。
2.故障恢复时发现文件离线
客户通过备份去恢复和重构一个系统,恢复时发现有一个文件处于离线状态,无法Online,客户尝试了很多方式和方法,最后的结果是仍然被多个ORA-600错误所困扰,无法回复一个正常的数据库。
这也是备份时缺乏验证和检验导致的,这类问题给我们的警示是:确认备份的有效性和备份同样重要。
3.断电引起数据一致性问题
今天遇到的另外一个用户,由于断电导致了数据库无法启动,这个数据库是没有备份的,只能通过隐含参数牺牲一致性,最后启动数据库。这个数据库系统数据量不大,但是在线的应用相当重要。
这个问题给我们的警示是:再小的系统遇到灾难时也和大系统恢复同样复杂。
故事六:那些年我们遭遇到的数据回档
在行业里,数据回档是一个艰难的词汇,这意味这数据的彻底损失,为了一致性不得不放弃部分数据,在金融行业,这会是灾难。
看一看这样的案例吧:
2015年中秋节IT论坛的数据回档
ITPUB技术论坛 - 作为国内最大的数据库论坛,因为意外导致数据故障,当时全站数据回档到6月10号的数据内容,其他数据正在紧张的恢复之中。回忆起几年前,CSDN用户账户和明文密码泄露,这两者可以共为警醒。
以开发为主的论坛泄露用户明文密码,以数据为主的论坛丢失论坛数据。这不禁再次让我们警醒:如何强调备份和安全的重要性都不为过。
2017年炉石传说的数据回档
炉石因为数据损失选择了回档,已经在行业里引起了巨大的关注,我的文章详细分析了这个事故:炉石传说的Oracle故障,不要以为你也可以幸免。在这次事故之后,很多用户开始去梳理如何改善自己环境的数据安全,保障业务的连续运行。
多年以前我曾经在书中写到:唯一能够让DBA在深夜惊醒的事情就是 - 没有备份。想一想如果今晚你的硬盘损坏,数据丢失,你将如何应对明天?
所以如何强调数据备份、数据保全、数据安全都不为过,愿大家的数据库能够平平安安的度过2017年!
故事七:那些运维保平安的非理性因素
不止一位老专家和我传授过,运维保平安的不传之秘:内心平和,外保安详。
他们一般是这么执行的:
还有这样的:
海外的经验:
当然:如果假期数据库就是不肯消停,还有以下这些兄弟可以为您保价护航,可以及时 Call 云和恩墨的紧急救援团队,让数据库也过一个安心的新年!