Upgrade strategies

When you upgrade to a new DS version, you choose between:

Upgrade in place: unpack the new software over the old software and run the upgrade command.
Add new servers then retire old ones.

For some scenarios, like upgrading Docker images in a Kubernetes deployment, you must upgrade in place.

Upgrade in place

The most straightforward option when upgrading DS servers is to upgrade in place. DS software provides an upgrade command to simplify the process.

One by one, you stop, upgrade, and restart each server individually, leaving the service running during upgrade:

Advantages Disadvantages

Advantages	Disadvantages
No additional systems to manage.	During the upgrade, the host system must meet the requirements for both the older version and the new release. For example, you may need to have more than one Java environment installed. The operating system must also be supported for both releases.
Simpler to understand.	Slower to roll back. Rollback involves restoring each server to its pre-upgrade state. Once a replica’s databases have been upgraded, they cannot be rolled back.
Easier to maintain compatibility. To the extent possible, the `upgrade` command leaves the configuration as is.	You must manually enable new features after the upgrade.

No additional systems to manage.

During the upgrade, the host system must meet the requirements for both the older version and the new release.

For example, you may need to have more than one Java environment installed. The operating system must also be supported for both releases.

Simpler to understand.

Slower to roll back.

Rollback involves restoring each server to its pre-upgrade state.

Once a replica’s databases have been upgraded, they cannot be rolled back.

Easier to maintain compatibility.

To the extent possible, the upgrade command leaves the configuration as is.

You must manually enable new features after the upgrade.

On upgrading replicas

The in-place upgrade process is designed to support a rolling (sequential) upgrade of replicated servers.

Do not upgrade all replicated servers at once in parallel, as this removes all replication changelog data simultaneously, breaking replication.

If the deployment includes DS 7.4.0 servers with data encryption using default settings, you must add new servers instead. For details, read Upgrade from DS 7.4.0.

When upgrading in place, follow these steps for each replica:

Direct client application traffic away from the server to upgrade.
Upgrade the replica.
Direct client application traffic back to the upgraded server.

Add new servers

Adding new servers and then retiring old ones is an alternative to upgrading in place. You replicate data between old and new systems, leaving the service running during the upgrade:

Advantages Disadvantages

Advantages	Disadvantages
Smoothly phase out old host systems. After successfully completing the upgrade, you gradually retire the old systems.	New host systems to manage.
Faster to roll back. Old servers remain in operation until the upgrade completes successfully.	Harder to maintain compatibility. You must manually configure new servers to be fully compatible with existing servers, rather than relying on the `upgrade` command. This requires an in-depth understanding of both your existing configuration and the new configuration. Some new default settings may be incompatible with the old default settings, for example.
	Requires initializing the new replicas. Depending on the volume of data to synchronize, you can initialize at least the first new replica online. For deployments with medium to large data sets, initialize from exported LDIF or from backup files created using an upgraded DS server. In either case, you must plan the operation.
	While the upgrade is in progress, replication monitoring is split between the older servers that use `dsreplication status` and the newer servers that use `dsrepl status`. Run both commands to get a more complete picture of replication status.
	You must manually enable new features after the upgrade.

Smoothly phase out old host systems.

After successfully completing the upgrade, you gradually retire the old systems.

New host systems to manage.

Faster to roll back.

Old servers remain in operation until the upgrade completes successfully.

Harder to maintain compatibility.

You must manually configure new servers to be fully compatible with existing servers, rather than relying on the upgrade command. This requires an in-depth understanding of both your existing configuration and the new configuration. Some new default settings may be incompatible with the old default settings, for example.

Requires initializing the new replicas.

Depending on the volume of data to synchronize, you can initialize at least the first new replica online. For deployments with medium to large data sets, initialize from exported LDIF or from backup files created using an upgraded DS server. In either case, you must plan the operation.

While the upgrade is in progress, replication monitoring is split between the older servers that use dsreplication status and the newer servers that use dsrepl status.

Run both commands to get a more complete picture of replication status.

You must manually enable new features after the upgrade.

PingDS 7.5.1

Upgrade strategies

Upgrade in place

On upgrading replicas

Add new servers