Skip to content

[server] Register external KV snapshots and restore replicas - #4242

Open
platinumhamburg wants to merge 5 commits into
apache:mainfrom
platinumhamburg:feature-kv-snapshot-import
Open

[server] Register external KV snapshots and restore replicas#4242
platinumhamburg wants to merge 5 commits into
apache:mainfrom
platinumhamburg:feature-kv-snapshot-import

Conversation

@platinumhamburg

Copy link
Copy Markdown
Contributor

Purpose

Linked issue: close #4223

Brief change log

Tests

API and Format

Documentation

Share KV snapshot file metadata across modules and register externally produced target-bucket snapshots with coordinator fencing and idempotent retries. Adopt confirmed snapshots into retention and protect persistent references when registration responses are lost.

Initialize the local log boundary from snapshot-only history through ordinary replica role notifications. Cover external snapshot production, registration, recovery, repeated notifications, online writes, failover and subsequent snapshot retention.
Use the selected KV snapshot to initialize an empty local log after its
files have been loaded, and capture the leader log boundary after recovery.
Reject conflicting log initialization and propagate snapshot lookup errors.

Release partially recovered KV state before retrying, and publish leader
identity only after recovery succeeds so failed elections can be retried.
Cover snapshot lookup and download failures, metadata retry after loading,
and protection of existing local log records.
Keep the existing leader and follower transition behavior while coordinating
KV snapshot recovery with local log initialization. Test snapshot lookup
failures independently of role transition retries, and recover from a failed
download under a subsequent leader epoch.
Serialize external snapshot identity and ordering checks, persistent handle
confirmation and retention updates in CompletedSnapshotStore. Delegate
coordinator fencing and idempotent persistence to the handle store while
preserving ordinary snapshot writes and cleanup behavior.

Describe the snapshot counter check as an allocation bound; reserving the
ID remains the caller's responsibility.
Resolve the recovery snapshot and log prerequisites before changing role
state or discarding the current KV. Reuse that selection for the first
recovery attempt while preserving retries through older healthy snapshots.
Avoid remote manifest lookups when the local log already covers the snapshot.

Cover metadata lookup failures with a live KV and recovery after metadata
becomes available. Clarify that obsolete snapshot cleanup may be deferred.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Server] Support importing completed KV snapshots

1 participant