Database Reference
In-Depth Information
•
dfs.journalnode.edits.dir
: This is the complete path of the location where the ed-
its and other local state files on the machines running the JournalNode service are
stored. The following is a sample configuration entry for
dfs.journalnode.edits.dir
:
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/tmp/jnode</value>
</property>
Apart from the preceding properties, there are properties that are meant for fencing. Fen-
cing is a way to assure that only one namenode writes to the JournalNodes. However, it is
possible that when a failover is initiated, the previous active namenode may still serve cli-
ent requests till the namenode shuts down. The previous namenode shuts down when it
tries to write to the JournalNodes. Using fencing methods, this namenode can be shut
down as the failover is initiated.
The following are two fencing methods:
•
sshfence
•
shell
The type of fencing to be used is defined by the
dfs.ha.fencing.methods
prop-
erty, which is defined by the
hdfs-site.xml
file.
The
sshfence
option provides a way to SSH into the target node and use the
fuser
command to kill the process listening on the TCP port. In other words, it kills the previ-
ously active namenode. To perform this action, the SSH needs to happen without a pass-
phrase. For this to work, the
dfs.ha.fencing.ssh.private-key-files
prop-
erty needs to be configured. The following is a sample configuration entry to set up fen-
cing:
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/home/admin/.ssh/id_rsa</value>
</property>
