Hi @Meepoljd    As per the description of the issue, I believe you are hitting ZOOKEEPER-1622 . Cloudera has already released TSB-2022-577 for this. As mentioned in the TSB, the session IDs should be unique but due to this bug, two clients might use the same session ID and hence causing the unexpected session termination. ... View more

Hello @loridigia ,   It seems due to the outage there would be multiple ServerCrashProcedures created for the Regionservers. The Dead region severs with same names are different instances of the Region servers with a different epoch timestamp. As the Hbase Master was also down, it might be possible that it was not able to process the expiration of the Region servers. You might see some Crash procedures waiting to be finished under "Procedures & Locks" section of the Active Hbase Master Web UI. As you have already solved this issue in the past involving zookeeper. I guess you can try this : 1. Stop Hbase 2. Login to zookeeper using #hbase zkcli ( with a valid hbase ticket ) 3. Delete the /hbase-secure znode. rmr /hbase-secure 4. Sideline the entries under HDFS dir. hdfs dfs -mv /hbase/MasterProcWALs/*  /tmp. ( Not sure if this was done earlier ) 5. Start Hbase ... View more

Hello @KPG1 ,   The time taken to mark a datanode as stale is give by dfs.namenode.stale.datanode.interval, with a default of 30 seconds. If this is happening with a specific Datanode, you can check if there is any network issues between the Datanode and the Namenode or if the Datanode has any JVM pauses reported by checking the Datanode logs. As a bandaid, you can bump up the above parameter till the underlying problem is solved. ... View more

Hello,   Based on the above test, I guess you are hitting HBASE-21852 which is still unresolved in the upstream. ... View more