[
https://issues.apache.org/jira/browse/HBASE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13752103#comment-13752103
]
Himanshu Vashishtha commented on HBASE-9110:
--------------------------------------------
Stack,
bq. WHy not run log splitting as part of migration? Add a new step?
Hmmm, but the namespace upgrade is done on an offline cluster. With the current
approach, it is akin to adding a step in migration as when master is coming up
first time after post upgrade, it does the splitting. Or, do you mean some kind
of offline splitting for the current logs? The main advantage of this approach
is to fully re-use the existing log splitting mechanism, and we wouldn't
enforce a clean cluster shutdown as a prerequisite to upgrade.
Deveraj,
bq. why can't we blindly try to split meta-logs if the meta-location can't be
found in ZK?
You mean for "all" the dead regionservers (obtained from
getPreviouselyFailedMetaServersFromZK()), right? Otherwise, how will you know
which server had meta logs?
So, split meta-logs for all regionservers when meta-location couldn't be found.
That sounds right, but it will not cover migration from 0.94 (with no separate
meta logs). Otherwise, I buy that idea for normal case (infact, had similar
thoughts after uploading this patch).
> 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
>
>
> 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
