[
https://issues.apache.org/jira/browse/HBASE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753289#comment-13753289
]
stack commented on HBASE-9110:
------------------------------
So, if -ROOT- got changed recently such that latest edit is in memory and not
flushed out AND .META. has edits up in memory that are not flushed though we
asked operator to flush .META. (and -ROOT- I suppose too) before shutting down
the cluster AND it is not a clean shutdown, yeah, this could be an issue.
Downside of the migration running the log splitting is that (as Himanshu
uncovered), it is not a distributed log split so will run slower which would
only really be a problem if cluster totally crashed down (it could be hours
before cluster could come back up -- in this case we'd probably suggest restart
0.94 until get a clean or mostly clean shutdown). Other minor downside is we
might split logs for a server no longer online (this'd probably be good though).
What you have [[email protected]]? If you have the logsplitter, we could
commit that for the RC?
> Meta region edits not recovered while migrating to 0.96.0
> ---------------------------------------------------------
>
> Key: HBASE-9110
> URL: https://issues.apache.org/jira/browse/HBASE-9110
> Project: HBase
> Issue Type: Sub-task
> Components: migration
> Affects Versions: 0.95.2, 0.94.10
> Reporter: Himanshu Vashishtha
> Priority: Critical
> Fix For: 0.96.0
>
> Attachments: HBase-9110-v0.patch, HBase-9110-v1.patch
>
>
> I was doing the migration testing from 0.94.11-snapshot to 0.95.0, and faced
> this issue.
> 1) Do some edits in meta table (for eg, create a table).
> 2) Kill the cluster.
> (I used kill because we would be doing log splitting when upgrading anyway).
> 3) There is some dependency on WALs. Upgrade the bits to 0.95.2-snapshot.
> Start the cluster.
> Every thing comes up. I see log splitting happening as expected. But, the
> WAL-data for meta table is missing.
> I could see recovered.edits file for meta created, and placed at the right
> location. It is just that the new HMaster code tries to recover meta by
> looking at meta prefix in the log name, and if it didn't find one, just opens
> the meta region. So, the recovered.edits file, created afterwards, is not
> honored.
> Opening this jira to let folks give their opinions about how to tackle this
> migration issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
