Breaking Upgrades

In some cases, an in-place update is not possible. This is true for unusually large or complex changes to the fundamental functioning of the system.

It may also come a time where operators may wish to replace one of Replicante Core dependencies, which prevents a gradual rollout. This breaking updates process can be used for that too.

More then one Replicante Core cluster MUST not be managing the same datastore or actions generated by the different clusters may cause conflicts or issues.

During the initial phases of development, large breaking changes are needed more frequently.

Supporting the full gradual release process while the system is evolving this fast is also very costly so it is not done every time.

1. Read the upgrade notes for any special consideration for the version you are upgrading to.
2. Install and configure a new set of dependencies, with any desired change.
3. Install and configure a new Replicante Core cluster on top of them (see the install section).
4. Remove all configured discovery backends.
5. Start the replicante processes on the new cluster.
6. For each discovery backend (or for groups of backends) configured on the existing cluster:
   1. Remove the backend (or group of backends) from the existing cluster.
   2. Rolling-restart all processes to prevent the existing replicante cluster for managing nodes.
   3. Add the backend (or group of backends) to the new cluster.
   4. Rolling-restart all processes to ensure the new cluster starts managing the nodes.
7. Once access to historic data is no long needed, delete the initial replicante cluster.

The process described above works because current data is either generated by the system or is historical data collected over time.

This will change once organisations are introduced and dynamic user content will be stored. When that happens, this process will be updated to support transferring user data across instances.