主题
本文说明一套基于 KingbaseES 原生流复制（streaming replication）的一主一备集群备份方案。方案不依赖 repmgr，也不部署读写分离组件。
集群由一台主库、一台备库和一台独立 repo 节点组成：主库提供读写服务，备库持续接收并回放 WAL，repo 节点负责保存 sys_rman 备份集和归档 WAL。repo 节点不部署数据库实例，也不参与主备选举。
目录布局、sys_backup.conf 的初始化方式以及 sys_rman 的使用方式，均遵循既有文档：Kingbase 物理备份 和 基于 sys_rman 的异机物理备份与恢复。
一、架构与约束
1.1 节点规划
| 节点角色 | IP 地址 | 主机名 | 主要职责 |
|---|---|---|---|
| Kingbase 主库（DB-A） | 172.24.0.158 | master | 提供当前读写服务，生成 WAL，并向备库发送流复制数据。 |
| Kingbase 备库（DB-B） | 172.24.0.159 | slave | 持续接收和回放主库 WAL；主库无法恢复时，可按既定流程提升为新主库。 |
| repo 节点 | 172.24.0.153 | repo | 保存 sys_rman 备份集和归档 WAL，并执行备份、校验及恢复操作。 |
三台服务器应部署相同大版本的 KingbaseES，并使用统一的操作系统用户 kingbase 执行数据库和备份相关操作。
1.2 固定目录规范
为降低部署、备份和恢复过程中的目录差异风险，本文统一采用以下目录结构：
text
/home/application/KingbaseES/
├── V9/Server/ # KingbaseES 安装目录
│ ├── bin/
│ ├── share/
│ └── log/
├── data/ # 数据库数据目录，仅 DB-A 和 DB-B 使用
└── backup/rman/ # sys_rman 仓库目录，仅 repo 节点使用
├── archive/ # 归档 WAL
├── backup/ # 全量、差异和增量备份集
└── sys_rman.conf # 由初始化脚本生成的运行时配置各目录的绝对路径如下：
bash
# KingbaseES 安装目录
/home/application/KingbaseES/V9/Server
# 数据目录
/home/application/KingbaseES/data
# repo 仓库目录
/home/application/KingbaseES/backup/rmansys_backup.conf 的初始模板位于：
bash
/home/application/KingbaseES/V9/Server/share/sys_backup.conf实施时，应将模板复制至以下路径后再进行配置：
bash
/home/application/KingbaseES/V9/Server/bin/sys_backup.confsys_backup.sh 优先读取 bin/sys_backup.conf；仅当该文件不存在时，才读取 share/sys_backup.conf 模板。初始化完成后，脚本会自动生成 sys_rman.conf，不建议直接手工修改该文件。
1.3 数据复制与备份链路
text
streaming replication
DB-A 主库 172.24.0.158 ───────────────────────> DB-B 备库 172.24.0.159
│ │
│ 当前主库执行 archive_command │ 主备切换后成为新主库时，
│ │ 接管后续归档和备份
└───────────── archive-push / backup ───────────────┘
│
▼
repo 172.24.0.153
├── backup/ 物理备份集
└── archive/ 归档 WAL同一时刻，仅当前主库可以向同一 repo stanza 写入归档 WAL 并生成备份链。
备库可以安装 KingbaseES 和 sys_rman 工具，但在正常主备状态下，不应与主库同时向同一 stanza 创建独立备份集或归档 WAL。混合写入不同数据库状态或不同时间线的备份资产，将增加恢复点判定和灾难恢复操作的风险。
因此，上图中 DB-A 和 DB-B 到 repo 的链路表示主库角色切换后的接管关系，而非正常状态下的并行写入关系：
- 正常状态下，DB-A 为主库，DB-A 负责 WAL 归档，repo 以 DB-A 作为当前备份源。
- 主备切换完成后，DB-B 被提升为新主库，由 DB-B 接管 WAL 归档和后续备份。
- 原 DB-A 修复后不得直接恢复为主库，应以新主库 DB-B 为源重建为备库。
1.4 不采用 repmgr / RWC 读写分离集群的范围说明
官方文档中的部分物理备份示例基于读写分离集群的组件化部署。该模式提供选举、节点管理和路由能力，同时需要维护额外的元数据、代理和集群组件。
本文使用原生主从复制，适用于希望维持较少组件、并已具备应用侧连接切换能力或人工切换流程的环境。其主要特征如下：
- 架构组成仅包括主库、备库和独立 repo 节点。
- 数据写入、WAL 流复制和物理备份的责任边界清晰。
- 可与既有单节点和异机
sys_rman备份目录及操作规范保持一致。
本方案不提供 repmgr/RWC 的自动选主和自动故障转移能力，并具有以下运维约束：
- 主库故障后，备库提升、应用连接切换和防脑裂必须按照既定流程执行，或由外部高可用机制负责。
- 复制中断不应直接触发主备切换；应先识别网络、认证、复制延迟、WAL 缺失或时间线分叉等具体原因。
- 主备角色发生切换后，必须确认 repo 的归档与备份源已切换至新的主库。
二、原生主从部署
本节在 DB-A（172.24.0.158）和 DB-B（172.24.0.159）之间建立原生 streaming replication。repo 节点暂不参与本节操作；sys_rman 初始化及 WAL 归档配置将在后续章节实施。
2.1 前置条件
- DB-A 与 DB-B 已安装相同大版本的 KingbaseES，安装目录为
/home/application/KingbaseES/V9/Server。 - 两个数据库节点均使用
kingbase用户运行服务，数据目录均为/home/application/KingbaseES/data。 - DB-A 已完成初始化并能够正常启动；DB-B 的既有数据目录仅用于初始化操作，不保留业务数据。
- DB-A 的
54321端口可被 DB-B 访问；防火墙策略仅放行必要的主备通信。 - 以下示例使用数据库超级用户
system，并假定数据库端口为54321。如实际端口不同，应统一替换。
以下配置仅建立异步流复制。业务对零数据丢失有要求时，应在完成基础部署后，结合业务延迟、网络条件和故障策略评估是否启用同步复制。
2.2 配置主库 DB-A
以下操作在 DB-A（172.24.0.158）以 kingbase 用户执行。
首先编辑主库参数文件 /home/application/KingbaseES/data/kingbase.conf，确认或增加以下参数：
conf
[root@master ~]# su - kingbase
上一次登录： 一 8月 3 15:24:59 CST 2026
[kingbase@master ~]$ vim +999 /home/application/KingbaseES/data/kingbase.conf
# 流复制相关参数
wal_level = replica
max_wal_senders = 10
max_replication_slots = 1各参数说明如下：
| 参数 | 作用 | 本文配置的含义与注意事项 |
|---|---|---|
wal_level | 决定 WAL 中记录的信息级别。流复制要求 WAL 包含足够的复制信息。 | 必须设置为 replica（或更高等级），否则主库不能向物理备库提供流复制。该参数为启动级参数，修改后需要重启数据库。 |
max_wal_senders | 限制主库同时允许的 WAL Sender 进程数量；每个物理备库连接通常占用一个 WAL Sender。 | 设置为 10 可为当前一台备库及后续扩容、基础备份等场景预留连接余量。该值并非越大越好，应结合实际备库数量、并发基础备份任务和系统资源设置。 |
max_replication_slots | 限制主库可创建的复制槽数量。复制槽会记录备库仍需要的最早 WAL 位置，防止主库提前回收所需 WAL。 | 本文设置为 1，仅为后续可能启用的一台物理备库复制槽预留容量。初始部署不创建复制槽；如明确不使用复制槽，该参数可以设为 0。该参数为启动级参数，修改后需要重启数据库。 |
本阶段不手工配置 archive_mode 和 archive_command。后续由 repo 节点的 sys_backup.sh init 统一生成并写入 sys_rman archive-push 归档命令，以避免存在两套 WAL 归档逻辑。
重启主库使参数生效：
bash
[kingbase@master ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl restart \
-D /home/application/KingbaseES/data2.3 创建复制账户并限制访问来源
在 DB-A 上使用 system 用户创建专用复制账户。复制账户不应用于应用业务连接。
sql
CREATE ROLE replica LOGIN REPLICATION ENCRYPTED PASSWORD 'kingbase';确认账户已具备复制属性：
sql
\du replica随后编辑 DB-A 的 /home/application/KingbaseES/data/sys_hba.conf，仅允许 DB-B 使用该账户建立物理复制连接：
conf
# TYPE DATABASE USER ADDRESS METHOD
host replication replica 172.24.0.159/32 scram-sha-256不得使用 0.0.0.0/0 或 trust 作为生产环境的复制访问规则。修改完成后重新加载服务器配置文件：
sql
SELECT sys_reload_conf();2.4 初始化备库 DB-B
以下操作在 DB-B（172.24.0.159）以 kingbase 用户执行。
停止 DB-B 上可能存在的数据库服务：
bash
[root@slave ~]# su - kingbase
上一次登录： 一 8月 3 16:24:59 CST 2026
[kingbase@slave ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl stop \
-D /home/application/KingbaseES/data -m fast首次建立备库前，数据目录必须为空。为保留原初始化目录以便回退或排查，使用移动方式进行备份，不直接删除：
bash
[kingbase@slave ~]$ mv /home/application/KingbaseES/data /home/application/KingbaseES/data.pre-replica-YYYYMMDD
[kingbase@slave ~]$ mkdir -p /home/application/KingbaseES/data
[kingbase@slave ~]$ chmod 700 /home/application/KingbaseES/data将 YYYYMMDD 替换为实际操作日期。确认迁移目录不再需要后，再按照变更流程另行清理。
使用 sys_basebackup 工具初始化备库
sys_basebackup 的任务是从正在运行的主库获取一个数据目录级别的一致性基础副本，并将该副本直接写入 DB-B 的数据目录。结合 -R 参数，工具还会生成 standby.signal 和连接主库所需的恢复配置，使 DB-B 启动后立即以物理备库身份连接 DB-A 并持续接收 WAL。
因此，sys_basebackup 在本方案中的作用是建立或重建复制节点，典型使用场景包括：
- 首次部署一主一备集群时初始化 DB-B；
- 备库数据目录损坏时，从当前主库重新建立备库；
- 备库落后过多且主库已回收其所需 WAL 时，重新初始化备库；
- 主备切换后，将修复完成的旧主库重建为新主库的备库。
以下操作在 DB-B（172.24.0.159）以 kingbase 用户执行。
执行 sys_basebackup，从 DB-A 获取基础副本并自动写入备库恢复配置：
bash
[root@slave ~]# su - kingbase
上一次登录： 一 8月 3 16:42:36 CST 2026 pts/1 上
[root@slave ~]# /home/application/KingbaseES/V9/Server/bin/sys_basebackup \
-h 172.24.0.158 \
-p 54321 \
-U replica \
--password \
-X stream \
-Fp \
--progress \
-D /home/application/KingbaseES/data \
-R- 需要输入replica用户的密码
参数说明如下：
| 参数 | 说明 |
|---|---|
-X stream | 在基础备份过程中通过流复制方式获取所需 WAL。 |
-Fp | 使用普通文件格式写入数据目录。 |
--progress | 输出基础备份进度。 |
-D | 指定备库数据目录。 |
-R | 自动生成 standby.signal 及备库连接主库所需的恢复配置。 |
sys_basebackup 与 sys_rman 的区别
sys_basebackup 和 sys_rman 都会读取数据库物理文件，但其目标、输出位置和恢复能力不同。
| 对比项 | sys_basebackup | sys_rman |
|---|---|---|
| 主要目标 | 初始化或重建物理备库。 | 对数据库集簇执行长期物理备份、归档管理和恢复。 |
| 数据来源 | 当前可用主库。 | 当前指定的备份源及 repo 中已有的备份、归档资产。 |
| 输出位置 | 直接写入备库的 KB_DATA，即 /home/application/KingbaseES/data。 | 写入独立 repo 仓库，即 /home/application/KingbaseES/backup/rman。 |
| 结果 | 可直接启动为备库的数据目录，并持续接收后续 WAL。 | 可管理的全量、差异或增量备份集，以及归档 WAL。 |
| WAL 处理 | -X stream 仅保障本次基础副本自身一致、可作为备库启动。 | 持续保存归档 WAL，并支持基于备份集执行完全恢复和时间点恢复（PITR）。 |
| 典型时机 | 建库、备库重建、主备切换后的旧主回建。 | 日常定时备份、备份校验、误操作恢复、主备双毁或异机灾难恢复。 |
两者在流程上的关系如下：
text
DB-A 主库 ── sys_basebackup ──> DB-B 数据目录
用于初始化/重建备库
当前主库 ── sys_rman + archive-push ──> repo
用于保留备份集与归档 WAL，支持灾难恢复sys_basebackup 不能替代 sys_rman：前者通常只保留当前一次基础副本，不负责备份保留策略、归档 WAL 管理或 PITR。反过来，sys_rman 也不应替代 sys_basebackup 作为日常主从初始化工具；虽然其备份集可用于灾难恢复，但将备库直接以 sys_basebackup 从当前主库建立，能够更直接地形成连续的流复制关系。
执行成功后，应确认以下文件存在：
bash
[kingbase@slave ~]$ ls -l /home/application/KingbaseES/data/standby.signal
[kingbase@slave ~]$ grep -n 'primary_conninfo' /home/application/KingbaseES/data/kingbase.auto.confprimary_conninfo 应指向 172.24.0.158:54321。该文件由工具生成，不应直接编辑。应通过账户密码策略和文件权限控制复制凭据；不得为避免密码问题而将 sys_hba.conf 的认证方式改为 trust。
启动备库：
bash
[kingbase@slave ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl start \
-D /home/application/KingbaseES/data2.5 验证流复制状态
在主库 DB-A 上执行以下 SQL，确认备库已连接：注意是主库
sql
SELECT application_name,
client_addr,
state,
sync_state,
write_lsn,
flush_lsn,
replay_lsn
FROM sys_stat_replication;
application_name | client_addr | state | sync_state | write_lsn | flush_lsn | replay_lsn
------------------+--------------+-----------+------------+-----------+-----------+------------
internal_backup | 172.24.0.159 | streaming | async | 0/8000058 | 0/8000058 | 0/8000058
(1 行记录)预期结果应包含 DB-B（172.24.0.159）的一条记录，且 state 为 streaming。本方案为异步复制时，sync_state 通常显示为 async。
在备库 DB-B 上确认实例处于恢复状态：
sql
test=# SELECT sys_is_in_recovery();
sys_is_in_recovery
--------------------
t
(1 行记录)返回 t 表示当前节点为备库。
最后执行一次最小化的数据同步验证。在主库创建测试表并写入数据：注意是主库
sql
CREATE TABLE public.replication_check (
id integer PRIMARY KEY,
created_at timestamp DEFAULT current_timestamp
);
INSERT INTO public.replication_check (id) VALUES (1);在备库执行只读查询：
sql
SELECT * FROM public.replication_check;
id | created_at
----+---------------------
1 | 2026-08-03 16:51:10
(1 行记录)查询到相同记录，且主库复制状态为 streaming，即表示原生一主一备流复制部署完成。测试表可在确认后按变更规范删除。
本节的 sys_basebackup -R 初始化方式、standby.signal 和 primary_conninfo 的生成行为，下一节将准备独立 repo 节点的运行环境、目录权限和 SSH 连通性。
三、独立 repo 节点准备
本节准备 repo 节点 172.24.0.153 的软件环境、仓库父目录、计划任务权限和 SSH 连通性。repo 节点仅运行 sys_rman 与 sys_backup.sh 等工具，不启动或承载 KingbaseES 数据库实例。
3.1 软件版本与工具检查
DB-A、DB-B 和 repo 节点应安装相同大版本的 KingbaseES。repo 节点无需创建或启动数据库实例，但必须具备与数据库节点匹配的 sys_rman 和 sys_backup.sh 工具。
分别在三个节点执行版本检查：
bash
[kingbase@master ~]$ /home/application/KingbaseES/V9/Server/bin/sys_rman --version
[kingbase@slave ~]$ /home/application/KingbaseES/V9/Server/bin/sys_rman --version
[kingbase@repo ~]$ /home/application/KingbaseES/V9/Server/bin/sys_rman --version
sys_rman (KingbaseES) V009R001C010
[kingbase@repo ~]$ ls -l /home/application/KingbaseES/V9/Server/bin/sys_backup.sh三个节点的 sys_rman 主版本必须保持一致。若版本不一致，应先统一软件版本，再执行备份初始化；不建议用不同版本的工具读写同一 repo 仓库。
repo 节点不应启动数据库实例。若 repo 节点在安装过程中创建过测试实例，应保持该实例停止。本方案的 repo 数据目录不参与主从复制，也不保存业务数据。
3.2 检查备份仓库父目录并确认权限
sys_backup.sh init 会在 _repo_path 下创建 archive/、backup/ 和 sys_rman.conf。因此，本节只创建其父目录 /home/application/KingbaseES/backup，不预先手工创建 rman 子目录及其内部结构。
以下操作在 repo（172.24.0.153）以 root 用户执行。
[kingbase@repo ~]$ su - root
[root@repo ~]# mkdir -p /home/application/KingbaseES/backup
[root@repo ~]# chown kingbase:kingbase /home/application/KingbaseES/backup建议将 /home/application/KingbaseES/backup 挂载在独立磁盘、逻辑卷或网络存储上，而不是与操作系统根分区共用空间。容量至少应满足“保留的全量备份集 + 相应增量或差异备份集 + 归档 WAL + 恢复期间的操作余量”。
使用以下命令确认文件系统容量和挂载位置：
以下操作在 repo（172.24.0.153）以 kingbase 用户执行。
bash
# 再切换至 kingbase 用户执行
[root@repo ~]# su - kingbase
[kingbase@repo ~]$ df -Ph /home/application/KingbaseES/backup
文件系统 容量 已用 可用 已用% 挂载点
/dev/sdb 200G 11G 190G 6% /home/application
[kingbase@repo ~]$ ls -ld /home/application/KingbaseES/backup
drwxr-xr-x 2 kingbase kingbase 6 6月 25 14:44 /home/application/KingbaseES/backup3.3 配置计划任务权限
后续将由 repo 节点上的 kingbase 用户执行 sys_backup.sh start，该脚本会为全量、差异或增量备份创建 crontab 任务。应提前确认该用户具备使用 crontab 的权限。
以下命令在 repo 节点以 root 用户执行：
bash
[kingbase@repo ~]$ su - root
[root@repo ~]# chmod a+x,u+x /usr/bin/crontab
[root@repo ~]# echo 'kingbase' >> /etc/cron.allow随后以 kingbase 用户验证：
bash
[root@repo ~]# su - kingbase
[kingbase@repo ~]$ crontab -l
no crontab for kingbase首次执行时，crontab -l 可能显示 no crontab for kingbase，这表示尚未创建计划任务；若出现权限拒绝信息，则需要先检查 /etc/cron.allow、/etc/cron.deny 及系统的 cron 服务状态。
3.4 SSH 免密认证与访问方向
本架构的 SSH 访问方向如下：
| 发起节点 | 目标节点 | 用途 |
|---|---|---|
| repo | 当前主库 DB-A | repo 执行备份、检查和恢复准备时访问数据库节点。 |
| DB-A | repo | 当前主库执行 archive_command，将 WAL 推送至 repo。 |
| repo | DB-B | 为主备切换后的新主库接管备份做准备。 |
| DB-B | repo | 为主备切换后的新主库推送 WAL 做准备。 |
DB-A 与 DB-B 的流复制使用数据库端口 54321，不依赖 SSH。 备份时，备份节点需要登录主库读取数据；归档 WAL 和故障恢复时，主库需要登录备份节点。因此必须为 kingbase 用户配置双向 SSH 免密。
若各节点的 kingbase 用户尚未生成 SSH 密钥，分别执行以下命令。已存在密钥时不应重复生成或覆盖：
bash
#主库
[kingbase@master ~]$ cd ~
[kingbase@master ~]$ ssh-keygen -t rsa -b 4096
#备库
[kingbase@slave ~]$ cd ~
[kingbase@slave ~]$ ssh-keygen -t rsa -b 4096
#repo节点
[kingbase@repo ~]$ cd ~
[kingbase@repo ~]$ ssh-keygen -t rsa -b 4096按以下方向安装公钥。命令首次执行时会要求输入目标节点 kingbase 用户的密码；完成后，后续连接不应再提示输入密码。
bash
# repo 可访问当前主库和备库
[kingbase@repo ~]$ ssh-copy-id kingbase@172.24.0.158
[kingbase@repo ~]$ ssh-copy-id kingbase@172.24.0.159
# 当前主库和备库均可访问 repo
[kingbase@master ~]$ ssh-copy-id kingbase@172.24.0.153
[kingbase@slave ~]$ ssh-copy-id kingbase@172.24.0.153使用 BatchMode=yes 验证免密登录。该选项禁止 SSH 交互式询问密码，命令返回成功才表示免密认证有效：
bash
[kingbase@repo ~]$ ssh -o BatchMode=yes kingbase@172.24.0.158 'hostname'
[kingbase@repo ~]$ ssh -o BatchMode=yes kingbase@172.24.0.159 'hostname'
[kingbase@master ~]$ ssh -o BatchMode=yes kingbase@172.24.0.153 'hostname'
[kingbase@slave ~]$ ssh -o BatchMode=yes kingbase@172.24.0.153 'hostname'四、初始化 sys_rman、WAL 归档与首次全量备份
本节在 repo 节点初始化 sys_rman。由于本文采用原生一主一备流复制，而非 RWC/repmgr 集群，sys_backup.conf 的 _target_db_style 应设置为 single，并将当前主库 DB-A（172.24.0.158）作为唯一备份源。
single 表示“以一个指定数据库实例作为备份源”，并不表示业务架构为单机。主备发生角色切换后，备份源必须切换至新主库；此项操作将在故障切换章节说明。
4.1 主库启用归档模式并配置数据库免密连接
执行初始化前，DB-A 必须正常运行并启用归档模式。以下操作在 DB-A（当前主库）执行。
编辑主库参数文件：
bash
[kingbase@master ~]$ vim +999 /home/application/KingbaseES/data/kingbase.conf在文件末尾确认以下参数。初始化前将 archive_command 置空；后续由 sys_backup.sh init 自动改写为 sys_rman archive-push 命令：
conf
archive_mode = on
archive_command = ''archive_mode 为启动级参数，修改后重启数据库：
bash
[kingbase@master ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl restart \
-D /home/application/KingbaseES/data为使 repo 节点能够通过备份脚本连接 DB-A，应在 DB-A 的 kingbase 用户主目录生成 system 用户的加密密码文件。将占位符替换为实际密码；密码和 ~/.encpwd 的内容不得提交至代码仓库或记录在共享文档中。
bash
[kingbase@master ~]$ cd ~
[kingbase@master ~]$ sys_encpwd -H \* -P \* -D \* -U system -W kingbase
[kingbase@master ~]$ chmod 600 ~/.encpwd
[kingbase@master ~]$ ls -l ~/.encpwdsys_encpwd 用于保存加密后的命令行数据库登录凭据，避免备份操作交互式输入密码。该文件必须由 DB-A 上的 kingbase 用户创建和持有。
4.2 创建并配置 sys_backup.conf
以下操作均在 repo 节点以 kingbase 用户执行。首次初始化时，将模板复制到 bin 目录：
bash
[kingbase@repo ~]$ cp /home/application/KingbaseES/V9/Server/share/sys_backup.conf \
/home/application/KingbaseES/V9/Server/bin/sys_backup.conf
[kingbase@repo ~]$ vim /home/application/KingbaseES/V9/Server/bin/sys_backup.conf保留模板中未展示参数的默认值，并配置以下内容：
conf
# 原生主从方案以当前主库作为唯一备份源
_target_db_style="single"
# 主库IP地址
_one_db_ip="172.24.0.158"
# 备份节点 IP 地址
_repo_ip="172.24.0.153"
# 备份实例名称（stanza）
_stanza_name="kingbase"
# 执行备份任务的操作系统用户
_os_user_name="kingbase"
# 备份仓库根目录，rman目录会自动生成，确保 kingbase 用户有对/home/application/KingbaseES/backup/目录所有权限
_repo_path="/home/application/KingbaseES/backup/rman"
# 保留的全量备份数量
_repo_retention_full_count=3
# 备份计划：每隔 7 天执行一次全量备份，在凌晨 02:00 执行
_crond_full_days=7
_crond_full_hour=2
# 备份计划：不执行差异备份
_crond_diff_days=0
_crond_diff_hour=3
# 备份计划：每隔 1 天执行一次增量备份，在凌晨 04:00 执行
_crond_incr_days=1
_crond_incr_hour=4
# 限速带宽；0 表示不限速
_band_width=0
# 操作系统命令的绝对路径
_os_ip_cmd="/sbin/ip"
_os_rm_cmd="/bin/rm"
_os_sed_cmd="/bin/sed"
_os_grep_cmd="/bin/grep"
_os_base64_cmd="/bin/base64"
# 是否使用 scmd 远程命令模式；off 表示不使用
_use_scmd=off
# 启动/停止数据库时是否使用快速模式
_start_fast=y
# 备份压缩类型
_compress_type=gz
# 非归档 WAL 预留空间，单位通常为 MB
_non_archived_space=1024
# 是否收集归档统计信息
_archive_statistics=n
# 当前主库部署信息
_single_data_dir="/home/application/KingbaseES/data"
_single_bin_dir="/home/application/KingbaseES/V9/Server/bin"
_single_db_user="system"
_single_db_port="54321"主要参数说明：
| 参数 | 说明 |
|---|---|
_target_db_style="single" | 指定当前主库为唯一备份源，不使用依赖 RWC/repmgr 元数据的 cluster 模式。 |
_one_db_ip | 当前主库 IP。主备切换后必须更新为新主库地址。 |
_repo_ip | 独立 repo 节点 IP，本文固定为 172.24.0.153。 |
_repo_path | sys_rman 仓库根目录。初始化后将在此创建备份、归档和配置文件。 |
_repo_retention_full_count | 保留的全量备份数。设置为 3 时，仍需为关联的增量备份和归档 WAL 预留容量。 |
_compress_type=gz | 使用 gzip 压缩备份集，以 CPU 开销降低网络和存储消耗。 |
_non_archived_space=1024 | 未归档 WAL 的预留空间阈值，单位以当前版本模板说明为准；不能替代归档失败和磁盘空间监控。 |
4.3 执行初始化
初始化将生成 sys_rman.conf、创建 stanza、更新 DB-A 的 archive_command、校验备份环境，并执行首次全量备份。初始化应安排在业务低峰；执行期间不得进行主备切换。
在 repo 节点以 kingbase 用户执行。
bash
[kingbase@repo ~]$ cd /home/application/KingbaseES/V9/Server/bin
[kingbase@repo bin]$ ./sys_backup.sh init成功输出通常包含以下关键阶段：
text
# pre-condition: check the non-archived WAL files
Authorized users only. All activities may be monitored and reported.
Authorized users only. All activities may be monitored and reported.
Authorized users only. All activities may be monitored and reported.
Authorized users only. All activities may be monitored and reported.
# generate single sys_rman.conf...
Authorized users only. All activities may be monitored and reported.
DONE
Authorized users only. All activities may be monitored and reported.
Authorized users only. All activities may be monitored and reported.
# update single archive_command with sys_rman.archive-push...DONE
# create stanza and check...(maybe 60+ seconds)
# create stanza and check...DONE
# initial first full backup...(maybe several minutes)
# initial first full backup...DONE
# Initial sys_rman OK.
'sys_backup.sh start' should be executed when need back-rest feature.4.4 验证初始化结果
在 repo 节点以 kingbase 用户执行。
bash
[kingbase@repo bin]$ ls -l /home/application/KingbaseES/backup/rman
总用量 4
drwxr-x--- 3 kingbase kingbase 22 8月 3 17:38 archive
drwxr-x--- 3 kingbase kingbase 22 8月 3 17:38 backup
-rw-r--r-- 1 kingbase kingbase 1386 8月 3 17:38 sys_rman.confsys_rman.conf 由初始化脚本生成。后续如需修改，应调整 sys_backup.conf 并按流程重新初始化，不建议直接编辑 sys_rman.conf。
注释：
--config 默认指定的配置文件路径在/etc/sys_rman.conf， 我们只需要把sys_rman.conf 软连接到/etc/sys_rman.conf 就无需每次添--config 选项
在 repo 节点以 root 用户执行。
[kingbase@repo ~]$ su - root
#配置软链接
[root@repo ~]# ln -s /home/application/KingbaseES/backup/rman/sys_rman.conf /etc/sys_rman.conf
[root@repo ~]# ls -l /etc/sys_rman.conf
lrwxrwxrwx 1 root root 54 7月 28 00:29 /etc/sys_rman.conf -> /home/application/KingbaseES/backup/rman/sys_rman.conf
#再切换至kingbase用户
[root@repo ~]# su - kingbase
上一次登录： 一 8月 3 17:09:20 CST 2026 pts/0 上[kingbase@repo bin]$ sys_rman \
--config=/home/application/KingbaseES/backup/rman/sys_rman.conf \
--stanza=kingbase check
[kingbase@repo bin]$ sys_rman \
--config=/home/application/KingbaseES/backup/rman/sys_rman.conf \
--stanza=kingbase info
[kingbase@repo bin]$ sys_rman \
--config=/home/application/KingbaseES/backup/rman/sys_rman.conf \
--stanza=kingbase verify
或者：
[kingbase@repo bin]$ sys_rman \
--stanza=kingbase check
[kingbase@repo bin]$ sys_rman \
--stanza=kingbase info
[kingbase@repo bin]$ sys_rman \
--stanza=kingbase verify随后在 DB-A 确认归档已启用，且归档命令已由初始化脚本接管：
在 master 节点以 kingbase 用户执行。
bash
[root@master ~]# su - kingbase
[kingbase@master ~]$ ksql -U system -d test
授权类型: 企业版.
输入 "help" 来获取帮助信息.
test=# SHOW archive_mode;
archive_mode
--------------
on
(1 行记录)
test=# SHOW archive_command;
archive_command
------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------
export TZ=Asia/Shanghai;/home/application/KingbaseES/V9/Server/bin/sys_rman --config /home/application/KingbaseES/backup/rman/sys_rman.conf --s
tanza=kingbase archive-push %p
(1 行记录)archive_command 应包含 sys_rman archive-push，并指向备份节点的仓库配置。若初始化没有自动更新主库配置，先停止处理业务并排查 SSH 免密、主库路径和权限，不要手工猜测或拼接 archive_command。
五、日常备份、保留策略与巡检
完成首次全量备份后，应在 repo 节点启用定时任务，并对备份链、归档 WAL 和仓库容量进行持续检查。本节所有命令均在 repo 节点以 kingbase 用户执行，除非另有说明。
5.1 备份策略
本文使用“每周全量 + 每日增量”的备份策略，不启用差异备份：
| 备份类型 | 配置 | 执行时间 | 用途 |
|---|---|---|---|
| 全量备份（full） | _crond_full_days=7 | 02:00 | 生成完整、独立的恢复基线。 |
| 差异备份（diff） | _crond_diff_days=0 | 不执行 | 本文不启用。 |
| 增量备份（incr） | _crond_incr_days=1 | 04:00 | 仅备份自上一次有效备份以来的变更，降低每日备份窗口与空间消耗。 |
| 归档 WAL | archive_command | 持续执行 | 支持备份间的 WAL 重放、完全恢复和 PITR。 |
该策略的恢复依赖关系如下：
text
最近一次全量备份
└── 后续增量备份链
└── repo 中连续归档 WAL_repo_retention_full_count=3 表示至少保留 3 个全量备份周期及其依赖的备份链。实际所需空间还取决于全量备份大小、每日变更量、WAL 产生速率和恢复窗口，不应仅按数据库当前数据量估算。
_crond_full_days=7最终由sys_backup.sh转换为 cron 表达式，常见形式为*/7的“日”字段。它按日历日执行，并不严格等同于每 168 小时执行一次。生产环境应以crontab -l的实际输出和变更窗口为准。
5.2 启用定时任务
sys_backup.sh init 仅完成环境初始化和首次全量备份，不会自动启用周期任务。执行以下命令创建或更新 kingbase 用户的 crontab：
在 repo 节点以 kingbase 用户执行。
bash
[kingbase@repo ~]$ cd /home/application/KingbaseES/V9/Server/bin
[kingbase@repo bin]$ sys_backup.sh start
Enable some sys_rman in crontab-daemon
no crontab for kingbase
Set full-backup in 7 days
Set incr-backup in 1 days
0 2 */7 * * /home/application/KingbaseES/V9/Server/bin/sys_rman --config=/home/application/KingbaseES/backup/rman/sys_rman.conf --stanza=kingbase --archive-copy --type=full backup >> /home/application/KingbaseES/V9/Server/log/sys_rman_backup_full.log 2>&1
0 4 */1 * * /home/application/KingbaseES/V9/Server/bin/sys_rman --config=/home/application/KingbaseES/backup/rman/sys_rman.conf --stanza=kingbase --archive-copy --type=incr backup >> /home/application/KingbaseES/V9/Server/log/sys_rman_backup_incr.log 2>&1
[kingbase@repo bin]$ crontab -l
0 2 */7 * * /home/application/KingbaseES/V9/Server/bin/sys_rman --config=/home/application/KingbaseES/backup/rman/sys_rman.conf --stanza=kingbase --archive-copy --type=full backup >> /home/application/KingbaseES/V9/Server/log/sys_rman_backup_full.log 2>&1
0 4 */1 * * /home/application/KingbaseES/V9/Server/bin/sys_rman --config=/home/application/KingbaseES/backup/rman/sys_rman.conf --stanza=kingbase --archive-copy --type=incr backup >> /home/application/KingbaseES/V9/Server/log/sys_rman_backup_incr.log 2>&1如果需要临时停止自动备份而不删除历史备份，可执行：
bash
[kingbase@repo bin]$ ./sys_backup.sh pause恢复已暂停的备份任务：
bash
[kingbase@repo bin]$ ./sys_backup.sh unpause如需完全取消由脚本创建的定时任务，可执行：
bash
[kingbase@repo bin]$ ./sys_backup.sh stopstop 仅停止计划任务，不会删除 repo 中已有的备份集和归档 WAL。
5.3 手工执行备份
在首次部署、重大变更前后、主备切换完成后或定时任务异常时，可手工执行备份。手工命令使用显式 --config，避免依赖 /etc/sys_rman.conf 软链接。
执行全量备份：
bash
[kingbase@repo ~]$ /home/application/KingbaseES/V9/Server/bin/sys_rman \
--stanza=kingbase --archive-copy --type=full backup执行差异备份：
bash
[kingbase@repo ~]$ /home/application/KingbaseES/V9/Server/bin/sys_rman \
--stanza=kingbase --archive-copy --type=diff backup执行增量备份：
bash
[kingbase@repo ~]$ /home/application/KingbaseES/V9/Server/bin/sys_rman \
--stanza=kingbase --archive-copy --type=incr backup除非已明确评估恢复窗口和存储空间，否则不建议在计划任务之外频繁穿插差异、增量和全量备份，以免增加备份链管理复杂度。关键变更后的全量备份应在变更验证完成后执行。
5.4 日常检查与备份校验
建议至少每日检查一次备份状态。check 用于检查配置、数据库连接和归档条件；info 用于查看备份集和备份链；verify 用于校验备份集中已存储的文件。
bash
[kingbase@repo ~]$ /home/application/KingbaseES/V9/Server/bin/sys_rman \
--stanza=kingbase check
[kingbase@repo ~]$ /home/application/KingbaseES/V9/Server/bin/sys_rman \
--stanza=kingbase info
[kingbase@repo ~]$ /home/application/KingbaseES/V9/Server/bin/sys_rman \
--stanza=kingbase verify检查 repo 目录空间和备份、归档文件数量：
bash
[kingbase@repo ~]$ df -h /home/application/KingbaseES/backup
[kingbase@repo ~]$ du -sh /home/application/KingbaseES/backup/rman/backup
[kingbase@repo ~]$ du -sh /home/application/KingbaseES/backup/rman/archive
[kingbase@repo ~]$ find /home/application/KingbaseES/backup/rman/archive -type f | wc -l5.5 保留与清理原则
备份集和归档 WAL 的清理应由 sys_rman 的保留策略管理。不得使用 rm -rf 手工删除 backup/ 或 archive/ 下的文件，否则可能破坏增量备份依赖或 PITR 所需的 WAL 链。
调整 _repo_retention_full_count、备份周期或备份时间后，应在 repo 节点重新执行 sys_backup.sh start，使脚本重新生成 crontab；涉及主库地址、数据目录、端口和仓库路径等数据库连接信息变更时，应按后续主备切换流程重新初始化并完整校验。
六、主从不同步处理与备库重建
主从不同步是复制状态异常，不等同于主库故障。当前主库仍可正常对外提供服务时，首要目标是恢复或重建备库。
6.1 复制状态检查
发生复制延迟或中断时，先分别在主库和备库采集状态。
在当前主库 DB-A 执行：
bash
[kingbase@master ~]$ ksql test systemsql
#打开拓展显示
\x
test=# SELECT application_name,
client_addr,
state,
sync_state,
sent_lsn,
write_lsn,
flush_lsn,
replay_lsn,
reply_time
FROM sys_stat_replication;
application_name | client_addr | state | sync_state | sent_lsn | write_lsn | flush_lsn | replay_lsn | reply_time
------------------+--------------+-----------+------------+------------+------------+------------+------------+----------------------------
internal_backup | 172.24.0.159 | streaming | async | 0/1A000058 | 0/1A000058 | 0/1A000058 | 0/1A000058 | 2026-08-03 18:09:58.537909
(1 行记录)在备库 DB-B 执行：
bash
[kingbase@slave ~]$ ksql test systemsql
test=# SELECT sys_is_in_recovery();
-[ RECORD 1 ]------+--
sys_is_in_recovery | t
test=# SELECT status,
sender_host,
sender_port,
received_lsn,
latest_end_lsn
FROM sys_stat_wal_receiver;
-[ RECORD 1 ]--+-------------
status | streaming
sender_host | 172.24.0.158
sender_port | 54321
received_lsn | 0/1A000058
latest_end_lsn | 0/1A000058sys_stat_replication.state = streaming、备库 sys_is_in_recovery() = t，且 sys_stat_wal_receiver.status = streaming 表示物理复制链路正常。如果备库未返回 WAL receiver 记录，通常说明其未连接主库或 WAL receiver 未正常启动。
| 现象 | 常见原因 | 处置原则 |
|---|---|---|
| 主库有备库记录，但 LSN 持续落后 | 备库磁盘 I/O、网络带宽、回放速度或长查询导致延迟 | 不切换；定位性能瓶颈并等待或恢复回放。 |
| 主库无备库记录，备库仍处于恢复状态 | 网络、端口、sys_hba.conf、复制密码或主库服务异常 | 修复连接条件，备库通常会自动重连。 |
备库日志出现 requested WAL segment ... has already been removed | 备库落后过久，主库已回收所需 WAL | 不能继续追平；重新初始化备库。 |
| 备库已被提升或曾对外写入 | 主备时间线分叉 | 不得直接重新接回；使用 sys_rewind 或完整重建。 |
6.2 可自动追平的复制中断
对于短时网络波动、主库短暂重启或备库 WAL receiver 异常，主库仍保留备库所需 WAL 时，无须重建备库。应按以下顺序检查：
- 确认 DB-A 的
54321端口和数据库服务正常。 - 确认 DB-B 到 DB-A 的网络可达，且 DB-A 的
sys_hba.conf仍允许replica用户从172.24.0.159/32建立复制连接。 - 检查 DB-B 的
primary_conninfo是否仍指向172.24.0.158:54321。 - 检查 DB-B 的数据库日志，定位认证失败、连接超时、磁盘满或 WAL receiver 异常。
- 修复故障后观察
sys_stat_replication是否恢复为streaming；不要重复执行sys_basebackup。
检查备库的恢复配置和磁盘空间：
bash
[kingbase@slave ~]$ grep -n 'primary_conninfo' \
/home/application/KingbaseES/data/kingbase.auto.conf
[kingbase@slave ~]$ df -h /home/application/KingbaseES/data如果确认仅 WAL receiver 进程异常，可先重启备库服务；该操作不会修改主库数据：
bash
[kingbase@slave ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl restart \
-D /home/application/KingbaseES/data重启后再次执行第 6.1 节的主库和备库状态检查。只有在日志明确表明所需 WAL 已不可获得时，才进入重建流程。
6.3 所需 WAL 已被回收时重建备库
当备库日志出现以下特征错误时，表示备库无法从当前位点继续接收 WAL：
text
requested WAL segment <WAL文件名> has already been removed此时不能通过反复重启备库、手工复制单个 WAL 文件或修改 wal_keep_segments 来修复已经断裂的复制链。正确处理方式是以当前主库为源重新初始化备库。
重建前应确认 DB-A 仍为唯一主库且服务健康：
bash
[kingbase@master ~]$ ksql test systemsql
test=# SELECT sys_is_in_recovery();返回 f 表示 DB-A 是主库。随后在 DB-B 停止实例，并保留旧数据目录用于问题取证：
bash
[kingbase@slave ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl stop \
-D /home/application/KingbaseES/data -m fast
[kingbase@slave ~]$ mv /home/application/KingbaseES/data \
/home/application/KingbaseES/data.wal-missing-YYYYMMDD
[kingbase@slave ~]$ mkdir -p /home/application/KingbaseES/data
[kingbase@slave ~]$ chmod 700 /home/application/KingbaseES/data将 YYYYMMDD 替换为实际日期。确认取证完成前，不应删除旧目录。
使用 sys_basebackup 从当前主库 DB-A 重新初始化 DB-B：
bash
[kingbase@slave ~]$ /home/application/KingbaseES/V9/Server/bin/sys_basebackup \
-h 172.24.0.158 -p 54321 -U replica --password \
-X stream -Fp --progress \
-D /home/application/KingbaseES/data -R
[kingbase@slave ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl start \
-D /home/application/KingbaseES/data启动后，以第 6.1 节的 SQL 确认主库状态为 streaming、备库处于恢复状态。备库重建只影响 DB-B 的本地数据目录，不会中断 DB-A 的业务。
七、主库故障、备库提升与 REPO 接管
本方案不使用 repmgr、RWC 或自动选主组件。因此，主库故障后的切换由人工流程或外部高可用机制发起。以下流程以“DB-A（172.24.0.158）故障，DB-B（172.24.0.159）提升为新主库”为例。
提升备库前必须先完成旧主库隔离（fencing）。在网络分区场景中，如果 DB-A 仍在接受写入，同时将 DB-B 提升为主库，将产生脑裂和不可自动合并的数据分叉。无法确认 DB-A 已停止写入时，不得执行提升。
7.1 故障判定与旧主隔离
首先从应用、主机和数据库三个层面确认 DB-A 故障。DB-B 仍处于备库状态时，可执行只读检查：
在 slave 节点以 kingbase 用户执行。
bash
[kingbase@slave ~]$ ksql test systemsql
test=# SELECT sys_is_in_recovery();返回 t 表示 DB-B 尚未提升。
在提升 DB-B 前，应完成以下隔离动作：
- 停止或隔离应用到 DB-A 的写入流量。
- 若 DB-A 仍可登录，停止其数据库服务。
- 若 DB-A 无法登录但主机仍可能运行，通过防火墙、交换机、云安全组、虚拟化平台或断网操作隔离 DB-A，确保其不能再访问应用和 DB-B。
- 记录故障发生时间、最后确认的复制状态和当前 REPO 备份状态。
若能够登录旧主库 DB-A，执行以下停止命令：
在 master 节点以 kingbase 用户执行。
bash
[kingbase@master ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl stop \
-D /home/application/KingbaseES/data -m fastsys_ctl status 应显示实例已停止；但仅停止数据库并不能代替网络隔离。在网络抖动或操作无法确认执行结果时，仍需使用基础设施层面的 fencing。
7.2 提升 DB-B 为新主库
确认旧主已隔离后，在 DB-B 执行提升：
在 slave 节点以 kingbase 用户执行。
bash
[kingbase@slave ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl promote \
-D /home/application/KingbaseES/datasys_ctl promote 用于使备库退出恢复模式并开始读写。等待命令完成后，验证 DB-B 已成为主库：
bash
[kingbase@slave ~]$ ksql test systemsql
test=# SELECT sys_is_in_recovery();返回 f 表示 DB-B 已完成提升。此时还应确认新主库可以写入：
sql
#创建一个新表
test=# CREATE TABLE public.failover_check (
id integer PRIMARY KEY,
created_at timestamp DEFAULT current_timestamp);
#插入数据
test=# INSERT INTO public.failover_check (id) VALUES (1);
#查询表里的数据
test=# SELECT * FROM public.failover_check;
id | created_at
----+---------------------
1 | 2026-08-04 09:26:13
(1 行记录)验证通过后，按照应用既有的连接切换方案，将应用写入流量切换至 DB-B。由于本文不部署 VIP 或读写分离代理，应用侧切换地址、DNS、负载均衡或连接池配置属于外部流程；完成切换前，不应恢复应用写入。
7.3 暂停原备份计划并准备新主库
主备角色切换期间，应先在 REPO 节点暂停定时备份任务，避免计划任务仍按旧主库地址发起备份：
在 repo 节点以 kingbase 用户执行。
bash
[kingbase@repo ~]$ cd /home/application/KingbaseES/V9/Server/bin
[kingbase@repo bin]$ ./sys_backup.sh pauseDB-B 现在是新主库。由于 ~/.encpwd 属于操作系统用户的本地文件，DB-A 上的凭据文件不会自动复制到 DB-B。应在 DB-B 的 kingbase 用户主目录重新生成 system 用户的加密密码文件：
bash
[kingbase@slave ~]$ cd ~
[kingbase@slave ~]$ sys_encpwd -H \* -P \* -D \* -U system -W kingbase
[kingbase@slave ~]$ chmod 600 ~/.encpwd
[kingbase@slave ~]$ ls -l ~/.encpwd同时确认新主库已具备到 REPO 的 SSH 免密连接；该连接应已在第 3 节预先配置：
bash
[kingbase@slave ~]$ ssh -o BatchMode=yes kingbase@172.24.0.153 'hostname'7.4 将 REPO 备份源切换至新主库
编辑 sys_backup.conf，将 _one_db_ip 从旧主库 DB-A 更新为新主库 DB-B：
在 repo 节点以 kingbase 用户执行。
bash
[kingbase@repo bin]$ vim /home/application/KingbaseES/V9/Server/bin/sys_backup.conf修改后的关键配置如下：
conf
_one_db_ip="172.24.0.159"当前主库地址已经改变，必须重新执行初始化，而不是仅执行 sys_backup.sh start：
bash
[kingbase@repo bin]$ ./sys_backup.sh init直接初始化，会提示报错： ERROR: Configured repo-path [/home/application/KingbaseES/backup/rman] already exists
需要现删除原来的备份数据
[kingbase@repo bin]$ rm -rf /home/application/KingbaseES/backup/rman重新初始化将为新主库生成或更新 sys_rman.conf，将 DB-B 的 archive_command 更新为 sys_rman archive-push，完成环境检查，并创建新的首次全量备份。初始化成功后恢复计划任务：
bash
[kingbase@repo bin]$ ./sys_backup.sh start
[kingbase@repo bin]$ crontab -l7.5 验证新主库的归档和备份链
在 REPO 节点检查新备份链：
bash
[kingbase@repo bin]$ ./sys_rman \
--config=/home/application/KingbaseES/backup/rman/sys_rman.conf \
--stanza=kingbase check
[kingbase@repo bin]$ ./sys_rman \
--config=/home/application/KingbaseES/backup/rman/sys_rman.conf \
--stanza=kingbase info
[kingbase@repo bin]$ ./sys_rman \
--config=/home/application/KingbaseES/backup/rman/sys_rman.conf \
--stanza=kingbase verify在新主库 DB-B 确认归档参数：
bash
[kingbase@slave ~]$ ksql test systemsql
test=# SHOW archive_mode;
test=# SHOW archive_command;
test=# SELECT sys_switch_wal();至此，DB-B 已成为新的业务主库和备份源，REPO 已接管新时间线的归档 WAL 与后续备份。
八、回建故障修复后的旧主库 DB-A
本节对应以下实际场景：
- 原主库 DB-A：
172.24.0.158，发生故障后已完成操作系统、磁盘或硬件修复； - 原备库 DB-B：
172.24.0.159，已在故障期间提升为当前主库，并已接管业务写入、WAL 归档和 REPO 备份； - 目标：从当前主库 DB-B 获取一份完整的、一致的数据副本到 DB-A，使 DB-A 重新加入集群。
这里的“回建旧主库”是指恢复 DB-A 这台原主库服务器，并使其重新成为 DB-B 的备库。DB-A 不能直接以主库身份启动，否则会与 DB-B 构成双主并导致脑裂。
若业务最终要求将
172.24.0.158再次切回主库，应在 DB-A 已追平且 DB-B 保持健康后，另行执行一次计划内角色切换。本节不执行该操作。
8.1 回建前检查
首先确认 DB-B 是唯一可写主库。以下操作在 DB-B 执行：
bash
[kingbase@slave ~]$ ksql test systemsql
test=# SELECT sys_is_in_recovery();返回 f 表示 DB-B 当前为主库。
DB-A 必须已完成硬件和操作系统修复，并满足以下条件：
- 已安装与 DB-B 相同大版本的 KingbaseES；
- 安装目录为
/home/application/KingbaseES/V9/Server； - 数据目录为
/home/application/KingbaseES/data； - 操作系统用户为
kingbase； - DB-A 可以访问 DB-B 的
54321端口； - DB-A 上原数据库实例已经停止。
在 DB-A 确认旧实例未运行：
bash
[kingbase@master ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl status \
-D /home/application/KingbaseES/data如实例仍在运行，先停止。不能在运行中的数据目录上执行 sys_basebackup：
bash
[kingbase@master ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl stop \
-D /home/application/KingbaseES/data -m fast8.2 允许 DB-A 连接新的主库 DB-B
DB-A 回建为备库后，将从 172.24.0.158 连接 DB-B。因此必须在新的主库 DB-B 上增加复制访问规则。以下操作在 DB-B 执行：
bash
[kingbase@slave ~]$ vim /home/application/KingbaseES/data/sys_hba.conf增加或确认以下规则：
conf
# TYPE DATABASE USER ADDRESS METHOD
host replication replica 172.24.0.158/32 scram-sha-256重新加载 DB-B 配置：
bash
[kingbase@slave ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl reload \
-D /home/application/KingbaseES/data此处必须使用 DB-A 的 IP 地址 172.24.0.158。原集群中 DB-A 是主库时，sys_hba.conf 中允许的是 DB-B（172.24.0.159）连接；主备角色切换后，复制连接方向已经反转，访问规则也必须同步调整。
8.3 隔离 DB-A 原数据目录
DB-A 故障前的数据目录属于旧时间线，不能继续使用。为便于问题取证和回退分析，使用移动方式隔离旧目录，而非直接删除。
以下操作在 DB-A 执行：
bash
[kingbase@master ~]$ mv /home/application/KingbaseES/data \
/home/application/KingbaseES/data.before-rebuild-YYYYMMDD
[kingbase@master ~]$ mkdir -p /home/application/KingbaseES/data
[kingbase@master ~]$ chmod 700 /home/application/KingbaseES/data将 YYYYMMDD 替换为实际回建日期。确认 DB-A 原数据目录没有用于取证的价值后，才可根据变更流程清理。
8.4 从 DB-B 完整初始化 DB-A
在 DB-A 使用 sys_basebackup 从当前主库 DB-B 获取一份完整的一致性基础副本，并通过 -R 自动生成 standby.signal 和 primary_conninfo。
以下操作在 DB-A 执行：
bash
[kingbase@master ~]$ /home/application/KingbaseES/V9/Server/bin/sys_basebackup \
-h 172.24.0.159 \
-p 54321 \
-U replica \
--password \
-X stream \
-Fp \
--progress \
-D /home/application/KingbaseES/data \
-R命令完成后，确认 DB-A 已生成备库配置，且上游地址为 DB-B：
bash
[kingbase@master ~]$ ls -l /home/application/KingbaseES/data/standby.signal
[kingbase@master ~]$ grep -n 'primary_conninfo' \
/home/application/KingbaseES/data/kingbase.auto.conf输出中的 primary_conninfo 应包含 host=172.24.0.159 和 port=54321。如不一致，应停止排查复制账户、sys_hba.conf 和 sys_basebackup 的执行参数，不应启动 DB-A 后再手工修正旧时间线数据。
8.5 启动 DB-A 并验证复制恢复
在 DB-A 启动数据库：
bash
[kingbase@master ~]$ /home/application/KingbaseES/V9/Server/bin/sys_ctl start \
-D /home/application/KingbaseES/data在 DB-A 确认其已作为备库进入恢复模式：
bash
[kingbase@master ~]$ ksql test systemsql
test=# SELECT sys_is_in_recovery();返回 t 表示 DB-A 已经作为备库运行。
随后在 DB-B 确认 DB-A 已建立流复制连接：
在 DB-B 节点以 kingbase 用户执行。
bash
[kingbase@slave ~]$ ksql test systemsql
test=# SELECT application_name,
client_addr,
state,
sync_state,
write_lsn,
flush_lsn,
replay_lsn
FROM sys_stat_replication;预期结果中应出现 client_addr = 172.24.0.158 的记录，且 state 为 streaming。至此，DB-A 已从 DB-B 获得完整数据副本，并重新加入为备库。
九、参考文献
[1] 中电科金仓（北京）科技股份有限公司. sys_rman 物理备份与恢复[EB/OL]. [2026-08-04]. https://docs.kingbase.com.cn/cn/KES-V9R1C10/availability/backup/backup-restore/physical-backup/sys_rman/sys_rman-6.
[2] srebro. 一、Kingbase 物理备份[EB/OL]. [2026-08-04]. https://opforge.srebro.cn/database/kingbase/07.html.
[3] srebro. KingbaseES运维实践（二）：基于 sys_rman 的异机物理备份与恢复[EB/OL]. [2026-08-04]. https://opforge.srebro.cn/database/kingbase/08.html.
[4] slnngk. kingbase部署主从（原始主从，非读写分离集群）[EB/OL]. (2024-02-29)[2026-08-04]. https://www.cnblogs.com/hxlasky/p/18042931.