Skip to content

Use snapshot transfers by default#8784

Merged
timvisee merged 6 commits into
devfrom
default-shard-transfer-method-snapshot
Apr 30, 2026
Merged

Use snapshot transfers by default#8784
timvisee merged 6 commits into
devfrom
default-shard-transfer-method-snapshot

Conversation

@timvisee

Copy link
Copy Markdown
Member

Depends on #8782

Switches the default shard transfer method from stream records to snapshot. This is desired because snapshot based transfers generally perform much better. WAL delta transfers are still preferred for automatic recovery transfers, after which it might fall back to snapshots.

Two changes are made to make this happen:

  1. select default method on entrypoint peer, not on each peer separately
  2. use snapshot method as default

Before this PR, selecting the default transfer method was not synchronized. If you'd trigger a transfer with no method, each peer would select the default method separately. Peers selecting different versions breaks consensus as transfers don't match up. Since we change the default method, running a cluster with mixed versions could trigger this. It was also possible to set different defaults in the configuration of each peer.

Now the peer that first sees the transfer request is responsible for setting the default transfer method. For user requests it'd be the entry point of their request. For automatic recovery transfers it'd be the peer that triggered the recovery.

All Submissions:

  • Contributions should target the dev branch. Did you create your branch from dev?
  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

  1. Does your submission pass tests?
  2. Have you formatted your code locally using cargo +nightly fmt --all command prior to submission?
  3. Have you checked your code using cargo clippy --workspace --all-features command?

Changes to Core Features:

  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your core changes, as applicable?
  • Have you successfully ran tests with your changes locally?

@timvisee timvisee added do not merge Pull requests blocked on an external event release:1.18.0 labels Apr 24, 2026
@timvisee timvisee force-pushed the default-shard-transfer-method-snapshot branch 2 times, most recently from 123fde1 to 60bf9e1 Compare April 24, 2026 10:34
@timvisee timvisee self-assigned this Apr 24, 2026
@timvisee timvisee removed the do not merge Pull requests blocked on an external event label Apr 30, 2026
@timvisee timvisee marked this pull request as ready for review April 30, 2026 09:26
@timvisee timvisee force-pushed the default-shard-transfer-method-snapshot branch from 60bf9e1 to 86fbbf5 Compare April 30, 2026 09:26
@timvisee timvisee requested a review from ffuugoo April 30, 2026 09:27
@qdrant qdrant deleted a comment from coderabbitai Bot Apr 30, 2026
@qdrant qdrant deleted a comment from coderabbitai Bot Apr 30, 2026

@agourlay agourlay left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's merge to let our CI chew on it over the next few days.

@timvisee timvisee merged commit 57290a8 into dev Apr 30, 2026
15 checks passed
@timvisee timvisee deleted the default-shard-transfer-method-snapshot branch April 30, 2026 15:08
timvisee added a commit that referenced this pull request May 8, 2026
* [ai] Always set default transfer method on entry peer

This will propagate a specific transfer type through consensus to all
peers. It ensures all peers will use the same transfer method when
applying the operation.

* [ai] Enforce the shard method to be specified

* Still allow unspecified transfer method for older peer versions

* Use snapshot shard transfers by default in Qdrant 1.18.0 and up

* New method does not have to be async

* Use stream records based transfer for replicate points with filter
@timvisee timvisee mentioned this pull request May 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants