目录

 

概述

原理

主备切换

小结:

概述

进入到了hadoop 2.x的时代,为了保证namenode上的元数据不会丢失,而且是高可用的,出现了双实例HA的机制

原理

集群里启动两个namenode,一个是active状态(主),一个是standby(备)状态。所有的操作都是发送给active namenode的,然后standby namenode是一个热备,不停的同步元数据 集群里引入一组节点,叫做journal nodes,一般是启动3个journal nodes,用来保存edits log这种操作日志 每次namenode有一个元数据变更,就要将这个edits log发送给journal nodes里的大多数standby namenode就监控journal nodes里的edits log变更,只要变更了就会读取edits log,同时应用到自己本地的内存里去,形成一个跟active namenode一致的fsiamge数据在内存里如果active namenode挂掉了,那么此时standby namenode立刻就会感知到的,然后他会确保自己从journal nodes读取了所有的edits log之后,内存的fsimage绝对是最新的之后,就会将自己切换为active namenode,形成主备切换。

主备切换

ZKFC两个进程保证自动faillover,就是每个namenode机器上都要跑一个ZKFailoverController的进程,简称之ZKFC,他们俩会不断的监控两个namenode,同时在zookeeper集群上(至少3个节点)维护namenode的状态如果active namenode挂了,那么ZKFC里的也给HealthMonitor就会监控到,然后就会告诉ZKFC里的一个FailoverController通知说namenode挂了,接着FailoverContrller找ActiveStandbyElector组件说要主备重新选举ActiveStandbyElector就会基于zk集群完成主备选举,会选举出来standby namenode作为主然后zk会通知standby机器上的ZKFC中的ActiveStandbyElector组件,ActiveStandbyElector通知FailoverController要切换standby为active了,然后FailoverController再通知standby namenode切换为active namenodejournal nodes只允许一台namenode给他写edits log,就是为了避免脑裂问题,两台namenode的网络环境不通了,他们俩都以为自己是active往journal nodes写数据,此时只能有一台写

小结:

namenode数据不会丢失,因为有journal nodes在里面用多台机器保存着,namenode高可用,一台挂了,另外一台立马接管,数据一致所有的datanode都是配置了两台namenode,那么datanode会将自己的block report汇报给主备两台namenode,确保他们都能感知到集群里的datanode的状态和block的情况

好文推荐

评论可见,请评论后查看内容,谢谢!!!
 您阅读本篇文章共花了: