跳到正文
go-sequentGo 支付 / 账本场景的 CQRS + Event Sourcing 库

运维

备份与恢复手册

备份 go-sequent 的 PostgreSQL 事件库并演练经过验证的恢复：备份对象、持续 WAL 归档、季度演练、时间点恢复，以及恢复后的快照处理。

备份与恢复手册

PostgreSQL 事件库是不可丢的。读模型可以丢弃再建，事件与命令不行。

备份什么

对象 优先级
commands、events、aggregates、*_types 关键
aggregate_unique_keys、idempotency_keys 对正确性关键
snapshot_records 高。可由事件重建，但能加快加载。
outbox 如果异步集成有积压则为高
读模型与视图表 低。通过 replay 重建。
event_tombstones 中。GDPR 审计线索（Tombstone：追加标记事件，读模型不再暴露个人数据）。

完整性来自 hash chain（按聚合串联事件哈希，用来发现篡改），再加访问控制、备份，以及可选的 WORM 存储。不做事件签名。

持续备份

  1. 启用持续 WAL 归档，或云上的时间点恢复。
  2. 按计划做基础备份，使用 pgBackRest、Barman 或云的自动备份。
  3. 备份静态加密，并限制谁可以执行恢复。
  4. 把保留策略与 GDPR 的 Tombstone（标记清除事件）策略一起写下来。删除只通过 Tombstone 完成，见 事件演进与 锁定决策。

经过验证的恢复演练

每季度做一次。

  1. 恢复到一个隔离的实例，永远不要盲目覆盖生产。
  2. 只有在 schema 对象缺失时才运行 go run ./cmd/go-sequent migrate -dsn …。更推荐恢复一份已包含 schema 的一致性集群快照。
  3. 冒烟测试：
    • 对一个已知聚合执行 LoadStream，这同时会校验 hash chain。
    • 带 SyncInTxn（写事务内同步更新读模型）Projector 执行一次 CommandService.Execute。
    • 对某个租户做一次 Idempotency 键（同一业务键重复提交只生效一次）往返。
  4. 可选：用 replay 流水线重建读模型，见 读模型重建。
  5. 记录实际达到的 RTO 与 RPO，并补上缺口。

想要更强的校验，可以在恢复后对一批聚合调用 Store 的 VerifyChain。

时间点恢复

  • 优先恢复到事故发生前一刻。
  • 恢复之后，不要导入 Ruby Sequent 的 dump。
  • 如果在一次失败的切换中发生了双写，先停掉所有写入方，恢复到已知良好的 LSN，再让客户端通过幂等重试追上。见 故障转移与 Idempotency。

恢复后的快照

如果 snapshot_version 或聚合 schema 发生了变化，删除 snapshot_records 中不兼容的行。Snapshotter 会重新填充，也可以只从事件加载。见 快照。

相关

文档随 go-sequent 源码更新；若与 API 不一致，以源码为准。