[HBASE-20159] Support using separate ZK quorums for client

• Type: New Feature
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 3.0.0-alpha-1, 2.1.0
• Component/s: Client, Operability, Zookeeper
• Hadoop Flags: Incompatible change, Reviewed

Release Note

After HBASE-20159 we allow client to use different ZK quorums by introducing three new properties: hbase.client.zookeeper.quorum and hbase.client.zookeeper.property.clientPort to specify client zookeeper properties (note that the combination of these two properties should be different from the server ZK quorums), and hbase.client.zookeeper.observer.mode to indicate whether the client ZK nodes are in observer mode (false by default)

HConstants.DEFAULT_ZOOKEPER_CLIENT_PORT has been removed in HBase 3.0 and replaced by the correctly spelled DEFAULT_ZOOKEEPER_CLIENT_PORT.

• Assignee: Yu Li
• Reporter: Yu Li
• Created: 08/Mar/18 07:33
• Updated: 26/Mar/19 02:32
• Resolved: 04/Apr/18 04:38

Description

Currently we are using the same zookeeper quorums for client and server, which makes us under risk that if some client connection boost exhausted zookeeper, RegionServer might abort due to zookeeper session loss. Actually we have suffered from this many times in production.

Here we propose to allow client to use different ZK quorums, through below settings:

hbase.client.zookeeper.quorum
hbase.client.zookeeper.property.clientPort
hbase.client.zookeeper.observer.mode

The first two are for specifying client zookeeper properties, and the third one indicating whether the client ZK nodes are in observer mode. If the client ZK are not observer nodes, HMaster will take responsibility to synchronize necessary meta information (such as meta location and master address, etc.) from server to client ZK

Issue Links

• breaks: HBASE-22079 master leaks ZK on shutdown and gets stuck because of netty threads if netty socket is used
• is related to: HBASE-20862 Address 2.1.0 Compatibility Report Issues
• links to: ReviewBoard