These instructions detail the upgrade from MariaDB ColumnStore 6 to MariaDB ColumnStore 23.10 in a Multi-Node topology on a range of supported Operating Systems.

Set Replicas to Maintenance Mode

This action is performed for each replica server on the MaxScale node.

Prior to upgrading, the replica servers must be set to maintenance mode in MaxScale. The replicas can be set to maintenance mode in MaxScale using . If you are using , the replicas can be set to maintenance mode using the set server command:

maxctrl set server \
   mcs2 \
   maintenance

• As the first argument, provide the name for the server

• As the second argument, provide maintenance as the state

This action is performed on the MaxScale node.

Confirm that the replicas are set to maintenance mode in MaxScale using . If you are using , the state of the replicas can be viewed using the command:

If the node is properly in maintenance mode, then the State column will show Maintenance as one of the states.

This action is performed on each replica server.

The system variable must be disabled for this upgrade procedure. If the gtid_strict_mode system variable is enabled in any configuration files, disable it temporarily until the upgrade procedure is complete.

You can check if the gtid_strict_mode system variable is set in a configuration file by executing my_print_defaults command with the mysqld option:

If the gtid_strict_mode system variable is set, you can temporarily disable it by adding # in front of it in the configuration file, so that it will be treated as a comment and ignored:

Prior to upgrading, MariaDB Enterprise ColumnStore must be shutdown.

This action is performed on each ColumnStore node.

Prior to upgrading, several services must be stopped on each ColumnStore node:

1. Stop the service:

2. Stop the MariaDB Enterprise ColumnStore service:

3. Stop the MariaDB Enterprise Server service:

MariaDB Corporation provides package repositories for YUM (RHEL, CentOS, Rocky Linux) and APT (Debian, Ubuntu).

1. Retrieve your Customer Download Token at and substitute for CUSTOMER_DOWNLOAD_TOKEN in the following directions.

2. Configure the YUM package repository.

   Enterprise ColumnStore 23.10 is included with MariaDB Enterprise Server 11.4. Pass the version to install using the --mariadb-server-version flag to .

   To configure YUM package repositories:

1. Retrieve your Customer Download Token at and substitute for CUSTOMER_DOWNLOAD_TOKEN in the following directions.

2. Configure the APT package repository.

   Enterprise ColumnStore 23.10 is included with MariaDB Enterprise Server 11.4. Pass the version to install using the --mariadb-server-version flag to .

   To configure APT package repositories:

This action is performed on each ColumnStore node.

After upgrading, the MariaDB Enterprise ColumnStore service should be stopped, since it will be controlled by :

CMAPI disables the Enterprise ColumnStore service in a multi-node deployment. The Enterprise ColumnStore service will be started as-needed by the CMAPI service, so it does not need to start automatically upon reboot.

This action is performed on each ColumnStore node.

After upgrading, the service and the MariaDB Enterprise Server service must be started on each ColumnStore node:

1. Start the CMAPI service:

2. Start the MariaDB Enterprise Server service:

On the primary server, run to upgrade the data directory with binary logging enabled to update the system tables:

After upgrading, MariaDB Enterprise ColumnStore must be started.

This action is performed on each replica server.

If you temporarily disabled the system variable in the step, it can be re-enabled. If the gtid_strict_mode system variable was temporarily disabled in any configuration files, re-enable it.

This action is performed on each ColumnStore node.

After upgrading, it is recommended to confirm the Enterprise ColumnStore version on each ColumnStore node. Connect to the node using and query the ColumnStore_version status variable with :

This action is performed on each ColumnStore node.

After upgrading, it is recommended to confirm the ES version on each ColumnStore node. Connect to the node using and query the system variable with :

This action is performed for each replica server on the MaxScale node.

After the upgrade, maintenance mode for each replica has been cleared in MaxScale using . If you are using , maintenance mode can be cleared using the clear server command:

• As the first argument, provide the name for the server

• As the second argument, provide maintenance as the state

This action is performed for each replica server on the MaxScale node.

Confirm that maintenance mode in MaxScale has been cleared for each replica using . If you are using , the state of the replicas can be viewed using the list servers command:

If the node is no longer in maintenance mode, then the State column will no longer show Maintenance as one of the states.

_{This page is: Copyright © 2026 MariaDB. All rights reserved.}

_{This page is: Copyright © 2026 MariaDB. All rights reserved.}

These instructions detail the comprehensive upgrade path from MariaDB ColumnStore 6 to MariaDB ColumnStore 23.10 in a Multi-Node topology. To ensure a successful upgrade, it is highly critical to execute package updates simultaneously across all nodes and ensure strict CMAPI synchronization.

1. Pre-Upgrade Preparation

