背景

数据库集群完成主备切换后，运维人员还要检查同步组件、网络策略和日志连续性。

某日，客户生产系统发生了一次 KFS 数据同步中断。数据库集群完成了主备切换，但 R3 版本 KFS 没有随新主库恢复同步。

客户调整网络策略后，R3 版本 KFS 仍未接管。运维人员从归档节点补齐 WAL 日志后，事务号恢复推进。

从发现异常到完成处置和状态确认，整个过程约 3 小时 35 分钟。运维团队核对后确认终端业务运行正常、数据完整。团队将结合本次记录，优化 WAL 容量管理、网络配置和恢复流程。

故障现场：进程还在，事务号却不动了

17:25 左右，运维人员发现 R3 版本 KFS 的同步序列号，即事务号，长时间没有变化，数据同步疑似中断。

17:35 左右，运维人员再次检查，事务号仍未推进，随即开始排查 KFS 日志和数据库状态。

事件影响 R3 版本 KFS 数据同步链路。故障期间数据同步暂停并产生延迟，终端业务保持运行；事后核对未发现数据丢失或经济损失。

当时的系统关系

故障发生时，R2、R3 两个版本的 KFS 正处于并行双跑阶段，同时解析源库数据。

                         ┌──> R2 版本 KFS（192.168.56.15）
数据库主备集群（源库）───┤
                         └──> R3 版本 KFS（192.168.56.16）
原主库：192.168.56.13
切换后新主库：192.168.56.12
归档 WAL 所在节点：192.168.56.13

项目组通过 R2、R3 并行运行验证新版本。这种部署增加了源库解析负载，也提高了 WAL 保留和故障恢复的复杂度。

故障链路

运维记录还原出以下链路：

R2 版本 KFS（192.168.56.15）解析大事务卡顿
        ↓
源库 WAL 持续堆积
        ↓
数据库节点磁盘写满
        ↓
集群自动完成主备切换
        ↓
R3 KFS 无法访问新主库 192.168.56.12
        ↓
同步中断，所需 WAL 逐步转入 192.168.56.13 的归档目录
        ↓
自动补取持续失败
        ↓
网络放通后仍无法立即恢复
        ↓
手工将归档 WAL 复制到 192.168.56.16
        ↓
日志回放恢复，事务号继续推进

团队将原因分为起始因素、链路中断原因和恢复耗时因素。

1. 起始因素：R2 解析卡顿导致 WAL 堆积

R2 版本 KFS（192.168.56.15）解析大事务时出现卡顿。源库继续产生 WAL，消费位置没有推进，WAL 随之堆积。

WAL 占满磁盘后，数据库集群触发主备切换，数据库节点面临存储风险。

2. 链路中断原因：网络策略没有覆盖新主库

磁盘写满后，数据库集群自动完成主备切换，新主库变为 192.168.56.12。

集群完成切换后，R3 版本 KFS 到 192.168.56.12 的网络端口尚未放通。KFS 无法连接新主库，数据同步中断。

高可用组件负责数据库节点的角色切换，外围组件仍依赖既有网络策略。本次网络策略只包含原主库，未覆盖候选主库。

3. 恢复耗时因素：所需 WAL 已经进入归档

客户放通 192.168.56.12 的网络端口后，R3 版本 KFS 已经可以连接新主库，但事务号仍未继续推进。

运维人员检查日志后发现，KFS 恢复所需的 WAL 已从在线目录转入 192.168.56.13 节点的归档目录。

R3 版本 KFS 原计划自动补取这些日志。网络中断期间，自动复制持续失败；网络恢复后，历史 WAL 缺口仍需补齐。

运维人员在 192.168.56.13 上定位缺失的归档 WAL，再手工复制到 R3 版本 KFS 服务器 192.168.56.16。

日志定位和文件传输占用了本次恢复过程中的主要时间。

处置时间线

