论坛徽章:: 1

电梯直达

1楼 [收藏(0)] [报告]

发表于 2014-08-09 00:48 |只看该作者 |倒序浏览

本帖最后由 mike1979 于 2014-08-09 00:53 编辑

银监会通报中涉及到的技术原因描述是“在季末结算业务量较大的情况下，因备份系统异常导致备份存储磁盘读写处理严重延时，备份与主存储数据不一致，在采取中断数据备份录像操作后，造成生产数据库损坏并宕机”

这类通告大都含糊其辞，这份也不例外。尽量根据通告进行分析，应该有两层意思：
1，业务量大，备份系统异常，导致备份的IO超时
2，中断数据备份录像操作，导致生产数据库损坏
比较有意思的是“备份与主存储数据不一致”，这句话的意思应该是说LVM镜像的两个分支之间出现了数据不一致。那么是因为备份超时，导致数据不一致，还是因为中断备份录像操作导致数据不一致？

从公告看，似乎是前者。那么事情大概是这样：季度末业务量大，IO压力高，作为LVM Mirror的一个分支的CDP存储性能抗不住了，拖累了整个系统。由于CDP上IO连续超时，AIX认为CDP上的某些PV不可用了，标记为stale pv不再访问，所以主存储和CDP上的数据不一致了。
可如果是这样的话，应该不会出现这么故障。CDP存储被踢出去后，写操作只要落地到主存储就可以了，系统整体性能应该上去了才对。至于CDP和主存储数据不一致，那也没关系，找个业务量小点的时间varyonvg，进行数据同步就可以。当然这个缺省是数据全同步，IO量会很大。
接下去看后面半段，为了尽可能的释放性能给数据库的IO操作，那么应该停止CDP上的快照，尤其是那些还没被AIX踢出去的PV上的快照。可这个操作也不会导致数据库损坏阿。就算CDP上的数据损坏了，主存储上的数据还是完好可用的。

如果从“造成生产数据库损坏”这句话倒推，什么情况下会出现数据库损坏？如果不考虑数据库本身的原因，只从系统层面考虑。那么在LVM没有预计到的情况下，LVM镜像的两个分支出现了数据不一致，这个情况会导致数据库损坏。也就是说不是因为AIX将CDP上的PV踢出去导致LVM镜像不一致，而是其它原因导致的。
再进一步倒推，是什么操作会导致LVM镜像不一致？这个操作和“中断数据备份录像操作”有关联么？如果这个录像操作只是说备份（对于CDP来说就是快照了），那应该是没有关联的。但是如果这个录像操作是指恢复（快照reverse），那就很有可能了。快照reverse是把快照的源LUN回滚到某个时间点，这个操作在存储层面执行，LVM是感知不到的。在LVM看来，就是LVM镜像的两个分支突然间就不一致了。
也就是说出于某个未知原因，有人在断开CDP和主机的连接之前，就把CDP上的数据恢复到以前的某个时间点，却没想到主存储上的数据是没法随之恢复到那个时间点的，于是“备份与主存储数据不一致”，“造成生产数据库损坏并宕机”。

至于“因备份系统异常导致备份存储磁盘读写处理严重延时”，这个和数据库损坏应该没直接关系，但或许是促使他执行恢复操作的某个直接或者间接原因。就像前面说的，CDP因为性能差，确实会拖累整个系统的IO性能，尤其是写性能。但是最坏情况也就是AIX主动将CDP上的PV踢出去。这个动作LVM是知道的，它知道CDP上的PV不可用了，就不会去读写它。虽然数据不一致了，但是不会导致数据库损坏。

那么为什么要把CDP上的数据恢复到以前的某个时间点呢？这个就不得而知了。是否和数据库有关？比如碰到bug，数据库怎么重起也起不来，就想“把数据库恢复到第一次重起前的那个时间点应该能解决问题”，于是就......

PS 附上两招图