Description
What's the issue?
Before performing a restore, 'cbbackupmgr' will bulk update the scopes/collections on the target cluster, we will then wait for the changes to propagate throughout the cluster i.e. have all the scopes/collection be ready to take traffic.
When getting the collection manifest using 'gocbcore' the request is dispatched to the node which contains vBucket 0/replica 0. This is an issue for 'cbbackupmgr' because manifest updates are not cluster wide i.e. just because one node is ready to take traffic for a new scope/collection doesn't mean any of there others are ready.
What's the fix?
'cbbackupmgr' should perform its checks against the oldest manifest in the cluster (the one with the lowest uid). This is not possible at the moment because we don't have the ability to fetch the manifest from a specific node/number of nodes.
We should add a function the 'gocbcore' which will allows us to fetch the collection manifest from all the nodes in the cluster at once (in a similar fashion to how stats calls are dispatched to all the nodes in the cluster).
Attachments
Issue Links
- blocks
-
MB-41830 cbbackupmgr fails to wait until manifest update has propagated throughout the cluster
- Closed