ob_archive_clog_split_engine.cpp

OceanBase 技术问题
#1

生产环境 ,3.1.4-OceanBase CE
线上应用大批量写入数据后，clog盘压力100%，要求业务停止写入后，服务器写入降为0，但读还是非常高，多持续了2个小时.
通过perf抓取，确认当时是 [ARCHIVE] ob_archive_clog_split_engine.cpp:497 耗时高

observer.log:[2023-07-17 18:54:28.334946] INFO [ARCHIVE] ob_archive_clog_split_engine.cpp:497 [74736][2623][Y0-0000000000000000] [lt=12] [dc=0] just skip the checkpoint task(clog_task={epoch_id:1689577757000000, need_update_log_ts:false, round_start_log_id:846964, round_start_ts:-1, checkpoint_ts:1689591261928192, log_submit_ts:1689591265329782, clog_epoch_id:-1, accum_checksum:0, processed_log_count:0, incarnation:1, log_archive_round:1, task_type:2, compressor_type:1, pg_key:{tid:1100611139453793, partition_id:235, part_cnt:0}, clog_pos_list:[]}, last_split_log_id=838559, last_split_log_submit_ts=1689586659537437, last_split_checkpoint_ts=1689586647281591, ret=0)
代码位置:

image
image948×504 31 KB

问题：
1、archive模块 ob_archive_clog_split_engine.cpp,从原理上当时不知在做什么呢？
2、clog回收，或者重放不知是否有详细的资料分享

#3

你好！你的环境应该是开启了备份恢复，导入压力很大的时候，日志归档会落后，等导入压力停了之后，日志归档还是需要继续(将导入产生的clog都备份出去)，日志归档本身会读clog盘，所以在导入压力停止之后，读压力还是很大。需要确认停压力后读clog盘持续两个小时是否符合预期，导入是否真的产生了这么多的clog(导入产生的clog文件总数*64M)，有可能和读clog使用的line cache的命中率低导致重复读同一份数据有关系，可以在日志中搜索"[LINE_CACHE] STAT"查看cache命中率。
此外，在导入场景下开启备份恢复是不是也没有太大的意义？可以考虑在导数期间关闭备份恢复。导入完成后再开启。

问题回答：

  1. ob_archive_clog_split_engine.cpp是负责读取clog，生成分区级别归档任务的模块。
    2 . https://www.oceanbase.com/docs/common-oceanbase-database-cn-10000000001699393 这个文档中有日志回放小结，可以参考，
#4

非常感谢，1.5TB的clog，确认是clog归档引起的

#5

客气了，欢迎交流 :grinning: