Thank you for the inputs Bryan! Not much we can do at this time and need to figure out a way to incorporate secure 3.5.5 ZK running in parallel with ZK 3.4.x in our environment.
Thanks, Harsha Sent from Outlook<http://aka.ms/weboutlook> ________________________________ From: Bryan Bende <[email protected]> Sent: Thursday, June 4, 2020 3:34 PM To: [email protected] <[email protected]> Subject: Re: Upgrade NiFi 1.11.4 Cluster External ZooKeeper 3.4.X Hello, Starting with NiFi 1.10.0 [1], ZooKeeper 3.5.x is a requirement, it will not work with 3.4.x. It is generally not recommended to use embedded ZK for production. Thanks, Bryan [1] https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance On Thu, Jun 4, 2020 at 3:04 PM Sri Harsha Chavali <[email protected]<mailto:[email protected]>> wrote: Hi All, We have been running NiFi 1.9.2 (3 Node Cluster) with external ZooKeeper 3.4.X in both CDH 6.2.X and 5.15.X versions. We are trying to upgrade our NiFi cluster to version 1.11.4 but noticed that it has Zookeeper 3.5.5 dependency. I have a couple of questions after playing with NiFi 1.11.4 on my VM. 1. Is the ZK 3.5.5 a mandatory dependency or can we still live with ZK 3.4.x? 2. If ZK 3.5.5 is a mandatory dependency. Can we reliably run embedded ZK on all cluster nodes while not using the existing ZK which comes with our cluster? I ask this question because if we run a 3 node NiFi cluster with embedded ZK, the ZK on that node goes down along with NiFi when there is an issue. This will cause Quorum/voting issues and will that break the NiFi cluster? 3. If piggybacking on the existing External ZK 3.4.X is an option what is the functionality we will lose? Is it all the processors that rely on state-management that get effected? Thank you, Harsha Sent from Outlook<http://aka.ms/weboutlook>