时间	现场情况	处置结果
17:25 左右	R3 版本 KFS 事务号长时间不变	判断数据同步疑似中断
17:35 左右	事务号仍未推进	开始检查 KFS 日志和数据库状态
随后	数据库已切换到 192.168.56.12，KFS 到新主库网络不通	定位到切机后的网络策略问题
网络放通后	KFS 可以连接新主库，但仍未恢复同步	转向排查 WAL 连续性
WAL 排查	所需 WAL 已归档到 192.168.56.13，自动补取失败	确认需要人工补齐归档日志
手工恢复	将归档 WAL 复制到 192.168.56.16	KFS 恢复回放和接管，事务号继续推进
21:00 左右	故障节点恢复，主库回切至 192.168.56.13	数据同步追平，故障处理完毕

现场排查与维护命令

本节命令来自 KingbaseES V9R1C10 和 Kingbase FlySync 官方手册。

电科金仓在 KingbaseES 文档中列出了 sys_ctl、 sys_isready、 ksql 等运维工具，以及 sys_stat_replication、 sys_stat_archiver、 sys_replication_slots 等系统视图。

KFS 管理手册列出了 replicator status、 kufl list、 fsrepctl status 等同步状态检查命令。

KFS 在线手册当前标识为 V2R2。现场 R2、R3 发布包的命令参数可能存在差异，执行前应先核对对应安装包手册和命令帮助。

执行提示：操作人员必须将安装目录、数据目录、端口、数据库名、账号、KFS 服务名和归档目录替换为现场值。数据库密码不得写入命令行或故障报告。

1. 设置现场变量

操作人员可先设置变量，减少输入错误。该步骤不修改数据库。

export KB_BIN='<KES安装目录>/Server/bin'export KB_DATA='<KingbaseES实际data目录>'export ARCHIVE_DIR='<192.168.56.13实际归档目录>'export DB_NODE_NEW='192.168.56.12'export DB_NODE_OLD='192.168.56.13'export KFS_NODE='192.168.56.16'export DB_PORT='<实际监听端口>'export DB_NAME='<实际数据库名>'export DB_USER='<只读运维账号>'export KFS_BIN='<KFS安装目录>/flysync/flysync-replicator/bin'export KFS_SERVICE='<R3实际服务名>'

执行人员应逐项回显并复核，重点检查 KB_DATA、 ARCHIVE_DIR 和 KFS_SERVICE。

printf '%s\n' \  "$KB_BIN" "$KB_DATA" "$ARCHIVE_DIR" \  "$DB_NODE_NEW" "$DB_NODE_OLD" "$KFS_NODE" \  "$DB_PORT" "$DB_NAME" "$DB_USER" \  "$KFS_BIN" "$KFS_SERVICE"

2. 只读检查：记录时间、主机和磁盘状态

操作人员先记录现场时间和执行节点，再检查文件系统容量与 inode。inode 耗尽同样会造成写入失败。

date -Ins
hostname -f
df -hT "$KB_DATA" "$ARCHIVE_DIR"df -ih "$KB_DATA" "$ARCHIVE_DIR"du -xsh "$KB_DATA/sys_wal"du -xsh "$ARCHIVE_DIR"

操作人员可用下列命令定位占用最大的一级目录：

du -x --max-depth=1 "$KB_DATA" \
  | sort -n \
  | tail -20

大目录扫描会产生额外 I/O。业务高峰期，操作人员应先评估目录规模并限定扫描范围。

3. 只读检查：确认 KingbaseES 实例是否运行

sys_ctl status 检查指定数据目录对应的实例状态。

"$KB_BIN/sys_ctl" status -D "$KB_DATA"

该命令只报告本机实例进程状态。操作人员还需检查集群角色、复制延迟和业务连通性。

4. 只读检查：从 KFS 节点验证两个数据库节点

运维人员应在 192.168.56.16 上分别检查 192.168.56.12 和 192.168.56.13。

"$KB_BIN/sys_isready" \
  -h "$DB_NODE_NEW" -p "$DB_PORT" \
  -d "$DB_NAME" -U "$DB_USER""$KB_BIN/sys_isready" \
  -h "$DB_NODE_OLD" -p "$DB_PORT" \
  -d "$DB_NAME" -U "$DB_USER"

sys_isready 的结果用于判断数据库是否接受连接。运维人员还要使用只读账号完成一次 SQL 登录：

