nfs挂掉之后，OB原有的备份任务一致无法终止

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OBCE-4.2.2
【 使用版本 】OBCE-4.2.2
【问题描述】ob备份 nfs 机器换了之后，原先的备份任务无法结束，导致新的备份任务无法发起。
【复现路径】问题出现前后相关操作

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

image
image718×368 90.2 KB

1 个赞
#3

@论坛小助手

1 个赞
#4

根据您的描述，您遇到了OceanBase备份任务在更换NFS服务器后无法正常终止的问题。

推荐使用 obdiag 工具进行日志采集，以便我们能够更好地定位问题所在。

日志采集场景: 数据备份问题
日志采集命令: obdiag gather scene run --scene=observer.backup

请您执行上述命令并提供采集到的日志压缩包，这将帮助我们更准确地分析问题的原因。

为了进一步了解问题，请您提供一些额外的信息：

  1. 您是在何时更换的NFS服务器？
  2. 更换NFS服务器前后，是否进行了任何配置更改或调整？
  3. 当前遇到的问题是否影响到了所有的备份任务，还是仅针对特定的任务？
  4. 您是否尝试过停止备份任务？如果尝试过，请描述一下具体的步骤和结果。

具体信息可参考以下文档:

附上敏捷诊断工具 obdiag 使用帮助链接

1 个赞
#5

@论坛小助手

1 个赞
#6

再向您确认几个问题:

  1. 更换NFS服务器时是否确保了所有OBServer节点都挂载了新的NFS并且使用了建议的参数
  2. 在更换NFS服务器前后是否有对备份策略或相关的系统参数进行过修改
  3. 当备份任务无法结束时您尝试使用ALTER SYSTEM CANCEL BACKUP命令取消了吗结果如何
  4. 除了使用ALTER SYSTEM命令外您还尝试过哪些方法来尝试终止或重启备份任务
1 个赞
#7

– 之前公司的nfs 服务器故障挂掉了，重新配置nfs服务器，原先的备份任务一直停止不掉，新任务无法发起，如下是 先关信息：
select * from oceanbase.CDB_OB_BACKUP_PARAMETER where tenant_id=1008;

image
image1059×192 20.5 KB

image
image1077×243 28.4 KB

image
image1513×435 67.2 KB

image
image1516×295 40.4 KB

后天的备份任务一直处于 CANCELING 停止不掉

image
image1011×456 39.1 KB

1 个赞
#8

尝试过重新设置 备份目录，rs切换 还是不行 。

#9

根据您提供的信息，您更换了NFS服务器后，原有的备份任务一直停留在 CANCELING 状态，导致新的备份任务无法发起。接下来，我们将一步步排查这个问题。

步骤 1: 查询备份任务状态

首先，我们需要确认当前备份任务的状态。您可以使用以下SQL语句来查询：

SELECT * FROM oceanbase.CDB_OB_BACKUP_TASKS WHERE tenant_id = 1008;

步骤 2: 分析备份参数

您已经提供了备份参数表的信息：

SELECT * FROM oceanbase.CDB_OB_BACKUP_PARAMETER WHERE tenant_id = 1008;

根据输出结果，我们可以看到：

  • dest_id: 1001
  • path: file:///backup/catl_cloudDB_MES/12/tenant_incarnation_1/1008/clog
  • piece_switch_interval: 1d
  • state: ENABLE

步骤 3: 检查租户信息

您也提供了租户信息：

SELECT tenant_id, tenant_name, tenant_type, primary_zone, tenant_role, log_mode FROM oceanbase.DBA_OB_TENANTS WHERE tenant_id = 1008;

根据输出结果，我们可以看到：

  • tenant_id: 1008
  • tenant_name: CM_c
  • tenant_type: USER
  • primary_zone: zone1,zone2,zone3
  • tenant_role: PRIMARY
  • log_mode: NOARCHIVELOG

步骤 4: 检查日志归档进度

您还提供了日志归档进度的信息：

SELECT tenant_id, dest_id, ls_id, round_id, piece_id, incarnation, scn_to_timestamp(start_scn) start_scn_ts, scn_to_timestamp(checkpoint_scn) ckpt_scn_ts, status, file_id FROM oceanbase.CDB_OB_LS_LOG_ARCHIVE_PROGRESS WHERE tenant_id = 1008 ORDER BY start_scn DESC;

