企业官网建设流程全解析

OpenGauss 事务日志重置操作测试报告

📋 测试概述

测试时间：2026-02-04
测试实例：opengauss-[实例ID]
测试环境：Kubernetes 集群（命名空间：qfusion-admin）
数据目录：/pgdata/data/opengauss-[实例ID]

🎯 测试目的

验证以下命令的影响和风险：

gs_ctl stop -D /pgdata/data/opengauss-[实例ID]pg_resetxlog -f /pgdata/data/opengauss-[实例ID]

重点关注：

• WAL（Write-Ahead Log）文件的变化
• 数据完整性影响
• LSN（Log Sequence Number）变化
• 服务状态变化
• 潜在风险点

📊 测试过程

一、初始状态记录

1.1 数据库运行状态

[gs_ctl]: gs_ctl query HA state: local_role : Normal db_state : Normal server mode : Primary

1.2 时间和 LSN 信息

SELECTcurrent_timestamp,pg_is_in_recovery(),pg_current_xlog_location();

1.3 WAL 文件状态（重置前）

/pgdata/data/opengauss-[实例ID]/pg_xlog/ total 32M -rw------- 1 opengauss opengauss 16M Feb 4 15:54 000000010000000000000001 -rw------- 1 opengauss opengauss 16M Feb 4 16:09 000000010000000000000002 drwx------ 2 opengauss opengauss 43 Feb 4 15:54 archive_status

1.4 测试数据准备

-- 创建测试表CREATETABLEIFNOTEXISTStest_reset_log(idserial,datatext,create_timetimestampdefaultnow());-- 插入测试数据INSERTINTOtest_reset_log(data)VALUES('before reset'),('test data 1'),('test data 2');-- 验证数据SELECT*FROMtest_reset_log;

二、执行重置操作

2.1 插入测试数据（模拟未检查点数据）

INSERTINTOtest_reset_log(data)VALUES('after last checkpoint - MAY BE LOST');

2.2 停止数据库

gs_ctl stop -D /pgdata/data/opengauss-[实例ID]

执行结果：

[2026-02-04 16:10:58.841][8172][][gs_ctl]: gs_ctl stopped waiting for server to shut down......... done server stopped

2.3 强制重置事务日志

pg_resetxlog -f /pgdata/data/opengauss-[实例ID]

执行结果：

Transaction log reset

三、重置后状态变化

3.1 WAL 文件变化（重置后）

/pgdata/data/opengauss-[实例ID]/pg_xlog/ total 16M -rw------- 1 opengauss opengauss 16M Feb 4 16:11 000000010000000000000004 drwx------ 2 opengauss opengauss 6 Feb 4 16:11 archive_status

变化分析：

关键发现：

• ✅ WAL 序列号从 000000002 跳跃到 000000004
• ⚠️ 旧的 WAL 文件（000000001, 000000002）被清除
• ⚠️ 历史归档日志（如果有）将无法使用

3.2 重新启动数据库

gs_ctl stop -M immediate -D /pgdata/data/opengauss-[实例ID]gs_ctl start -D /pgdata/data/opengauss-[实例ID]

启动日志关键信息：

[REDO] LOG: Recovery parallelism, cpu count = 16, max = 8, actual = 8 [BACKEND] LOG: create gaussdb state file success: db state(STARTING_STATE), server mode(Normal), connection index(1)

3.3 数据完整性验证

SELECT*FROMtest_reset_log;

验证结果：

✅ 数据完整性结论：所有数据完整，无丢失

四、多次重置压力测试 🔄

4.1 测试设计

为了验证pg_resetxlog在多次重复执行下的累积影响，进行了16 次连续重置测试：

测试变量：

• 重置次数：16 次（第 1 次单独测试 + 第 2-15 次连续测试 + 第 16 次追踪测试）
• 测试数据：每次重置前插入新数据
• 观察指标：WAL 文件编号变化、数据完整性、服务稳定性

4.2 WAL 文件编号变化轨迹

完整变化历史：

🔍 关键发现：

• ✅每次重置增加 2 个编号：从 N → N+2，保持稳定的���跃模式
• ✅WAL 文件始终保持单个：每次只保留一个新的 WAL 文件
• ⚠️注意：16 次重置实际总增长为 25（从 000000002 到 000000027），而非理论值 32（16×2）

最终状态：

/pgdata/data/opengauss-[实例ID]/pg_xlog/ total 16M -rw------- 1 opengauss opengauss 16M Feb 4 20:22 000000010000000000000027 drwx------ 2 opengauss opengauss 6 Feb 4 20:22 archive_status

4.3 数据完整性追踪

测试数据历史：

最终数据状态：

SELECTid,data,create_timeFROMtest_reset_logORDERBYid;

🔍 关键发现：

