高读写负载情况下,集群节点个数扩容之后负载均衡任务失败

【 使用环境 】生产环境
【 OB or 其他组件 】OceanBase
【 使用版本 】OceanBase-CE-4.2.1-bp8
【问题描述】由于正在使用的OB集群的磁盘使用率较高,最高的节点磁盘使用率87%,最低的56%。安排通过OCP对OB集群进行节点扩容操作,并修改租户的UNIT_NUM个数进行租户扩容。上述操作完成后,观察新加入的节点磁盘是否正常。
发现新加入的节点磁盘一直未上涨,集群整体的磁盘情况未获得缓解。
查看负载均衡的相关表,结果如下:

MySQL [oceanbase]> select * from cdb_ob_balance_tasks limit 5\G;
*************************** 1. row ***************************
               TENANT_ID: 1002
                 TASK_ID: 85348527502
             CREATE_TIME: 2025-05-29 15:32:50.249740
             MODIFY_TIME: 2025-05-29 16:00:14.606135
               TASK_TYPE: LS_SPLIT
                  SRC_LS: 1043
                 DEST_LS: 4932
               PART_LIST: 557950:558567
      FINISHED_PART_LIST: 
              PART_COUNT: 1
     FINISHED_PART_COUNT: 0
             LS_GROUP_ID: 1015
                  STATUS: TRANSFER
             PARENT_LIST: NULL
              CHILD_LIST: 85348527503
CURRENT_TRANSFER_TASK_ID: 3441226
                  JOB_ID: 85348527500
                 COMMENT: 
*************************** 2. row ***************************
               TENANT_ID: 1002
                 TASK_ID: 85348527503
             CREATE_TIME: 2025-05-29 15:32:50.249740
             MODIFY_TIME: 2025-05-29 15:32:50.249740
               TASK_TYPE: LS_ALTER
                  SRC_LS: 4932
                 DEST_LS: 4932
               PART_LIST: NULL
      FINISHED_PART_LIST: NULL
              PART_COUNT: 0
     FINISHED_PART_COUNT: 0
             LS_GROUP_ID: 1021
                  STATUS: INIT
             PARENT_LIST: 85348527502
              CHILD_LIST: 85348527504
CURRENT_TRANSFER_TASK_ID: -1
                  JOB_ID: 85348527500
                 COMMENT: NULL
*************************** 3. row ***************************
               TENANT_ID: 1002
                 TASK_ID: 85348527504
             CREATE_TIME: 2025-05-29 15:32:50.249740
             MODIFY_TIME: 2025-05-29 15:32:50.249740
               TASK_TYPE: LS_MERGE
                  SRC_LS: 4932
                 DEST_LS: 4632
               PART_LIST: NULL
      FINISHED_PART_LIST: NULL
              PART_COUNT: 0
     FINISHED_PART_COUNT: 0
             LS_GROUP_ID: 1021
                  STATUS: INIT
             PARENT_LIST: 85348527503
              CHILD_LIST: NULL
CURRENT_TRANSFER_TASK_ID: -1
                  JOB_ID: 85348527500
                 COMMENT: NULL
3 rows in set (0.03 sec)
MySQL [oceanbase]> select * from cdb_OB_TRANSFER_TASKS limit 5\G;
*************************** 1. row ***************************
              TENANT_ID: 1002
                TASK_ID: 3441226
            CREATE_TIME: 2025-05-29 16:00:14.606135
            MODIFY_TIME: 2025-05-29 16:00:14.608232
                 SRC_LS: 1043
                DEST_LS: 4932
              PART_LIST: 557950:558567
             PART_COUNT: 1
    NOT_EXIST_PART_LIST: NULL
LOCK_CONFLICT_PART_LIST: NULL
 TABLE_LOCK_TABLET_LIST: NULL
            TABLET_LIST: NULL
           TABLET_COUNT: 0
              START_SCN: 0
             FINISH_SCN: 0
                 STATUS: INIT
               TRACE_ID: YB421372120C-0006351B1D8D7F10-0-0
                 RESULT: -1
        BALANCE_TASK_ID: 85348527502
    TABLE_LOCK_OWNER_ID: -1
                COMMENT: Wait to retry due to the last failure
1 row in set (0.04 sec)
MySQL [oceanbase]> select * from cdb_OB_TRANSFER_TASK_history order by FINISH_TIME desc limit 5\G;
*************************** 1. row ***************************
              TENANT_ID: 1002
                TASK_ID: 3441227
            CREATE_TIME: 2025-05-29 16:01:14.797374
            FINISH_TIME: 2025-05-29 16:02:14.749683
                 SRC_LS: 1043
                DEST_LS: 4932
              PART_LIST: 557950:558567
             PART_COUNT: 1
    NOT_EXIST_PART_LIST: NULL
