Thanks for the summary, and all your efforts on this enhancement, Bharath. Let me highlight here on point re: this architecture. Because the Master is use in place of ZooKeeper for clients to find their way around the cluster, this changes our operational requirements on the Master. With this feature enabled, operators will need to keep at least one Master up and responding to RPC's in order for clients to locate meta. As with the existing ZK-based meta location discovery, the location is cached by the client so as to not make excessive calls. There are tests in place that ensure this functionality behaves appropriately even if Master leader election somehow fails.
As for me, I'm +1 on merging this implementation to master and branch-2. Thanks, Nick On Tue, Feb 4, 2020 at 8:37 AM Bharath Vissapragada <[email protected]> wrote: > Hello everyone, > > I'd like to kickoff a discuss thread on dev@ to see what folks think about > merging the feature branch for HBASE-18095 > <https://issues.apache.org/jira/browse/HBASE-18095> into the master. For > those of you who aren't following this work, over the last few months, a > lot of effort went into a feature branch > < > https://github.com/apache/hbase/tree/HBASE-18095/client-locate-meta-no-zookeeper > > > to > remove the ZK dependency in the client. > > *Please refer to the design doc > < > https://docs.google.com/document/d/1JAJdM7eUxg5b417f0xWS4NztKCx1f2b6wZrudPtiXF4/edit > > > attached to the parent jira and go through the subtasks for all the > technical details and design considerations*. > > *TL;DR*: With this feature, the client connection implementation *does not* > need access to zookeeper to fetch the connection metadata. Instead, a > predefined set of master end points in the configuration are used by > clients to fetch the required metadata. > > This new feature is *enabled by default on the feature branch* and passes > the entire nightly test suite (modulo some known flakes not specific to the > branch). At this point, I'm not aware of any performance concerns / feature > gaps compared to original default implementation. The original registry > implementation is still retained and can be used by setting the following > client configuration. This kill switch gives the users more flexibility > since they have a fallback incase they run into any issues. > > <property> > <!-- Reverts to the original ZK based connection registry > implementation --> > <name>hbase.client.registry.impl</name> > <value>org.apache.hadoop.hbase.client.ZKConnectionRegistry</value> > </property> > > This work is also slated to go into the upcoming releases* 2.3.0* and > *1.6.0*. However, it will be *disabled by default*. Having this work back > ported to those branches enables users to try it out in their environments > and report any feedback. > > Please speak up (respond to this email) if there are any objections to > merging this work in the master branch. > > Many thanks to Nick Dimiduk, Andrew Purtell and Michael Stack for their > invaluable feedback throughout this work. > > - Bharath >