根据输出结果，我们可以看到所有记录的状态都是 DOING，这表明日志归档正在进行中。

步骤 5: 检查归档日志信息

您还提供了归档日志的信息：

SELECT tenant_id, dest_id, round_id, incarnation, status, start_scn_display, checkpoint_scn_display, piece_switch_interval, base_piece_id, comment, path FROM oceanbase.CDB_OB_ARCHIVELOG WHERE tenant_id = 1008;

根据输出结果，我们可以看到：

  • status: 未知（未提供具体值）
  • path: file:///backup/catl_cloudDB_MES/12/tenant_incarnation_1/1008/data

排查建议

  1. 检查NFS挂载状态：确认所有OBServer节点都成功挂载了新的NFS，并且使用了建议的参数。
  2. 检查租户状态：确认租户状态是否正常，以及日志归档是否已开启。
  3. 检查备份任务状态：确认备份任务是否仍然处于 CANCELING 状态。
  4. 检查归档日志状态：确认归档日志的状态是否正常，是否存在异常状态。
  5. 尝试取消备份任务：再次尝试使用 ALTER SYSTEM CANCEL BACKUP 命令取消备份任务，并查看命令执行结果。

进一步排查

如果上述步骤未能解决问题，您可以进一步执行以下步骤：

  1. 查询备份任务执行信息：
    SELECT * FROM oceanbase.__all_virtual_backup_schedule_task WHERE tenant_id = 1008;
  2. 检查日志：
    • 登录到 destination 列所显示的机器上，执行以下命令搜索日志：
      grep 'trace_id' observer.log
    • 其中，trace_id 为上一步查询出来的 trace_id 的值。

结论

根据您提供的信息，备份任务可能因为日志归档仍在进行中而无法终止。请按照上述步骤进行排查，并提供进一步的信息以便于更准确地定位问题。

具体信息可参考以下文档:

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#10

手动执行取消 备份任务:

MySQL [oceanbase]> ALTER SYSTEM CANCEL BACKUP tenant='CMAAS_C';
Query OK, 0 rows affected (0.00 sec)

查询备份任务还是 CANCELING

MySQL [oceanbase]> select tenant_id, job_id,incarnation,backup_set_id,PLUS_ARCHIVELOG ,backup_type,job_level,start_timestamp, status ,DESCRIPTION ,PATH 
   -> from oceanbase.CDB_OB_BACKUP_JOBS
   -> where tenant_id=1008;

image
image973×377 22.3 KB

#11

查询结果是空的
SELECT * FROM oceanbase.__all_virtual_backup_schedule_task WHERE tenant_id = 1008;

#12

麻烦查一下看看：

select * from __all_virtual_backup_ls_task where tenant_id=1008 \G

#13

空的

#14

  1. __all_virtual_backup_ls_task 记录是空的。

  2. 停掉日志备份的方法没有 。

alter system noarchivelog tenant=xxxx;

命令虽然不报错，但是 cdb_ob_ls_log_archive_progress 里 tenant_id=1008 的 doing 记录还是在。

  1. 无法修改日志 备份目录，会提示日志备份进行中，无法修改备份目录。
#15

select * from cdb_ob_backup_set_files where tenant_id=1008 order by START_TIMESTAMP desc limit 10;

#16 
*************************** 1. row ***************************
               TENANT_ID: 1008
           BACKUP_SET_ID: 91
                 DEST_ID: 1002
             INCARNATION: 1
             BACKUP_TYPE: INC
 PREV_FULL_BACKUP_SET_ID: 90
  PREV_INC_BACKUP_SET_ID: 90
         START_TIMESTAMP: 2024-07-30 04:00:15.017285
           END_TIMESTAMP: 2024-07-30 04:02:02.052950
                  STATUS: SUCCESS
             FILE_STATUS: AVAILABLE
        ELAPSED_SECONDES: 107
         PLUS_ARCHIVELOG: OFF
        START_REPLAY_SCN: 1722252760404237001
