kingbase数据库报错the database is recovery mode

Kingbase 数据库当前处于介质恢复模式 / 崩溃恢复中，不允许普通 DML、DDL、用户连接操作，只能执行恢复相关指令。

常见触发原因

1. 数据库异常宕机（断电、kill -9、服务器重启、磁盘 IO 故障），启动后自动进入 crash recovery；
2. 手动执行了 START RECOVERY 介质恢复命令，未正常结束；
3. WAL 日志缺失、损坏，自动恢复卡住；
4. 备库节点处于恢复复制状态（standby 常态就是 recovery 模式，正常）。

分场景处理

场景 1：主库，异常宕机后自动崩溃恢复（最常见）

1. 先看数据库日志，确认是否在自动恢复

# 日志路径示例
tail -f /kingbase/data/log/kingbase-*.log

 

出现大量 redo apply、recovering 日志，说明正在自动回放 WAL，耐心等待自动结束，不需要人工干预。

1. 恢复完成标志
    
   日志输出 database system is ready to accept connections，自动退出恢复模式，业务可正常连接。

小提示：数据量大、WAL 日志多时恢复耗时很久，不要反复重启数据库。

场景 2：手动执行恢复命令，卡在恢复模式

① 普通介质恢复退出

连接 ksql（超级用户 system）：

-- 结束恢复，打开数据库
SELECT pg_wal_replay_resume();

 

或者标准恢复结束语句：

END RECOVERY;

② 若提示还有未应用归档 WAL

把缺失的归档日志放到归档目录，重新执行恢复，归档应用完毕再执行 END RECOVERY;。

场景 3：备库（Standby）一直显示 recovery mode【正常现象】

流复制备库常态就是恢复模式，持续同步主库 WAL，不用处理。

 

如需把备库升级成主库：

SELECT pg_promote(true);

 

场景 4：WAL 日志损坏，自动恢复失败

1. 无法正常回放 WAL，只能做不完全恢复（会丢失数据）

START RECOVERY;
-- 基于时间点/事务ID不完全恢复
RECOVER TO TIMESTAMP '2026-06-11 10:00:00';
END RECOVERY;

1. 极端情况：强制跳过损坏 WAL（数据丢失风险极高，生产慎用）
    
   修改 kingbase.conf

recovery_target_action = 'promote'
recovery_target_timeline = 'latest'

 

重启数据库。

快速状态核查 SQL（system 用户）

-- 查看是否处于恢复模式
SELECT pg_is_in_recovery();

-- 查看WAL回放状态（备库/恢复中主库）
SELECT pid, usename, application_name, state, wal_received_location, wal_replay_location FROM pg_stat_replication;

-- 查看恢复进度
SELECT pg_wal_replay_pause(),pg_wal_replay_resume();

• 返回 true：恢复模式；false：正常读写模式。