OceanBase 备份清理任务卡死之谜-低调大师

OceanBase 备份清理任务卡死之谜

2025-02-07 145

正常情况下，会有一个 OceanBase 备份文件清理任务定期执行。备份文件超过了预设数量，猜测可能是文件清理任务出现问题。

> 作者：何文超，爱可生南区交付服务部 DBA 团队成员。主要负责 MySQL 故障处理，MySQL 高可用架构改造，OceanBase 相关技术支持。爱好足球，羽毛球。 > >爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 > >本文约 1500 字，预计阅读需要 5 分钟。

问题背景

客户 OceanBase 集群的备份策略是每天全备，备份文件最近保留 4 天。经过观察，实际保留的备份文件多大 13 个，导致磁盘空间占用较高。

问题排查

正常情况下，会有一个备份文件清理任务定期执行。备份文件超过了预设数量，猜测可能是文件清理任务出现问题。

1. 备份文件的清理任务

先看一下自动清理时间间隔的计算公式：

自动清理的时间间隔 = min(recovery_window/2, 1d)

故正常每天会发起一次备份文件的清理任务。

> 注意：对于 oceanbase-3.1.2-20211230114204 之前的版本（不含该版本），自动清理的时间间隔为 recovery_window/2。

备份文件的清理任务卡住了！

信息采集时间为 22 日。

发现 19 日发起备份清理任务，22 日还未完成，判断为清理任务卡住了。

MySQL [oceanbase]&gt; select * from __all_tenant_backup_clean_info;
+----------------------------+----------------------------+-----------+--------+----------------------------+----------------------------+-------------+------------------------+--------+------------------+-----------+---------+------------------+--------+---------+
| gmt_create                 | gmt_modified               | tenant_id | job_id | start_time                 | end_time                   | incarnation | type                   | status | parameter        | error_msg | comment | clog_gc_snapshot | result | copy_id |
+----------------------------+----------------------------+-----------+--------+----------------------------+----------------------------+-------------+------------------------+--------+------------------+-----------+---------+------------------+--------+---------+
| 2021-03-19 14:18:50.841475 | 2024-10-19 00:28:50.021733 |         1 |   1187 | 2024-10-19 00:28:49.998736 | 2024-10-19 00:27:09.663132 |           1 | DELETE OBSOLETE BACKUP | DOING  | 1728923329993025 |           |         | 1728845993342237 |      0 |       0 |
| 2024-10-19 00:28:50.030195 | 2024-10-19 00:28:50.030195 |      1001 |   1187 | 2024-10-19 00:28:49.998736 | 2024-10-19 00:27:09.663132 |           1 | DELETE OBSOLETE BACKUP | DOING  | 1728923329993025 |           |         | 1728845993342237 |      0 |       0 |
+----------------------------+----------------------------+-----------+--------+----------------------------+----------------------------+-------------+------------------------+--------+------------------+-----------+---------+------------------+--------+---------+
2 rows in set (0.01 sec)

集群备份清理有关的历史事件信息。

MySQL [oceanbase]&gt; select * from __all_rootservice_event_history where module='backup_clean';
+----------------------------+--------------+------------+-----------+--------+---------------+--------+---------+--------+----------+-------------------------------+-------+--------+-------+--------+------------+----------------+-------------+
| gmt_create                 | module       | event      | name1     | value1 | name2         | value2 | name3   | value3 | name4    | value4                        | name5 | value5 | name6 | value6 | extra_info | rs_svr_ip      | rs_svr_port |
+----------------------------+--------------+------------+-----------+--------+---------------+--------+---------+--------+----------+-------------------------------+-------+--------+-------+--------+------------+----------------+-------------+
| 2024-04-16 18:55:49.799602 | backup_clean | backup_set | tenant_id | 1      | backup_set_id | 1099   | copy_id | 0      | trace_id | YB42B6B49660-0005E8F1C2B2E2CD |       |        |       |        |            | 182.180.150.96 |        2882 |
-----------
输出信息过多,省略部分信息
-----------
| 2024-10-19 00:28:50.010504 | backup_clean | backup_set | tenant_id | 1      | backup_set_id | 1288   | copy_id | 0      | trace_id | YB42B6B49660-0005E8F1C2B2E845 |       |        |       |        |            | 182.180.150.96 |        2882 |
| 2024-10-19 00:28:50.010521 | backup_clean | backup_set | tenant_id | 1      | backup_set_id | 1289   | copy_id | 0      | trace_id | YB42B6B49660-0005E8F1C2B2E845 |       |        |       |        |            | 182.180.150.96 |        2882 |
+----------------------------+--------------+------------+-----------+--------+---------------+--------+---------+--------+----------+-------------------------------+-------+--------+-------+--------+------------+----------------+-------------+
191 rows in set (29.60 sec)

