【详述】
测试多副本的数据表，在be节点storage目录损坏(删除)后对业务的影响。
期望是，当1个be节点的storage路径不可读写时，可以正常的完成表的读写操作。
但实际是，读写都会失败，没有达到预期的数据多副本高可用的效果。
比如当1个副本丢失后，读取操作可以调度正常的数据副本，完成查询。
写入时也是先向可用的tablet副本中写，不要让写入失败。
2副本表会报错success replica num 1 less then quorum replica num 2 while error backends,
期望是可以在剩下的可用的be节点上完成另一个replica的写入，而不是始终向不可用的be节点写replica，导致写入任务一直无法成功。
【背景】做过哪些操作？
删除Bankend=10031的be节点的storage目录后，有如下测试结果：
1、 2副本、明细模型、日期分区表
①查询报错
查询被删除的节点的tablet的状态，显示NORMAL正常，但是应该是异常才对
②写入报错
2、 3副本、明细模型、日期分区表
①查询报错
查询被删除节点的tablet的状态，同样显示NORMAL正常，但是应该异常才对
②写入报错
而且日志上报显示被删除损坏的be节点，状态依然是可用的。
3、 关闭异常节点的be服务后，显示该节点上的副本状态为dead
此时2副本表查询成功，写入失败
此时3副本表查询成功，写入失败，且写入时会导致其他查询卡住
4、 关闭异常节点的be服务一段时间后，starrocks会在其他可用的be节点上不全dead的副本，删除dead的副本
【业务影响】
【StarRocks版本】2.5.2
【集群规模】例如：1fe+6be（fe与be混部）
【机器信息】24C/125G/万兆
【联系方式】社区群5-不惑 或者 zxdtony@126.com
【附件】
be.INFO.log.20230322-140710.bak1 (4.0 MB)
be.WARNING.log.20230322-141735.bak1 (270.8 KB)
fe.audit.log (85.1 KB)
fe.log.bak (18.8 MB)
fe.out (12.8 KB)
fe.warn.log (1.9 MB)