在CDH4中提供了NameNode和JobTracker的HA机制，本章就学习以下者两者的HA部署方法
HDFS High Availability
在减少整个HDFS集群的可用性方面主要有两个注意点：
1 一些意外事件的发生，比如机器crash，则整个集群会变得不可用，直到namenode重启恢复服务
2 计划中的机器维护，例如在namenode上的软件升级或者硬件升级，会导致集群在一段事件内不可用。
1 Introduction to HDFS High Availability
HDFS集群，在CDH4之前的版本，Namenode在HDFS集群中都是单点的(SPOF)，每个集群只有一个namenode，如果namenode机器或者进程出现故障，那么整个集群都会变成不可用，直到namenode进程重启或者重新启动一台namenode机器，注意，Secondary namenode这个组件，初看还以为是namenode的standby，其实该组件并不提供任何故障转移功能。
HDFS HA通过在一个集群中运行两个namenode节点来解决上述问题，一个namenode处于active状态，一个namenode处于standby状态，处于active状态的namenode负责所有客户端在集群内部的操作，处于standby状态的namenode就相当于slave，它维护足够的信息，在必要的时候进行故障快速转移。
CDH4提供两种主要的实现方式：
1 Quorum-based Storage
Quorum-based Storage实现HA机制依赖于Quorum Journal Manager (QJM)，为了使standby节点和active节点之间保持状态的同步，这两个节点都需要和一组独立分开的journalnodes进程通讯，当active节点执行了任何namespace的修改，它把这些修改记录保存在JournalNodes，standby节点可以从JournalNodes读取这些edit的信息，并且不断的监控edit log是否有变化，只要standby节点监控到这些变化，就会把这些变化应用到自己的namespace上，在故障转移事件中，standby在把它自己提升为active状态前会确认它是否已经读取了JournalNodes的所有的edits log。这样确保故障转移的时候standby的namespace是完全同步的。
为了提供快速的故障转移，还需要standby节点有整个集群自启动之后的所有blocks位置信息，为了达到这样的目的，datanodes配置中配置两个namenodes，并且发送block位置信息到
两个namenode上。
为了确保整个集群的HA机制正常运行，在同一时刻只能有一个namenode处于active状态，否则，namespace的状态会在两个namenode之间快速切换，这样会造成我们所说的脑裂问题，
JournalNodes在同一时刻只允许一个namenode节点进行写操作，在故障转移期间，哪个namenode处于active状态，才能在JournalNodes上执行写操作。
***Because of this, fencing is not required in a Quorum-based Storage deployment, as it is with Shared Storage using NFS. But fencing is still useful with Quorum-based Storage
2 Shared Storage Using NFS
因为CDH5已经不支持NFS了，所以本章就不讲解了，具体操作过程请看：官方文档HA方案之NFS
***cloudera建议你选择quorum-based storage作为你的解决方案，因为NFS只在CDH4中支持，在CDH5并不支持NFS方案。怎样从已有的NFS方案转移到Quorum-based方案呢？参看：NFS to Quorum-based Storag
2 Hardware Configuration for HDFS
这节主要讲解两种HA配置的硬件配置需求
1 Hardware Configuration for Quorum-based Storage
为了部署Quorum-based Storage模式的HA集群，你需要准备以下：
namenode机器 -- 该机器运行active和standby namenodes，他们应该有着相同的硬件配置。
JournalNode机器 -- 该机器只运行JournalNodes。
JournalNode进程是相当轻量级的，因此这些进程可以运行在集群内的其他机器上，例如：namenode、jobtracker、YARN RM等。cloudera建议你把JournalNode进程部署在“master”主机上，或者部署在namenode、standby namenode、jobtracker上。因此，JournalNode可以利用以上机器上面的本地存储空间。
在部署时至少要有三台JournalNode，edit log的修改必须写在大部分JournalNodes节点上面，这样系统可以允许一台JournalNode宕机，当然你也可以运行更多的JournalNode，但为了增加可以忍受的宕机数量，最好允许奇数数目的JournalNode节点。当你允许N台JournalNode节点，则系统可以忍受(N-1)/2台JournalNode宕机。如果需要的quorum数量不达标，则namenode会启动失败。
2 Hardware Configuration for Shared Storage Using NFS
因为不采用NFS方案，所以就不讲解该方案了，具体操作请看：NFS配置需求
3 Software Configuration for HDFS
该章节主要讲解两种HA配置的软件需求
1 Software Configuration for Quorum-based Storage
1 Configuration Overview
HA配置向后兼容并且允许现有的单节点namenode配置不需要配置就可以工作。新的配置文件被设计成使得在集群中的所有节点都可以具有相同的配置文件，而不需要部署不同的配置文件在
不同的机器上。
在由多个HA namenode组成的集群中，HA集群重复使用NameService ID来确定单个运行的HDFS实例。另外，一个抽象的概念叫NameNode ID，每个在集群中的namenode都有不同的NameNode ID，以支持所有的namenode可以使用一个配置文件，相关的配置参数都是以NameService ID或者NameNode ID结尾的。
1 Changes to Existing Configuration Parameters
如果你使用“mycluster”作为你的NameService ID，这将是你所有HDFS路径权威部分的值。你可以在core-site.xml文件中设置默认路径：
1 MRv1
<property>
<name>fs.default.name</name>
<value>hdfs://mycluster</value>
</property>2 YARN
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>2 New Configuration Parameters
继续配置HA namenode，需要在hdfs-site.xml配置文件中加几个配置项，这些配置项的顺序并不重要，但是你为dfs.nameservices和dfs.ha.namenodes.[NameService ID]设置的值将会决定它后面的keys，因此，在你设置其余的配置选项之前，应该先设置这些值。
1 dfs.nameservices 新的nameservice的本地名称
为nameservice选择一个本地名称，例如：mycluster，这个名称是可以随意选择的。如果你也使用了HDFS Federation，则这个配置是一个list，包含了其他nameservices。
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>2 dfs.ha.namenodes.[nameservice ID] 每个namenode在nameservice中的唯一识别符
是一个用逗号分隔的namenode ID列表，这个用来帮助datanode确认在集群中的所有namenode节点。例如，我们上面使用“mycluster”作为NameService ID的值，你使用“nn1”和“nn2”作为namenode的ID，则可以按照以下配置：
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2</value>
</property>***注意，在这个配置中最多只能有两个namenodes。
3 dfs.namenode.rpc-address.[nameservice ID].[name node ID] 每个namenode监听的RPC地址
对于两个之前设置的namenode ID，设置详细的地址和端口。这两个配置必须写在两个配置选项中，例如：
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>machine1.example.com:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>machine2.example.com:8020</value>
</property>4 dfs.namenode.http-address.[nameservice ID].[name node ID] 每个namenode监听的详细HTTP地址，和上面的RPC地址一样，例如：
<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>machine1.example.com:50070</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>machine2.example.com:50070</value>
</property>5 dfs.namenode.shared.edits.dir 共享存储目录的地址
配置提供共享edit存储的JournalNodes的地址，active namenode用来写入，standby namenode用来读取active namenode的改变信息。你必须设置多个JournalNode地址，并且把它们写在一个URL中， Journal ID是这个nameservice的唯一标示符，假如JournalNodes在HDFS集群中运行在 node1.example.com, node2.example.com, and node3.example.com上，并且nameserviceID是我们上面设置的mycluster，你可以按照以下设置来配置：
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value>
</property>6 dfs.journalnode.edits.dir JournalNode进程存储本地状态的目录。
在每个JournalNode机器上，配置绝对路径用来存储edit和其他的本地状态信息。只使用一个单一的路径。如下：
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/data/1/dfs/jn</value>
</property>
mkdir -p /data/1/dfs/jn
chown -R hdfs:hdfs /data/1/dfs/jn7 dfs.client.failover.proxy.provider.[nameservice ID] HDFS的客户端使用一个java类来和active namenode联系。
这个还真没搞懂具体是干啥的？？？？
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>8 dfs.ha.fencing.methods 一个java类或者一列脚本，在故障转移期间用来防护active namenode
集群中在任何时间必须确保只有一个namenode处于active状态，当你使用Quorum-based Storage模式，同一时刻只允许一个namenode给JournalNodes写数据，所以没有什么潜在的可能造成闹裂行为，但是当故障转移发生时，之前active namenode仍旧可能在接受客户端的请求，这些请求可能超时，直到namenode关闭。因此，我们应该配置一些防护措施。
在故障转移期间，fencing方法被配置成一个列表，用回车分隔的列表，将会在这些fencing中尝试，直到一个fencing返回成功为止。目前在hadoop中有两个fecing方法：
sshfence：sshfence - SSH to the Active NameNode and kill the process
使用SSH连接到目标节点，使用fuser杀死相关进程进程。为了使用sshfence，必须配置ssh无密码登陆，因此你必须配置dfs.ha.fencing.ssh.private-key-files选项，它的值是一个用逗号分隔的ssh 私有key列表。这个文件必须可以被运行namenode进程的用户可读。例如：
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/home/exampleuser/.ssh/id_rsa</value>
</property>shell：shell - run an arbitrary shell command to fence the Active NameNode
shell fencing方法运行一个shell命令，例如：
<property>
<name>dfs.ha.fencing.methods</name>
<value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
</property>3 Automatic Failover Configuration
以上章节讲解了怎样通过手动配置故障转移。在上面的模式中，系统不会自动的触发故障转移机制，从actice到stanby，即使active node已经失效。因此，这个章节讲解怎样配置和部署自动转移故障。自动故障转移需要添加两个新的组件：ZooKeeper quorum和ZKFailoverController进程
1 ZooKeeper是一个高可用服务，维护协调少量数据，通知客户端更改数据，监控客户端故障。HDFS的自动故障转移依赖zookeeper的以下特性：failure detection--每个在集群中的namenode机器维护一个到zookeeper的session，如果机器crash了，zookeeper session会过期，通知其他namenode故障转移应该被触发了。active namenode election--zookeeper提供一个简单的机制来选择一个node作为active状态。
2 ZKFailoverController (ZKFC)，一个zookeeper客户端，监听和管理所有的namenode状态，每个运行namenode的机器都需要安装ZKFC，ZKFC的职责如下:
health monition--ZKFC周期性的ping本地的namenode来作为健康监测。只要namenode有回应，则认为是健康的。如果namenode crash、frozen或者其他状态，则monitor标记它为不健康状态。
zookeeper session management--当本地namenode健康的时候，ZKFC保持一个同zookeeper连接的session。如果本地namenode是active，则同时也保持一个对znode的特别锁。如果session过期，则锁会被自动删除。
zookeeper based election--如果本地namenode是健康的，并且ZKFC看到没有其他node持有znode锁，它则会试图取得该锁。如果获取了该锁，他就赢得了选举权，使本地的namenode变成active状态。
3 Deploying ZooKeeper
ZooKeeper进程一般部署在三台或者五台机器上面。ZooKeeper本身消耗很少的资源，所以它可以运行在namenode、standby namenode。zookeeper的部署参看：zookeeper部署
注意：在配置故障自动转移之前，先关掉集群
4 修改配置文件，如下：
#在hdfs-site.xml文件中做如下配置：
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
#接着在core-site.xml做如下配置：
<property>
<name>ha.zookeeper.quorum</name>
<value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
</property>在你配置完配置项之后，需要初始化zookeeper必须的状态，你可以再一个namenode节点上运行以下命令：
su - hdfs hdfs zkfc -formatZK以上命令会在zookeeper中创建znode，用来存储故障转移数据。
2 Software Configuration for Shared Storage Using NFS
关于NFS方案的介绍请看：NFS HA
4 HDFS High Availability Initial Deployment
在你配置完必须的配置项之后，你已经准备好启动两台namenode了，如果你启动的是新的HDFS集群，则需要初始化namenode。
1 Install and Start the JournalNodes (Quorum-based Storage only)
apt-get install hadoop-hdfs-journalnode
service hadoop-hdfs-journalnode start2 Initialize the Shared Edits directory
如果你是从non-HA模式转换到HA模式，则需要初始化共享edits目录。
su - hdfs hdfs namenode -initializeSharedEdits3 Start the NameNodes
1 启动active namenode
service hadoop-hdfs-namenode start 2 启动standby namenode
su - hdfs hdfs namenode -bootstrapStandby
service hadoop-hdfs-namenode start在启动standby namenode时使用参数-bootstrapStandby从primary namenode的metadata目录拷贝数据到standby namenode。
你可以在每个namenode节点通过配置的HTTP地址来查看namenode的状态，如果HA namenode启动了，而没有启动自动故障转移，则初始化standby状态，如果开启了自动故障转移，则第一个启动的namenode变成active状态。
4 Restart Services
如果你是从non-HA转换到HA模式，你需要重启 JobTracker, TaskTracker, and DataNode服务。
#DataNode节点
service hadoop-hdfs-datanode start
#TaskTracker节点
service hadoop-0.20-mapreduce-tasktracker start
#JobTracker节点
service hadoop-0.20-mapreduce-jobtracker start5 Deploy Automatic Failover
如果你是使用ZooKeeper FailoverController来配置自动故障转移，则需要在每个namenode节点上安装zkfc进程：
apt-get install hadoop-hdfs-zkfc
service hadoop-hdfs-zkfc start启动zkfc和namenode进程的顺序并无严格要求，你应该监控每个运行namenode主机上的zkfc进程在运行，同时还需要监控zookeeper集群。
5 HDFS HA Administration
1 HA Administration using the haadmin command
当你HA namenode配置好并且启动后，你可以使用一些额外的命令来管理你的HA HDFS集群。你要熟悉hdfs haadmin命令。
本章只讲解几个常用的，其他具体信息请看：hdfs haadmin -help <command>
failover--在namenodes之间发起一个故障转移，该子命令引起一个故障转移在你提供的namenode上，从第一个转移到第二个上面。如果提供的第一个namenode本来就是standby状态，则该命令简单的转变第二个namenode到active状态，并不返回错误。如果第一个namenode本来就是active状态，然后试图优雅的转换到standby状态，如果失败了，则fencing方法将会试图执行，直到一个fencing方法成功，只有这个操作完成后，第二个namenode才会转移到active状态，如果没有fencing方法执行成功，则第二个namenode不会转移到active状态，并且返回一个错误。
getServiceState--判断给定的namenode处于什么状态
checkHealth--检查给定的namenode的健康性，该子命令目前还未实现，总是返回success2 Using the dfsadmin command when HA is enabled
High Availability for the JobTracker (MRv1)
这个章节主要讲解怎样配置JobTracker的HA，以下主题提供了更多的信息和说明：
1 About JobTracker High Availability (HA)
如果你运行的是MRv1，你可以配置HA的Jobtracker。你可以配置手动或者自动的转移到standby jobtracker，目前没有支持YARN的HA机制，和HDFS HA一样，jobtracker HA也是向后兼容的，如
果你不想开启jobtracker HA，你可以保持你现有的配置文件不变，然后启动各个服务。如果你要启动jobtracker HA，则需要创建新的配置。新的配置文件被设计成使得在集群中的所有节点都可以具
有相同的配置文件，而不需要部署不同的配置文件在不同的机器上。
在集群中的每个JobTracker都有不同的JobTracker ID，用来支持一个配置文件适合所有的JobTracker。相关的配置选项一JobTracker本地名称或者JobTracker ID结尾。HA JobTracker的安装
包和non-HA的安装包不一样，你不能在一个集群中同时运行HA和non-HA JobTracker，如果不需要HA JobTracker就不要安装相关的包，如果你要从HA JobTracker转换到non-HA JobTracker，则需要卸
载掉HA JobTracker的安装包。
2 Replacing the non-HA JobTracker with the HA JobTracker
HA JobTracker安装包不能和non-HA JobTracker安装包安装在同一台机器上。
1 Removing the non-HA JobTracker
service hadoop-0.20-mapreduce-tasktracker stop
service hadoop-0.20-mapreduce-jobtracker stop
apt-get remove hadoop-0.20-mapreduce-jobtracker2 Installing the HA JobTracker
apt-get install hadoop-0.20-mapreduce-jobtrackerha3 install the failover controller package(Optionally)
apt-get install hadoop-0.20-mapreduce-zkfc3 Configuring JobTracker High Availability
本章节讲解HA JobTracker的配置，JobTracker HA在mapred-site.xml文件中重用了mapred.job.tracker参数来定义active-standby。你同时也必须开启mapred.jobtracker.restart.recover,
mapred.job.tracker.persist.jobstatus.active和mapred.job.tracker.persist.jobstatus.hours配置项。
1 Configuring and Deploying Manual Failover
1 Configure the JobTrackers, TaskTrackers, and Clients，Changes to existing configuration parameters
mapred.job.tracker(local)--在HA模式中，逻辑名称是JobTracker active-standby....在non-HA模式中，该参数的值是一个host:port的字符串格式，但是在HA模式下，逻辑名称必须是不包含端口的
mapred.jobtracker.restart. recover(false)--在HA模式下必须设置为true
mapred.job.tracker.persist. jobstatus.active(false)--在HA模式下必须设置为true
mapred.job.tracker.persist. jobstatus.hours(0)--job状态在HDFS中保存的时间，在HA模式下必须是一个大于0的数字
mapred.job.tracker.persist. jobstatus.dir(/jobtracker/jobsInfo)--一个HDFS目录，用来长久保持job状态，这个目录必须存在，并且属主为mapred用户。
# 以下部分是新增加的配置项
mapred.jobtrackers.<name>--一个分割开的active和standby的jobtrackers，name的值是mapred.job.tracker
mapred.jobtracker.rpc- address.<name>.<id>--独立的JobTracker的RPC地址，name值是mapred.job.tracker，id值是mapred.jobtrackers.<name>其中的一个。
mapred.job.tracker.http. address.<name>.<id>--独立的JobTracker的HTTP地址
mapred.ha.jobtracker. rpc-address.<name>.<id>--jobtracker的HA服务的RPC地址，jobtracker监听在一个独立的端口上。
mapred.ha.jobtracker. http-redirect-address.<name>.<id>--
mapred.ha.jobtracker.id--该JobTracker实例的身份，主要用来测试
mapred.client.failover. proxy.provider.<name>--故障转移提供的class，目前可用的class是org.apache.hadoop.mapred. ConfiguredFailoverProxyProvider
mapred.client.failover. max.attempts(15)--最多尝试故障转移的次数
mapred.client.failover. sleep.base.millis(500)--在第一次故障转移前等待的时间
mapred.client.failover. sleep.max.millis(1500)--故障切换之间等待的时间
mapred.client.failover. connection.retries(0)--故障切换之间尝试的次数
mapred.client.failover. connection.retries.on. timeouts(0)--
mapred.ha.fencing.methods--一个脚本列表，或者一个java class。 下面来看一个mapred-site.xml实例：
<configuration>
<property>
<name>mapred.job.tracker</name>
<value>logicaljt</value>
<!-- host:port string is replaced with a logical name -->
</property>
<property>
<name>mapred.jobtrackers.logicaljt</name>
<value>jt1,jt2</value>
<description>Comma-separated list of JobTracker IDs.</description>
</property>
<property>
<name>mapred.jobtracker.rpc-address.logicaljt.jt1</name>
<!-- RPC address for jt1 -->
<value>myjt1.myco.com:8021</value>
</property>
<property>
<name>mapred.jobtracker.rpc-address.logicaljt.jt2</name>
<!-- RPC address for jt2 -->
<value>myjt2.myco.com:8022</value>
</property>
<property>
<name>mapred.job.tracker.http.address.logicaljt.jt1</name>
<!-- HTTP bind address for jt1 -->
<value>0.0.0.0:50030</value>
</property>
<property>
<name>mapred.job.tracker.http.address.logicaljt.jt2</name>
<!-- HTTP bind address for jt2 -->
<value>0.0.0.0:50031</value>
</property>
<property>
<name>mapred.ha.jobtracker.rpc-address.logicaljt.jt1</name>
<!-- RPC address for jt1 HA daemon -->
<value>myjt1.myco.com:8023</value>
</property>
<property>
<name>mapred.ha.jobtracker.rpc-address.logicaljt.jt2</name>
<!-- RPC address for jt2 HA daemon -->
<value>myjt2.myco.com:8024</value>
</property>
<property>
<name>mapred.ha.jobtracker.http-redirect-address.logicaljt.jt1</name>
<!-- HTTP redirect address for jt1 -->
<value>myjt1.myco.com:50030</value>
</property>
<property>
<name>mapred.ha.jobtracker.http-redirect-address.logicaljt.jt2</name>
<!-- HTTP redirect address for jt2 -->
<value>myjt2.myco.com:50031</value>
</property>
<property>
<name>mapred.jobtracker.restart.recover</name>
<value>true</value>
</property>
<property>
<name>mapred.job.tracker.persist.jobstatus.active</name>
<value>true</value>
</property>
<property>
<name>mapred.job.tracker.persist.jobstatus.hours</name>
<value>1</value>
</property>
<property>
<name>mapred.job.tracker.persist.jobstatus.dir</name>
<value>/jobtracker/jobsInfo</value>
</property>
<property>
<name>mapred.client.failover.proxy.provider.logicaljt</name>
<value>org.apache.hadoop.mapred.ConfiguredFailoverProxyProvider</value>
</property>
<property>
<name>mapred.client.failover.max.attempts</name>
<value>15</value>
</property>
<property>
<name>mapred.client.failover.sleep.base.millis</name>
<value>500</value>
</property>
<property>
<name>mapred.client.failover.sleep.max.millis</name>
<value>1500</value>
</property>
<property>
<name>mapred.client.failover.connection.retries</name>
<value>0</value>
</property>
<property>
<name>mapred.client.failover.connection.retries.on.timeouts</name>
<value>0</value>
</property>
<property>
<name>mapred.ha.fencing.methods</name>
<value>shell(/bin/true)</value>
</property>
</configuration>2 Start the JobTrackers
service hadoop-0.20-mapreduce-jobtrackerha start3 Activate a JobTracker
除非配置了自动故障转移，否则两个jobtracker在jobtrackerha启动后都处于standby状态，在你执行mrhaadmin命令时，必须使用mapred用户。
sudo -u mapred hadoop mrhaadmin -getServiceState <id> id值是mapred.jobtrackers.<name>定义的其中一个，例如：jt1，jt2
sudo -u mapred hadoop mrhaadmin -transitionToActive <id> 把某一个jobtracker转换到active状态
sudo -u mapred hadoop mrhaadmin -getServiceState <id> 检查上一步的结果 4 Verify that failover is working
把当前active的jobtracker转换到inactive状态
sudo -u mapred hadoop mrhaadmin -failover <id_of_active_JobTracker> <id_of_inactive_JobTracker>
sudo -u mapred hadoop mrhaadmin -failover jt1 jt2 jt1转换到inactive状态
sudo -u mapred hadoop mrhaadmin -getServiceState jt2 这时候检查jt2，它已经切换到active状态了 2 Configuring and Deploying Automatic Failover
1 Configure a ZooKeeper ensemble (if necessary)
和namenode的自动故障转移一样，先搭建zookeeper
2 Configure parameters for manual failover
就是上面的手动设置过程
3 Configure failover controller parameters
使用下面的参数为每一个jobtracker配置故障转移控制机制，故障转移控制进程运行在jobtracker节点。
mapred.ha.automatic-failover.enabled(false)--如果开启自动故障转移，必须设置为true
mapred.ha.zkfc.port(8019)--zookeeper故障转移控制端口
ha.zookeeper.quorum--MRZKFailoverController使用的所有zookeeper节点
#mapred-site.xml：
<property>
<name>mapred.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
<property>
<name>mapred.ha.zkfc.port</name>
<value>8018</value>
<!-- Pick a different port for each failover controller when running one machine -->
</property>
#core-site.xml：
<property>
<name>ha.zookeeper.quorum</name>
<value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181 </value>
<!-- ZK ensemble addresses -->
</property>4 Initialize the HA state in ZooKeeper
在你配置完故障转移控制机制后，下一步是要初始化zookeeper所需要的状态，你可以在jobtracker上运行以下命令，不过在运行之前确保zookeeper已经启动了
service hadoop-0.20-mapreduce-zkfc init这会创建znode
5 Enable automatic failover
一旦你配置完毕，你就可以启动jobtracker哈和zkfc进程了
service hadoop-0.20-mapreduce-zkfc start
service hadoop-0.20-mapreduce-jobtrackerha start6 Verify automatic failover
#获取状态
sudo -u mapred hadoop mrhaadmin -getServiceState <id>
#手动让JVM crash
kill -9 <pid of JobTracker>
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
