[
https://issues.apache.org/jira/browse/HBASE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111060#comment-17111060
]
Francis Christopher Liu edited comment on HBASE-11288 at 5/19/20, 10:42 AM:
----------------------------------------------------------------------------
{quote}
We store the procedure data in a local HRegion on master.
{quote}
I see thanks for the explanation and the link.
{quote}
And on client accessing meta, I think for root region it is fine. We do not
mirror all the requests to region servers to master, when will only contact
master when locating meta, which should be rarely happen.
{quote}
I can think of a couple of cases were it might not be good/ideal:
1. Large batch jobs that does lookups on an hbase table in tasks would hit it
on startup. Same for large application restarts (eg storm topologies, etc).
2. In the event of failure degradation is not as graceful, as if clients are
not able to find meta regions they will start hammering the master when the
master is already busy trying to recover the cluster.
3. Generally just misbehaving actors (eg poorly written applications) or buggy
third party client implementations that users attempt to use.
{quote}
And now we even have a MasterRegistry on 2.x, where we move the locating meta
requests from zk to master.
{quote}
I think what we might do is add a resolver plugin so all master registry
requests just go to the backup masters. I've not looked at the code yet but
maybe we can have the backup masters serve out the local hregion content from
the backup masters? IMHO ideally the registry should've been served out of
the regionservers. Today we have a "system" regionserver group where all the
system tables served out of (including root). With the new setup we would have
a system group and an extra set of master servers for serving out root and
registry stuff and the extra operational nuance of backup masters not just
being backup but doing active work for the system.
Just laying out my concerns let me know what you guys think? Let me know if
it's reasonable/unreasonable.
was (Author: toffer):
{quote}
We store the procedure data in a local HRegion on master.
{quote}
I see thanks for the explanation and the link.
{quote}
And on client accessing meta, I think for root region it is fine. We do not
mirror all the requests to region servers to master, when will only contact
master when locating meta, which should be rarely happen.
{quote}
I can think of a couple of cases were it might not be good/ideal:
1. Large batch jobs that does lookups on an hbase table in tasks would hit it
on startup. Same for large application restarts (eg storm topologies, etc).
2. In the event of failure degradation is not as graceful, as if clients are
not able to find meta regions they will start hammering the master when the
master is already busy trying to recover the cluster.
3. Generally just misbehaving actors (eg poorly written applications) or buggy
third party client implementations that users attempt to use.
{quote}
And now we even have a MasterRegistry on 2.x, where we move the locating meta
requests from zk to master.
{quote}
I think what we might do is add a resolver plugin so all master registry
requests just go to the backup masters. I've not looked at the code yet but
maybe we can have the backup masters serve out the local hregion content from
the backup masters? IMHO ideally the registry should've been served out of
the regionservers. Today we have a "system" regionserver group where all the
system tables served out of (including root). With the new setup we would have
a system group and an extra set of master servers for serving out root and
registry stuff and the extra nuance of backup masters not just being backup but
doing active work for the system.
Just laying out my concerns let me know what you guys think?
> Splittable Meta
> ---------------
>
> Key: HBASE-11288
> URL: https://issues.apache.org/jira/browse/HBASE-11288
> Project: HBase
> Issue Type: Umbrella
> Components: meta
> Reporter: Francis Christopher Liu
> Assignee: Francis Christopher Liu
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