• ⚠️只有第 1 次重置前的数据保留：后续 15 次插入的所有数据全部丢失
• ⚠️CHECKPOINT 无效：即使执行 CHECKPOINT 后插入的数据也会丢失
• ⚠️数据丢失原因：
  1. 快速连续重置，数据库未完全启动就插入数据
  2. 插入操作可能在备库模式执行（Patroni 切换为 Standby）
  3. WAL 被立即清除，未有机会归档或持久化

4.4 服务稳定性验证

16 次重置后的服务状态：

gs_ctl query -D /pgdata/data/opengauss-[实例ID]

HA state: local_role : Normal db_state : Normal server mode : Primary sync_mode : Async

验证结果：

4.5 多次重置累积影响分析

影响评估矩阵：

📊 统计数据：

总重置次数：16 次 总 WAL 编号变化：000000002 → 000000027（增长 25） 平均每次增长：1.5625 数据丢失率：93.75%（15/16 次插入的数据丢失） 服务成功率：100%（16/16 次都能正常启动）

4.6 Patroni 集群环境下的特殊行为

在多次重置测试中发现 Patroni 的介入模式：

关键日志模式：

[BACKEND] LOG: create gaussdb state file success: db state(STARTING_STATE), server mode(Normal), connection index(1)

五、Patroni 集群影响

5.1 Patroni 自动介入

由于测试实例受 Patroni 管理，重置操作后 Patroni 自动介入：

recovery.conf 配置：

# Do not edit this file manually! # It will be overwritten by Patroni! recovery_target_timeline = '' standby_mode = 'on'

5.2 实例角色变化

SELECTpg_is_in_recovery();

⚠️ 关键发现：

• Patroni 检测到重置后，将实例切换为备库模式
• 需要重新建立与主库的复制关系
• 可能需要时间线（Timeline）恢复

🔍 影响分析

一、正面影响 ✅

1.1 恢复数据库服务

• 场景：数据库因 WAL 损坏无法启动
• 效果：重置后可以正常启动
• 前提：数据文件本身未损坏

1.2 重置 LSN 序列

• 场景：需要从备份重新初始化
• 效果：清空旧 WAL，避免混淆

1.3 测试环境验证

• 场景：开发和测试环境
• 效果：快速清理和重置

1.4 多次重置的稳定性

• 场景：需要频繁重置 WAL（如测试循环）
• 效果：16 次重置测试证明服务保持稳定
• 优势：无服务退化，启动时间一致

二、负面影响 ⚠️

2.1 数据丢失风险（单次重置）

场景：

• 数据库异常崩溃（非正常关闭）
• 未完成的事务
• 未刷新到磁盘的缓冲区数据

影响程度：

┌─────────────────────────────────────────────────┐ │ 正常关闭场景（如本次测试） │ │ ✅ 已提交事务已持久化 → 数据无丢失 │ └─────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────┐ │ 异常崩溃场景 │ │ ⚠️ 未提交事务丢失 │ │ ⚠️ 未刷新缓冲区数据丢失 │ └─────────────────────────────────────────────────┘

2.2 数据丢失风险（多次重置）🔴高危

⚠️ 累积效应：

• 数据丢失率：93.75%（16 次测试中 15 次丢失数据）
• 丢失原因：
  1. 快速连续重置，数据库未完全启动就执行写入
  2. Patroni 将实例切换为备库，写入操作失败
  3. WAL 立即被清除，无持久化机会

⚠️ 关键警示：

# ❌ 错误做法：循环重置foriin{1..10};dogs_ctl stop -D$DATADIRpg_resetxlog -f$DATADIRgs_ctl start -D$DATADIR# 此时插入数据 → 极大概率丢失！done# ✅ 正确做法：等待完全启动foriin{1..10};dogs_ctl stop -D$DATADIRpg_resetxlog -f$DATADIRgs_ctl start -D$DATADIRsleep10# 等待完全启动# 确认角色后再插入数据gsql -c"SELECT pg_is_in_recovery();"done

2.3 WAL 文件清除

2.4 复制中断

影响：

• 备库无法继续从旧 WAL 接收数据
• 需要重新构建备库（全量备份 + WAL）
• 主备切换可能失败

2.5 Patroni 集群影响

影响：

• 实例角色可能改变（Primary → Standby）
• 需要重新加入集群
• 可能触发自动故障转移

三、LSN 变化分析

3.1 LSN 跳跃情况

3.2 影响

旧 LSN 范围: 0/0 - 0/20011A8 → 不可用 新 LSN 范围: 0/0 - ??? → 从头开始

📝 操作风险评估

风险等级矩阵

多次重置风险详解 🔴

基于 16 次连续重置测试的统计：

关键风险点：

