[ 
https://issues.apache.org/jira/browse/HBASE-23055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17012514#comment-17012514
 ] 

Michael Stack commented on HBASE-23055:
---------------------------------------

bq. For the procedure store, it has an interface, so the damage to the whole 
architecture can be limited. But meta is another story, and is even more 
critical. We reference meta table descriptor everywhere in the code, not sure 
if there are other implicit assumptions in the code.

Mishap in store impl and the cluster is hosed, unfixable. There will be little 
solace that the store implementation is against an interface.

Default for this feature is no difference in operation. Regards implicit 
assumptions in the code, perhaps, but would think full test suite run would 
have turned up the worst offenders. In testing, looking for others.

bq. I think we’d better do this on feature branch, do more testing, fix 
problems, and then merge it back.

It'll get more testing being in upcoming RC that it will having it out on 
feature branch.

Any objection to the workings of the patch as is? It has been made less 
ambitious than previous go around.



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

Reply via email to