[
https://issues.apache.org/jira/browse/HBASE-23055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17013559#comment-17013559
]
Michael Stack commented on HBASE-23055:
---------------------------------------
bq. And for meta table, yes, we all know that the single meta region is a
bottle neck on large cluster but at least, it does not introduce damage to all
the 2.x users right?
Its arguable replacing procedure store was an emergency. It does not address
all cases of why we have stuck RIT. What was there basically worked in my
extreme loadings over last month or so. That said, I'm glad the work was done.
I saw an odd case of corruption in my loadings. We'll probably have corruption
in the new setup but as you argued making the change, we'll have a better
chance fixing any bugs when the procedure store is just like a user-space
Region. The procedure store change is a radical, risky undertaking in a minor
release but I'm happy to test at scale to ensure it is good before we cut 2.3.0.
Adding a feature on a minor release does not require that it address an
emergency.
Here I want to alter hbase:meta schema. Under load, RS carrying hbase:meta
burns way more CPU than other RSs. At extreme, I see all priority handlers
occupied showing Scanners iterating Cells in meta block. When I enable index,
meta throughput goes up noticably and CPU load falls off. Others will likely
want this benefit.
I have seen under sustained heavy load damage in the cluster (easy enough to
reproduce). The Master unable to access hbase:meta starts dropping edits
(CallQueueTooBigException); Master's accounting of cluster state begins to
stray. We need to dig in on rpc scheduling/queuing but faster meta updating
seems to put off the point of corruption in my testing. Because of this, I'd
like to enable indexes (Sorry, hard numbers are hard to obtain on a buckling
cluster).
I will work on version of this patch that allows alter of hbase:meta but that
does not allow disable of hbase:meta and that prevents operator delete of core
columnfamilies. If such a patch is a problem for you, please raise objections
here early so we can get them out of the way before I do the work. I'm not up
for predicating this change on splittable hbase:meta project nor on refactors
that break out Region from hbase-server module or that undo RegionServer
dependency in Region (all good things to do but out of scope for here IMO).
Thanks [~zhangduo]
> Alter hbase:meta
> ----------------
>
> Key: HBASE-23055
> URL: https://issues.apache.org/jira/browse/HBASE-23055
> Project: HBase
> Issue Type: Task
> Components: meta
> Reporter: Michael Stack
> Assignee: Michael Stack
> Priority: Major
> Fix For: 3.0.0, 2.3.0
>
>
> hbase:meta is currently hardcoded. Its schema cannot be change.
> This issue is about allowing edits to hbase:meta schema. It will allow our
> being able to set encodings such as the block-with-indexes which will help
> quell CPU usage on host carrying hbase:meta. A dynamic hbase:meta is first
> step on road to being able to split meta.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
