Hello @pauljoshiva The NameNode endeavors to ensure that each block always has the intended number of replicas. The NameNode detects that a block has become under- or over-replicated when a block report from a DataNode arrives. When a block becomes over replicated, the NameNode chooses a replica to remove. The NameNode will prefer not to reduce the number of racks that host replicas, and secondly prefer to remove a replica from the DataNode with the least amount of available disk space. The goal is to balance storage utilization across DataNodes without reducing the block's availability.   Hope this answers your query.      Regards, Manoj ... View more

If ranger database is corrupted then only option is to drop and recreate it (if we dont have backup). Refer the below article for steps to create ranger DB:   https://docs.cloudera.com/HDPDocuments/HDP3/HDP-3.1.5/installing-ranger/content/configuring_a_database_instance_for_ranger.html ... View more

@pauljoshiva    What this error is telling is that the flow.xml.gz on this node does not match the flow.xml.gz that is running on another node.  On startup of all your NiFi nodes an election takes place to determine which flow.xml.gz will be elected as the cluster flow.  So node 1 presents its flow (1 vote), then node 2 presents its flow (if it matches node 1's flow that flows vote increases to 2, if not it gets its own singular vote), this process repeats for all nodes joining the cluster until a flow.xml.gz is elected to be the cluster vote.  At that point in time, any nodes that have a flow.xml.gz that matched this elected cluster flow will throw the exception you  reported and shut back down. Since all nodes in your cluster must be running the exact same flow.xml.gz, you can copy the flow.xml.gz from one of the nodes that is up and joined in to the cluster to the node that threw the exception and restart it.  It should successfully join the cluster at on restart this time. Hope this helps, Matt ... View more