"$KB_BIN/ksql" \
  -h "$DB_NODE_NEW" \
  -p "$DB_PORT" \
  -U "$DB_USER" \
  -d "$DB_NAME" \
  -c "SELECT now() AS check_time;"

现场缺少 sys_isready 时，可使用操作系统命令检查 TCP 端口。运维人员仍需单独验证数据库认证和 SQL 执行。

nc -vz -w 3 "$DB_NODE_NEW" "$DB_PORT"nc -vz -w 3 "$DB_NODE_OLD" "$DB_PORT"

5. 验证类 SQL：确认主备角色

以下 SQL 不修改数据。 sys_is_in_recovery() 返回 false 时，当前节点通常为主库；返回 true 时，当前节点通常为备库。

SELECT now() AS check_time,
       sys_is_in_recovery() AS is_standby;

DBA 应在 192.168.56.12、192.168.56.13 分别执行并保存结果。集群应保持一个可写主库。

6. 验证类 SQL：检查流复制状态与延迟

在当前主库查询 sys_stat_replication：

SELECT pid,
       application_name,
       client_addr,
       state,
       sent_lsn,
       write_lsn,
       flush_lsn,
       replay_lsn,
       sync_stateFROM sys_stat_replicationORDER BY client_addr;

DBA 可用以下 SQL 量化备库回放差值：

SELECT application_name,
       client_addr,
       state,
       sync_state,
       sys_wal_lsn_diff(
         sys_current_wal_flush_lsn(),
         replay_lsn
       ) AS replay_lag_bytesFROM sys_stat_replicationORDER BY client_addr;

state = 'streaming' 表示复制连接存在。DBA 还要检查 replay_lag_bytes、LSN 推进情况和业务数据。

7. 验证类 SQL：检查归档状态

先查看 WAL 与归档配置：

SHOW wal_level;SHOW archive_mode;SHOW archive_command;SHOW archive_timeout;

再查询归档统计：

SELECT archived_count,
       last_archived_wal,
       last_archived_time,
       failed_count,
       last_failed_wal,
       last_failed_time,
       stats_resetFROM sys_stat_archiver;

DBA 应观察 failed_count 的变化、 last_archived_wal 的推进情况和 last_archived_time。

操作人员可在操作系统侧检查等待归档的 WAL 标记：

find "$KB_DATA/sys_wal/archive_status" \
  -maxdepth 1 \
  -type f \
  -name '*.ready' \
  -print \
  | head -100

.ready 文件持续增加时，DBA 需要检查归档进程。未经确认，不得删除 sys_wal、归档目录或 archive_status 中的文件。

8. 验证类 SQL：检查复制槽是否保留大量 WAL

sys_replication_slots 显示数据库集簇中的复制槽及其状态。

SELECT slot_name,       plugin,
       slot_type,
       active,
       active_pid,
       restart_lsn,
       confirmed_flush_lsn,
       xmin,
       catalog_xminFROM sys_replication_slotsORDER BY slot_name;

以下 SQL 估算每个槽位保留的 WAL：

SELECT slot_name,
       active,
       restart_lsn,
       confirmed_flush_lsn,       CASE
         WHEN restart_lsn IS NULL THEN NULL
         ELSE sys_size_pretty(
                sys_wal_lsn_diff(
                  sys_current_wal_lsn(),
                  restart_lsn
                )
              )       END AS retained_walFROM sys_replication_slotsORDER BY slot_name;

复制槽不活跃且 restart_lsn 长时间不推进时，数据库可能持续保留 WAL。DBA 未确认同步依赖前，不得删除复制槽。

9. 验证类 SQL：检查长事务

大事务或长事务会拉长 WAL 保留时间，也会增加 KFS 解析压力。

SELECT pid,
       usename,
       application_name,
       client_addr,
       state,       now() - xact_start AS xact_age,
       wait_event_type,
       wait_event,       left(query, 200) AS query_textFROM sys_stat_activityWHERE xact_start IS NOT NULLORDER BY xact_start;

该查询用于定位长事务。DBA 终止会话前，应确认业务、事务内容、锁影响和回滚成本。

10. KFS 只读检查：进程、解析位置和同步状态

