ndimiduk commented on a change in pull request #1880: URL: https://github.com/apache/hbase/pull/1880#discussion_r438346674
########## File path: src/main/asciidoc/_chapters/cp.adoc ########## @@ -139,7 +139,7 @@ Referential Integrity:: Secondary Indexes:: You can use a coprocessor to maintain secondary indexes. For more information, see - link:https://wiki.apache.org/hadoop/Hbase/SecondaryIndexing[SecondaryIndexing]. + link:https://cwiki.apache.org/confluence/display/HADOOP2/Hbase+SecondaryIndexing[SecondaryIndexing]. Review comment: Yikes! https://issues.apache.org/jira/browse/HBASE-24533 ########## File path: src/main/asciidoc/_chapters/ops_mgt.adoc ########## @@ -3400,20 +3549,10 @@ Here is example using a few of the rsgroup commands. To add a group, do as foll .RegionServer Groups must be Enabled [NOTE] ==== -If you have not enabled the rsgroup Coprocessor Endpoint in the master and Review comment: Looks like I need to revert HBASE-23890 from this patch. ########## File path: src/main/asciidoc/_chapters/architecture.adoc ########## @@ -260,6 +260,73 @@ For region name, we only accept `byte[]` as the parameter type and it may be a f Information on non-Java clients and custom protocols is covered in <<external_apis>> +[[client.masterregistry]] +=== Master registry (new as of release 3.0.0) Review comment: @bharathv is there some tweak we can make to this language so that it's applicable to all the back ported branches as well? Backports have happened, so we can now be more precise about what the state is on each branch. Just a small change here saying something to the effect of "this is the new default in 3.0, but it available as an optional feature in versions 1.x+ and 2.y+" I see down in `configuration.adoc` it's very clear about what the state is on 3.x vs 2.3+. Let's get it as a separate ticket, I don't want to also make doc changes in this back-port ticket. ########## File path: src/main/asciidoc/_chapters/faq.adoc ########## @@ -33,7 +33,7 @@ When should I use HBase?:: See <<arch.overview>> in the Architecture chapter. Are there other HBase FAQs?:: - See the FAQ that is up on the wiki, link:https://wiki.apache.org/hadoop/Hbase/FAQ[HBase Wiki FAQ]. + See the FAQ that is up on the wiki, link:https://cwiki.apache.org/confluence/display/HADOOP2/Hbase+FAQ[HBase Wiki FAQ]. Review comment: Circular references are fun! https://issues.apache.org/jira/browse/HBASE-24534 ########## File path: src/main/asciidoc/_chapters/architecture.adoc ########## @@ -260,6 +260,73 @@ For region name, we only accept `byte[]` as the parameter type and it may be a f Information on non-Java clients and custom protocols is covered in <<external_apis>> +[[client.masterregistry]] +=== Master registry (new as of release 3.0.0) + +Client internally works with a _connection registry_ to fetch the metadata needed by connections. +This connection registry implementation is responsible for fetching the following metadata. + +* Active master address +* Current meta region(s) locations +* Cluster ID (unique to this cluster) + +This information is needed as a part of various client operations like connection set up, scans, +gets etc. Up until releases 2.x.y, the default connection registry is based on ZooKeeper as the +source of truth and the the clients fetched the metadata from zookeeper znodes. As of release 3.0.0, +the default implementation for connection registry has been switched to a master based +implementation. With this change, the clients now fetch the required metadata from master RPC end +points directly. This change was done for the following reasons. + +* Reduce load on ZooKeeper since that is critical for cluster operation. +* Holistic client timeout and retry configurations since the new registry brings all the client +operations under HBase rpc framework. +* Remove the ZooKeeper client dependency on HBase client library. + +This means that + +* At least a single active or stand by master is needed for cluster connection setup. Refer to +<<master.runtime>> for more details. +* Master can be in a critical path of read/write operations, especially if the client metadata cache +is empty or stale. +* There is higher connection load on the masters that before since the clients talk directly to +HMasters instead of ZooKeeper ensemble` + +To reduce hot-spotting on a single master, all the masters (active & stand-by) expose the needed +service to fetch the connection metadata. This lets the client connect to any master (not just active). + +==== RPC hedging Review comment: @bharathv @Apache9 what was the conclusion on RPC hedging? This was reverted, wasn't it? Need to update the docs here? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
