【产品名称】oceanbase-CE
【产品版本】v3.1.3
【问题描述】日志备份周期是由log_archive_checkpoint_interval参数配置的，但max_next_time有时会延后较多（大于log_archive_checkpoint_interval配置的值）， 这种情况会有什么原因导致， 有什么排查思路吗？
你好，max_next_time是最大日志备份的logts，是一个具体的时间值，log_archive_checkpoint_interval是日志备份的时间间隔，是一个时间区间值，max_next_time大于log_archive_checkpoint_interval？我没有明白你的问题，能描述具体点吗
举个例子：加入集群开启了日志备份， 最大的日志备份呢logts 是9:50分，设置的 log_archive_checkpoint_interval = 5 分钟， 理论上来说，在9:55分之前会有一次日志备份进行， 也就是max_next_time会更新为9:50 - 9:55之间的一个值，但是有时候在9:50之后很久(>5分钟)没有日志备份，也就是max_next_time一直停留在了9:50
你好。oceanbase数据库每个租户下由许多分区partition组成，日志备份的执行者是每一个分区leader，max_next_time是一个租户级概念，比如说max_next_time=9:50，意味着对外承诺所有分区<=9:50的日志都已经备份出去。max_next_time取的是所有分区日志备份中跑的最慢的那一个，但是更新同时受到一些其他条件的制约。如果max_next_time长时间不更新，通常是由于某些分区异常或者某些机器异常.
- 首先看内部表__all_virtual_pg_backup_log_archive_status表(log_archive_cur_ts表示归档进度)，select * from __all_virtual_pg_backup_log_archive_status order by log_archive_cur_ts limit 10;可以找到最落后分区以及归档进度log_archive_cur_ts
- 当出现某个分区所有副本落后时，在1中表里可以看到该分区全部副本都是落后的，尝试看表__all_virtual_pg_log_archive_stat(max_archived_checkpoint_ts表示归档进度)， select * from __all_virtual_pg_log_archive_stat where table_id = xxx and partition_id = yyy;可以看到实时的归档状态。
- 如果在2中表中能找到该分区，说明在为该分区服务，如果没有找到该分区，继续排查是否有leader，select * from __all_virtual_clog_stat where table_id = xxx and partition_idx = yyy; 通过role列看是否有leader
- 如果有leader但是在2中没有该分区，尝试以svr_ip，svr_port看leader所在机器在__all_virtual_pg_log_archive_stat是否有记录，排查是否是机器问题，导致该机器归档出现问题
- 通过grep ARCHIVE observer.log看是否有报错，判断该机器是否出现问题