1. 数据丢失累积：连续重置导致数据丢失风险从 🟡 低 → 🔴 极高
2. 时间线混乱：每次重置都会改变 WAL 序列，PITR（时间点恢复）失效
3. 复制断裂：备库需要完全重建，无法增量恢复
4. 无法预测行为：Patroni 在多次重置后可能进入不确定状态

🚨 风险缓解建议

一、操作前检查清单 ✅

• 数据备份确认

  # 检查最近备份时间ls-lh /backup/last_full_backup/

• 集群拓扑确认

  # 查看集群成员patronictl list

• 当前角色确认

  SELECTpg_is_in_recovery();

• WAL 归档状态

  # 检查归档是否完整ls-lh /pgdata/archive/

• 业务停运确认

  • 业务已停止或切换到其他节点
  • 通知相关人员

二、操作步骤建议 📋

方案 A：标准操作（推荐）

# 1. 优雅停止gs_ctl stop -D /pgdata/data/opengauss-[实例ID]# 2. 备份数据目录（可选但强烈推荐）cp-r /pgdata/data/opengauss-[实例ID]/backup/opengauss-[实例ID]-before-reset# 3. 强制重置pg_resetxlog -f /pgdata/data/opengauss-[实例ID]# 4. 启动数据库gs_ctl start -D /pgdata/data/opengauss-[实例ID]# 5. 验证状态gs_ctl query -D /pgdata/data/opengauss-[实例ID]gsql -c"SELECT pg_is_in_recovery();"

方案 B：Patroni 集群环境

# 1. 如果可能，先暂停 Patronipatronictl pause[集群名]# 或使用信号替代kill-19<patroni_pid># 重要！！！ 重启一下试下gs_ctl restart -M primary# 2. 执行重置操作 ！！！gs_ctl stop -D /pgdata/data/opengauss-[实例ID]！！！ 先备份数据，备份不了就备份数据目录 ！！！ 会丢数！！！ pg_resetxlog -f /pgdata/data/opengauss-[实例ID]# 3. 启动并观察gs_ctl start -D /pgdata/data/opengauss-[实例ID]# 4. 恢复 Patronikill-18<patroni_pid># 或patronictl resume[集群名]# 5. 重新加入集群# Patroni 会自动处理

方案 C：异常恢复场景

# 0. 重启一下试下gs_ctl restart -M primary -D /pgdata/data/opengauss-[实例ID]# 1. 立即模式停止（如果有残留进程）gs_ctl stop -M immediate -D /pgdata/data/opengauss-[实例ID]# 2. 清理锁文件（如果需要）rm-f /pgdata/data/opengauss-[实例ID]/postmaster.pid# 3. 强制重置pg_resetxlog -f /pgdata/data/opengauss-[实例ID]# 4. 启动gs_ctl start -D /pgdata/data/opengauss-[实例ID]# 5. 检查数据完整性gsql -c"SELECT count(*) FROM important_table;"

三、操作后验证 ✅

# 1. 检查进程psaux|grepgaussdb# 2. 检查日志tail-100 /pgdata/data/pglog/postgresql-*.log|grep-E'FATAL|ERROR'# 3. 检查数据gsql -c"SELECT count(*) FROM test_reset_log;"# 4. 检查复制状态（如果是备库）gsql -c"SELECT * FROM pg_stat_replication;"# 5. 检查 Patroni 状态patronictl list

📊 测试结论

核心发现

适用场景

✅推荐使用的场景：

1. 开发/测试环境快速重置
2. WAL 文件损坏导致无法启动
3. 从备份恢复后清理旧 WAL
4. 单实例环境（无复制关系）

❌不推荐使用的场景：

1. 生产环境主库（优先考虑备份恢复）
2. 有活跃备库的复制环境
3. 数据库异常崩溃后（优先分析 WAL）
4. 需要 PITR（时间点恢复）的场景

🔧 故障排查指南

常见问题

Q1: 重置后无法启动？

# 检查锁文件ls-la /pgdata/data/opengauss-[实例ID]/postmaster.pid# 如果存在，删除后重试rm-f /pgdata/data/opengauss-[实例ID]/postmaster.pid gs_ctl start -D /pgdata/data/opengauss-[实例ID]

Q2: Patroni 一直处于备库模式？

# 检查 recovery.confcat/pgdata/data/opengauss-[实例ID]/recovery.conf# 如果 standby_mode = 'on'，说明 Patroni 配置为备库# 需要等待 Patroni 自动处理，或手动触发选举patronictl restart[集群名][实例名]

Q3: 备库报错 “invalid checkpoint record”？

# 备库需要重建# 在备库上执行：gs_ctl stop -D /pgdata/data/opengauss-[实例ID]rm-rf /pgdata/data/opengauss-[实例ID]/*# 使用 gs_ctl build 重建gs_ctl build -D /pgdata/data/opengauss-[实例ID]

📌 附录

A. 命令参考

B. 重要文件路径

C. 相关 SQL 函数