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 a lot.
On the data freshness, this is a problem. But anyway, in the old master registry implementation, if you go to backup masters, you still can't always get the newest data. This is a problem we should try to do better, like using the above framework to replicate the modification quickly, without involving active master in the normal read/write path. Nick Dimiduk <[email protected]> 于2021年8月19日周四 上午2:38写道： > > 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 evolved since I last checked? > > On Sun, Aug 15, 2021 at 5:20 PM Bharath Vissapragada <[email protected]> > wrote: > > > 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 registry in 2.5.0 in favor of a "RegionServer" based registry and > > remove it completely in 4.0.0. IMO we should *not *expose any opt-in > > configuration to allow masters as that violates the design principle that > > we all agreed upon and instead only use region servers as the registry > > hosting services. > > > > > > On Fri, Aug 13, 2021 at 7:59 PM 张铎(Duo Zhang) <[email protected]> > > wrote: > > > > > 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 meta, we planned to > > > make use of this framework to hide the actual ROOT table > > > implementation. But then we found out that the approach of using > > > masters as connection registry, violates one of our tendencies that we > > > do not want to inline masters, especially the active master in the > > > normal read/write path. > > > > > > The several sub tasks of HBASE-26149 aims to solve this problem. We > > > all agree that by default, we should not inline masters, but there are > > > some conflicts on whether to still allow end users to configure that > > > they want to use masters as registry endpoints, as it is a feature > > > which has already been published in our releases. > > > > > > There are some discussions in the PR for HBASE-26172 > > > https://github.com/apache/hbase/pull/3566#discussion_r684494130 > > > > > > Feel free to post your opinion here. > > > > > > Thanks. > > > > >
