Upgrade between versions

In which order to upgrade and what changes when you move up a patch, a minor or a major release.

Move your cluster from one TeselaDB release to another without stopping service. You always replace the binary node by node. Only if the new release announces a more recent MongoDB version do you then raise featureCompatibilityVersion.

Requirements

You have read the notes of the target release, above all "Breaking changes" and "Known issues".
The target release is the next minor after yours or a patch of your own minor. If you are further behind, upgrade to each minor in between, one after the other.
A recent backup.

Move up a patch or a minor

Replace the binary node by node, as Upgrade without downtime explains. While some nodes run each version, the cluster keeps serving.

Move up a major

Adapt your application to the breaking changes the release notes list, then replace the binary node by node as for a minor.

Turn on a more recent MongoDB version

featureCompatibilityVersion takes MongoDB versions, such as 9.0. When the notes say the new release announces a more recent MongoDB version, turn its features on once every node has it:

JavaScript

db.adminCommand({ setFeatureCompatibilityVersion: "<MongoDB version>", confirm: true });

Check

setFeatureCompatibilityVersion answers ok: 1 when every node supports that version. As on a MongoDB mongos, getParameter does not return featureCompatibilityVersion; that answer is your check.

Common problems

setFeatureCompatibilityVersion refuses the version because a node still runs the earlier binary. Finish replacing the binary on every node and run it again.
A new feature is not available after replacing every binary because featureCompatibilityVersion has not been raised yet.