LOCK_CONFLICT_PART_LIST: NULL
 TABLE_LOCK_TABLET_LIST: 208838
            TABLET_LIST: 208838:0,1152921504606893484:0,1152921504606894144:0,1152921504606894804:0,1152921504606895464:0
           TABLET_COUNT: 5
              START_SCN: 0
             FINISH_SCN: 0
                 STATUS: FAILED
               TRACE_ID: YB421372120C-0006351B1D8D7F4D-0-0
                 RESULT: -7114
        BALANCE_TASK_ID: 85348527502
    TABLE_LOCK_OWNER_ID: 85370831571
                COMMENT: 
*************************** 2. row ***************************
              TENANT_ID: 1002
                TASK_ID: 3441226
            CREATE_TIME: 2025-05-29 16:00:14.606135
            FINISH_TIME: 2025-05-29 16:01:14.619607
                 SRC_LS: 1043
                DEST_LS: 4932
              PART_LIST: 557950:558567
             PART_COUNT: 1
    NOT_EXIST_PART_LIST: NULL
LOCK_CONFLICT_PART_LIST: NULL
 TABLE_LOCK_TABLET_LIST: 208838
            TABLET_LIST: 208838:0,1152921504606893484:0,1152921504606894144:0,1152921504606894804:0,1152921504606895464:0
           TABLET_COUNT: 5
              START_SCN: 0
             FINISH_SCN: 0
                 STATUS: FAILED
               TRACE_ID: YB421372120C-0006351B1D8D7F10-0-0
                 RESULT: -7114
        BALANCE_TASK_ID: 85348527502
    TABLE_LOCK_OWNER_ID: 85366559553
                COMMENT: 
*************************** 3. row ***************************
              TENANT_ID: 1002
                TASK_ID: 3441225
            CREATE_TIME: 2025-05-29 15:59:14.419215
            FINISH_TIME: 2025-05-29 16:00:14.445245
                 SRC_LS: 1043
                DEST_LS: 4932
              PART_LIST: 557950:558567
             PART_COUNT: 1
    NOT_EXIST_PART_LIST: NULL
LOCK_CONFLICT_PART_LIST: NULL
 TABLE_LOCK_TABLET_LIST: 208838
            TABLET_LIST: 208838:0,1152921504606893484:0,1152921504606894144:0,1152921504606894804:0,1152921504606895464:0
           TABLET_COUNT: 5
              START_SCN: 0
             FINISH_SCN: 0
                 STATUS: FAILED
               TRACE_ID: YB421372120C-0006351B1D8D7ED3-0-0
                 RESULT: -7114
        BALANCE_TASK_ID: 85348527502
    TABLE_LOCK_OWNER_ID: 85366557326
                COMMENT: 
MySQL [oceanbase]> select count(*) from __all_virtual_trans_stat where tenant_id=1002 and ls_id=1043;
+----------+
| count(*) |
+----------+
|      248 |
+----------+
1 row in set (0.01 sec)

根据上面的查询结果,进行梳理:

  1. 集群、租户扩容完成后,rebalance任务正常发起,先在磁盘使用率最高的节点上进行了日志流的分裂,生成了临时的日志流,再与新扩容节点上的日志流进行合并
  2. transfer任务也正常发起,状态一直出于INIT中,通过cdb_OB_TRANSFER_TASK_history 表可以看到,transfer 任务持续失败,错误码-7114
  3. 依据错误码检索,发现原因是“ 没有开启 transfer 杀事务时(_enable_balance_kill_transaction ),transfer 要等待活跃事务完成(默认 100ms)。当活跃事务本身持续时间较长,且业务侧持续开启新事务时,transfer 等不到活跃事务结束,导致 transfer 持续失败。”
  4. 检查相关参数,确认当前集群确实没有开启_enable_balance_kill_transaction,并且该集群属于7*24小时高负载的情况。

疑问:

  1. rebalance任务为什么设计成 在待搬出的节点上进行日志流分裂,再与待搬入的节点进行日志流合并的方式?
  2. 4.x 和 3.x 的负载均衡表现差异较大,原3.x 在同等负载压力的情况下,扩容节点个数后磁盘负载均衡速度挺快的。当前这个集群,扩容操作完成后,一个星期,新扩容的节点磁盘使用率才上涨至7%。原3.x版本上,分区负载均衡的实际表现优于4.x的日志流均衡。

解决方案:
目前看只能尝试打开_enable_balance_kill_transaction ,并设置_balance_wait_killing_transaction_end_threshold 为合理的数值,等待活跃事务完成完成transfer。最差情况下,需要业务停压,这样对业务的影响就很大了

1 个赞

负载均衡4x如果迁移的分区存在事物,均衡任务会失败,建议扩容在业务低峰做,最好让业务先停止一段时间,均衡任务完毕在起业务,修改参数会导致事物执行失败,影响业务

业务没有低峰,7*24小时都是高峰,停机的影响太大了,事务执行失败的影响也很大。
3.x 版本上我们做过很多次扩容节点的操作了,集群的负载压力是基本对等的,并没有出现负载均衡任务调度失败的情况。

如果可预见性的 业务量会暴增 例如双11或者618这样的活动 可以先低峰期提前扩容 这样话可以避免这样的问题