[jira] [Commented] (HBASE-24459) Move the locateMeta logic from AsyncMetaRegionTableLocator to ConnectionRegistry
[
https://issues.apache.org/jira/browse/HBASE-24459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159413#comment-17159413
]
Viraj Jasani commented on HBASE-24459:
--
Thanks [~zhangduo].
{quote}at server side, we will provide caches at backup masters to handle the
requests.
{quote}
This means backup masters will have to talk to active HMaster(through client /
ZKConnectionRegistry?) to get latest RegionLocations for meta since we can't
get that detail from ZK anymore?
> Move the locateMeta logic from AsyncMetaRegionTableLocator to
> ConnectionRegistry
>
>
> Key: HBASE-24459
> URL: https://issues.apache.org/jira/browse/HBASE-24459
> Project: HBase
> Issue Type: Sub-task
>Reporter: Duo Zhang
>Priority: Major
>
> Now the related code is only in AsyncMetaRegionTableLocator, we could make
> the actually implementation pluggable, so we do not always need to go to the
> active master.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-24459) Move the locateMeta logic from AsyncMetaRegionTableLocator to ConnectionRegistry
[ https://issues.apache.org/jira/browse/HBASE-24459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159242#comment-17159242 ] Duo Zhang commented on HBASE-24459: --- The plan is to let the ZKConnectionRegistry to go to the active master, as we can get the active master from zk. It will be the registry used inside HBase Cluster, i.e, the Connections at RS side will use it to locate meta. And for MasterConnectionRegistry, the client side is almost the same, we will do hedge requests to the configured masters, and at server side, we will provide caches at backup masters to handle the requests. > Move the locateMeta logic from AsyncMetaRegionTableLocator to > ConnectionRegistry > > > Key: HBASE-24459 > URL: https://issues.apache.org/jira/browse/HBASE-24459 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > > Now the related code is only in AsyncMetaRegionTableLocator, we could make > the actually implementation pluggable, so we do not always need to go to the > active master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-24459) Move the locateMeta logic from AsyncMetaRegionTableLocator to ConnectionRegistry
[ https://issues.apache.org/jira/browse/HBASE-24459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158625#comment-17158625 ] Viraj Jasani commented on HBASE-24459: -- Few questions: If we move locateMeta to ConnectionRegistry, MasterRegistry can call MasterProtos.locateMetaRegion(), however, what about ZKConnectionRegistry? Are we expecting default registry to be MasterRegistry with splittable meta work (skimmed through design doc, maybe I missed something related to this)? I think mostly no because many internal cluster connections still do require ZKConnection right? I hope the intention of this Jira is for clients to hedge the requests in a random order to avoid hot-spotting a single HMaster, hence using Master Registry. Also, with splittable meta, we have no chance of ZK locating meta regions. Is that correct? > Move the locateMeta logic from AsyncMetaRegionTableLocator to > ConnectionRegistry > > > Key: HBASE-24459 > URL: https://issues.apache.org/jira/browse/HBASE-24459 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > > Now the related code is only in AsyncMetaRegionTableLocator, we could make > the actually implementation pluggable, so we do not always need to go to the > active master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-24459) Move the locateMeta logic from AsyncMetaRegionTableLocator to ConnectionRegistry
[ https://issues.apache.org/jira/browse/HBASE-24459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149508#comment-17149508 ] Duo Zhang commented on HBASE-24459: --- I think we could start this one? Any volunteers? > Move the locateMeta logic from AsyncMetaRegionTableLocator to > ConnectionRegistry > > > Key: HBASE-24459 > URL: https://issues.apache.org/jira/browse/HBASE-24459 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > > Now the related code is only in AsyncMetaRegionTableLocator, we could make > the actually implementation pluggable, so we do not always need to go to the > active master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-24459) Move the locateMeta logic from AsyncMetaRegionTableLocator to ConnectionRegistry
[ https://issues.apache.org/jira/browse/HBASE-24459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146657#comment-17146657 ] Michael Stack commented on HBASE-24459: --- Duo has talked of keeping the ConnectionRegistry Interface read-only and simple so Implemention could go against an existing caching tier. Could also keep the cache tier in-cluster with Master farming out location updates on (rare) change via remote procedure infrastructure so any RegionServer can participate? For implementation later. > Move the locateMeta logic from AsyncMetaRegionTableLocator to > ConnectionRegistry > > > Key: HBASE-24459 > URL: https://issues.apache.org/jira/browse/HBASE-24459 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > > Now the related code is only in AsyncMetaRegionTableLocator, we could make > the actually implementation pluggable, so we do not always need to go to the > active master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
