宁夏银行的事，我觉得问题出在管理员身上，飞康被躺枪了

bbjmmj

大家注意看银监会通报，里面有这么一句话：“备份与主存储数据不一致”，这句话已经说得很清楚了，LVM镜像出了问题，大家迷信小型机，迷信AIX，以为它不会出毛病，可实际上就是小机OS出的问题，管理员在长达7年的时间里没有发现这么大的隐患，有渎职之嫌。

“在采取中断数据备份录像操作后，造成生产数据库损坏并宕机”，这句话说明宕机前的最后操作是“中断数据备份录像”，至于说这个操作会不会引起宕机，我认为可能性基本为零，这个操作在灾备产品开发的过程中可能已经操作过几千次了，最基本的测试，有问题早就发现了。管理员做的最后一个操作是跟飞康有关的，很明显飞康躺枪了。

管理员为什么要“中断数据备份录像”？就常识而言，银行的备份系统也是生产系统一部分，不能随便停掉，他这么做之前得到上级领导批准了吗？

我对银行IT业务了解很少，但我明白一点，成千上万用户使用的系统，停37个小时实在是太久了，宁夏银行的IT部门是怎么运作的？

撒旦的使者

出了这种事情，一定会拉人出来背锅了。
出事的原因嘛，只有当局人才知道，放出来的消息都是空泛的。

bbjmmj

镜像IO超时多久自动中断？大于应用容忍的范围就会丢数据。卷组上一大堆锁，踢出镜像要做很多硬盘操作，肯定超时。银监会通报里说：“备份与主存储数据不一致”，已经证实LVM镜像出了问题。
我总觉得LVM镜像不靠谱，LVM写入的时候要处理一堆锁，会很麻烦，盘阵支持LUN复制，不容易超时或者锁死，逻辑卷迁移很容易，管理上会很方便。至于“数据录像”，也就是写入日志，对LVM镜像卷记录写日志会严重拖慢主卷速度，还不如直接对主卷直接做写入日志，这样锁会比较少，原子操作耗时短，不易占用过多系统资源。

xuman6601651

这是天朝，很多事情根本不是技术上的问题

bbjmmj

xuman6601651 发表于 2014-08-11 10:34
这是天朝，很多事情根本不是技术上的问题

按说应该做LUN复制而不是用LVM镜像，做LVM镜像可能是不得已的，原来的存储不支持LUN复制，或者后上的存储不能跟原来的存储做LUN复制。存储不支持就应该换掉，上百万人用的系统，不差这几个钱，很明显管理层决策有问题。

bbjmmj

看内核源码，make menuconfig，默认的I/O scheduler是CFQ，后发出的写请求可能会先完成，MIRROR并不是实时的。为了保证数据一致性，LVM不得不在卷组上弄一堆锁，踢出镜像卷不止是简单的停止读写，还要处理一大堆没用的锁，会导致较长IO延迟，IO延迟导致应用读写超时，造成数据库宕机。管理员管了7年系统，应该意识到这个系统风险。

sunny4710

回复 1# bbjmmj


    主存储和备份存储用的LVM？？ 公告里没说啊

bbjmmj

回复 7# sunny4710


    知情人士透露的。

rtm009

都说了 不是技术问题 技术是背黑锅的 18摸背的黑锅还少吗?还在纠结技术问题 无语中 建议去找医生测智商

常笑

不知道是谁写的通告，“在采取中断数据备份录像操作后，造成生产数据库损坏并宕机”。
个人认为正常的逻辑有可能是：1.采取中断数据备份录像操作后，照成生产系统主机宕机；
                                        2，宕机后，造成数据库损坏。
中断数据库备份录像操作，不可能对源数据库产生影响的，要有影响，也只会是性能上的影响；
不可能造成源数据逻辑上的损坏的。
而中断数据备份数据操作，不管厂商怎么忽悠，怎么说，毕竟是操作系统上的操作，在极端的
系统状态下，导致宕机则完全有可能。（系统超负荷运转，速度本来就慢的极端情况）
而系统宕机，重启后，源数据库损坏，就很好解释了。