START_REPLAY_SCN_DISPLAY: 2024-07-29 19:32:40.404237
         MIN_RESTORE_SCN: 1722283322044522000
 MIN_RESTORE_SCN_DISPLAY: 2024-07-30 04:02:02.044522000
             INPUT_BYTES: 2005809445
            OUTPUT_BYTES: 135528522
       OUTPUT_RATE_BYTES: 1266199.6541
        EXTRA_META_BYTES: 0
            TABLET_COUNT: 5740
     FINISH_TABLET_COUNT: 5740
       MACRO_BLOCK_COUNT: 963
FINISH_MACRO_BLOCK_COUNT: 952
              FILE_COUNT: 0
            META_TURN_ID: 1
            DATA_TURN_ID: 0
                  RESULT: 0
                 COMMENT: 
         ENCRYPTION_MODE: NONE
                  PASSWD: 
       TENANT_COMPATIBLE: 4.2.2.1
       BACKUP_COMPATIBLE: 3
                    PATH: file:///backup/catl_cloudDB_MES/12/tenant_incarnation_1/1008/data
         CLUSTER_VERSION: 4.2.2.1
          CONSISTENT_SCN: 1722283252211678000
           MINOR_TURN_ID: 1
           MAJOR_TURN_ID: 1
*************************** 2. row ***************************
               TENANT_ID: 1008
           BACKUP_SET_ID: 90
                 DEST_ID: 1002
             INCARNATION: 1
             BACKUP_TYPE: FULL
 PREV_FULL_BACKUP_SET_ID: 0
  PREV_INC_BACKUP_SET_ID: 0
         START_TIMESTAMP: 2024-07-29 04:00:12.870714
           END_TIMESTAMP: 2024-07-29 04:01:49.221648
                  STATUS: SUCCESS
             FILE_STATUS: AVAILABLE
        ELAPSED_SECONDES: 96
         PLUS_ARCHIVELOG: OFF
        START_REPLAY_SCN: 1722161459377621003
START_REPLAY_SCN_DISPLAY: 2024-07-28 18:10:59.377621
         MIN_RESTORE_SCN: 1722196909214784000
 MIN_RESTORE_SCN_DISPLAY: 2024-07-29 04:01:49.214784000
             INPUT_BYTES: 2030975293
            OUTPUT_BYTES: 150623511
       OUTPUT_RATE_BYTES: 1563280.2376
        EXTRA_META_BYTES: 0
            TABLET_COUNT: 5740
     FINISH_TABLET_COUNT: 5740
       MACRO_BLOCK_COUNT: 964
FINISH_MACRO_BLOCK_COUNT: 964
              FILE_COUNT: 0
            META_TURN_ID: 1
            DATA_TURN_ID: 0
                  RESULT: 0
                 COMMENT: 
         ENCRYPTION_MODE: NONE
                  PASSWD: 
       TENANT_COMPATIBLE: 4.2.2.1
       BACKUP_COMPATIBLE: 3
                    PATH: file:///backup/catl_cloudDB_MES/12/tenant_incarnation_1/1008/data
         CLUSTER_VERSION: 4.2.2.1
          CONSISTENT_SCN: 1722196844167244000
           MINOR_TURN_ID: 1
           MAJOR_TURN_ID: 1
*************************** 3. row ***************************
               TENANT_ID: 1008
           BACKUP_SET_ID: 89
                 DEST_ID: 1002
             INCARNATION: 1
             BACKUP_TYPE: INC
 PREV_FULL_BACKUP_SET_ID: 86
  PREV_INC_BACKUP_SET_ID: 88
         START_TIMESTAMP: 2024-07-28 04:00:08.738552
           END_TIMESTAMP: 2024-07-28 04:02:11.558965
                  STATUS: SUCCESS
             FILE_STATUS: AVAILABLE
        ELAPSED_SECONDES: 123
         PLUS_ARCHIVELOG: OFF
        START_REPLAY_SCN: 1722059929661726001
START_REPLAY_SCN_DISPLAY: 2024-07-27 13:58:49.661726
         MIN_RESTORE_SCN: 1722110531551671000
 MIN_RESTORE_SCN_DISPLAY: 2024-07-28 04:02:11.551671000
             INPUT_BYTES: 2003711874
            OUTPUT_BYTES: 135626783
       OUTPUT_RATE_BYTES: 1104269.0680
        EXTRA_META_BYTES: 0
            TABLET_COUNT: 5740
     FINISH_TABLET_COUNT: 5740
       MACRO_BLOCK_COUNT: 965
