[
https://issues.apache.org/jira/browse/HBASE-23055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17013311#comment-17013311
]
Duo Zhang commented on HBASE-23055:
-----------------------------------
Let me explain my point. In general, the procedure store change is emergency,
and 'altering meta, splittable meta' are important but not emergency.
I've seen people sending emails to the mailing list about broken RIT procedures
hang the whole system and can not recover. Usually the solution is to remove
all the content under the MasterProcWALs and try restart again, and then
manually fix everything, this is almost a mission-impossible for junior users.
And proc-v2 is one of the most important feature for 2.x, so we have to try our
best to stablize it on branch-2.
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? And it is not likely that we could implement splittable meta
quickly on branch-2. So I define this type of things "important but not
emergency", That means, we have plenty of time to polish our design, think of
the future, set the road map and milestones, and finally have a (almost)
perfect solution for splittable meta.
Back to the patch here, yes, I think it is a bit like the RegionProcedureStore.
In fact, if it is not emergency, I would like to refactoring the HRegion class
and make it decouple with HRegionServer, and then the code for
RegionProcedureStore will be much cleaner. But it is not likely that we could
finish this in the near soon so I've done some dirty hacks to make it work. But
as I explained above, I do not think 'altering meta' needs the dirty hacks such
as transient meta state, modifying meta from client directly. And who has the
permission to modify meta table? And we also removed the checks of system table
so users can also modify system tables now. Have we considered this critically?
How about ACLs? In general, It is not a big deal to not get this in 2.3.0 or
even 2.4.0. We should have a clear road map on how these feature are
implemented and released.
Thanks.
> Alter hbase:meta
> ----------------
>
> Key: HBASE-23055
> URL: https://issues.apache.org/jira/browse/HBASE-23055
> Project: HBase
> Issue Type: Task
> 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)