Kingbase FlySync 手册列出以下基础检查命令：

cd "$KFS_BIN"./replicator status
./kufl list
./fsrepctl status

replicator status：同步程序是否启动；
kufl list：当前解析位置；
fsrepctl status：同步服务状态。

故障现场应间隔 30 至 60 秒执行两次，并记录事务号或解析位置。进程存活且位置停滞时，运维人员需要继续排查。

11. KFS 变更命令：必须审批并确认影响范围

KFS 官方手册提供以下启停命令：

cd "$KFS_BIN"./replicator stop
./replicator start

replicator stop 可能影响该节点上的多个同步服务。执行人员必须先确认节点承载范围、停机窗口、恢复顺序和回滚方式。

执行人员将指定服务置为 OFFLINE 或 ONLINE 时，必须填写并复核服务名：

./fsrepctl -service "$KFS_SERVICE" offline
./fsrepctl -service "$KFS_SERVICE" online

修改 flysync.ini 或 setupCDC.conf 时，官方流程要求操作人员停止同步程序，修改配置，执行 fspm update，然后启动同步程序：

cd "$KFS_BIN"./replicator stop# 修改配置前先备份，并进行双人复核。# 修改 flysync.ini 或 setupCDC.conf。./fspm update
./replicator start

配置变更前，操作人员必须保留原文件、记录差异并准备回退。同步运行期间不得覆盖配置。

12. 高风险命令：故障现场默认禁止

KFS 手册列出了跳过事务、重置服务等能力。执行这些命令可能造成数据缺口或改变恢复起点。

fsrepctl online -skip-seqno ... 会跳过指定事务。执行人员必须取得业务确认、数据一致性评估和厂商支持意见。

磁盘空间告警不得直接触发以下操作：

删除或清空 sys_wal；
删除归档 WAL；
删除复制槽；
使用 sys_resetwal 强制重置 WAL；
对 KFS 服务执行无依据的 reset；
将未知 WAL 文件直接覆盖到 KFS 工作目录。

执行这些操作可能导致数据不一致，甚至破坏数据库恢复能力。

13. 归档 WAL 人工补齐：先进入暂存区

人工补齐 WAL 属于变更操作。DBA 与 KFS 运维人员必须先确认所缺 WAL 段、来源节点、目标目录、文件权限和版本兼容性。

操作人员先在 192.168.56.13 上核对文件：

export WAL_SEGMENT='<KFS日志明确报缺的WAL文件名>'stat "$ARCHIVE_DIR/$WAL_SEGMENT"sha256sum "$ARCHIVE_DIR/$WAL_SEGMENT"

操作人员应将文件传入 192.168.56.16 上预先创建的事件暂存目录，不得直接写入 KFS 工作目录：

export WAL_STAGING_DIR='<192.168.56.16事件暂存目录>'scp -p \  "$ARCHIVE_DIR/$WAL_SEGMENT" \  "$KFS_NODE:$WAL_STAGING_DIR/"

操作人员在目标端再次校验：

sha256sum "$WAL_STAGING_DIR/$WAL_SEGMENT"stat "$WAL_STAGING_DIR/$WAL_SEGMENT"

源端和目标端校验值一致后，DBA 与 KFS 运维人员再按现场版本手册导入文件并触发回放。

原始故障报告没有记录 KFS 的导入目录、文件权限和专用命令，因此本节不提供最后一步命令。

14. 恢复后验证

恢复验证需覆盖 KFS 服务状态、解析位置和事务号推进情况：

cd "$KFS_BIN"date -Ins
./replicator status
./kufl list
./fsrepctl status

间隔 30 至 60 秒再次执行，确认解析位置和事务号持续推进。

DBA 再检查数据库复制与归档：

SELECT application_name,
       client_addr,
       state,
       sent_lsn,
       write_lsn,
       flush_lsn,
       replay_lsn,
       sync_stateFROM sys_stat_replicationORDER BY client_addr;SELECT archived_count,
       last_archived_wal,
       last_archived_time,
       failed_count,
       last_failed_wal,
       last_failed_timeFROM sys_stat_archiver;

