When configuring for Embedded Zookeeper for NiFi, question regarding generating 'state' directory

[#1]

Hi,

Reading the latest NiFi manual from the Hortworks web site: http://docs.hortonworks.com/HDPDocuments/HDF1/HDF-1.2.0.1/bk_AdminGuide/content/index.html (this uses NiFi version 0.6.0.)

The manual talks about creating a 'state' directory you need to use, when you want to use "embedded zookeeper' for a clustered NiFi environment:

When using an embedded ZooKeeper, the ./conf/zookeeper.properties file has a property nameddataDir. By default, this value is set to./state/zookeeper. If more than one NiFi node is running an embedded ZooKeeper, it is important to tell the server which one it is. This is accomplished by creating a file named myid and placing it in ZooKeeper's data directory. The contents of this file should be the index of the server as specific by theserver.<number>. So for one of the ZooKeeper servers, we will accomplish this by performing the following commands:

cd $NIFI_HOME

mkdir state

mkdir state/zookeeper

echo 1 > state/zookeeper/myid


When I started looking around the directories, before running these commands from the manual, I found a 'state' directory already in out there in the same directory level as 'conf', 'logs' and 'bin'. The ONLY sub-directory under "state" was" "local".

I don't want to 'assume' anything.  Should I use this 'state' directory and build a 'zookeeper' sub directory in it, then add the file called 'myid'?  I am logged on as the root user trying to create this.  

[#2 · Accepted solution]

Yes you can use that state directory and just create the zookeeper sub directory in which you will have the myid file. I do recommend that your state directory is instead created somewhere outside of the base NiFi install path. This can aid in simplifying future upgrades of NiFi. Since newer version will still want to reference the existing cluster wide state created in your existing NiFi version. If you do choose to move it form default, update the zookeeper properties file and create the new path.

[#3]

That state directory you found only exists because at some point you started your NiFi instance and it was generated by the application. Had this been a fresh install it would not have existed and you would have needed to create yourself to complete the zookeeper setup.

[#4]

Hello,

Thank you for the fast reply. Someone else initially installed the software. A start command was issued via a NiFi Service once, then we realized I needed to go in and edit several of the properties files for this configuration, since it is a Clustered environment. Have we unintentionally caused the configuration to be unusable, or should we reload the software?

Now I am trying to go back and edit all of the configuration files like: nifi.properties, bootstrap,zookeeper, authority providers and users... to try and set this up for a cluster environment using embedded zookeeper.

Thank you for your reply.

[#5]

The fact that it was started without any configuration modification will have only one impact. With default configuration, the NiFi instance would have started http as a standalone instance. As a result it would have generated a flow.xml.gz file and a templates directory inside the NiFi conf directory. If the cluster NCM you are joining this node to already has a existing flow or templates, this node will fail to join because they will not match. NO need to reinstall to fix this if that is the case. Simply delete the flow.xml.gz file and the templates directory before starting it again. When it joins the cluster it will get the current flow and templates from the NCM.

[#6]

Thank you very, very much for your feedback.

[#7]

Hello one last time, as follow-up to your last comment:

"If the cluster NCM you are joining this node to already has an existing flow or templates, this node will fail to join because they will not match. NO need to reinstall to fix this if that is the case. Simply delete the flow.xml.gz file and the templates directory before starting it again. When it joins the cluster it will get the current flow and templates from the NCM."

When the " start" command was originally issued (to accidently make this a standalone configuration) nothing had been configured - there was no NCM or node specific parameters defined. Bottomline: There were no other NiFi configurations previously in existence in this environment.

Thanks again for your great answers and the articles you post to this site. They are very much appreciated.