Discussion: Proper handling of Meta endpoint address

Question

Discussion: Proper handling of Meta endpoint address

risingwavelabs/risingwave

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

Here are some recommendations:

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.
To be clearer, LeaderService should not have current_leader but default_leader_as_self when election_client is None
Leader id stored in etcd is not guaranteed to be unique. We should have cluster membership to check uniqueness. (TODO)
Remove host addr from MetaNodeOpts, this currently does nothing

3 4 4

database serverless sql rust postgresql cloud-native stream-processing distributed-database

jon-chuang

2023-01-25

CAJan93

2023-01-25

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.

0

jon-chuang

2023-01-25

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.

0

CAJan93

2023-01-25

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.

0

jon-chuang · Accepted Answer · 2023-01-25

jon-chuang

2023-01-25

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.

1