FINISH_MACRO_BLOCK_COUNT: 951
              FILE_COUNT: 0
            META_TURN_ID: 1
            DATA_TURN_ID: 0
                  RESULT: 0
                 COMMENT: 
         ENCRYPTION_MODE: NONE
                  PASSWD: 
       TENANT_COMPATIBLE: 4.2.2.1
       BACKUP_COMPATIBLE: 3
                    PATH: file:///backup/catl_cloudDB_MES/12/tenant_incarnation_1/1008/data
         CLUSTER_VERSION: 4.2.2.1
          CONSISTENT_SCN: 1722110462150823000
           MINOR_TURN_ID: 1
           MAJOR_TURN_ID: 1
*************************** 4. row ***************************
               TENANT_ID: 1008
           BACKUP_SET_ID: 88
                 DEST_ID: 1002
             INCARNATION: 1
             BACKUP_TYPE: INC
 PREV_FULL_BACKUP_SET_ID: 86
  PREV_INC_BACKUP_SET_ID: 87
         START_TIMESTAMP: 2024-07-27 04:00:10.087291
           END_TIMESTAMP: 2024-07-27 04:02:00.048654
                  STATUS: SUCCESS
             FILE_STATUS: AVAILABLE
        ELAPSED_SECONDES: 110
         PLUS_ARCHIVELOG: OFF
        START_REPLAY_SCN: 1721974789094222001
START_REPLAY_SCN_DISPLAY: 2024-07-26 14:19:49.094222
         MIN_RESTORE_SCN: 1722024120041982000
 MIN_RESTORE_SCN_DISPLAY: 2024-07-27 04:02:00.041982000
             INPUT_BYTES: 2012101077
            OUTPUT_BYTES: 141230108
       OUTPUT_RATE_BYTES: 1284361.1988
        EXTRA_META_BYTES: 0
            TABLET_COUNT: 5740
     FINISH_TABLET_COUNT: 5740
       MACRO_BLOCK_COUNT: 966
FINISH_MACRO_BLOCK_COUNT: 955
              FILE_COUNT: 0
            META_TURN_ID: 1
            DATA_TURN_ID: 0
                  RESULT: 0
                 COMMENT: 
         ENCRYPTION_MODE: NONE
                  PASSWD: 
       TENANT_COMPATIBLE: 4.2.2.1
       BACKUP_COMPATIBLE: 3
                    PATH: file:///backup/catl_cloudDB_MES/12/tenant_incarnation_1/1008/data
         CLUSTER_VERSION: 4.2.2.1
          CONSISTENT_SCN: 1722024036910483000
           MINOR_TURN_ID: 1
           MAJOR_TURN_ID: 1
*************************** 5. row ***************************
               TENANT_ID: 1008
           BACKUP_SET_ID: 87
                 DEST_ID: 1002
             INCARNATION: 1
             BACKUP_TYPE: INC
 PREV_FULL_BACKUP_SET_ID: 86
  PREV_INC_BACKUP_SET_ID: 86
         START_TIMESTAMP: 2024-07-26 04:00:08.919533
           END_TIMESTAMP: 2024-07-26 04:01:50.835628
                  STATUS: SUCCESS
             FILE_STATUS: AVAILABLE
        ELAPSED_SECONDES: 102
         PLUS_ARCHIVELOG: OFF
        START_REPLAY_SCN: 1721888834732896003
START_REPLAY_SCN_DISPLAY: 2024-07-25 14:27:14.732896
         MIN_RESTORE_SCN: 1721937710828107000
 MIN_RESTORE_SCN_DISPLAY: 2024-07-26 04:01:50.828107000
             INPUT_BYTES: 2012100991
            OUTPUT_BYTES: 142487577
       OUTPUT_RATE_BYTES: 1398087.0931
        EXTRA_META_BYTES: 0
            TABLET_COUNT: 5740
     FINISH_TABLET_COUNT: 5740
       MACRO_BLOCK_COUNT: 965
