vshard: bump to 0.1.42 and cover backup of a sharded cluster - #1338
Merged
bigbes merged 2 commits intoJul 31, 2026
Conversation
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 30, 2026 06:14
7e86de2 to
f43a207
Compare
bigbes
changed the base branch from
g.rybakov/tntp-8608-start-rework-tests
to
bigbes/tntp-8670-backup-verify
July 30, 2026 06:14
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 30, 2026 06:29
f43a207 to
2135df6
Compare
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 30, 2026 12:42
2135df6 to
a4cc7f7
Compare
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
2 times, most recently
from
July 30, 2026 12:52
8ebe6de to
d37c671
Compare
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 30, 2026 19:15
d37c671 to
ef76794
Compare
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 30, 2026 19:23
ef76794 to
cacc0a6
Compare
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 30, 2026 19:56
cacc0a6 to
4662da2
Compare
sssciel
approved these changes
Jul 30, 2026
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 31, 2026 06:19
4662da2 to
c69d30d
Compare
Merged
patapenka-alexey
approved these changes
Jul 31, 2026
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 31, 2026 07:48
c69d30d to
a389bd9
Compare
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 31, 2026 08:52
a389bd9 to
80e5d53
Compare
Every vshard pin in the tree still pointed at 0.1.25: the built-in vshard_cluster template and the three test rockspecs. 0.1.42 is the first release that ships roles/recovery-point-manager/backends/vshard-router.lua, the backend that lets the Tarantool recovery point manager role take a cluster-wide recovery point via the router. Backup needs that to record a consistent point across shards, so the pin has to move to at least 0.1.42. Part of TNTP-8032
The backup tests so far ran against a single plain instance, so nothing exercised the multi-shard artifact layout that the manifest aggregation consumes, and recovery points were only ever created per instance. Add a sharded_app fixture: two storage replicasets plus a router that runs roles.recovery-point-manager with the vshard-router backend from vshard 0.1.42. The tests assert the role picked that backend up, that a cluster recovery point created on the router reaches both storage masters, and that 'tt backup start' carries it into the manifest fragment of every shard. The app advertises over TCP because vshard needs a real advertise URI, which is also why the storages are addressed by <URI> rather than <APP:INSTANCE>. Unlike test_backup_start.py these tests do not compare against golden fragments: on a sharded cluster the vclocks move on their own, so the assertions are structural. Part of TNTP-8032
bigbes
force-pushed
the
bigbes/gh-no-vshard-update
branch
from
July 31, 2026 10:25
80e5d53 to
bfccd2b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every vshard pin in the tree still pointed at
0.1.25: the built-invshard_clustertemplate and the three test rockspecs. They move to0.1.42, which is the first release shippingroles/recovery-point-manager/backends/vshard-router.lua- the backend that lets the coreroles.recovery-point-managerrole take a cluster-wide recovery point through the router.Part of TNTP-8032