Skip to content

Overview of dynamic upgrades

This page explains how dynamic and offline upgrades work in KX Sensors, when to use each, and what to expect in a multi-node environment.

This chapter covers dynamic and offline upgrades. Dynamic upgrades allow you to upgrade any component of your system without the need for a system shutdown and restart.

Dynamic upgrades are performed on the fly with zero downtime or disruption to KX Sensors operation. You can use dynamic upgrades in the following situations:

  • To install a minor version upgrade or patch release from KX.
  • To make minor non-KX changes to your system such as adding or removing table columns.

Note

If you are making major non-KX changes to your system, you may need to perform an offline upgrade with a system or node restart. Consult with KX when uncertain and always ensure upgrades are tested in a UAT environment before production release.

Dynamic upgrades fully support partial upgrades targeting service classes or processes. You can additionally target individual nodes and deploy schema or code changes only to that node as a rolling upgrade — see Multi-node environments below for how this works across a cluster.

If you make a mistake during a dynamic upgrade, you can roll back or downgrade the system to a previous version and then re-deploy the corrected package.

Typical upgrade steps

  1. Create a new package containing your schema, code, or API changes in your test environment. The package name must be distinct from existing packages already deployed to the system — for example, increment kxs-core-3.0.0 to kxs-core-3.0.1.
  2. Update .pkg to increment the version number associated with the package.
  3. Copy the package to the package directory on all nodes involved in the upgrade.
  4. Perform the upgrade using the KX Sensors CLI, which generates a unique revision number and propagates the upgrade to all specified processes.

Warning

Dynamic upgrade of the config objects feed.yaml and ems.yaml is not fully supported. These are typically configured in the env/ package. Any upgrade of the env/ package must not include changes to these objects.

Database integrity

Dynamic and offline upgrades involving a schema change must never be performed during DBC (Database Copy) operations.

Multi-node environments

In a multi-node environment, a release may be performed in a rolling manner of single-node releases, simultaneous multi-node releases, or a combination of both. Nodes not involved in the release continue to run on the older version. In all cases, nodes at different schema levels convert messages targeted to each other to the format that they expect in-transit.

If a release is issued while a node is down, the upgrade should proceed normally when it comes back up.

Dynamic vs offline upgrades

Dynamic upgrades differ from offline upgrades in that offline upgrades require the system to be restarted. In most cases, prefer dynamic upgrades. Notable exceptions are listed in Perform an offline upgrade and typically involve a custom upgrade script for schema modifications or changes to non-trivial configuration.

Next steps