---
title: 关闭归档后，再次开启归档卡在 BEGINNING 阶段-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 关闭归档后，再次开启归档卡在 BEGINNING 阶段相关的常见问题和使用技巧，帮助您快速解决 关闭归档后，再次开启归档卡在 BEGINNING 阶段的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# 关闭归档后，再次开启归档卡在 BEGINNING 阶段

更新时间：2026-05-12 09:06

适用版本： V2.2.x、V3.1.x、V3.2.x 内容类型：Troubleshoot  

## 问题现象

开启归档卡在 BEGINNING 阶段。

## 关键诊断信息

### 触发条件

停止归档后再开启归档。这个是必要条件，不是充分条件。

### 事前巡检

开启归档之前，执行查询 `select count(1) as cnt from __all_virtual_pg_log_archive_stat;` 检查下是否有上一轮的残留信息。如果查询结果不为 0，则表明遇到了这个问题。需要通过下文中的规避手段规避。

### 事后诊断

1. 执行查询 `select distinct incarnation,log_archive_round from oceanbase.__all_virtual_pg_log_archive_stat;` 结果集有两条记录，两条记录的 `log_archive_round` 相差 1，其中较大的 `log_archive_round` 是当前开启的归档轮次。
 2. 执行查询 `select distinct svr_ip,svr_port from __all_virtual_pg_log_archive_stat where log_archive_round= 步骤 1 中结果中的较小 log_archive_round 值`。获取有问题的 OBServer 列表，登录问题 OBServer 查看 observer.log，会有带有如下关键字的日志内容打印 `log archive start prepare not ready`。

日志示例如下。

![image](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/backup-and-restore/20250213beginning-stage.png)

## 问题原因

当前轮次开启归档后内存中残留有某分区上轮开启归档的任务，导致该 OBServer 上其他分区的归档进度无法推进。残留原因是上轮归档 stop 时候，分区归档任务管理线程有并发的添加该分区的归档任务，在最后插入管理 map 时候做不了原子性保证，导致任务残留。在分区多以及 NFS 访问 RT 高的场景下，该问题出现概率更大。

## 问题的风险及影响

开启归档会卡在 BEGINNING 阶段。

## 影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

## 影响版本

OceanBase 数据库企业版 V2.2.77 GA（oceanbase-2.2.77-20210508211731）及之后版本、V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本。

## 解决方法

关闭归档，归档推进到关闭状态下后查询 `select count(1) as cnt from oceanbase.__all_virtual_pg_log_archive_stat;` 检查下是否有上一轮的残留信息。

- 如果查询结果为 0，表明无残留，继续开启归档即可。
 - 如果查询结果不为 0，则执行查询 `select table_id, partition_id from oceanbase.__all_virtual_pg_log_archive_stat;` 确认有问题的分区，将分区 Leader 切到其他副本上去，预期 `__all_virtual_pg_log_archive_stat` 会清空，之后再开启归档即可。

分区切主语句如下。

```shell
alter system switch replica leader partition_id = '5%0@1101710652467189' server= 'xxx.xxx:2882';

```

很多测试环境用的是单节点的集群，无法通过切主恢复，此时需要重启有问题的 OBServer 节点。

## 规避方式

开启归档之前，执行查询 `select count(1) as cnt from oceanbase.__all_virtual_pg_log_archive_stat;` 检查下是否有上一轮的残留信息。

- 如果查询结果为 0，表明无残留，继续开启归档即可。
 - 如果查询结果不为 0，则执行查询 `select table_id, partition_id from oceanbase.__all_virtual_pg_log_archive_stat;` 确认有问题的分区，将分区 Leader 切到其他副本上去，预期 `__all_virtual_pg_log_archive_stat` 表会被清空，待 `select * from oceanbase.__all_virtual_pg_log_archive_stat;` 查询不到结果之后再开启归档即可。

分区切主语句如下。

```

其中 `5%0@1101710652467189` 中的 5 是 `partition_id`，1101710652467189 是 `table_id`。

上一篇

[OceanBase 数据库 V3.1.2 版本中日志归档停不掉，报错 fetch_log_archive_backup_status_map(ret=-4016 的原因和解决办法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003273829)

下一篇

[OceanBase 数据库使用 NAS 作为备份介质，租户日志归档启动卡 BEGINNING 阶段，日志打印报错 -4009 Disk quota exceeded](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002998409) ![有帮助](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) 咨询热线