Before making any modifications, prepare your cluster and secure backups of your current state.

• Perform Backups: Consider taking a full production backup using bash mcs_backup_manager.sh backup (note that this will lock out writes during the backup). Determine the primary node by running mcs cluster status and take a DBRM backup using bash mcs_backup_manager.sh dbrm_backup -bl <path> -nb before-shutdown-before-upgrade.

• Save Configurations: On every node, create a timestamped directory and save backups of Columnstore.xml, storagemanager.cnf, cmapi_server.conf, and server.cnf.

• Set Maintenance Mode: On the MaxScale node, set each replica server to maintenance mode to prevent traffic routing during the upgrade. You can do this using MaxCtrl (e.g., maxctrl set server mcs2 maintenance). Verify this by running maxctrl list servers; the state should reflect Maintenance.

• Disable GTID Strict Mode: Temporarily disable the gtid_strict_mode system variable on each replica server to reduce the chance of replication issues. Comment out gtid_strict_mode=1 in your configuration files (e.g., /etc/my.cnf.d/server.cnf).

Services must be completely shut down across the cluster prior to upgrading packages.

1. Stop Cluster: On the primary node, stop the ColumnStore cluster by executing mcs cluster stop.

2. Stop Node Services: On every node, stop the MariaDB Enterprise Server, MariaDB ColumnStore, and CMAPI services.

3. Terminate Orphaned Processes: On every node, forcefully kill any remaining ColumnStore processes if needed. Check for processes like PrimProc, ExeMgr

1. Configure Package Manager: On every node, configure the package repository using the MariaDB Enterprise Release Helper script. Pass the target version using the --mariadb-server-version="11.4" flag (as Enterprise ColumnStore 23.10 is included with MariaDB Enterprise Server 11.4).

2. Execute Update: On every node at the same time, execute the package update.

   • For YUM (RHEL/CentOS): sudo yum update "MariaDB-*" "MariaDB-columnstore-engine" "MariaDB-columnstore-cmapi"

With packages updated, services must be brought back online in a specific order to allow CMAPI to synchronize the cluster state.

1. Start Services: On every node, start and enable the MariaDB server and CMAPI services.

2. Verify Status: On the primary node, check the status using mariadb -e "show status like '%Columnstore%';" and mcs cluster status. Ensure all nodes and dbroots are present. (If there are issues, you may need to restore the Columnstore.xmlbacked up earlier and run clearShm ).

1. Write Binary Log: On the primary server, run mariadb-upgrade --write-binlog to upgrade the data directory with binary logging enabled to update system tables.

2. Verify Versions: On each node, query SHOW GLOBAL STATUS LIKE 'Columnstore_version'; to confirm the version reads 23.10.0, and SHOW GLOBAL VARIABLES LIKE 'version'; to check the ES version.

_{This page is: Copyright © 2026 MariaDB. All rights reserved.}

This page provides a major release upgrade procedure for MariaDB ColumnStore. A major release upgrade is an upgrade from an older major release to a newer major release, such as an upgrade from MariaDB ColumnStore 5 to MariaDB ColumnStore 22.08.

Compatibility

• ColumnStore 5

• ColumnStore 6

• ColumnStore 22.08

This procedure assumes that the new ColumnStore version will be installed onto new servers.

To reuse existing servers for the new ColumnStore version, you must adapt the procedure detailed below. After step 1, confirm all data has been backed-up and verify backups. The old version of ColumnStore should then be uninstalled, and all ColumnStore files should be deleted before continuing with step 2.

On the old ColumnStore cluster, perform a full backup.

MariaDB recommends backing up the table schemas to a single SQL file and backing up the table data to table-specific CSV files.

1. For each table, obtain the table's schema by executing the SHOW CREATE TABLE :

   Backup the table schemas by copying the output to an SQL file. This procedure assumes that the SQL file is named schema-backup.sql.

2. For each table, backup the table data to a CSV file using the SELECT .. INTO OUTFILE :

On the new ColumnStore cluster, follow the deployment instructions of the desired topology for the new ColumnStore version.

For deployment instructions, see "".

On the new ColumnStore cluster, restore the table schemas and data.

1. Restore the schema backup using :

   • HOST and PORT should refer to the following:

     • If you are connecting with MaxScale as a proxy, they should refer to the host and port of the MaxScale listener

On the new ColumnStore cluster, verify that the table schemas and data have been restored.

1. For each table, verify the table's definition by executing the SHOW CREATE TABLE statement:

2. For each table, verify the number of rows in the table by executing SELECT COUNT(*):

3. For each table, verify the data in the table executing the statement.

_{This page is: Copyright © 2026 MariaDB. All rights reserved.}