问题现象
业务发起 Unit 迁移操作。
在迁移复制过程中从监控信息上看到了 TPS 或者 QPS 严重下跌，业务的查询 RT 变高。
迁移或者复制的目的端的日志流成为了 Leader，通过如下 SQL 确认。
select * from oceanbase.__all_virtual_ls_info where tenant_id = xxx and migrate_status != 0 and ls_state = 'LEADER';
关键诊断信息
触发条件
UNIT NUM 为 1 的场景：
等待迁移完成之前以后再切 SLB 不会出现问题；迁移未完成之前切了 SLB 有概率出现这个问题。
UNIT NUM 为 2 的场景：
因为这个时候会存在多个用户日志流，这个过程中和是否提前切换 SLB 无关，这个过程中迁移有概率出现这个问题；在弱网或者磁盘比较差的情况下容易出现。
事前巡检
在不触发迁移场景下没有这个问题。
事后诊断
迁移或者复制的目的端的日志流成为了 Leader，通过如下 SQL 确认。
select * from oceanbase.__all_virtual_ls_info where tenant_id = xxx and migrate_status != 0 and ls_state = 'LEADER';上述如果有记录，会有 Leader 所在的 OBServer 节点和日志流 ID。
在 Leader 所在的节点搜相关的日志。
grep "\-6231" observer.log输出的关键日志信息如下：
observer.log.20240427230847360:[2024-04-27 23:08:46.260457] WDIAG [STORAGE] get_read_tables (ob_ls_tablet_service.cpp:2323) [25125][BlackListServic][T1003][xxxxx-xxxxx-xxxxx-xxxxx] [lt=11][errcode=-6231] ls is not allow to read(ret=-6231, ls_={ls_meta:{tenant_id:1003, ls_id:{id:1}, ls_create_status:1, clog_checkpoint_scn:{val:0, v:0}, clog_base_lsn:{lsn:0}, rebuild_seq:0, migration_status:3, gc_state_:1, offline_scn_:{val:18446744073709551615, v:3}, restore_status:{status:0}, replayable_point:{val:18446744073709551615, v:3}, tablet_change_checkpoint_scn:{val:0, v:0}, all_id_meta:{id_meta:[{limited_id:1, latest_log_ts:{val:18446744073709551615, v:3}}, {limited_id:1, latest_log_ts:{val:18446744073709551615, v:3}}, {limited_id:1, latest_log_ts:{val:18446744073709551615, v:3}}]}, transfer_scn:{val:0, v:0}, rebuild_info:{status:{status:0}, type:{type:0}}}, switch_epoch:0, log_handler:{role:2, proposal_id:0, palf_env_:0x7ff1baffa030, is_in_stop_state_:false, is_inited_:true, id_:1}, restore_handler:{is_inited:true, is_in_stop_state:false, id:1, proposal_id:9223372036854775807, role:2, parent:null, context:{issue_task_num:0, issue_version:-1, last_fetch_ts:-1, max_submit_lsn:{lsn:18446744073709551615}, max_fetch_lsn:{lsn:18446744073709551615}, max_fetch_scn:{val:18446744073709551615, v:3}, error_context:{ret_code:0, trace_id:Y0-0000000000000000-0-0, error_type:-1526522004, err_lsn:{lsn:18446744073709551615}}, task_count:0}, restore_context:{seek_done:false, lsn:{lsn:18446744073709551615}}}, is_inited:true, tablet_gc_handler:{tablet_persist_trigger:3, is_inited:true}, startup_transfer_info:{ls_id:{id:0}, transfer_start_scn:{val:18446744073709551615, v:3}}})
问题原因
日志流迁移到目的端加入到了成员列表中，并且成为了 Leader，但是这个时候迁移流程未结束（这个过程是一个异步的动作，多个任务并发回造成迁移结束的时间很长），不允许日志流可读，造成了查询报错，影响业务的请求
问题的风险及影响
业务进行迁移或者复制的时候如果 Leader 切到了迁移过程中的副本，会造成业务的读写请求失败，影响业务查询和写入；当部署方式是 2F1A，UNIT NUM 为 1，Prmary Zone 为 1，进行了增配的迁移，在迁移任务未完成之前切了 SLB；Prmary Zone 为 1 的情况下只有两个日志流用户日志流和 1 号日志流，如果出现了成为了 Leader 不允许读的情况下理论上等待迁移完成以后再切 SLB 不会有问题；Prmary Zone 大于等于 2 的场景下会有多个日志流，那么这个时候进行迁移出现这个问题的概率会变高，推荐做这个变更的时间选择业务低峰期做，并且联系相关的研发在线一起做变更。
影响租户
影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。
影响版本
OceanBase 数据库企业版 V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本、V4.3.0（oceanbase-4.3.0.0-100000072024020200）及之后版本。
解决方法
升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库 V4.2.1 BP6 Hotfix1（oceanbase-4.2.1.6-106010032024052709）版本、V4.2.1 BP6 Hotfix2（oceanbase-4.2.1.6-106020022024061709）版本、V4.2.1 BP7（oceanbase-4.2.1.7-107000112024052920）及之后版本、V4.2.4（oceanbase-4.2.4.0-100000252024070621）及之后版本、V4.3.1（oceanbase-4.3.1.0-100000212024051522）及之后版本。
通过查询 OceanBase 数据库内部表和日志确定了以后，直接重启 Leader 所在的节点（参考本文 关键诊断信息 中的 事后诊断 这小节内容）。
规避方式
Prmary Zone 为 1 的时候发起 Unit 迁移，迁移未完成之前不要切 SLB。
Prmary Zone 为 2 的时候发起 Unit 迁移，尽量在业务低峰期的时候进行变更，变更的时候联系相关的研发一起进行变更。
