--- title: Unit 迁移问题的排查方法-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于Unit 迁移问题的排查方法相关的常见问题和使用技巧，帮助您快速解决Unit 迁移问题的排查方法的难题。 --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # Unit 迁移问题的排查方法 更新时间：2026-06-10 01:56 适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x、V4.0.x、V4.1.x、V4.2.x、V4.3.x 内容类型：Troubleshoot 本文主要介绍 OceanBase 数据集在副本迁移过程中遇到的问题的排查方法。 ## 适用版本 OceanBase 数据库所有版本。 ## OceanBase V4.x 版本迁移问题排查方法 ### Unit 迁移无法结束 在 Unit 迁移过程中，可能会存在 Unit 迁移长时间无法结束的情况，可通过如下方式排查： 1. 确定迁移未完成的 Unit。 通过查询视图 `DBA_OB_UNITS`，确定处于迁移状态的 Unit，同时确定其 unit_id、迁移的源端位置、迁移的目的端位置。 ```shell obclient> select unit_id, concat(migrate_from_svr_ip, ':', migrate_from_svr_port) as source, concat(svr_ip, ':', svr_port) as destination from oceanbase.DBA_OB_UNITS where migrate_from_svr_ip is not null; ``` 返回结果如下： ```shell +---------+-------------------+-------------------+ | unit_id | source | destination | +---------+-------------------+-------------------+ | 1003 | x.xx.xxx.149:5073 | x.xx.xxx.149:5072 | +---------+-------------------+-------------------+ 1 row in set ``` 通过查询得知，unit_id为1003 的 Unit 正在从 `x.xx.xxx.149:5073` 机器迁移到 `x.xx.xxx.149:5072` 机器，如果此查询结果为空，则表示当前集群没有处在迁移中的 Unit。 2. 确认未迁移完成的副本。 通过上述查询得到未迁移完成的 Unit 后，查询获取该 Unit 上还存在哪些副本没有迁移完成。 ```shell obclient> select tenant_id, ls_id from oceanbase.CDB_OB_LS_LOCATIONS where role = "LEADER" and concat(tenant_id, ':', ls_id) in (select concat(tenant_id, ':', ls_id) from oceanbase.__all_virtual_ls_meta_table where unit_id = 1003) and (member_list like "%x.xx.xxx.149:5073%" or learner_list like "%x.xx.xxx.149:5072%"); ``` 返回结果如下： ```shell +-----------+-------+ | tenant_id | ls_id | +-----------+-------+ | 1001 | 1 | | 1002 | 1 | | 1002 | 1001 | +-----------+-------+ 3 rows in set ``` 查询说明： - 需要替换 unit_id 为迁移中的 Unit，并且模糊匹配 member_list 以及 learner_list 为迁移源端地址。 - 如果查询结果为空，说明该 Unit 上已经没有任何日志流在 leader 成员列表中的副本了，请参照步骤 4，确认是否因为异常原因导致 Unit 迁移结束时清空 migrate_from_svr_ip 字段失败了。 - 如果查询结果非空，说明该 Unit 还存在需要迁移的副本，例如上述查询结果说明：1003 的 Unit 还存在三个日志流的副本在源端 `x.xx.xxx.149:5073` 机器上，分别为 1001 租户的 1 日志流、1002 租户的 1 日志流以及 1002 租户的 1001 日志流，这些日志流都需要从 `x.xx.xxx.149:5073` 的副本内迁移走。 3. 确认日志流副本迁移任务的生成和执行情况 如果有副本没有迁移完成，需要确认副本迁移任务的生成和执行情况。 - 查看 `CDB_OB_LS_REPLICA_TASKS`，该视图显示了所有正在执行中的迁移任务，如果在这张视图中可以查询到结果，说明该迁移任务正在执行，需要等待任务执行完成(可以通过 tenant_id 和 ls_id 进行过滤)： ```shell obclient> obclient> select TENANT_ID,LS_ID,TASK_TYPE,TASK_ID,TARGET_REPLICA_SVR_IP,TARGET_REPLICA_SVR_PORT,SOURCE_REPLICA_SVR_IP,SOURCE_REPLICA_SVR_PORT from CDB_OB_LS_REPLICA_TASKS where tenant_id = 1001 and ls_id = 1; ``` 返回结果如下： ```shell +-----------+-------+-----------------+------------------------------------+-----------------------+-------------------------+-----------------------+-------------------------+ | TENANT_ID | LS_ID | TASK_TYPE | TASK_ID | TARGET_REPLICA_SVR_IP | TARGET_REPLICA_SVR_PORT | SOURCE_REPLICA_SVR_IP | SOURCE_REPLICA_SVR_PORT | +-----------+-------+-----------------+------------------------------------+-----------------------+-------------------------+-----------------------+-------------------------+ | 1001 | 1 | MIGRATE REPLICA | Y13CE060CEA95-000632F8CFE3F877-0-0 | x.xx.xxx.149 | 5072 | x.xx.xxx.149 | 5073 | +-----------+-------+-----------------+------------------------------------+-----------------------+-------------------------+-----------------------+-------------------------+ 1 row in set (0.07 sec) ``` 如上说明该任务处于执行中。 - 查询视图 `V$OB_LS_REPLICA_TASK_PLAN`，查看副本迁移情况。如果该视图为空，说明当前没有需要进行迁移的副本，即副本都已经迁移完成。 ```shell obclient> select * from V$OB_LS_REPLICA_TASK_PLAN; ``` 返回结果如下： ```shell +-----------+-------+-----------------+----------+-----------------------+-------------------------+-----------------------------+---------------------+-----------------------+-------------------------+-----------------------------+---------------------+------------------+--------------------+---------------------------------------+ | TENANT_ID | LS_ID | TASK_TYPE | PRIORITY | TARGET_REPLICA_SVR_IP | TARGET_REPLICA_SVR_PORT | TARGET_PAXOS_REPLICA_NUMBER | TARGET_REPLICA_TYPE | SOURCE_REPLICA_SVR_IP | SOURCE_REPLICA_SVR_PORT | SOURCE_PAXOS_REPLICA_NUMBER | SOURCE_REPLICA_TYPE | TASK_EXEC_SVR_IP | TASK_EXEC_SVR_PORT | COMMENT | +-----------+-------+-----------------+----------+-----------------------+-------------------------+-----------------------------+---------------------+-----------------------+-------------------------+-----------------------------+---------------------+------------------+--------------------+---------------------------------------+ | 1001 | 1 | MIGRATE REPLICA | LOW | x.xx.xxx.149 | 5073 | 2 | FULL | x.xx.xxx.149 | 5072 | 2 | FULL | x.xx.xxx.149 | 5073 | migrate replica due to unit not match | | 1002 | 1 | MIGRATE REPLICA | LOW | x.xx.xxx.149 | 5073 | 2 | FULL | x.xx.xxx.149 | 5072 | 2 | FULL | x.xx.xxx.149 | 5073 | migrate replica due to unit not match | | 1002 | 1001 | MIGRATE REPLICA | LOW | x.xx.xxx.149 | 5073 | 2 | FULL | x.xx.xxx.149 | 5072 | 2 | FULL | x.xx.xxx.149 | 5073 | migrate replica due to unit not match | +-----------+-------+-----------------+----------+-----------------------+-------------------------+-----------------------------+---------------------+-----------------------+-------------------------+-----------------------------+---------------------+------------------+--------------------+---------------------------------------+ 3 rows in set (0.66 sec) ``` - RS 采用无限重试的机制来执行日志流副本的迁移任务，如果某次迁移发生故障导致了失败，RS 会重试该日志流的迁移任务，直到成功为止。假设集群有故障导致任务无法完成且 RS 持续重试该迁移任务时（目的端磁盘满的情况），`CDB_OB_LS_REPLICA_TASKS` 视图中可能会一直有该副本的迁移信息，表示该副本一直处于迁移中。此时需要通过查询任务执行的历史记录来确认是否存在任务失败 RS 一直重试的情况。 这里主要通过 `DBA_OB_ROOTSERVICE_EVENT_HISTORY` 或者 `CDB_OB_LS_REPLICA_TASK_HISTORY`，如下分别介绍下两个视图的使用方式： - DBA_OB_ROOTSERVICE_EVENT_HISTORY ```shell obclient> select value1 as tenant_id, value2 as ls_id, timestamp, event, value3 as task_id, name4, value4, name5, value5, name6, value6, extra_info, concat(rs_svr_ip, ':', rs_svr_port) as rs_addr from oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY where module like "%disaster%" and value1 = 1002 and value2 = 1001 order by timestamp desc limit 10 \G ``` 查询说明： - 正常的一次迁移任务会对应两条记录，一次 `start_migrate_ls_replica` 记录标记迁移任务的开始，一次 `finish_migrate_ls_replica` 记录标记迁移任务的结束，标记结束的这次记录同时记录了迁移任务的执行结果 `execute_result`。 - 如果 `execute_result` 有报错说明副本迁移任务执行失败。 - 如果只有一条 `start_migrate_ls_replica` 的记录，找不到对应的 `finish_migrate_ls_replica`，说明这次迁移任务正在执行，如果长时间没有 finish_migrate_ls_replica 记录，则表示迁移存在问题。 - 如果没有 `start_migrate_ls_replica` 记录，说明没有发起迁移任务。 - CDB_OB_LS_REPLICA_TASK_HISTORY 该视图会记录所有执行完成的任务，包括失败的任务。可以通过 tenant_id 和 ls_id进行过滤。 #### 注意 - 在 V4.3.x 版本中，该视图从 V4.3.3 版本开始引入。 - 在 V4.2.x 版本中，该视图从 V4.2.3 及 V4.2.1 BP8 版本开始引入。 ```shell obclient> select TENANT_ID,LS_ID,TASK_TYPE,TASK_ID,TASK_STATUS,EXECUTE_RESULT,COMMENT from CDB_OB_LS_REPLICA_TASK_HISTORY where tenant_id = 1002 and ls_id = 1001 order by start_time desc; ``` 返回结果如下： ```shell +-----------+-------+-----------------+------------------------------------+-------------+-------------------------------------+---------------------------------------+ | TENANT_ID | LS_ID | TASK_TYPE | TASK_ID | TASK_STATUS | EXECUTE_RESULT | COMMENT | +-----------+-------+-----------------+------------------------------------+-------------+-------------------------------------+---------------------------------------+ | 1002 | 1001 | MIGRATE REPLICA | Y13CE060CEA95-000632F8CFE3F879-0-0 | COMPLETED | ret:0, OB_SUCCESS; elapsed:5773459; | migrate replica due to unit not match | +-----------+-------+-----------------+------------------------------------+-------------+-------------------------------------+---------------------------------------+ 1 row in set (0.07 sec) ``` 如果有故障导致迁移任务无法完成，RS 一直重试调度时，该视图内会出现多条记录，且执行结果都为失败（ TASK_STATUS 为 FAILED，注意需要根据 start_time 进行排序查看最新的执行记录），这里可以忽略错误码为 `-4737:OB_LS_EXIST` 和 `-4766:OB_LS_WAITING_SAFE_DESTROY`，主要关注这俩错误码之外的其他错误码。 ### Unit 发生迁移的原因 Unit 发生迁移的原因有很多，例如用户手动发起 Unit 迁移、删除 Server 触发 Unit 自动迁移、Server 永久下线触发 Unit 自动迁移、开启了 SYS 租户 Unit 资源独占等等。 #### 用户手动发起 Unit 迁移 用户可以通过：`alter system migrate unit xxx destination ‘$svr_ip:$svr_port’;` 命令手动发起unit迁移，将指定的unit迁往指定的目的端。可以查询 `DBA_OB_ROOTSERVICE_EVENT_HISTORY` 视图确定发起手动迁移的历史记录。查询 SQL 及示例如下： ```shell obclient> select timestamp, event, name1, value1, name2, value2, rs_svr_ip, rs_svr_port from DBA_OB_ROOTSERVICE_EVENT_HISTORY where event like "%admin_migrate_unit%" \G ``` 返回结果如下： ```shell *************************** 1. row *************************** timestamp: 2024-07-29 14:31:33.690741 event: admin_migrate_unit name1: ret value1: 0 name2: arg value2: {unit_id:1003, is_cancel:false, destination:"xxx.xx.xxx.212:7002"} rs_svr_ip: xxx.xx.xxx.212 rs_svr_port: 7000 *************************** 2. row *************************** timestamp: 2024-07-29 14:36:09.771273 event: admin_migrate_unit name1: ret value1: 0 name2: arg value2: {unit_id:1003, is_cancel:false, destination:"xxx.xx.xxx.212:7003"} rs_svr_ip: xxx.xx.xxx.212 rs_svr_port: 7000 2 rows in set ``` #### Delete Server 触发 Unit 自动迁移 Delete Server 操作会自动触发该 Server 上的 Unit 迁移，可以查看 Unit 迁移的源端在那段时间是不是被 Delete 过，查询 SQL 和示例如下： ```shell obclient> select * from DBA_OB_SERVER_JOBS\G ``` 返回结果如下： ```shell *************************** 1. row *************************** JOB_ID: 7 JOB_TYPE: DELETE_SERVER JOB_STATUS: SUCCESS RESULT_CODE: 0 PROGRESS: 100 START_TIME: 2024-07-29 20:08:10.949799 MODIFY_TIME: 2024-07-29 20:08:40.969912 SVR_IP: xxx.xx.xxx.212 SVR_PORT: 7003 SQL_TEXT: NULL EXTRA_INFO: NULL RS_SVR_IP: xxx.xx.xxx.212 RS_SVR_PORT: 7000 1 row in set ``` #### Server 永久下线触发 Unit 自动迁移 Server 永久下线后，会触发该 Server 上的 Unit 自动迁移到同 Zone 另一台不含该租户 Unit 资源的 Server 上，因此可以查看迁移源端的机器在该时间是否永久下线过，查询 SQL 及示例如下： ```shell obclient> select * from oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY where module like "%server%" and event like "%permanent_offline%" \G ``` 返回结果如下： ```shell *************************** 1. row *************************** TIMESTAMP: 2024-07-30 10:47:16.544546 MODULE: server EVENT: permanent_offline NAME1: server VALUE1: "xxx.xx.xxx.212:7003" NAME2: VALUE2: NAME3: VALUE3: NAME4: VALUE4: NAME5: VALUE5: NAME6: VALUE6: EXTRA_INFO: RS_SVR_IP: xxx.xx.xxx.212 RS_SVR_PORT: 7000 1 row in set ``` 此处存在一个延伸的场景，在机器永久下线后未触发 Unit 自动迁移，但是永久下线后通过 ADD Server 在该 Zone 增加机器后触发了 Unit 迁移。这可能是因为永久下线时，该 Zone 其他机器已有该租户其他的 Unit，因此这个 Unit 无处可迁，当 ADD Server 操作后该 Zone 有了一台空的机器，该 Unit 就可以迁移，该情况看起来为 ADD Server 触发的 Unit 迁移，其本质原因还是机器永久下线。 #### 开启 SYS 租户 Unit 资源独占 如果开启 SYS 租户资源独占，那 SYS 租户的 Unit 所在的 Server 上面只能有 SYS 租户的 Unit，如果有其他租户的 Unit，会尝试将这些租户的 Unit 自动迁移到其他机器，若是没有其他可用机器，不会发起迁移。 查看当前 SYS 租户是否开启了 Unit 资源独占。 ```shell obclient> show parameters like "%enable_sys_unit_standalone%" \G ``` 返回结果如下： ```shell *************************** 1. row *************************** zone: z3 svr_type: observer svr_ip: xxx.xx.xxx.212 svr_port: 7002 name: enable_sys_unit_standalone data_type: BOOL value: True info: specifies whether sys unit standalone deployment is turned on. Value: True:turned on False: turned off section: LOAD_BALANCE scope: CLUSTER source: DEFAULT edit_level: DYNAMIC_EFFECTIVE default_value: False isdefault: 0 1 rows in set ``` 当 value 值为 True 时，表示开启系统租户的 Unit 独占节点。关于该配置项的更多信息可参考 [enable_sys_unit_standalone](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002015803)。 #### 负载均衡触发 Unit 自动迁移 如果 SYS 租户的 enable_rebalance 是开启的，那 SYS 租户会对集群进行 Unit 均衡，尽可能使各个 Server 的 Unit 负载是均衡的。负载均衡自动触发的 unit 迁移当前视图并未展示原因，可以分析日志，搜索如下关键字找到对应时间的 trace，展开观察下是否生成了均衡任务。 ```shell grep -rni "start to do tenant group unit balance" rootservice.log ``` ### Unit 迁移历史记录查询 可通过视图 `DBA_OB_ROOTSERVICE_EVENT_HISTORY` 查看历史上所有 Unit 迁移的事件，有关该视图的详细介绍，请参考 [DBA_OB_ROOTSERVICE_EVENT_HISTORY](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002014589)。 ```shell obclient> select * from oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY where module like "%unit%" and event like "%migrate%" \G ``` 返回结果如下： ```shell *************************** 1. row *************************** TIMESTAMP: 2024-07-30 10:47:24.848327 MODULE: unit EVENT: migrate_unit NAME1: unit_id VALUE1: 1003 NAME2: migrate_from_server VALUE2: "xxx.xx.xxx.212:7003" NAME3: server VALUE3: "xxx.xx.xxx.212:7002" NAME4: tenant_id VALUE4: 1002 NAME5: manual_migrate VALUE5: NO NAME6: VALUE6: EXTRA_INFO: RS_SVR_IP: xxx.xx.xxx.212 RS_SVR_PORT: 7000 *************************** 2. row *************************** TIMESTAMP: 2024-07-30 10:47:24.914597 MODULE: unit EVENT: finish_migrate_unit NAME1: unit_id VALUE1: 1003 NAME2: end_op VALUE2: COMMIT NAME3: migrate_from_server VALUE3: "xxx.xx.xxx.212:7003" NAME4: server VALUE4: "xxx.xx.xxx.212:7002" NAME5: tenant_id VALUE5: 1002 NAME6: manual_migrate VALUE6: NO EXTRA_INFO: RS_SVR_IP: xxx.xx.xxx.212 RS_SVR_PORT: 7000 2 rows in set (0.00 sec) ``` ## OceanBase V2.x、V3.x 版本迁移问题排查方法 ### 手动调度迁移问题的排查 OceanBase 数据库的 RootService 模块负责 Unit 迁移的调度，如果一直没有对迁移进行调度，可以通过以下方法进行排查。 1. 通过以下 SQL 找到 RootService 的 IP 地址。 ```unknow obclient> SELECT * FROM __all_server WHERE with_rootserver=1; +----------------------------+----------------------------+----------------+----------+----+-------+------------+-----------------+--------+-----------------------+--------------------------------------------------------------------------------------+-----------+--------------------+--------------+----------------+-------------------+ | gmt_create | gmt_modified | svr_ip | svr_port | id | zone | inner_port | with_rootserver | status | block_migrate_in_time | build_version | stop_time | start_service_time | first_sessid | with_partition | last_offline_time | +----------------------------+----------------------------+----------------+----------+----+-------+------------+-----------------+--------+-----------------------+--------------------------------------------------------------------------------------+-----------+--------------------+--------------+----------------+-------------------+ | 2021-03-24 10:32:55.367438 | 2021-03-24 10:35:56.904319 | xx.xxx.xxx.xxx | 2882 | 2 | zone2 | 2881 | 1 | active | 0 | 2.2.76_20210314152507-03d916596ba416277bf49a1a2fccb0b0d36a1631(Mar 14 2021 15:56:27) | 0 | 1616553286007503 | 0 | 1 | 0 | +----------------------------+----------------------------+----------------+----------+----+-------+------------+-----------------+--------+-----------------------+--------------------------------------------------------------------------------------+-----------+--------------------+--------------+----------------+-------------------+ 1 row in set (0.01 sec) ``` 2. 登录到 RootService 所在的服务器，通过以下命令搜索 balancer 相关的日志。 ```unknow [admin@oceanbase /]$ grep balancer log/rootservice.log ``` ### 迁移过慢问题排查 1. 检查数据库配置项，建议的值如下： - 将 `server_data_copy_out_concurrency` 配置为 10。 - 将 `server_data_copy_in_concurrency` 配置为 10。 - 将 `sys_bkgd_io_low_percentage` 按需配置。 - 将 `sys_bkgd_net_percentage` 按需配置。 其中，`server_data_copy_in_concurrency` 与 `server_data_copy_out_concurrency` 分别用于配置单个节点迁入数据与迁出数据的最大并发数。`sys_bkgd_io_low_percentage` 表示 `sys_io_percent` 的下限，如果下限太低则可能导致合并的 I/O 很慢，可以通过适当调大这个值来调大 I/O。`sys_bkgd_net_percentage` 表示后端网络带宽占用。 有关以上配置项的详细信息，请参见《OceanBase 数据库 参考指南》中的 **系统配置项** 章节。 2. 检查 Unit 迁移操作是否为异地进行。 通过以下命令检查延时，如果延时大于 5 ms，则表示迁移操作为异地进行。将操作系统的 `sysctl.conf` 文件中的 `tcp_slow_start_after_idle` 参数设置为 0，避免 TCP 连接在空闲后被重新设置。其中 `observer_ip` 表示迁移目的服务器的 IP 地址。 ```unknow [admin@oceanbase /]$ ping ``` 3. 检查 I/O 是否达到磁盘瓶颈。 通过以下命令确认是否达到磁盘 I/O 瓶颈。 ```unknow [root@hostname /]# iostat -x -k 1 Linux 3.10.0-327.ali2019.alios7.x86_64 (k08j13249.eu95sqa) 03/30/2021 _x86_64_ (64 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 16.29 0.00 6.85 0.02 0.00 76.84 ``` 通过以下命令检查 `io_size_byte` 列中 2097152 对应行 `io_ps` 是否达到 500 以上。 ```unknow [admin@oceanbase /]$ cat etc/io_resource.conf version 1 io_type io_size_byte io_ps io_rt_us 0 4096 139979.75 123.25 0 8192 122290.50 139.44 0 16384 102972.00 164.16 0 32768 64478.75 196.28 0 65536 38162.25 219.13 0 131072 20608.50 232.28 0 262144 10537.00 280.90 0 524288 5284.00 414.86 1 2097152 890.00 1781.68 submit_thread_cnt 1 getevent_thread_cnt 5 ``` 如果 `io_ps` 未达到 500，检查日志，查看 `sys_io_high_percent` 是否与配置 `sys_bkgd_io_low_percentage` 一致。如果不一致，则说明存在 I/O 限流。 ```unknow [admin@oceanbase /]$ grep io_stat log/observer.log [2019-01-11 16:45:35.629871] INFO [COMMON] ob_io_manager.cpp:1424 [26043][Y0-0000000000000000] [lt=18] Current io stat, (sys_io_percent=60, sys_iops_up_limit=770, user_max_rt=20775.528088989257, user_io_stat={average_size:0, average_rt_us:"0.000000000000", old_stat:{io_cnt:27169649, io_bytes:349257160063, io_rt_us:276864943639}, new_stat:{io_cnt:27169649, io_bytes:349257160063, io_rt_us:276864943639}}, sys_io_stat={average_size:2097152, average_rt_us:"2784.086956521739", old_stat:{io_cnt:10151653, io_bytes:21289559392256, io_rt_us:127287447387}, new_stat:{io_cnt:10151676, io_bytes:21289607626752, io_rt_us:127287511421}}, io_conf={sys_io_low_percent:50, sys_io_high_percent:60, user_iort_up_percent:100, cpu_high_water_level:7680, write_failure_detect_interval:60000000, read_failure_black_list_interval:300000000, retry_warn_limit:2, retry_error_limit:5}, cpu_stat={avg_usage:584}) ``` 4. 检查网络配置。 1. 检查网卡是千兆还是万兆。 2. 检查 `ifconfig` 输出的结构是否有 `drop` 或者 `error` 的包。 3. 通过 `tsar` 或 `vsar` 检查 retrans，如果大于 0.2 则说明交换机或者链路存在问题。 5. 检查出现迁移过慢的步骤。 执行以下 SQL 语句，检查 `ACTION` 列值，该字段表示目前迁移正处于的步骤。 ```unknow obclient> SELECT * FROM __all_virtual_partition_migration_status WHERE action!='END' AND result = 0\G ``` ### 迁移失败问题的排查 1. 确认常见错误码。 目前，常见的迁移失败对应两个错误码，分别为： - **ERROR 4109** ：常见于 OceanBase 数据库 V1.4 版本，如果目的端在合并或者转储，可能出现该错误。如果 rebuild 的时候遇到，可以通过加快合并速度来回避，即调大合并线程数或者增量 sysio 的带宽限制。 - **ERROR 4018** ：表示源端进行了合并或者转储，导致找不到需要的数据。需要调大迁移的带宽、`sysio` 限制或者降低转储合并的频率。 2. 检查是否存在硬件问题。 1. 检查机器各硬件是否存在故障。 2. 检查错误日志。 如果结果为空则表示无故障。 ```unknow [root@hostname /]# dmesg|grep -E "Failed status, reset controller|Controller encountered a fatal error and was reset|Controller encountered a fatal error and was reset ``` 对于配置了 Raid 的机器还需要进行以下检查，如果结果为空则表示无故障。 ```unknow [root@hostname /]# tbraid log | grep -E "Read Medium ERR|Error" ``` 3. 通过以下命令确认是否存在 RX 或 TX 错误。 ```unknow [root@hostname /]# ifconfig bond0: flags=5187 mtu 1500 inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx broadcast xxx.xxx.xxx.xxx ether xx:xx:xx:xx:xx:xx txqueuelen 0 (Ethernet) RX packets 234167440 bytes 206275603707 (192.1 GiB) RX errors 0 dropped 63 overruns 0 frame 0 TX packets 241808476 bytes 97456446934 (90.7 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ``` 4. 检查 `tsar` 或 `vsar` 的 `retrans` 值，如果大于 0.2 则表示网络链路故障。 ```unknow [root@hostname /]# tsar Time ---cpu-- ---mem-- ---tcp-- -----traffic---- --sda--- --dfa--- --dfb--- --dfc--- --dm-0-- --dm-7-- --dm-8-- --dm-9-- -dm-10-- -dm-11-- -dm-12-- -dm-14-- -dm-24-- --dm-3-- --dm-2-- --dm-4-- -dm-15-- --dm-5-- -dm-16-- -dm-18-- -dm-17-- -dm-21-- -dm-19-- -dm-20-- --dm-1-- --dm-6-- -dm-13-- -dm-22-- -dm-23-- -dm-25-- -dm-28-- -dm-26-- -dm-27-- -dm-29-- -dm-30-- -dm-31-- ---load- Time util util retran bytin bytout util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util load1 30/03/21-16:45 21.62 53.82 0.00 3.0K 4.9K 0.01 0.04 0.33 1.26 0.00 0.00 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.40 0.00 0.00 0.39 0.00 0.01 0.29 0.00 0.00 0.00 0.00 0.02 0.35 0.39 0.00 0.00 0.15 0.00 0.00 0.00 0.00 0.00 0.00 15.31 30/03/21-16:50 21.59 54.39 0.00 2.9K 4.8K 0.01 0.04 0.30 1.20 0.00 0.00 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.37 0.01 0.00 0.37 0.00 0.01 0.29 0.00 0.00 0.00 0.00 0.02 0.32 0.39 0.00 0.00 0.14 0.00 0.00 0.00 0.00 0.00 0.00 12.37 30/03/21-16:55 24.40 54.68 0.00 2.9K 4.9K 0.01 0.27 1.08 32.99 0.00 0.00 0.00 0.00 0.00 0.00 0.02 0.00 0.00 0.40 0.00 0.01 0.40 0.00 0.01 0.28 0.00 0.00 0.00 0.00 0.24 1.10 32.64 0.00 0.00 0.16 0.00 0.00 0.00 0.00 0.00 0.00 24.60 30/03/21-17:00 24.46 55.30 0.00 2.9K 4.9K 0.01 0.19 1.11 18.98 0.00 0.00 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.38 0.00 0.00 0.37 0.00 0.01 0.28 0.00 0.00 0.00 0.00 0.17 1.13 18.49 0.00 0.00 0.17 0.00 0.00 0.00 0.00 0.00 0.00 19.38 30/03/21-17:05 21.74 55.89 0.00 2.9K 4.9K 0.01 0.04 0.02 1.26 0.00 0.00 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.41 0.01 0.00 0.36 0.00 0.01 0.30 0.00 0.00 0.00 0.00 0.02 0.03 0.38 0.00 0.00 0.16 0.00 0.00 0.00 0.00 0.00 0.00 16.01 MAX 38.78 79.44 0.13 1.7M 51.1K 0.69 1.55 55.95 50.54 0.00 0.00 0.00 0.00 0.00 0.00 0.61 0.12 0.00 6.98 0.01 0.11 6.65 0.12 0.01 4.94 0.00 6.50 0.34 55.83 0.33 12.47 45.96 0.82 55.79 6.68 6.63 0.34 55.81 1.14 0.00 0.00 61.70 MEAN 29.42 76.67 0.00 9.4K 5.2K 0.01 0.09 0.71 3.73 0.00 0.00 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.44 0.01 0.01 0.44 0.00 0.01 0.33 0.00 0.40 0.01 0.35 0.03 0.20 2.13 0.02 0.55 0.43 0.41 0.01 0.35 0.00 0.00 0.00 22.73 MIN 16.84 48.16 0.00 2.8K 4.2K 0.01 0.06 0.00 1.14 0.00 0.00 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.42 0.01 0.01 0.41 0.00 0.01 0.29 0.00 0.04 0.01 0.00 0.02 0.00 0.34 0.01 0.00 0.04 0.04 0.01 0.00 0.00 0.00 0.00 10.32 [root@hostname /]# vsar Time ---cpu-- ---mem-- ---tcp-- -----traffic---- --sda--- --dfa--- --dfb--- --dfc--- --dm-0-- --dm-7-- --dm-8-- --dm-9-- -dm-10-- -dm-11-- -dm-12-- -dm-14-- -dm-24-- --dm-3-- --dm-2-- --dm-4-- -dm-15-- --dm-5-- -dm-16-- -dm-18-- -dm-17-- -dm-21-- -dm-19-- -dm-20-- --dm-1-- --dm-6-- -dm-13-- -dm-22-- -dm-23-- -dm-25-- -dm-28-- -dm-26-- -dm-27-- -dm-29-- -dm-30-- -dm-31-- ---load- Time util util retran bytin bytout util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util util load1 30/03/21-17:09:13 21.32 56.40 0.00 949.00 5.4K 0.02 0.06 0.00 1.38 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.34 0.02 0.00 0.32 0.00 0.00 0.36 0.00 0.00 0.00 0.00 0.02 0.00 0.42 0.02 0.00 0.24 0.00 0.00 0.00 0.00 0.00 0.00 13.32 30/03/21-17:09:18 21.46 56.41 0.00 4.4K 33.3K 1.42 0.00 0.00 0.92 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.28 0.00 0.00 0.38 0.00 0.00 0.30 0.00 0.00 0.00 0.00 0.00 0.00 0.26 0.00 0.00 0.14 0.00 0.00 0.00 0.00 0.00 0.00 12.74 30/03/21-17:09:23 21.73 56.41 0.00 931.00 5.3K 0.00 0.04 0.00 1.12 0.00 0.00 0.00 0.00 0.00 0.00 0.02 0.00 0.00 0.26 0.00 0.02 0.40 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.28 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 12.68 30/03/21-17:09:28 22.16 56.44 0.00 10.8K 5.1K 0.02 0.02 0.00 1.92 0.00 0.00 0.00 0.00 0.00 0.00 0.02 0.00 0.00 0.40 0.00 0.00 0.60 0.00 0.00 0.26 0.00 0.00 0.00 0.00 0.00 0.00 0.90 0.00 0.00 0.24 0.00 0.00 0.00 0.00 0.00 0.00 13.02 30/03/21-17:09:33 21.07 56.44 0.00 863.00 5.3K 0.00 0.02 0.00 1.16 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.34 0.00 0.00 0.36 0.00 0.02 0.38 0.00 0.00 0.00 0.00 0.00 0.00 0.28 0.00 0.00 0.28 0.00 0.00 0.00 0.00 0.00 0.00 13.02 30/03/21-17:09:38 21.21 56.45 0.00 2.3K 4.4K 0.02 0.08 0.00 1.02 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.36 0.00 0.02 0.38 0.00 0.00 0.16 0.00 0.00 0.00 0.00 0.06 0.00 0.26 0.00 0.00 0.16 0.00 0.00 0.00 0.00 0.00 0.00 13.02 30/03/21-17:09:43 21.18 56.44 0.00 2.8K 5.2K 0.00 0.06 0.00 1.08 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.34 0.02 0.02 0.26 0.00 0.00 0.18 0.00 0.00 0.00 0.00 0.00 0.00 0.30 0.00 0.00 0.16 0.00 0.02 0.00 0.00 0.00 0.00 13.34 30/03/21-17:09:48 20.99 56.44 0.00 2.3K 4.3K 0.00 0.02 0.00 0.98 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.22 0.00 0.00 0.32 0.00 0.00 0.34 0.00 0.00 0.00 0.00 0.00 0.00 0.20 0.02 0.00 0.10 0.00 0.00 0.00 0.00 0.00 0.00 13.07 30/03/21-17:09:53 21.52 56.45 0.00 863.00 5.1K 0.02 0.02 0.00 0.96 0.00 0.00 0.00 0.00 0.00 0.00 0.02 0.00 0.00 0.30 0.00 0.00 0.30 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.26 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 13.39 30/03/21-17:09:58 21.44 56.47 0.00 8.0K 4.5K 0.00 0.00 0.00 1.18 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.38 0.00 0.00 0.34 0.00 0.00 0.24 0.00 0.00 0.00 0.00 0.00 0.00 0.36 0.00 0.00 0.18 0.00 0.00 0.00 0.00 0.00 0.00 12.80 30/03/21-17:10:03 24.46 56.48 0.00 1.1K 5.5K 0.00 0.02 0.00 1.26 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.30 0.00 0.00 0.34 0.00 0.02 0.28 0.00 0.00 0.00 0.00 0.00 0.00 0.50 0.00 0.00 0.18 0.00 0.00 0.00 0.00 0.00 0.00 13.02 MAX 74.03 56.45 0.00 15.4M 186.1K 30.10 17.46 100.00 92.10 0.00 0.00 0.00 0.00 0.00 0.26 12.90 0.00 0.00 1.06 1.24 1.00 0.90 0.00 1.02 0.92 0.00 43.00 4.68 100.00 3.18 97.52 92.64 4.30 100.00 74.30 42.90 3.80 100.00 0.00 0.00 0.00 50.61 MEAN 22.13 51.58 0.00 78.8K 7.5K 0.05 0.18 7.02 4.33 0.00 0.00 0.00 0.00 0.00 0.00 0.05 0.00 0.00 0.39 0.01 0.01 0.38 0.00 0.01 0.29 0.00 0.15 0.02 4.19 0.04 0.88 3.36 0.04 6.54 0.36 0.15 0.02 4.20 0.00 0.00 0.00 15.21 MIN 16.19 48.24 0.00 642.00 3.9K 0.01 0.02 0.00 0.64 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.18 0.01 0.00 0.14 0.00 0.00 0.08 0.00 0.00 0.00 0.00 0.01 0.01 0.08 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 9.37 ``` 3. 检查内核问题。 通过以下命令检查是否存在内核故障。 如果出现形如 `task xxx blocked for more than 120 seconds` 的日志，则可能为内核故障。可以通过升级内核版本的方式解决该问题。 ```unknow [root@hostname /]# dmesg |grep blocked ``` 上一篇 [SSTable 连续性检查丢失](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000951840) 下一篇 [OceanBase 集群迁移空 unit 卡住](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207660) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线