【 使用版本 】社区版OCP 4.3+OB 4.2.1.8
【问题描述】租户内资源不足时，OBserver故障时的副本补齐流程
【部署架构说明】
1.2+2+2部署模式下，primary zone为3个az：az1,az2,az3，az1机器为ob1、ob2，az2机器为ob3、ob4，az3机器为ob5，ob6
2.租户的unit_number为2，每个zone都有2个unit
3.模拟当ob5机器故障时，az3因为只有一个机器存活，2个unit实际只有1个可用，ob6上能否将副本补齐
【测试流程说明】
1.使用sysbench写入数据数据写入测试
2.通过sql查看副本分布情况，SELECT DATABASE_NAME,TABLE_NAME,TABLE_ID,ZONE,SVR_IP,SVR_PORT,LS_ID FROM oceanbase.DBA_OB_TABLE_LOCATIONS where database_name =‘sysbench’ and table_name=‘sbtest2’;
3.使用sysbench持续测试，过程中将ob5的observer进程kill -9干掉
4.等待server_permanent_offline_time时间到位后检查副本情况以及从DBA_OB_ROOTSERVICE_EVENT_HISTORY查看ob的自身动作
5.通过ocp调整测试租户的unit_num数量
6.恢复ob5上的observer进程观察ob的操作流程
【测试结果】
1.机器都正常时可以看到sysbench测试的30张表leader副本均衡的分布在3组az的6台机器
2.模拟ob机器上ob进程异常且达到server_permanent_offline_time时间后从DBA_OB_ROOTSERVICE_EVENT_HISTORY里看问题节点ob5被permanent_offline了
并且有start_add_ls_replica和finish_add_ls_replica操作，提示data_source为ob5节点，destination为ob6节点(仅为租户下ls_id为1的日志流，业务表的日志流没有动作)；但此时从DBA_OB_TABLE_LOCATIONS可以看到sbtest2仅有2个副本，并且ocp的告警只有一个OBServer 进程停止
3.在第二步这个场景下，通过ocp调整测试租户的unit_num数量为1，任务会执行过程中报错
4.恢复OB5的observer进程后，DBA_OB_ROOTSERVICE_EVENT_HISTORY可以看到相关恢复replica到ob5的操作，并且第二步为2个副本的表也会恢复为3副本
5.在第四步这个场景下，尝试直接将某个机器直接删除，会提示报错，“剩余的server数不能小于租户[test2]在zone=zone2下的unit数”
【结果说明和疑问点】
参考https://ask.oceanbase.com/t/topic/35608483/7部分内容
1.ob的副本补齐和租户unit资源强相关，需要集群内有对应租户资源
2.如果租户内资源不足以恢复副本，现有ocp告警上有所不足。社区版OCP在处理副本补全这块是否有其他的告警逻辑