These instructions detail the upgrade from MariaDB Enterprise ColumnStore 6 to MariaDB Enterprise ColumnStore 23.10 in a Multi-Node topology on a range of supported Operating Systems.
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:
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:
Stop the service:
Stop the MariaDB Enterprise ColumnStore service:
Stop the MariaDB Enterprise Server service:
MariaDB Corporation provides package repositories for YUM (RHEL, CentOS, Rocky Linux) and APT (Debian, Ubuntu).
Retrieve your Customer Download Token at and substitute for CUSTOMER_DOWNLOAD_TOKEN in the following directions.
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:
Retrieve your Customer Download Token at and substitute for CUSTOMER_DOWNLOAD_TOKEN in the following directions.
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:
Start the CMAPI service:
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.
mariadb_es_repo_setup script can be found in the section at the bottom of the page. Substitute ${checksum} in the example above with the latest checksum.Update MariaDB Enterprise Server and package dependencies:
mariadb_es_repo_setup script can be found in the section at the bottom of the page. Substitute ${checksum} in the example above with the latest checksum.Update MariaDB Enterprise Server and package dependencies.
The update command depends on the installed APT version, which can be determined by executing the following command:
For versions prior to APT 2.0, execute the following command:
For APT 2.0 and later, execute the following command:
sudo yum update "MariaDB-*" "MariaDB-columnstore-engine" "MariaDB-columnstore-cmapi"apt --versionapt 2.0.9 (amd64)sudo apt install --only-upgrade "mariadb*"sudo apt install --only-upgrade '?upgradable ?name(mariadb.*)'maxctrl set server \
mcs2 \
maintenancemaxctrl list servers┌────────┬───────────────┬──────┬─────────────┬──────────────────────┬────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼───────────────┼──────┼─────────────┼──────────────────────┼────────┤
│ mcs3 │ 192.0.2.3 │ 3306 │ 0 │ Maintenance, Running │ 0-1-17 │
├────────┼───────────────┼──────┼─────────────┼──────────────────────┼────────┤
│ mcs2 │ 192.0.2.2 │ 3306 │ 0 │ Maintenance, Running │ 0-1-17 │
├────────┼───────────────┼──────┼─────────────┼──────────────────────┼────────┤
│ mcs1 │ 192.0.2.1 │ 3306 │ 0 │ Master, Running │ 0-1-17 │
└────────┴───────────────┴──────┴─────────────┴──────────────────────┴────────┘my_print_defaults --mysqld \
| grep "gtid[-_]strict[-_]mode"--gtid_strict_mode=1[mariadb]
...
# temporarily commented out for upgrade
# gtid_strict_mode=1mcs cluster stopsudo systemctl stop mariadb-columnstore-cmapisudo systemctl stop mariadb-columnstoresudo systemctl stop mariadbsudo yum install curlcurl -LsSO https://dlm.mariadb.com/enterprise-release-helpers/mariadb_es_repo_setupecho "${checksum} mariadb_es_repo_setup" | sha256sum -c -chmod +x mariadb_es_repo_setupsudo ./mariadb_es_repo_setup --token="CUSTOMER_DOWNLOAD_TOKEN" --apply \
--mariadb-server-version="11.4"sudo apt install curlcurl -LsSO https://dlm.mariadb.com/enterprise-release-helpers/mariadb_es_repo_setupecho "${checksum} mariadb_es_repo_setup" sha256sum -c -chmod +x mariadb_es_repo_setupsudo ./mariadb_es_repo_setup --token="CUSTOMER_DOWNLOAD_TOKEN" --apply \
--mariadb-server-version="11.4"sudo apt updatesudo systemctl stop mariadb-columnstore
sudo systemctl disable mariadb-columnstoresudo systemctl start mariadb-columnstore-cmapisudo systemctl start mariadbmariadb-upgrade --write-binlogmcs cluster startSHOW GLOBAL STATUS LIKE 'Columnstore_version';+---------------------+---------+
| Variable_name | Value |
+---------------------+---------+
| Columnstore_version | 23.10.0 |
+---------------------+---------+SHOW GLOBAL VARIABLES LIKE 'version';+---------------+----------------------------------+
| Variable_name | Value |
+---------------+----------------------------------+
| version | 10.6.9-5-MariaDB-enterprise-log |
+---------------+----------------------------------+maxctrl clear server \
mcs2 \
maintenancemaxctrl list servers┌────────┬───────────────┬──────┬─────────────┬─────────────────┬─────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼─────────┤
│ mcs3 │ 192.0.2.3 │ 3306 │ 0 │ Slave, Running │ 0-3-159 │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼─────────┤
│ mcs2 │ 192.0.2.2 │ 3306 │ 0 │ Slave, Running │ 0-1-88 │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼─────────┤
│ mcs1 │ 192.0.2.1 │ 3306 │ 0 │ Master, Running │ 0-1-88 │
└────────┴───────────────┴──────┴─────────────┴─────────────────┴─────────┘This page provides a major release upgrade procedure for MariaDB Enterprise ColumnStore. A major release upgrade is an upgrade from an older major release to a newer major release, such as an upgrade from MariaDB Enterprise ColumnStore 5 to MariaDB Enterprise ColumnStore 22.08.
Enterprise ColumnStore 5
Enterprise ColumnStore 6
Enterprise ColumnStore 22.08
This procedure assumes that the new Enterprise ColumnStore version will be installed onto new servers.
To reuse existing servers for the new Enterprise 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 Enterprise ColumnStore should then be uninstalled, and all Enterprise 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.
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.
For each table, backup the table data to a CSV file using the SELECT .. INTO OUTFILE :
Copy the SQL file containing the table schemas and the CSV files containing the table data to the primary node of the new ColumnStore cluster.
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.
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.
For each table, verify the table's definition by executing the SHOW CREATE TABLE statement:
For each table, verify the number of rows in the table by executing SELECT COUNT(*):
For each table, verify the data in the table executing the statement.
If the table is very large, you can limit the number of rows in the result set by adding a LIMIT clause:
If you are connecting directly to a multi-node ColumnStore cluster, they should refer to the host and port of the primary ColumnStore node
If you are connecting directly to single-node ColumnStore, they should refer to the host and port of the ColumnStore node
When the command is executed, mariadb client prompts for the user password
For each table, restore the data from the table's CSV file by executing the cpimport utility on the primary ColumnStore node:
sudo cpimport -s ',' \
DATABASE_NAME \
TABLE_NAME \
/path/to/DATABASE_NAME-TABLE_NAME.csvSHOW CREATE TABLE DATABASE_NAME.TABLE_NAME\GSELECT * INTO OUTFILE '/path/to/DATABASE_NAME-TABLE_NAME.csv'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM DATABASE_NAME.TABLE_NAME;mariadb --host HOST --port PORT --user USER --password < schema-backup.sqlSHOW CREATE TABLE DATABASE_NAME.TABLE_NAME\GSELECT COUNT(*) FROM DATABASE_NAME.TABLE_NAME;SELECT * FROM DATABASE_NAME.TABLE_NAME LIMIT 100;This page is: Copyright © 2025 MariaDB. All rights reserved.
This page is: Copyright © 2025 MariaDB. All rights reserved.