[
https://issues.apache.org/jira/browse/HDFS-5138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883415#comment-13883415
]
Suresh Srinivas edited comment on HDFS-5138 at 1/27/14 10:51 PM:
-----------------------------------------------------------------
bq. The concern is about losing edit logs by overwriting a renamed directory
with some contents, so by definition there will be some files in the directory
being renamed to.
That makes sense. Thanks.
bq. The preupgrade and upgrade failure scenarios should both be handled either
manually or by the storage recovery process
I do not think JN performs recovery, based on the following code from
JNStorage.java
{code}
void analyzeStorage() throws IOException {
this.state = sd.analyzeStorage(StartupOption.REGULAR, this);
if (state == StorageState.NORMAL) {
readProperties(sd);
}
}
{code}
For JournalNode, StorageDirectory#doRecover() is not called. Is that correct?
From my understanding, once it gets into this state, JournalNode restart will
not work?
was (Author: sureshms):
bq. The concern is about losing edit logs by overwriting a renamed directory
with some contents, so by definition there will be some files in the directory
being renamed to.
That makes sense. Thanks.
bq. The preupgrade and upgrade failure scenarios should both be handled either
manually or by the storage recovery process
I do not think JN performs recovery, based on the following code from
JNStorage.java
{code}
void analyzeStorage() throws IOException {
this.state = sd.analyzeStorage(StartupOption.REGULAR, this);
if (state == StorageState.NORMAL) {
readProperties(sd);
}
}
{code}
For JournalNode, StorageDirectory#doRecover() is not called. Is that correct?
From my understanding, once it gets into this state, JournalNode should not
startup?
> Support HDFS upgrade in HA
> --------------------------
>
> Key: HDFS-5138
> URL: https://issues.apache.org/jira/browse/HDFS-5138
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.1.1-beta
> Reporter: Kihwal Lee
> Assignee: Aaron T. Myers
> Priority: Blocker
> Fix For: 3.0.0
>
> Attachments: HDFS-5138.patch, HDFS-5138.patch, HDFS-5138.patch,
> HDFS-5138.patch, HDFS-5138.patch, HDFS-5138.patch, HDFS-5138.patch,
> HDFS-5138.patch, HDFS-5138.patch, HDFS-5138.patch, HDFS-5138.patch,
> hdfs-5138-branch-2.txt
>
>
> With HA enabled, NN wo't start with "-upgrade". Since there has been a layout
> version change between 2.0.x and 2.1.x, starting NN in upgrade mode was
> necessary when deploying 2.1.x to an existing 2.0.x cluster. But the only way
> to get around this was to disable HA and upgrade.
> The NN and the cluster cannot be flipped back to HA until the upgrade is
> finalized. If HA is disabled only on NN for layout upgrade and HA is turned
> back on without involving DNs, things will work, but finaliizeUpgrade won't
> work (the NN is in HA and it cannot be in upgrade mode) and DN's upgrade
> snapshots won't get removed.
> We will need a different ways of doing layout upgrade and upgrade snapshot.
> I am marking this as a 2.1.1-beta blocker based on feedback from others. If
> there is a reasonable workaround that does not increase maintenance window
> greatly, we can lower its priority from blocker to critical.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
