Bug Report
Problem
PD currently enforces uniqueness for a store's main address, but a new store can be accepted with a unique main address and a peer_address already used by another store.
This was reproduced with TiFlash stores. PD recorded both stores as Up:
store 1260: address=<tiflash-0>:3930 peer_address=<tiflash-0>:20170
store 1347: address=<new-pod>:3930 peer_address=<tiflash-0>:20170
The second store passed registration because its main store address was unique.
Impact
Raft routing prefers peer_address. Messages for store 1347 were therefore sent to store 1260. The receiving store correctly rejected them with:
StoreNotMatch { to_store_id: 1347, my_store_id: 1260 }
The learner could not receive/apply snapshots, the placement operator remained stuck, the TiFlash replica stayed unavailable, and forced TiFlash queries reported No access path.
Expected behavior / possible improvement
PD should prevent two live stores from publishing the same non-empty peer_address, or at minimum surface a strong diagnostic and keep the conflicting store out of scheduling.
Please also consider compatibility and stale-store semantics so that a legitimate replacement is not permanently blocked by metadata from an offline store.
Bug Report
Problem
PD currently enforces uniqueness for a store's main
address, but a new store can be accepted with a unique main address and apeer_addressalready used by another store.This was reproduced with TiFlash stores. PD recorded both stores as
Up:The second store passed registration because its main store address was unique.
Impact
Raft routing prefers
peer_address. Messages for store 1347 were therefore sent to store 1260. The receiving store correctly rejected them with:The learner could not receive/apply snapshots, the placement operator remained stuck, the TiFlash replica stayed unavailable, and forced TiFlash queries reported
No access path.Expected behavior / possible improvement
PD should prevent two live stores from publishing the same non-empty
peer_address, or at minimum surface a strong diagnostic and keep the conflicting store out of scheduling.Please also consider compatibility and stale-store semantics so that a legitimate replacement is not permanently blocked by metadata from an offline store.