1、问题描述
运气比较背,同为raid1 的两块a、b盘,b盘因为物理故障已经被系统faulty,同时a盘发生uncorectable read error,即数据页损坏。
数据页损坏是指:netezza一体机存储的数据都是进行1:4压缩的,比如数据存放的二进制是01010101,结果由于磁区退化或者电流性质导致bit位偏移,变成01111111,那么读这笔数据时就会报错。
hot spare盘(c盘)在顶替b盘过程中, a盘将原封不动copy这笔有问题的数据至镜像盘(c盘),那么在读取这笔有问题的数据时,系统由于无法解压该笔数据,将会再次把c盘faulty,然后该笔有问题的数据又会复制到下一块镜像盘,如此循环,导致系统宕机。如下图所示
2、解决方案
(1)尝试从底层去修复数据逻辑错
修改system catalog,增加系统数据读错误次数,防止系统将镜像盘faulty,并停止其上的应用。
通过nz_raid_check检查所有盘有多少这种错误,然后通过nz_micro_repair去修复.修复之后通过
nz_check_disk_scan_speeds 检查速度,如下图所示:
最后发现a、c盘这种错误无法修复,但是由于应用需要报送,必须恢复使用,因此经过国外二线工程师支持,再次修改system catalog ,因为系统数据读错误次数,随着应用的大量访问,始终会达到,最终还是会宕机。因此让系统不能自动failover硬盘,保障系统可用,但是读到该有问题数据块,应用会报错,但是由于netezza主要作为数据仓库,同时有问题数据只是几十笔,相当于其上运行着165T的数据、1万三千多张表,还是可忽略。
(2)备份a盘数据,rebuild a盘,恢复数据至a盘,更换a、c盘
总思路:查询出所有数据库所有表,然后在a盘查看是否有数据,如果有数据就备份,没有就跳过。备份好后进行数据delete,然后groom进行回收空间并rebuild盘,最后进行数据插入a、c盘与更换a、c盘。
1.查询所有数据库的表
将上述图中的表过滤出来,一万3千多张表,编辑批量备份脚本进行备份。考虑到内存溢出问题,计划4个线程并发备份,为保障线程合理运行,按表容量对表名进行排序,并进行mod8,然后再把表名分成4组。
备份过程中,备到有问题的数据块时报错,查看报错日志,找到数据坏页位置,进行清空,这也是Netezza架构最大优点处,因为如果是别的数据库,如果存在这样的数据逻辑错,绝对不能直接将数据坏页的地方直接置空,这很容易导致整个数据库数据错乱。
运行nzsqa emptypage -id 1600 -devId 31 -lba 1900291 -tblId 13817983,将数据坏页处理后,再次运行被中断的备份线程。
2.为保障数据可用性,创建临时库,进行数据还原测试,折腾死了小弟,可数据重要,没办法。
4.对有问题的数据盘a、c盘进行rebuild,相当于格式化。
3、经验及建议
数据是我们的最重要的资产,数据丢了,一切皆空。现在我们做的都是如何保障非逻辑错误数据的高可用,比如存储的复制技术、SVC技术,虽然我们通过TSM或者BRMS等其他备份软件实现备份,但是这些备份都是T-1日的,如果真的发生类似数据页损坏或数据逻辑错误,要恢复起来也是工作量很大,有没有一种软件可以做到准实时防逻辑错误数据备份产品,我行也正在启动该项目,前期对CDP技术进行了交流。通过这件事,防逻辑错误还是很必要的,没发生还好,一发生要命。
如果DB2遇到这种数据页损坏错误,是否有其他解决方案? Netezza架构在这方面还是做的不错,尽管丢了几十笔数据,但至少保障了其他数据可恢复。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞5
添加新评论2 条评论
2017-09-19 20:15
2017-09-19 19:25