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了