replication: check rs uuid on subscribe process
Remote node doing the subscribe might be from a different replicaset. Before this patch the subscribe would be retried infinitely because the node couldn't be found in _cluster, and the master assumed it must have joined to another node, and its ID should arrive shortly (ER_TOO_EARLY_SUBSCRIBE). The ID would never arrive, because the node belongs to another replicaset. The patch makes so the master checks if the peer lives in the same replicaset. Since it is doing a subscribe, it must have joined already and should have a valid replicaset UUID, regardless of whether it is anonymous or not. Correct behaviour is to hard cut this peer off immediately, without retries. Closes #6094 Part of #5613
Showing
- changelogs/unreleased/gh-6094-rs-uuid-mismatch.md 6 additions, 0 deletionschangelogs/unreleased/gh-6094-rs-uuid-mismatch.md
- src/box/box.cc 22 additions, 7 deletionssrc/box/box.cc
- test/replication/gh-3704-misc-replica-checks-cluster-id.result 0 additions, 68 deletions...replication/gh-3704-misc-replica-checks-cluster-id.result
- test/replication/gh-3704-misc-replica-checks-cluster-id.test.lua 0 additions, 25 deletions...plication/gh-3704-misc-replica-checks-cluster-id.test.lua
- test/replication/gh-6094-rs-uuid-mismatch.result 67 additions, 0 deletionstest/replication/gh-6094-rs-uuid-mismatch.result
- test/replication/gh-6094-rs-uuid-mismatch.test.lua 25 additions, 0 deletionstest/replication/gh-6094-rs-uuid-mismatch.test.lua
- test/replication/suite.cfg 1 addition, 1 deletiontest/replication/suite.cfg
Loading
Please register or sign in to comment