Camunda Cluster Migration

Migrating a running cluster without downtime

This procedure applies to migration from Camunda 7.24.0 to CIB seven 2.2 and higher versions.

CIB seven uses the same engine tables (ACT_*) as Camunda 7.24. A cluster whose nodes share one database can therefore be switched to CIB seven one node at a time, while it keeps serving requests. For a while, Camunda 7.24 nodes and CIB seven nodes run side by side on the same database, and running process instances continue on whichever node picks up their next job. The engine keeps no state between transactions, so it needs no session replication or distributed cache (see Clustering Model).

Prerequisites:

• All nodes run Camunda 7.24.0. Update older versions first.
• Your process applications are migrated with the migration script and deployed together with the CIB seven engine on each node.
• isAutoSchemaUpdate is false, so that no node changes the schema on start.

Configure the CIB seven nodes before you start them:

• useCibSevenNamespaceInScripting and useCibSevenNamespaceInReflection set to true, if your processes use org.camunda classes in scripts or store serialized Java objects (see Migration to CIB seven namespace).
• cronType set to SPRING53, if your timers use cron expressions. Camunda 7.24 parses cron expressions with the Spring 5.3 syntax, while CIB seven uses the Quartz syntax by default. With SPRING53, both engines compute the same due dates while they run side by side.
• The same JWT secret on all nodes, if you use the CIB seven webclient behind a load balancer (see Migration to CIB seven webclient).

Then switch the cluster:

1. For each node: take it out of the load balancer, stop it gracefully, start it with CIB seven and the migrated process applications, wait until all deployments are started, and put it back into the load balancer.
2. When all nodes run CIB seven, run the engine upgrade scripts from sql/upgrade (from <database>_engine_7.24_to_2.1.sql up to your target version). For the engine tables, they only record the new version in ACT_GE_SCHEMA_LOG.
3. CIB seven 3.0.0 and later only: If you use webclient extensions such as Modeler or Chat, create their additional tables by running sql/create/<database>_extensions_<version>.sql from the CIB seven distribution. These scripts are available starting with CIB seven 3.0.0. The script only adds new tables, related to the webclient extensions; the Camunda nodes ignore them.

On Kubernetes or OpenShift, a rolling update of the Deployment follows the same steps: a readiness probe, for example on /engine-rest/process-definition/count, keeps a pod out of the Service until its engine is up. If step 3 applies, the extensions tables must exist before the first CIB seven pod with webclient extensions enabled starts.

The same procedure works in the reverse direction, as long as:

• you have not run the upgrade scripts of step 2, and
• no CIB seven node has stored Java-serialized objects that contain org.camunda classes again: with useCibSevenNamespaceInReflection, CIB seven may write them with org.cibseven class names, which Camunda cannot read.