mirror of
https://github.com/scylladb/scylladb.git
synced 2026-06-02 13:06:57 +00:00
c0ce122f77
Raft instance needs to update RPC subsystem on changes in configuration, so that RPC can deliver messages to the new nodes in configuration, as well as dispose of the old nodes. I.e. the nodes which are not the part of the most recent configuration anymore. The effective scope of RPC mappings is limited by the piece of code which sends messages to both the "new" nodes (which are added to the cluster with the most recent configuration change) and the "old" nodes which are removed from the cluster. Until the messages are successfully delivered to at least the majority of "old" nodes and we have heard back from them, the mappings should be kept intact. After that point the RPC mappings for the removed nodes are no longer of interest and thus can be immediately disposed. There is also another problem to be solved: in Raft an instance may need to communicate with a peer outside its current configuration. This may happen, e.g., when a follower falls out of sync with the majority and then a configuration is changed and a leader not present in the old configuration is elected. The solution is to introduce the concept of "expirable" updates to the RPC subsystem. When RPC receives a message from an unknown peer, it also adds the return address of the peer to the address map with a TTL. Should we need to respond to the peer, its address will be known. An outgoing communication to an unconfigured peer is impossible. * manmanson/raft_mappings_wiring_v12: raft: update README.md with info on RPC server address mappings raft: wire up `rpc::add_server` and `rpc::remove_server` for configuration changes raft/fsm: add optional `rpc_configuration` field to fsm_output raft: maintain current rpc context in `server_impl` raft: use `.contains` instead of `.count` for std::set in `raft::configuration::diff` raft: unit-tests for `raft_address_map` raft: support expiring server address mappings for rpc module