Due to https://github.com/risingwavelabs/risingwave/pull/7179, we currently have some inaccuracies.

Here are some recommendations:

  1. Due to introduction HA, for meta with etcd should now specify its endpoint that becomes its identifier. It should not be inferred from its public IP or from the listen_addr. Using listen_addr is actually inaccurate, it is typically a localhost + port. endpoint should never default to listen_addr unless running in local mode.
  2. To be clearer, LeaderService should not have current_leader but default_leader_as_self when election_client is None
  3. Leader id stored in etcd is not guaranteed to be unique. We should have cluster membership to check uniqueness. (TODO)
  4. Remove host addr from MetaNodeOpts, this currently does nothing

Can't we just use a uuid for the leader ID? I used that for the leader lease in the previous election setup. It should be unique enough.


Yes, we can use something else for the ID (I'm in favour of uuid). But we still want each meta node to broadcast its contact-address (as of https://github.com/risingwavelabs/risingwave/pull/7530).

We may still want to verify that contact-adress is unique.


To whom do the meta nodes need to broadcast their contact-address? IMHO at least for the meta_client this is not required, since the meta_client only needs to access meta via the LB and after that it can contact the leader directly.


Yes, I meant in a figurative sense. It makes its contact-address available to the whole cluster by declaring it to etcd and proxied through meta nodes/LB.

© 2022 pullanswer.com - All rights reserved.