For the complete documentation index, see llms.txt. This page is also available as Markdown.

Upgrading from MariaDB Enterprise Server 10.6 to 11.8 with Galera Cluster

Upgrading a MariaDB Enterprise Server 10.6 Galera Cluster directly to 11.8 - the cluster-specific procedure (packages, bootstrap, state transfer) layered on top of the standalone 10.6-to-11.8 upgrade

Galera Cluster ships with MariaDB Enterprise Server. Upgrading a Galera Cluster node is very similar to upgrading a standalone server directly from MariaDB Enterprise Server 10.6 to 11.8. For the full list of prerequisites, removed and renamed options, character-set and optimizer-cost-model changes, and the reverse-replication safety net, follow the standalone guide:

Upgrading from MariaDB Enterprise Server 10.6 to 11.8

This page covers only what is specific to a Galera Cluster deployment: choosing an upgrade method, the Galera provider package, cluster shutdown order, and bootstrapping.

The direct upgrade from 10.6 to 11.8, skipping 11.4, is a supported Enterprise Server upgrade path - see the standalone guide linked above. This page applies that same jump to a Galera Cluster.

Choosing an Upgrade Method

There are two ways to move a Galera Cluster from 10.6 to 11.8. Which one you choose depends on whether you can tolerate a maintenance window.

  • Full cluster shutdown (recommended for the direct 10.6-to-11.8 jump). Stop every node, upgrade all nodes to 11.8, then bootstrap the cluster again. Because no 10.6 and 11.8 nodes are ever running at the same time, there is no mixed-version window to reason about - each node performs exactly the standalone 10.6-to-11.8 upgrade. This method requires a maintenance window.

  • Rolling upgrade through the intermediate LTS release (for zero downtime). Galera guarantees mixed-version replication only between adjacent releases, so a no-downtime rolling upgrade goes through the intermediate Enterprise Server LTS release rather than jumping straight to 11.8: 10.6 → 11.4 → 11.8.

The rest of this page describes the full-cluster-shutdown method.

Before You Begin

  • Read the standalone upgrade guide. All of the 10.6-to-11.8 configuration work - removed options that abort startup (wsrep_strict_ddl, wsrep_load_data_splitting, wsrep_replicate_myisam, and others), the character-set and optimizer-cost-model changes, and old_mode/character_set_collations compatibility - applies to every node. See Upgrading from MariaDB Enterprise Server 10.6 to 11.8.

  • Take a backup. Back up your data with mariadb-backup before proceeding.

  • Identify the most advanced node. Note which node has the highest wsrep_last_committed value at shutdown; you will bootstrap the new cluster from that node so it becomes the reference copy for state transfers.

  • Size gcache appropriately. A large enough gcache.size lets rejoining nodes catch up with an Incremental State Transfer (IST) instead of a full State Snapshot Transfer (SST). With a full shutdown, expect at least the first joining nodes to require an SST.

  • Finalize XA transactions. Run XA RECOVER and commit or roll back any prepared external XA transactions before stopping the service.

Performing a Full Cluster Shutdown Upgrade

1

Take a final backup and stop the whole cluster

Stop the application traffic (or drain the cluster from your load balancer or MaxScale), then perform a controlled shutdown on every node:

Stop the node holding the most up-to-date data last so it is the final writer, and record it - you will bootstrap from it in step 6.

2

Remove the 10.6 Enterprise packages on each node

Remove the old server together with the galera-enterprise-4 wsrep provider to avoid package-manager conflicts.

3

Switch each node to the 11.8 Enterprise repositories

4

Install the 11.8 release series on each node

Installing MariaDB-server pulls in the matching galera-enterprise-4 wsrep provider automatically - in the 11.8 series Galera is still a dependency of the server package. (This changes in MariaDB 12.3, where Galera moves to a separate mariadb-server-galera package.)

5

Apply the 11.8 configuration changes on each node

Before starting the service, update my.cnf on every node: scrub the removed 10.6 options and adopt the 11.8 defaults exactly as described in the standalone guide's Implement Version-Specific Configuration Changes and Incompatible and Significant Changes sections. Leave the Galera settings in your wsrep.cnf (such as wsrep_cluster_address and wsrep_provider_options) unchanged unless a value is explicitly removed in 11.8.

6

Bootstrap the first node

Start the most up-to-date node (identified in step 1) as the first member of the new cluster, using --wsrep-new-cluster (for example, galera_new_cluster). This node becomes the reference copy the other nodes synchronize from.

7

Start the remaining nodes

Start MariaDB normally on the other nodes, one at a time:

Each node rejoins the cluster and synchronizes via IST or SST. Wait for a node to reach Synced before starting the next one.

8

Run the data upgrade on each node

On every node, run mariadb-upgrade with --skip-write-binlog so the schema-fix statements are not replicated across the cluster:

This upgrades the system tables and marks all tables as compatible with 11.8.

Post-Upgrade Verification

After all nodes are upgraded, confirm the cluster is healthy and running 11.8:

  • VERSION() reflects the 11.8 series on every node.

  • wsrep_cluster_size equals the number of nodes in the cluster.

  • wsrep_cluster_status is Primary and wsrep_local_state_comment is Synced.

  • wsrep_provider_version is consistent across all nodes.

For general cluster health and quorum checks, see What is MariaDB Galera Cluster.

This page is licensed: CC BY-SA / Gnu FDL

spinner

Last updated

Was this helpful?