[
https://issues.apache.org/jira/browse/HBASE-26150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack updated HBASE-26150:
----------------------------------
Description:
Usually region server will be deployed on machines which are more powerful than
masters, so it will be good to let region servers carries more load.
h2. Background
This is preliminary work needed for one of the [splittable meta
designs|https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.90th11txi153].
We want to hide the implementation of ROOT from the client side, by adding new
methods in ClientMetaService for locating meta Regions.
One of the concerns is that the original implementation of the Master Registery
over in HBASE-18095 puts master inline in the normal read/write path, which is
not always a good choice. This issue aims to move the ConnectionRegistry off of
the masters.
In this issue, we let the region server implement the ClientMetaService
interface, so the client could also get the cluster id, active master, meta
region location, etc. from RegionServers (and not just Masters as it is
currently).
We introduce a new method getBootstrapNodes in ClientMetaService, for
refreshing the bootstrap nodes periodically or on error. The new
RpcConnectionRegistry will use this method to refresh the bootstrap nodes,
while the old MasterRegistry will use the getMasters method to refresh the
‘bootstrap’ nodes.
The getBootstrapNodes method will return all the region servers, so after the
first refreshing, the client will go to region servers for later rpc calls. But
since masters and region servers both implement the ClientMetaService
interface, it is free for the client to configure master as the initial
bootstrap nodes.
was:Usually region server will be deployed on machines which are more
powerful than masters, so it will be good to let region servers carries more
load.
> Let region server also carry ClientMetaService
> ----------------------------------------------
>
> Key: HBASE-26150
> URL: https://issues.apache.org/jira/browse/HBASE-26150
> Project: HBase
> Issue Type: Sub-task
> Components: Client, meta
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Priority: Major
> Fix For: 2.5.0, 3.0.0-alpha-2
>
>
> Usually region server will be deployed on machines which are more powerful
> than masters, so it will be good to let region servers carries more load.
> h2. Background
> This is preliminary work needed for one of the [splittable meta
> designs|https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.90th11txi153].
> We want to hide the implementation of ROOT from the client side, by adding
> new methods in ClientMetaService for locating meta Regions.
> One of the concerns is that the original implementation of the Master
> Registery over in HBASE-18095 puts master inline in the normal read/write
> path, which is not always a good choice. This issue aims to move the
> ConnectionRegistry off of the masters.
> In this issue, we let the region server implement the ClientMetaService
> interface, so the client could also get the cluster id, active master, meta
> region location, etc. from RegionServers (and not just Masters as it is
> currently).
> We introduce a new method getBootstrapNodes in ClientMetaService, for
> refreshing the bootstrap nodes periodically or on error. The new
> RpcConnectionRegistry will use this method to refresh the bootstrap nodes,
> while the old MasterRegistry will use the getMasters method to refresh the
> ‘bootstrap’ nodes.
> The getBootstrapNodes method will return all the region servers, so after the
> first refreshing, the client will go to region servers for later rpc calls.
> But since masters and region servers both implement the ClientMetaService
> interface, it is free for the client to configure master as the initial
> bootstrap nodes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
