管理指令碼遠端管理節點，再集群中隨便挑一台，把公鑰發給所有
搭建ha時，namenode的zkfc需要免秘鑰，用來管理自己和對方（故障應對）
邏輯物理對映
jn相關配置，資訊描述
故障發生時免秘鑰配置（還有一種是shell指令碼）
記得格式化之前啟動jn
第一台格式化之後啟動，並且讓後續namenode以standby啟動，就不用格式化了
zkfc有三隻手：zk，自己的namenode，還有對另外乙個namenode。因此免秘鑰不僅要和自己，還有和對方
不能直接格式化，兩個namenode。需要先開啟jn和zk。配置具體如下圖
啟動三個節點jn（包含免秘鑰過程），配置zk
namenode格式化
啟動第乙個nn
zk格式化 hdfs zkfc -formatzk （在zk上建立乙個新節點）
這裡三個節點兩個埠號的原因：
zk兩個狀態，可用和不可用。
zk作為分布式協調，zk集群應該要一直可靠執行。因此用主從模型leader和follower，所有增刪改都由f交給leader。
掛了之後無主模型，要推舉新的leader，對外繼續提供服務
200ms之內就可以恢復leader，掛了之後用3888選leader
之所以可以快，是因為選舉過程不用使用爭搶。server.x的這個x數字平時平級，在需要選舉時，亮出id，誰大誰就是leader。
zk兩個id，其中有乙個事物id：zxid，還有乙個server id
有事物時，不能強要求強一致性，強一致性可能破壞可用性。
一般有過半機制的存在，即有一半在事務決策或者選擇leader通過就行
zookeeper中設定了三個節點：
server.1=192.168.72.12:2888:3888
server.2=192.168.72.13:2888:3888
server.3=192.168.72.14:2888:3888
以我這三個節點為例，如果只啟動第乙個節點（指令：zkserver.sh start）
那麼會提示not running
如果啟動12，就會使2變為leader，因為這個時候已經過半了；即使再啟動3，3也和1一樣，是follower
最後的關鍵來了。
如果kill -9 加上第乙個nn
那麼第乙個節點zkfc還在，nn直接gg，node02去zk裡爭搶建立新點，變成active
即使重啟node01 的nn：hadoop-daemon.sh start namenode
此時node02還是active，node01變為standby
如果kill -9 加上第二個zkfc
那麼第乙個節點的zkfc將node02變為standby，同時將node01變為active
如果這個時候重新啟動第二個zkfc：hadoop-daemon.sh start zkfc，並且kill -9 加上第乙個zkfc
那麼第二個節點的zkfc將node01變為standby，同時將node02變為active
其實這意味著zkfc被再次啟動可以立刻參與到環境中去
按照上表重新部署
node02、node03、node04依次zkserver.sh start，由於過半機制的存在，node02為leader
node01作為管理節點，start-dfs.sh
停止：stop-dfs.sh；zkserver.sh stop
zkcli.sh
ls /
ls /hadoop-ha/mycluster
Hadoop中Namenode的HA查詢和切換
三颱小型hadoop集群，上星期公司機房停電了，這次上去start了集群，但是發現start之後無法工作了。檢視了jps發現該有的程序都有了，敲入 hadoop fs ls 報錯內容如下 org.apache.hadoop.ipc.remoteexception org.apache.hadoop....
Storm1 0支援HA集群部署（HA）
storm ha集群規劃 nimbus 192.168.175.141 active 192.168.175.142 supervisor 192.168.175.141,192.168.175.142,192.168.175.143 mv apache storm 1.0.2 storm stor...
Hadoop之HA高可用性
ha存在的背景 ha的工作原理圖 hdfs ha高可用性 1 active namenode對外提供服務和standby namenode時刻待機準備的 2 保證兩個namenode任何時候都是元資料同步的 3 standby namenode同樣需要去讀取fsimage和edits檔案 edits...