一块SSD盘故障，扩散踢掉整个节点，Hang 20多秒，业务能接受吗？

近日，与一金融用户见面交流中，偶遇某数据库厂家交付专家，一起切磋切磋了分布式架构。行里核心数据库架构分为6个单元，超100个分片设计，1主6从多副本设计。服务器本地盘配置了3块6.4TB盘，盘也不做池化，为了降低时延采取直通模式，VG，LV及RAID都等可靠性措施不做了，2个分片就压在一块SSD上，也没有热备盘概念。单盘6.4TB数据是可以装下数千万用户的数据，就压在一块盘上，上层基于账户hash计算来存在不同分片，并没有在技术架构上实现确定的热点切分均衡，可能大量热点数据就一直访问这块盘，特别是SSD盘使用几年后，垃圾数据增多，磨损度高，性能下降明显，难以想象没有做多盘池化磨损均衡算法构建的孤零零的单SSD能支撑多久？

假如这块6.4TB盘因为长期劳累过度，生病了，亚健康了，出现故障，FW BUG，慢盘，或者超时不响应，数据库怎么处理呢？底层块设备超时时间可能长达6分钟导致业务挂死，而这位数据库架构师告诉我，其数据库有探死机制，如果发现IO 5s不回来就进入超时处理，经过一系列处理还不行，20多秒后就把这个节点干死（底层盘的超时30秒，它这个比底层还快，也就是1个IO超时，节点就干死了），开始重新选主节点，业务切换到新主节点，一张盘故障需要切换节点，Hang 20多秒，值不？等这个节点的盘人工不知道多长时间更换新盘后重新接入系统，开始重建副本，6.4TB单盘，请问通过服务器跨IP网络来重构需要多少小时？还有另外2块6.4TB盘也要重构呢？重构压力怎么流控保障生产业务的呢？会不会影响前端业务交易时延过大？假如重构期间又有盘或者服务器故障，做增量重构吗？流程就更复杂了。跨节点的IP网络出现抖动、拥塞、误码导致hang死又怎么快速隔离处理呢？

难以想象数据库要开始来实现管盘、踢盘、踢服务器、重构、检测网络抖动等一系列复杂过程，是不是还要管内存EC错误呢？其实经典IOE时代，存储系统把这些苦活都干了，Oracle不需要来干这些苦活。盘是存数据的，怎么能轻易踢呢？所以存储厂家一定要懂盘的故障模式，不懂盘是做不好存储的，动不动就踢盘谁受得了，那么数据库们懂盘吗？存储系统的踢盘是非常严苛严谨的事情，踢盘容易，善后重构机制极其复杂，经过大量数据分析，盘临时故障经过重启下电等操作是可能就正常了，就救回来了，所以不到万不得已是不会踢盘的。

盘有亚健康，超时，存储系统检测有1秒慢盘通过RAID降级读写恢复业务，后台处理超时决策是否踢盘。而这位数据库哥们讲要20多秒Hang住，然后就踢盘，更恶劣是干死这台服务器节点，美其名曰为了保业务快速切换节点，20秒真的快吗？存储系统盘故障超时是1秒内恢复，还不用误伤服务器CPU。

本来一个盘故障就是很小的故障，有办法快速隔离，反而扩散到服务器节点级故障。打一个类似比喻，就像一个病人脚长疮了，符合常识的医治过程是把这个疮给消炎控住风险，再不济切掉这个疮，结果这位专家说不行，你得把整条腿给锯掉，这不是庸医吗？病人能接受吗？难以想象软件厂商不懂硬件的处理逻辑，多么不严谨幼稚反常识，未来给金融用户生产系统运维管理带来多么复杂的善后工作，然后客户数据中心运维搞不定，就绑死了玩，这可能才是核心利益逻辑。

一个小小的盘的故障，正常处理逻辑是控制住风险，快速隔离掉此“火情”，而不是扩散，扩散到节点，裂变到整个集群可能拉崩，还认为是合理的处理逻辑，这样的分布式主从多副本架构真的值得拥有？