运维人员最后按有索引的时间范围、业务主键或批次号核对源端与目标端数据。大表应避免无条件 COUNT(*)，以控制数据库负载。

网络恢复后同步未恢复的原因

基于 WAL 的同步链路需要满足两个恢复条件：KFS 能连接数据库，从上次消费位置到当前位置的日志保持连续。

中间缺失 WAL 时，KFS 无法跳过缺口解析后续日志。客户放通网络后，还需补齐历史 WAL。

现场恢复需要验证三个状态：

R3 版本 KFS 能否连接当前主库；
恢复所需的 WAL 是否完整、连续并可读取；
事务号是否持续推进，延迟是否追平。

三项检查全部通过后，运维人员才能确认同步恢复。

已完成的应急处置

运维团队完成了四项操作：

放通 R3 版本 KFS 到新主库 192.168.56.12 的网络连接；
在 192.168.56.13 上定位恢复所需的归档 WAL；
将 WAL 手工复制到 192.168.56.16，恢复日志回放和接管；
故障节点恢复后，将主库回切至 192.168.56.13，并确认同步追平。

运维团队核对后确认，R3 版本 KFS 运行正常，数据已经追平，未发现数据丢失。

复盘中的四个改进项

1. 双跑期的资源控制

R2、R3 同时解析源库，增加了 WAL 消费和资源管理的复杂度。R2 解析大事务卡顿后，WAL 持续堆积并占满磁盘。

2. 候选主库的网络策略

同步服务器的网络策略当时覆盖原主库，未包含候选主库。集群切换后，R3 版本 KFS 无法访问新主库。

3. 同步进度监控

监控范围需要纳入事务号停滞、WAL 增长、磁盘使用率和归档失败。进程状态可以作为其中一项指标。

4. 归档补取流程

自动补取失败后，运维人员需要人工定位和复制 WAL。团队可将文件定位、校验、传输和回放步骤写入操作规程。

后续改进

团队计划扩容 192.168.56.12 和 192.168.56.13 的磁盘，并同步处理 WAL 消费、网络策略和恢复流程。

第一步：结束 R2、R3 双跑

项目组将安排 R2 版本 KFS（192.168.56.15）下线，缩短双跑窗口，减少重复解析和资源叠加。

下线前，项目组应验证 R3 的同步完整性、追平能力和异常恢复能力。

第二步：补齐端到端监控

监控范围包括数据库磁盘使用率、WAL 目录增长、归档失败次数、KFS 事务号停滞时长、同步延迟和主备切换事件。

告警信息需要记录 WAL 保留来源、增长起始时间和当前消费位点，便于运维人员定位。

第三步：按集群配置网络策略

网络团队应配置 R3 版本 KFS 到 192.168.56.12、192.168.56.13 的数据库访问策略，并按计划验证。

主备切换演练应覆盖数据库角色和上下游连通性。切换完成后，运维人员需要检查 KFS 能否连接新主库。

第四步：固化归档 WAL 恢复流程

运维团队需要形成可审计的操作流程，涵盖缺失范围确认、归档文件定位、完整性校验、文件传输、日志回放和追平验证。

团队完成自动化前，操作人员应保留手工复制记录，并设置复核点和回滚路径。

第五步：推进数据库瘦身

DBA 团队需要制定历史数据清理和归档机制，控制数据库体量，缩短集群修复、备份恢复和 KFS 追平时间。

数据清理属于生产变更。执行前，DBA 必须明确保留周期、业务依赖、批次范围、锁影响、备份位置和回滚方案，并采用分批处理。

复盘结论

本次事件归类为一般技术、配置类故障。处置记录未发现人为误操作。

R2 版本 KFS（192.168.56.15）解析大事务时卡顿，WAL 随后堆积并占满磁盘，集群完成主备切换。网络策略未覆盖新主库 192.168.56.12，R3 版本 KFS 中断同步。归档 WAL 自动补取失败增加了恢复时间。

数据库完成主备切换后，运维人员还需核对外围网络、WAL 连续性和 KFS 进度。

团队将这些检查纳入监控、演练和应急流程，可以缩短同类事件的定位和恢复时间。

ITPub博客

一次 KFS 数据同步中断复盘

背景