Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions content/cn/docs/config/config-backend-hstore.md
Original file line number Diff line number Diff line change
Expand Up @@ -208,3 +208,19 @@ curl http://localhost:8080/metrics/backend
```

响应中的 `nodes` 就是 PD 返回的活跃 Store 数量。`nodes` 为 `0` 说明 Server 连上了 PD,但 PD 中没有状态为 `Up` 的 Store,通常是 Store 节点还没注册,或者因为不在 PD 的 `pd.initial-store-list` 中而注册成了 `Pending`。

### 9 旧 GraphID 升级预检

HugeGraph-Store 在启动和升级流程中提供旧版 GraphID 的安全预检保护机制。已发布的 1.7.0 及更早版本不包含此预检保护。
依赖下述拒绝行为前,请确认使用支持该特性的 Store 构建。

这些 Store 构建会在分配缺失的图 ID、元数据启动阶段首次打开尚未缓存的分区 DB、启动该分区的 Raft 状态机,或激活暂存快照前检查已有图数据列族。
首次打开时会在清理旧版本前检查所有仍保留的有效 DB 版本。发现保留前缀 `FFFE` 的旧数据时会拒绝操作;
如果选中的不完整 DB 版本缺少 `CURRENT`、会遮蔽仍保留的有效版本,也会拒绝。
这针对受影响的旧写入路径,不表示所有 1.7 数据库都需要迁移,持久化 ID 格式保持不变。

遇到拒绝时,保留原始数据 DB 版本、元数据、WAL,以及输入快照和暂存副本,在恢复写入或回放前调查相关写入与升级历史。
不要删除图到 ID 的映射,也不要把所有保留前缀行归给同一个图,因为不同图可能共享该前缀。Store/Raft 位置元数据可能已在预检前更新,因此整个启动流程并非只读。
预检不会自动迁移数据或修复归属;完整的 1.7 升级与恢复仍需针对具体部署验证。

详细行为与处置依据见官方升级指南中的 [Store GraphID 升级说明](https://github.com/apache/hugegraph/blob/master/docs/store-graphid-upgrade.md)。
19 changes: 19 additions & 0 deletions content/en/docs/config/config-backend-hstore.md
Original file line number Diff line number Diff line change
Expand Up @@ -246,3 +246,22 @@ curl http://localhost:8080/metrics/backend
The `nodes` value in the response is the count of active stores PD returns. A `nodes` value of `0` means the
Server reached PD but PD has no store in state `Up`, which usually means the Store nodes have not registered
yet, or registered as `Pending` because they are not in PD's `pd.initial-store-list`.

### 9 Legacy GraphID upgrade preflight

HugeGraph-Store provides legacy GraphID upgrade preflight checks during bootstrap and upgrade processes.
Released 1.7.0 and earlier Store builds do not contain this preflight guard.
Use a Store build supporting this capability before relying on the refusal behavior below.

These Store builds check existing graph-data column families before allocating a missing graph ID, first opening a cold
partition DB during metadata bootstrap, starting its Raft state machine, or activating a staged snapshot. Before pruning, the first cold DB open checks
all retained valid versions. Reserved `FFFE` legacy rows cause refusal.
An incomplete selected DB version without `CURRENT` is also rejected when it would hide retained valid versions. This concerns affected old write paths;
it does not mean that every 1.7 database needs migration, and the persisted ID format is unchanged.

On refusal, preserve the original data DB versions, metadata, WAL and incoming/staged snapshots. Investigate the affected write and upgrade history before
resuming writes or replay. Do not delete graph-to-ID mappings or assign all reserved-prefix rows to one graph: different graphs may share that prefix.
Store/Raft location metadata may already have been updated before the check, so the entire bootstrap is not read-only. The check performs no automatic
migration or ownership repair; a complete 1.7 upgrade and recovery still require deployment-specific validation.

See the [Store GraphID upgrade documentation](https://github.com/apache/hugegraph/blob/master/docs/store-graphid-upgrade.md) for details.
Loading