HDFS~脑裂
一、脑裂介绍
在自动故障恢复过程中,如果同时存在两个Active NameNode,客户端可以连接任何一个,客户端发出改变文件或目录的请求时,是不会在两个NameNode之间同步的,因为两个Active NameNode都不屑于去读edits,那么树目录就对不上了,这就是脑裂
二、发生脑裂的原因
- 必须在Follower将Leader共享的edits中的所有日志全部读取并合并到fsimage后才能将Follower的身份切换为Leader,在此期间Leader不能向客户端提供任何服务
- Leader出现故障,系统开始改朝换代,当Follower完成全部工作并且成为Leader后,原Leader又复活了(它的故障可能是暂时断开或系统暂时变慢,不能及时响应,但其NameNode进程还在),并且由于某种原因它对应的ZKFC并没有把它设置为Standby,所以原Leader还认为自己是Leader,客户端向它发出的请求仍会响应,于是脑裂就发生了
三、防止脑裂的方法
- 杀死死掉的NameNode进程
- 当前HDFS支持两种edits共享方式:NFS和QJM
- 如果选择NFS,就需要做好fencing脚本
- 如果选择QJM,可以不需要fencing,因为QJM支持单方读写,在切换时,先将写入方设置为竞选成功的Follower,那么Leader就写不了edits了
HDFS~脑裂
一、脑裂介绍
在自动故障恢复过程中,如果同时存在两个Active NameNode,客户端可以连接任何一个,客户端发出改变文件或目录的请求时,是不会在两个NameNode之间同步的,因为两个Active NameNode都不屑于去读edits,那么树目录就对不上了,这就是脑裂
二、发生脑裂的原因
- 必须在Follower将Leader共享的edits中的所有日志全部读取并合并到fsimage后才能将Follower的身份切换为Leader,在此期间Leader不能向客户端提供任何服务
- Leader出现故障,系统开始改朝换代,当Follower完成全部工作并且成为Leader后,原Leader又复活了(它的故障可能是暂时断开或系统暂时变慢,不能及时响应,但其NameNode进程还在),并且由于某种原因它对应的ZKFC并没有把它设置为Standby,所以原Leader还认为自己是Leader,客户端向它发出的请求仍会响应,于是脑裂就发生了
三、防止脑裂的方法
- 杀死死掉的NameNode进程
- 当前HDFS支持两种edits共享方式:NFS和QJM
- 如果选择NFS,就需要做好fencing脚本
- 如果选择QJM,可以不需要fencing,因为QJM支持单方读写,在切换时,先将写入方设置为竞选成功的Follower,那么Leader就写不了edits了