You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

These instructions assume:

Note:

  • You cannot have nodes with different NiFi versions in the same cluster.

  • Running multiple NiFi nodes on the same host machine is highly discouraged.

Release Notes & Migration Guidance

You should review the Release Notes carefully to ensure that you understand the changes made and the impact they may have on your existing data flows and/or environment.

The instructions below are general steps to follow when upgrading from one 1.x.0 release to another.  Check the Migration Guidance page for specific items that you should be aware of when moving between NiFi versions.

Before you begin

Before you begin, you can perform some tasks to improve the efficiency and success of your upgrade.

Preserving your custom processors

If you have written any custom NARs, first test and validate them in a separate desired release NiFi sandbox prior to upgrading.  The verified NARs can be preserved during the upgrade by storing them in a centralized location.

  1. Create a second library directory, called custom_lib.

  2. Move your custom NARs to this new lib directory.

  3. Add a new line to the nifi.properties file to specify this new lib directory:

nifi.nar.library.directory=./lib

nifi.nar.library.directory.custom=/opt/configuration_resources/custom_lib

Preserving your modified NARs

If you have modified any of the default NAR files, an upgrade will overwrite these changes. To preserve the customization:

  1. Identify and save the changes you have made to the default NAR files in your current instance.

  2. Perform your upgrade to the desired NiFi release.

  3. Redo the changes you have made to the NAR files in your new instance.

Installation

1. Download and extract the new NiFi tar.gz file.

2. For each node in your cluster, install the desired NiFi in parallel with your existing NiFi installation.  Assuming you have installed into an opt/ directory, for example:

Host Machine - Node 1

|--> opt/

   |--> 1.5.0-nifi

   |--> 1.6.0-nifi

 

Host Machine - Node 2

|--> opt/

   |--> 1.5.0-nifi

   |--> 1.6.0-nifi


Host Machine - Node 3

|--> opt/

   |--> 1.5.0-nifi

   |--> 1.6.0-nifi

 

Note:  Make sure that all file and directory ownerships for your new NiFi directories match what you set on the previous version.

3. On your existing NiFi installation:

  • Stop all processors responsible for ingesting new data.
  • Allow NiFi to run until no more FlowFiles are queued anywhere in the dataflow(s).
  • Shutdown your existing NiFi instance(s).

4. Use the <path to existing>/nifi/conf/ files to configure the corresponding files in your <path to new>/nifi/conf/ files of the same names.

Note:  If you are encrypting sensitive component properties in your dataflow via the sensitive properties key in nifi.properties file, make sure the same key is used when copying over your flow.xml.gz.  If you need to change the key, use the flow migration procedure and the NiFi Encrypt-Config Tool to produce a new flow.xml.gz file from the existing one.

5. Configure/confirm that your new instances point to the appropriate FlowFile, Content and Provenance repositories via the directory settings in the nifi.properties file.

6. To maintain state in your processors, copy the old local state directories to your new NiFi directories.  If you are also setting up a new external ZooKeeper, see the ZooKeeper Migrator section of the NiFi System Administrator’s Guide for instructions on how to move ZooKeeper information from one cluster to another and migrating ZooKeeper node ownership.

7. Start each of your new NiFi instances.

8. Verify that:

  • All your data flows have returned to a running state. Some processors may have new properties that need to be configured, in which case they will be stopped and marked “invalid”.
  • All your expected controller services and reporting tasks are running again.  Address any controller services or reporting tasks that are marked "invalid".

9. After confirming your new NiFi instances are stable and working as expected, the old instances can be removed.

  • No labels