Question
NiFi 2.7.2 Cluster Instability After Scheduled Stop/Start - Seeking Best Practices
Environment
- NiFi 2.7.2, 3-node cluster (3EC2 - 3ASG)
- ZooKeeper: 3-node ensemble (ECS)
- NiFi Registry (ECS)
- AWS Step Functions for scheduled stop/start (cost optimization)
Problem
After an overnight shutdown/startup, the cluster becomes unstable:
- Nodes rapidly flap: CONNECTED → DISCONNECTED → CONNECTING (every 2-3 seconds).
- Error: "Have not received heartbeat from node".
- Critical: Disconnected node logs show NO errors/warnings - node appears healthy while coordinator reports it as disconnected.
Root Cause
Parallel startup via Step Function Map state causes:
- NiFi nodes start before the ZooKeeper quorum forms
- All 3 nodes start simultaneously → chaotic coordinator election
Resolution
Deleted flow.xml.gz on disconnected nodes → restart → nodes rejoined successfully
Proposed Solution
Sequential startup with proper wait times:
1. ZK1 → 60s → ZK2 → 60s → ZK3 → 120s (quorum)2. NiFi Registry → 90s3. Node 1 → 180s → Node 2 → 120s → Node 3 → 120s
Sequential shutdown (reverse order)
Questions
- Official guidance on startup sequencing for multi-node clusters with external ZooKeeper?
- Should ZooKeeper state be cleared during scheduled shutdowns?
- Why don't disconnected node logs show any issues? Node appears unaware of disconnection.
- Recommended wait times between service starts?
- Best practices for scheduled start/stop on auto-scaling infrastructure?
Setup Details
- 32GB RAM, 20GB heap, G1GC
- Java 21 Amazon Corretto
- Time sync verified (chrony < 1μs drift)
- Network healthy, no packet loss
Has anyone implemented similar scheduled automation for NiFi clusters? Any guidance appreciated!

