We already have a connection to zookeeper at region server side, and
we already watched a lot of things, so watching one more znode does
not add too much pressure to zk.
And I've been implementing a framework to replicate meta location
without zookeeper, this could reduce the pressure on zookeeper
Are you referring to meta region location(s) cache? If so, yes we will have
more network chatter accessing those znode(s) whenever meta (replicas) move
around (what happens in split-meta is still under discussion as you
probably are already following, but it is likely that we will still use ZK
as
I recall that there was a concern about data freshness, that the masters
were all tracking the necessary state and all of them would always be
up-to-date. Region servers were not already in this business, and doing so
would put undue burden on ZooKeeper.
Perhaps I miss-remember, or the discussion
OK, seems no big concerns here.
Then I will go with the cleaner way, deprecated MasterRegistry and do
not return masters as registry endpoints.
Thanks.
Bharath Vissapragada 于2021年8月16日周一 上午8:20写道：
>
> Thanks, Duo. I commented on the PR but want to respond here too to kick
> start the
Thanks, Duo. I commented on the PR but want to respond here too to kick
start the discussion and in case anyone else has different viewpoints.
I agree that the original decision of inlining active masters needs to be
corrected going forward. I vote for the proposal to deprecate the master
based
In HBASE-18095, the community provided a new way to get the registry
information of a cluster, without touching ZooKeeper. The decision at
that time was to use masters(including active and backup masters) as
the connection registry endpoint.
Later, when discussing how to implement splittable
