[jira] [Comment Edited] (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 edited comment on HBASE-24459 at 7/16/20, 7:28 PM:
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 -
asyncClusterConnection / ZKConnectionRegistry?) to get latest RegionLocations
for meta?
Moreover, cache invalidation for backup masters might be a tricky case.
was (Author: vjasani):
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] [Comment Edited] (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 edited comment on HBASE-24459 at 7/16/20, 11:06 AM: - 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? As of now, logic of *locateMetaRegion() call to active HMaster* is kept in AsyncMetaTableRegionLocator. Is it due to the same reason that we don't have a way for ZK Resitry to provide us meta regions? was (Author: vjasani): 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] [Comment Edited] (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 edited comment on HBASE-24459 at 6/26/20, 10:03 PM: -- 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? Or simpler, ROOT Table Region replication across all Masters; active and backups. For implementation later. was (Author: stack): 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)
