负载均衡执行慢，transfer 调度缓慢的原因和解决方法

问题现象

专有云环境中，通过修改 Primary Zone 后，发现均衡做的非常慢。仔细查看其实每次 transfer 的执行时间（__all_transfer_task_history 中的 start_time 到 finish_time）都很短，但是每次执行完成开始调度下一个任务大约需要一分半的时间，这不符合预期的快速调度。

关键信息

• 从 transfer_history 中观察到，虽然单个 transfer 任务的执行时间符合预期，但任务之间的调度间隔异常长。

• 使用线程号搜索日志发现，在 transfer 清理完成后存在长时间无日志记录的情况，直到下一个任务开始生成。

• 当 balance_task 的 part_list 和 finished_part_list 字段过长时，每次调度线程更新这些字段的信息耗时较长，可能达到分钟级别。

问题原因

每次做完一轮 transfer 的时候会修改其上层的 balance_task 中的 finished_part_list 和 part_list。当单个 balance_task 需要转移的分区数量非常大（达到十万级别）时，我们做完 transfer 后对 balance_task 的其中一行做 update 的时候就会出现更新 balance_task 信息的过程会变得异常耗时，从而导致整个负载均衡的任务执行速度显著下降。

问题的风险及影响

负载均衡过程变慢，可能导致系统性能下降，影响用户体验。

适用版本

OceanBase 数据库 V4.2.x 以上版本。

解决方法

把均衡任务取消，这样重新生成的均衡任务中的 balance_task 中不会有很多的 finished_part_list 和 part_list（之前调度完成的不会在写在表中）。

1. 取消当前正在进行的 balance job: ALTER SYSTEM CANCEL BALANCE JOB [TENANT = 'tenant_name'];。

2. 等待 __all_virtual_balance_job 表清空。

3. 如果当时日志流数量不符合预期会重新自动发起日志流均衡；如果日志流数量已经符合预期需要手动触发分区均衡来生成任务。

   警告

   切勿生产环境中擅自手动清理 __all_virtual_balance_job 表信息，如有疑问请咨询 OceanBase 数据库技术支持团队获得帮助。

规避方式

1. 尽量避免触发需要转移大量分区（十万级别）的 balance_task。

2. 在进行大规模分区转移前，考虑先手动调整分区分布，减少单次 balance_task 需要处理的分区数量。