一块盘故障引发复杂手工恢复操作，值得吗？

近日，与一机构交流了解了分布式数据库O数据库的架构及切换机制。为了提升性能，推荐采用NVME SSD盘，但是现在NVME RAID卡没有配置，软RAID又担心性能不行，就采取直通模式，不做本地盘RAID，生产中心3副本，同城3副本，异地3副本，每台服务器配置6块3.84TB NVMe SSD盘，6块盘做VG，LV，再创建xfs文件系统，各节点互为主备，基于表的分区做主从多副本复制，生产到同城同步复制。堆了大几百台数据库服务器来承载只有不到30TB的有效数据，利用率低到难以想象！

模拟故障测试，拔掉一块NVMe盘，数据库默认检测5秒IO没有回来，就启动节点切换，8秒左右完成节点主从切换，如果盘有超时或者Bug导致Hang住，也是5秒快速启动切换，合计13秒搞定，真的很快，其实IO下到盘的超时时间是30秒，也就是底层有一个IO超过5秒，数据库就把节点直接干掉，切主从。

这个时候把新的一张盘插进去，OS会生产新的盘符，系统无法恢复。需要换成新的服务器，基于扩容方式来加入新节点，而原服务器因为一张盘故障，整台服务器就被认为是不可用了。新服务器加入集群，没有RAID保护，就只能重建VG，LV，XFS文件系统，需要将整台服务器的副本数据重建，需要多长时间？因为一块盘，或者内存问题，就扩散踢掉整个服务器节点，恢复操作需要客户运维手工操作？凌晨三点出问题，懵懵懂懂中还敢做这些操作吗？难以想象如此粗暴的逻辑会给客户带来多复杂的运维工作，尤其服务器运行2～3年后，部件故障率上升，不断倒腾切换受得了吗？一块盘或者内存的故障，需要厂商用备件来替换整台服务器，服务器厂商会认吗？这可都是成本呢。

另外，如果是慢盘呢，盘频繁出现20ms这样的亚健康，数据库会怎么处理呢？这么大一个数据库集群，尤其核心数据库每天全量备份，怎么快速的备份呢？恢复又怎么快速呢？

因此，一金融机构转而采用数据库+外置存储方案，慢盘、超时盘会快速隔离，30秒内频繁出现IO几十ms的慢盘，系统会进行统计，超过一个值，就标识为亚健康，业务通过存储RAID降级读写返回，后台进行IO检测时延是否异常，甚至重新上下电，还是异常就会快速隔离。如果出现IO超时，检测到秒级IO，存储系统内部就通过RAID重构完成恢复业务，业务不会感知超时，这些都不会影响数据库节点切换，运维管理就简单多了。

另外如一大行用户说的，如果因为服务器自身可靠性原因故障切换，新换服务器，只需要将外置存储LUN资源映射给新服务器，加入集群，追增量即可，而如果服务器本地盘方案，则从零开始重建副本，时间就会很长，而且影响生产网络的复制性能。计算资源和存储容量资源管理逻辑不一样，资源的管理一定是精细化的，而不是像存算一体这样粗放型的管理，存算分离是从1990年开始的，实践证明是成功的，存算解藕既节约资源，又管理高效，对运维管理也省事很多。