2. 查看日志

2.1 备份清理调度任务失败

[root@hwc-ocp RS_cl_bigdata]# grep "ob_backup_data_clean" rootservice.log.20241022040332 ｜ grep WARN
rootservice.log.20241022040332:[2024-10-22 03:48:55.440734] INFO  [RS] ob_backup_data_clean_scheduler.cpp:71 [101273][788][YB42B6B49660-0005E8CB48709532] [lt=7] [dc=0] backup data scheduler init(arg={type:12, value:1729194535439601, copy_id:0})
rootservice.log.20241022040332:[2024-10-22 03:48:55.445090] WARN  [RS] schedule_sys_tenant_backup_data_clean (ob_backup_data_clean_scheduler.cpp:352) [101273][788][YB42B6B49660-0005E8CB48709532] [lt=6] [dc=0] sys tenant clean info status is not stop, can do scheduler(ret=-9044, clean_info={tenant_id:1, job_id:1187, start_time:1729268929998736, end_time:1729268829663132, incarnation:1, copy_id:0, type:1, status:2, expired_time:1728923329993025, backup_set_id:0, error_msg:"", comment:"", clog_gc_snapshot:1728845993342237, result:0, backup_piece_id:0, backup_round_id:0})
rootservice.log.20241022040332:[2024-10-22 03:48:55.445176] WARN  [RS] schedule_backup_data_clean (ob_backup_data_clean_scheduler.cpp:275) [101273][788][YB42B6B49660-0005E8CB48709532] [lt=12] [dc=0] failed to schedule sys tenant backup(ret=-9044)
rootservice.log.20241022040332:[2024-10-22 03:48:55.445187] WARN  [RS] start_schedule_backup_data_clean (ob_backup_data_clean_scheduler.cpp:89) [101273][788][YB42B6B49660-0005E8CB48709532] [lt=8] [dc=0] failed to schedule backup data clean(ret=-9044, tenant_ids=[1, 1003, 1004])
rootservice.log.20241022040332:[2024-10-22 03:53:55.447033] INFO  [RS] ob_backup_data_clean_scheduler.cpp:71 [101273][788][YB42B6B49660-0005E8CB48709532] [lt=15] [dc=0] backup data scheduler init(arg={type:12, value:1729194835445853, copy_id:0})

判断关键字：sys tenant clean info status is not stop, can do scheduler

查看日志可推断 sys 租户备份清理任务状态不是 stop 的状态，故备份清理调度任务失败。

与上文中 __all_tenant_backup_clean_info 视图表查询结果形成呼应，判定为备份清理任务异常。

清理任务失败原因：上一次的备份清理任务状态一直为 doing。

2.2 无法识别到路径

通过备份清理任务的 trace_id 打印日志发现：频繁报错 4018，无法识别到路径。

