加入收藏 | 设为首页 | 会员中心 | 我要投稿 衡阳站长网 (https://www.0734zz.cn/)- 数据集成、设备管理、备份、数据加密、智能搜索!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

静默错误:Oracle数据库是如何应对和处理的 ?

发布时间:2018-09-09 21:35:13 所属栏目:MySql教程 来源:盖国强
导读:技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战 这两天,关于腾讯云『因为静默错误,把创业公司的数据彻底搞丢了』的事件已经传遍了整个互联网,引发了广泛的热议和讨论。 终极故障回放 腾讯云已经于8月7日公布了最近这次事故的根
副标题[/!--empirenews.page--] 技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战

这两天,关于腾讯云『因为静默错误,把创业公司的数据彻底搞丢了』的事件已经传遍了整个互联网,引发了广泛的热议和讨论。

终极故障回放

腾讯云已经于8月7日公布了最近这次事故的根本原因:

故障过程复盘 当天上午11:57,运维人员收到仓库Ⅰ空间使用率过高告警,准备发起搬迁扩容;在14:05时,从仓库Ⅰ选择了一批云盘搬迁至新仓库Ⅱ,为了加速搬迁,手动关闭了迁移过程中的数据校验;在20:27 搬迁完成之后,将客户的云盘访问切至仓库Ⅱ,同时为了释放空间,对仓库Ⅰ中的源数据发起了回收操作;到20:30 监控发现仓库Ⅱ部分云盘出现IO异常。

故障原因复盘 本次事故起源自因磁盘静默错误导致的单副本数据错误,再由于数据迁移过程中的不规范操作,导致异常数据扩散至三副本,进而导致客户数据完整性受损。

数据搬迁过程中的违规操作主要如下两点:

  1. 第一是正常数据搬迁流程默认开启数据校验,开启之后可以有效发现并规避源端数据异常,保障搬迁数据正确性,但是运维人员为了加速完成搬迁任务,违规关闭了数据校验;
  2. 第二是正常数据搬迁完成之后,源仓库数据应保留24小时,用于搬迁异常情况下的数据恢复,但是运维人员为了尽快降低仓库使用率,违规对源仓库进行了数据回收。

改进措施:经过技术复盘,腾讯云技术团队深入到每个环节,通过责任到人与流程闭环的双管齐下,相应作出如下的加强和改进措施:

  1. 首先,我们将全面审视所有的数据流程,涉及数据安全的流程自动化闭环,进一步提升我们常规运维自动化和流程化,降低人工干预。同时把全流程的数据安全校验作为系统的常开功能,不允许被关闭。
  2. 其次,针对物理硬盘静默数据错误,在当前用户访问路径数据校验自愈的基础上,我们优化现有巡检机制,通过优先巡检主副本数据块、跳过近期用户访问过的正确数据块等方法,加速发现该类错误,进行数据修复。

总结一下,故障的原因是:操作人员手工关闭数据校验,并且删除了源库,当发现『静默错误』导致的损坏时悔之晚矣。

无论如何,现在的事故已经发生,我想整个实践给行业以警示,我们的客户已经在设置方案将云上的数据库同步备份回本地。

而腾讯的一条改进建议是:提升自动化运维,降低人工干预。这一方面说明了自动化运维的重要性,另一方面仍然要警惕自动化中的故障传播。

既然有这样一个机会让我们了解了『静默错误』,那么我们可以进一步来看一看,在Oracle数据库中的静默错误是如何处理的。

首先还是回顾一下在我上一篇文章中描述的:什么是静默错误。

什么是静默错误

静默错误在英文中被称为:Silent Data Corruption,我们知道硬盘最核心的使命是正确的存入数据、正确的读出数据,在出错时及时抛出异常告警。磁盘出现异常的情形可能包括硬件错误、固件 BUG 或者软件 BUG、供电问题、介质损坏等,常规的这些问题都能够正常被捕获抛出异常,而最可怕的事情是,数据处理都是正常的,直到你使用的时候才发现数据是错误的、损坏的。这就是静默错误。

网上的一篇论文:Silent data corruption in SATA arrays: A solution - Josh Eddy August 2008 对静默错误进行了解释。这篇文章提到:

有些类型的存储错误在一些存储系统中完全未报告和未检测到。 它们会导致向应用程序提供损坏的数据,而不会发出警告,记录,错误消息或任何类型的通知。 虽然问题经常被识别为静默读取失败,但根本原因可能是写入失败,因此我们将此类错误称为“静默数据损坏”。这些错误很难检测和诊断,更糟糕的是 它们实际上在没有扩展数据完整性检测功能的系统中相当普遍。

在某些情况下,当写入硬盘时,应该写入一个位置的数据实际上最终写入另一个位置。 因为某些故障,磁盘不会将此识别为错误,并将返回成功代码。 结果,RAID系统未检测到“错误写入”,因为它仅在硬盘发出错误信号时才采取措施。

因此,不仅发生了未检测到的错误,而且还存在数据丢失。 在图2中,数据块C应该覆盖数据块A,而是覆盖数据块B.因此数据块B丢失,数据块A仍然包含错误的数据!

结果,数据被写入错误的位置; 一个区域有旧的,错误的数据; 另一个区域丢失了数据,RAID系统和HDD都未检测到此错误。 检索B或C的访问将导致返回不正确的数据而不发出任何警告。

静默错误:Oracle数据库是如何应对和处理的 ?

撕裂写入

在其他情况下,只有一些应该一起写入的扇区最终会出现在磁盘上。 这称为“撕裂写入”,其导致包含部分原始数据和部分新数据的数据块。 一些新数据已丢失,一些读取将返回旧数据。 同样,硬盘不知道此错误并返回成功代码,因此RAID无法检测到它。访问检索B将返回部分不正确的数据,这是完全不可接受的。

上文提到的“撕裂写入”,如果在 Oracle 数据库中发生,那么就是分裂块,当然 Oracle 数据库会自动检测这种情况。

那么“静默损坏”发生的概率有多少呢?该文提供了一组数据:

...一项针对NetApp数据库中150万个硬盘驱动器的学术研究在32个月内发现,8.5%的SATA磁盘会产生静默损坏。 某些磁盘阵列运行后台进程,以验证数据和RAID奇偶校验是否匹配,并且可以捕获这些类型的错误。 然而,该研究还发现,后台验证过程中错过了13%的错误。

那些未被发现的错误,就会成为企业的灾难。

即便没有任何错误,数据也需要定期进行读取,以确保数据无误,在几年前,我遇到过一起案例,Oracle 数据库莫名的发生了一定批量的数据损坏,存储上没有任何错误,但是数据库端大量的分裂块,存储没有检测到错误,并且复制到灾备站点,最后导致了数据丢失。

Oracle的静默错误

如果存储上出现了静默错误,在Oracle数据库中会是什么样的表现?

静默错误:Oracle数据库是如何应对和处理的 ?

(编辑:衡阳站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读