PingDS 8.0.0

Upgrade strategies

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

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.

If you want to use new hardware, you can often still upgrade in place. Move a server to the new hardware, then upgrade it in place.

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

Upgrade in place
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.

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. Learn more in Upgrade from DS 7.4.0.

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

  1. Direct client application traffic away from the server to upgrade.

  2. Upgrade the replica.

  3. 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.

When upgrading by adding new servers, reuse the server IDs of retired servers. After you retire a server, reuse its server ID the next time you add a new server.

This reduces the proliferation of obsolete server IDs polluting the replication topology state data.
Add new servers
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.

You must manually enable new features after the upgrade.

Blue-green deployment

Blue-green deployment is a way of making changes by alternating "blue" and "green" servers:

  • Start with existing servers that don’t change.

  • Add servers that apply the change.

  • Validate the change.

You can use this method to:

  • Upgrade servers.

  • Upgrade or refresh a server computer’s operating system or the JVM DS uses.

  • Test compatible configuration changes.

  • Apply patches.

Whatever changes you make—​OS and JVM updates, configuration and schema changes, DS upgrades or patches, and so on—​keep the following in mind.

DS replicates the same data to all DS servers in the deployment, regardless of whether you think of them as "blue" servers or "green" servers.

It’s better to roll out configuration, schema, and data changes separately from DS version upgrades.

When you write data to a "green" server, it replicates the change to the "blue" and the "green" servers. Likewise, changes to a "blue" server’s data replicate to the "green" and the "blue" servers. You’ll break things if you make changes to "blue" servers that render replicated data incompatible with "green" servers or the other way around. "Blue" and "green" servers are all part of the same deployment pool.

If a change could cause problems that only arise with live client applications, try a canary release. Direct a portion of client traffic to one server, make the change to the server, and monitor how the change affects the clients and DS.