[root@hwc-ocp RS_cl_bigdata]# grep "YB42B6B49660-0005E8F1C2B2E845" rootservice.log.20241022001100 |grep WARN
[2024-10-21 23:37:26.194250] WARN  [ARCHIVE] get_file_id_range_ (ob_archive_log_file_store.cpp:501) [101266][774][YB42B6B49660-0005E8F1C2B2E845] [lt=9] [dc=0] failed get_file_range(uri=file:///obbak_bigdata/cl_bigdata_new/cl_bigdata/2/incarnation_1/1003/clog/13/index/1102810163026406/13, ret=-4018, pg_key={tid:1102810163026406, partition_id:13, part_cnt:0})
[2024-10-21 23:37:26.194257] WARN  [ARCHIVE] get_index_file_id_range (ob_archive_log_file_store.cpp:281) [101266][774][YB42B6B49660-0005E8F1C2B2E845] [lt=5] [dc=0] failed to get_index_file_id_range(ret=-4018, pg_key={tid:1102810163026406, partition_id:13, part_cnt:0})
[2024-10-21 23:37:26.194264] WARN  [ARCHIVE] locate_file_by_log_ts_for_clear (ob_archive_log_file_store.cpp:252) [101266][774][YB42B6B49660-0005E8F1C2B2E845] [lt=5] [dc=0] get_index_file_id_range fail(ret=-4018, pg_key={tid:1102810163026406, partition_id:13, part_cnt:0})
[2024-10-21 23:37:26.217948] WARN  [ARCHIVE] get_file_id_range_ (ob_archive_log_file_store.cpp:501) [101266][774][YB42B6B49660-0005E8F1C2B2E845] [lt=8] [dc=0] failed get_file_range(uri=file:///obbak_bigdata/cl_bigdata_new/cl_bigdata/2/incarnation_1/1003/clog/13/index/1102810163026406/216, ret=-4018, pg_key={tid:1102810163026406, partition_id:216, part_cnt:0})

判断关键字：failed get_file_range

2.3 IO 调用异常

继续排查，发现通过该 trace_id 过滤中发现以下日志，该日志证明 IO 调用异常，该情况通常出现于 NFS 侧。

[root@hwc-ocp RS_cl_bigdata]# grep "access storage" rootservice.log.20241022040332 ｜ grep "YB42B6B49660-0005E8F1C2B2E845"
rootservice.log.20241022040332:[2024-10-22 04:02:23.121397] WARN  [STORAGE] print_access_storage_log (ob_storage.cpp:39) [101266][774][YB42B6B49660-0005E8F1C2B2E845] [lt=10] [dc=0] access storage op=list_files uri=file:///obbak_bigdata/cl_bigdata_new/cl_bigdata/2/incarnation_1/1003/clog/13/index/1102810162740407/88 size=0 Byte cost_ts=2129326 us speed=0.00 MB/s
rootservice.log.20241022040332:[2024-10-22 04:02:24.660028] WARN  [STORAGE] print_access_storage_log (ob_storage.cpp:39) [101266][774][YB42B6B49660-0005E8F1C2B2E845] [lt=9] [dc=0] access storage op=list_files uri=file:///obbak_bigdata/cl_bigdata_new/cl_bigdata/2/incarnation_1/1003/clog/13/index/1102810162744871/4 size=0 Byte cost_ts=1537551 us speed=0.00 MB/s
rootservice.log.20241022040332:[2024-10-22 04:02:33.558367] WARN  [STORAGE] print_access_storage_log (ob_storage.cpp:39) [101266][774][YB42B6B49660-0005E8F1C2B2E845] [lt=13] [dc=0] access storage op=storage reader uri=file:///obbak_bigdata/cl_bigdata_new/cl_bigdata/2/incarnation_1/1003/clog/13/index/1102810162738281/141/2 size=144 Byte cost_ts=1243114 us speed=0.00 MB/s
rootservice.log.20241022040332:[2024-10-22 04:02:38.908843] WARN  [STORAGE] print_access_storage_log (ob_storage.cpp:39) [101263][768][YB42B6B49660-0005E8CB48109532] [lt=9] [dc=0] access storage op=get_file_length uri=file:///obbak_bigdata/cl_bigdata_new/cl_bigdata/2/incarnation_1/cluster_clog_backup_info size=0 Byte cost_ts=1176124 us speed=0.00 MB/s

判断关键词：access storage，us speed=0.00 MB/s

3. 检查 NFS

[admin@x-shhp-oceanbase-db-p02:~]$ mount |grep nfs
2.4.8.124:/obbak_bigdata on /obbak_bigdata type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=2.4.8.124,mountvers=3,mountport=2050,mountproto=tcp,local_lock=none,addr=2.4.8.124)

生产环境的 NFS 版本为 3.x，原来 3 版本为 OB 侧非标部署。

结论：生产未严格按官方文档的要求配置 NFS，可能存在很多异常问题，包括备份清理问题。

优化建议

严格按官方文档的要求配置 NFS，修改 NFS 版本为 4.x，备份卡住的问题得到解决。

更多技术文章，请访问：https://opensource.actionsky.com/

关于 SQLE

SQLE 是一款全方位的 SQL 质量管理平台，覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库，为开发和运维提供流程自动化能力，提升上线效率，提高数据质量。

✨ Github：https://github.com/actiontech/sqle

📚 文档：https://actiontech.github.io/sqle-docs/

💻 官网：https://opensource.actionsky.com/sqle/

👥 微信群：请添加小助手加入 ActionOpenSource

🔗 商业支持：https://www.actionsky.com/sqle

微信关注我们

原文链接：https://my.oschina.net/actiontechoss/blog/17518069

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Databend 产品月报（2025年1月）

很高兴为您带来 Databend 2025 年 1 月的最新更新、新功能和改进！我们希望这些增强功能对您有所帮助，并期待您的反馈，祝您新春快乐！本地计算集群现在，您可以使用 SQL 命令管理本地计算集群，从而更轻松地在自托管的 Databend 环境中创建、扩展和提升查询性能。 CREATE WAREHOUSE my_warehouse ( ASSIGN 1 NODES FROM log_node, ASSIGN 2 NODES FROM infra_node ); 要详细了解相关概念和示例，请参阅通过 SQL 管理本地查询计算集群。有关计算集群的相关命令，请参阅计算集群相关命令。全新 Python 驱动：databend-driver 我们推出了适用于 Databend 的全新 Python 驱动 databend-driver，支持同步和异步接口，与 Databend 的交互更加流畅。借助该驱动，您可以更高效地执行 SQL 查询和管理数据操作。教程：使用 databend-driver 集成 Databend Cloud 重要提醒：此前的 Python 驱动 dat...

2025-02-07

142

为什么要保障数据质量？在数据加工链路中，如何确保高质量的数据产出是一个一直需要重点解决的问题。因为一旦数据加工链路中，出现了数据质量问题，轻则数据报表给出不靠谱的业务分析，影响业务决策；重则向用户推送数据错误，严重降低产品用户对产品的信心，甚至失去重要产品客户。根据Gartner的研究报告，“企业每年因低劣的数据质量而蒙受的平均损失高达1290万美元。”（参见Manasi Sakpal于2021年7月14日发布的《如何改进您的数据质量》一文，https://www.gartner.com/cn/information-technology/articles/how-to-improve-your-data-quality-cn）。尤其2022年下半年以来，随着ChatGPT的大规模推广，在全世界范围内掀起了有史以来最大的AI浪潮，高质量的数据诉求变得前所未见的高涨，那句“Garbage in，Garbage out”也变得人尽皆知。数据质量的评价指标那么数据质量应该如何确保呢？中国电子技术标准化研究院与相关部门起草了《GB/T 36344-2018 信息技术数据质量评价指标》。...

2025-02-08

183

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Oracle

Oracle Database，又名Oracle RDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的、适应高吞吐量的数据库方案。

Eclipse

Eclipse 是一个开放源代码的、基于Java的可扩展开发平台。就其本身而言，它只是一个框架和一组服务，用于通过插件组件构建开发环境。幸运的是，Eclipse 附带了一个标准的插件集，包括Java开发工具（Java Development Kit，JDK）。