Switching Implementations When switching between implementation
"families" (i.e. VolatileProvenanceRepository or
PersistentProvenanceRepository to
EncryptedWriteAheadProvenanceRepository), the existing
repository must be cleared from the file system before starting NiFi. A terminal
command like localhost:$NIFI_HOME $ rm -rf
provenance_repository/ is sufficient.

Switching between unencrypted and encrypted repositories

If a user has an existing repository
(WriteAheadProvenanceRepository only - notPersistentProvenanceRepository) that is not
encrypted and switches their configuration to use an encrypted repository, the
application writes an error to the log but starts up. However, previous events are
not accessible through the provenance query interface and new events will
overwrite the existing events. The same behavior occurs if a user switches from an
encrypted repository to an unencrypted repository. Automatic roll-over is a future
effort (NIFI-3722) but NiFi is not intended for long-term storage of provenance
events so the impact should be minimal. There are two scenarios for
roll-over:

Encrypted → unencrypted - if the previous repository implementation was
encrypted, these events should be handled seamlessly as long as the key
provider available still has the keys used to encrypt the events (see
Key Rotation)

Unencrypted → encrypted - if the previous repository implementation was
unencrypted, these events should be handled seamlessly as the previously
recorded events simply need to be read with a plaintext schema record reader
and then written back with the encrypted record writer

There is also a future effort to provide a standalone tool in NiFi Toolkit to
encrypt/decrypt an existing provenance repository to make the transition easier.
The translation process could take a long time depending on the size of the
existing repository, and being able to perform this task outside of application
startup would be valuable (NIFI-3723).

Multiple repositories - No additional effort or testing has been applied to
multiple repositories at this time. It is possible/likely issues will occur with
repositories on different physical devices. There is no option to provide a
heterogenous environment (i.e. one encrypted, one plaintext repository).

Corruption - when a disk is filled or corrupted, there have been reported issues
with the repository becoming corrupted and recovery steps are necessary. This is
likely to continue to be an issue with the encrypted repository, although still
limited in scope to individual records (i.e. an entire repository file won't be
irrecoverable due to the encryption).