[ 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)