[
https://issues.apache.org/jira/browse/HBASE-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991101#comment-12991101
]
stack commented on HBASE-3499:
------------------------------
@JD You thinking that we'd open the region if NOT bootstrap and check whats in
-ROOT-. If 16M for BLOCKSIZE, edit and write it back out again. An extra open
of the -ROOT- by the Master. Or you thinking something dumber where as soon as
-ROOT- is deployed, we go a get on .META. schema and if 16M, edit it.
You think this a blocker JD?
> Users upgrading to 0.90.0 need to have their .META. table updated with the
> right MEMSTORE_SIZE
> ----------------------------------------------------------------------------------------------
>
> Key: HBASE-3499
> URL: https://issues.apache.org/jira/browse/HBASE-3499
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.90.0
> Reporter: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.90.1
>
>
> With Jack Levin, we were able to figure that users that are upgrading from a
> 0.20.x era cluster have their .META. schema set with a 16KB MEMSTORE_SIZE.
> This was done in order to minimize lost meta rows when append wasn't
> available but even if we changed it in HTD, we also have to make sure all
> users upgrading to 0.90 have it changed too.
> In Jack's case, he ended up with 2143 storefiles in .META. during a cold
> start, slowing everything down. He reported a few times in the past that his
> .META. was always extremely busy.
> We should be able to do it as a one-off thing in HMaster when opening .META.
> (an update in place).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