FINISH_MACRO_BLOCK_COUNT: 955
              FILE_COUNT: 0
            META_TURN_ID: 1
            DATA_TURN_ID: 0
                  RESULT: 0
                 COMMENT: 
         ENCRYPTION_MODE: NONE
                  PASSWD: 
       TENANT_COMPATIBLE: 4.2.2.1
       BACKUP_COMPATIBLE: 3
                    PATH: file:///backup/catl_cloudDB_MES/12/tenant_incarnation_1/1008/data
         CLUSTER_VERSION: 4.2.2.1
          CONSISTENT_SCN: 1721937633550247000
           MINOR_TURN_ID: 1
           MAJOR_TURN_ID: 1
*************************** 6. row ***************************
               TENANT_ID: 1008
           BACKUP_SET_ID: 86
                 DEST_ID: 1002
             INCARNATION: 1
             BACKUP_TYPE: FULL
 PREV_FULL_BACKUP_SET_ID: 0
  PREV_INC_BACKUP_SET_ID: 0
         START_TIMESTAMP: 2024-07-25 04:00:09.332012
           END_TIMESTAMP: 2024-07-25 04:02:05.703616
                  STATUS: SUCCESS
             FILE_STATUS: AVAILABLE
        ELAPSED_SECONDES: 116
         PLUS_ARCHIVELOG: OFF
        START_REPLAY_SCN: 1721808734620906000
START_REPLAY_SCN_DISPLAY: 2024-07-24 16:12:14.620906
         MIN_RESTORE_SCN: 1721851325696715000
 MIN_RESTORE_SCN_DISPLAY: 2024-07-25 04:02:05.696715000
             INPUT_BYTES: 1959955261
            OUTPUT_BYTES: 132953320
       OUTPUT_RATE_BYTES: 1142489.3654
        EXTRA_META_BYTES: 0
            TABLET_COUNT: 4618
     FINISH_TABLET_COUNT: 4618
       MACRO_BLOCK_COUNT: 931
FINISH_MACRO_BLOCK_COUNT: 931
              FILE_COUNT: 0
            META_TURN_ID: 1
            DATA_TURN_ID: 0
                  RESULT: 0
                 COMMENT: 
         ENCRYPTION_MODE: NONE
                  PASSWD: 
       TENANT_COMPATIBLE: 4.2.2.1
       BACKUP_COMPATIBLE: 3
                    PATH: file:///backup/catl_cloudDB_MES/12/tenant_incarnation_1/1008/data
         CLUSTER_VERSION: 4.2.2.1
          CONSISTENT_SCN: 1721851254656875000
           MINOR_TURN_ID: 1
           MAJOR_TURN_ID: 1
#17

show variables like ‘version_comment’;

帮忙贴一下完整的版本号 文本。

#18

0e78617941ec1577dddbc0f77553bba5
0e78617941ec1577dddbc0f77553bba51011×435 91.5 KB

#19

该问题已经完结。总结如下：

  1. OB 的 nfs 路径尽量保持稳定。
  2. OB 集群的 nfs 备份目录不要轻易改动。改动之前一定要确保日志备份都停止了。
    3.OB 的 nfs 出现故障后第一要做的就是将所有使用该 nfs 备份的 数据备份和日志备份都停掉。特别是日志备份任务里检查（cdb_archivelog_progress ）都停止掉了。
  3. 如果 nfs 挂载路径是 /backup，那么 OB 集群备份路径建议设置为 /backup/obbackup 。这样以后如果想更换目录还可以调整为 /backup/obbackup2 ，又不受此前的备份目录影响。
  4. 如果 nfs 故障加上处理不当导致最后出现老的备份任务记录一直在，这个时候可以重启OB 集群解决。如果集群不能重启，则只有在 OB 社区原厂研发的分析建议下删除一些备份 相关的内部表去处理。不过这个风险也会很大。
  5. 建议一开始部署的时候就做好 备租户。这样即使中途备份出异常修复很困难时，还有个备租户正常运行。那OB的整体风险还是可控的。
  6. 生产不推荐用 4.2.2 版本，用 LTS 版本（4.2.1.x 或将来的 4.2.5.x）。预计 4.2.5 在10月份左右发布。
2 个赞