Updating a Cluster

Maintaining a cluster is a big responsibility. It includes deploying new and updated plugins and modules, applying fix packs, making configuration changes, and more. Maximizing server uptime and minimizing risks take priority when applying changes. Liferay DXP supports using standard cluster maintenance techniques.

  • Rolling restarts: Nodes are shut down and updated one at a time.
  • Blue-green deployment: Blue-green involves duplicating the current environment (blue environment), updating the duplicate (green environment), and cutting over users to the updated environment (green).

The techniques are compared below.

Cluster Update Techniques

Update Rolling Restart Blue-green
Plugin/module installationSupportedSupported
Plugin/module update (backward-compatible data/schema changes)SupportedSupported
Plugin/module update (non-backward-compatible data/schema changes) 1Not supportedSupported
Fix pack installation and removal (revertable fix pack)SupportedSupported
Fix pack installation (non-revertible fix pack)Not supportedSupported
Cluster code changes 2Not supportedSupported
Portal property changesSupportedSupported
System Setting changes via configuration admin filesSupportedSupported
Application server updatesSupportedSupported
JVM setting changesSupportedSupported
New Java version (minor)SupportedSupported
New Java version (major)Not supportedSupported

[1] Data and data schema changes that are not backward-compatible include, but are not limited to these:

  • Modifying data in existing columns
  • Dropping columns
  • Changing column types
  • Changing data formats used in columns (such as changing from XML to JSON)
  • Updating a Service Builder service module’s data schema to a version outside of the module’s required data schema range.

    A module’s Liferay-Require-SchemaVersion (specified in its bnd.bnd) must match the module’s schema version value in the Release_ table. Installing a module with a new schema version updates the Release_ table with that schema version and triggers a data upgrade process. If you install such a module on one node, the schema version in the Release_ table no longer matches the Liferay-Require-SchemaVersion of the modules on the other nodes, and the module’s Service Builder services become unavailable until the module is installed on the other nodes. Such changes cannot be reverted: the database must be restored from a backup. These schema version changes must be applied while all nodes are shut down.

[2] Cluster communication must stay intact. For this reason, cluster code must not be updated in rolling restarts. The Customer Portal identifies DXP fix packs that contain such changes as non-revertible. Here are packages you must not change in rolling restarts:

  • com.liferay.portal.kernel.cluster
  • com.liferay.portal.kernel.cluster.*
  • com.liferay.portal.kernel.exception.NoSuchClusterGroupException
  • com.liferay.portal.kernel.scheduler.multiple
  • com.liferay.portal.kernel.scheduler.multiple.*
  • com.liferay.portal.cache.multiple
  • com.liferay.portal.cache.multiple.*
  • com.liferay.portal.scheduler.multiple
  • com.liferay.portal.scheduler.multiple.*

Since eligible changes should be done with rolling restarts, it’s explained first.

« Auto Deploy to All NodesRolling Restarts »
Was this article helpful?
0 out of 0 found this helpful