Community Server with ColumnStore
These instructions detail the deployment of MariaDB ColumnStore 6 with MariaDB Community Server 10.6 in a Single-node ColumnStore Deployment configuration on a range of supported Operating Systems.
These instructions detail how to deploy a single-node columnar database, which is suited for an analytical or OLAP workload that does not require high availability (HA). This deployment type is generally for non-production use cases, such as for development and testing.
Community Server Components
These instructions detail the deployment of the following MariaDB Community Server components:
MariaDB ColumnStore 6
It is a columnar storage engine that provides distributed, columnar storage for scalable analytical processing and smart transactions.
It is the analytical component of MariaDB's single stack Hybrid Transactional/Analytical Processing (HTAP) solution.
Term Definitions
columnar database
A database where the columns of each row are stored separately.
Best suited for analytical and OLAP workloads.
Also known as a "column-oriented database".
row database
A database where all columns of each row are stored together.
Best suited for transactional and OLTP workloads.
Also known as a "row-oriented database".
High Availability
Single-node ColumnStore 6 does not support high availability.
For high availability and scalability, instead see "ColumnStore Object Storage Topology" or "ColumnStore Shared Local Storage Topology".
System Preparation
Systems hosting a ColumnStore deployment requires some additional configuration prior to installation:
Optimize Linux Kernel Parameters
MariaDB ColumnStore performs best when certain Linux kernel parameters are optimized.
Set the relevant kernel parameters in a sysctl configuration file. For proper change management, we recommend setting them in a ColumnStore-specific configuration file.
For example, create a
/etc/sysctl.d/90-mariadb-columnstore.conffile with the following contents:Set the same kernel parameters at runtime using the
sysctlcommand:
LSM Configuration for Install
To avoid confusion and potential problems, we recommend configuring the system's Linux Security Module (LSM) during installation. The specific steps to configure the security module will depend on the platform.
In the Configure the Linux Security Module section, we will configure the security module and restart it.
SELinux (RHEL, CentOS)
SELinux must be set to permissive mode before installing MariaDB ColumnStore.
Set SELinux to permissive mode by setting
SELINUX=permissivein/etc/selinux/config.For example, the file will usually look like this after the change:
Reboot the system.
Confirm that SELinux is in
permissivemode usinggetenforce:
AppArmor (Debian, Ubuntu)
AppArmor must be disabled before installing MariaDB ColumnStore.
Disable AppArmor:
Reboot the system.
Confirm that no AppArmor profiles are loaded using
aa-status:Example output:
Configure the Character Encoding
When using MariaDB ColumnStore, it is recommended to set the system's locale to UTF-8.
On RHEL 8, install additional dependencies.
Set the system's locale to
en_US.UTF-8by executinglocaledef:
S3-Compatible Storage
MariaDB ColumnStore supports S3-compatible object storage.
S3-compatible object storage is optional, but highly recommended.
S3-compatible object storage is:
Compatible: Many object storage services are compatible with the Amazon S3 API.
Economical: S3-compatible object storage is often very low cost.
Flexible: S3-compatible object storage is available for both cloud and on-premises deployments.
Limitless: S3-compatible object storage is often virtually limitless.
Resilient: S3-compatible object storage is often low maintenance and highly available, since many services use resilient cloud infrastructure.
Scalable: S3-compatible object storage is often highly optimized for read and write scaling.
Secure: S3-compatible object storage is often encrypted-at-rest.
Many S3-compatible object storage services exist. MariaDB Corporation cannot make guarantees about all S3-compatible object storage services, because different services provide different functionality.
If you have any questions about using specific S3-compatible object storage with MariaDB ColumnStore, contact us.
Create an S3 Bucket
If you want to use S3-compatible storage, it is important to create the S3 bucket before you start ColumnStore.
If you already have an S3 bucket, confirm that the bucket is empty.
We will configure ColumnStore to use the S3 bucket later in the Configure the S3 Storage Manager section.
ColumnStore Installation
MariaDB Corporation provides package repositories for YUM (RHEL, CentOS) and APT (Debian, Ubuntu).
MariaDB ColumnStore ships as a storage engine plugin for MariaDB Community Server and a platform engine to handle back-end storage processes. MariaDB Community Server 10.6 does not require any additional software to operate as a single-node analytics database.
Install ColumnStore via YUM (RHEL, CentOS)
Configure the YUM package repository.
MariaDB ColumnStore
6is available on MariaDB Community Server10.6.To configure YUM package repositories:
Checksums of the various releases of the
mariadb_repo_setupscript can be found in the Versions section at the bottom of the MariaDB Package Repository Setup and Usage page. Substitute${checksum}in the example above with the latest checksum.
Install the EPEL repository:
Install some additional dependencies for ColumnStore:
Install MariaDB ColumnStore and package dependencies:
Configure MariaDB ColumnStore.
Installation only loads MariaDB ColumnStore to the system. MariaDB ColumnStore requires configuration and additional post-installation steps before the database server is ready for use.
Install ColumnStore via APT (Debian, Ubuntu)
Configure the APT package repository.
MariaDB ColumnStore
6is available on MariaDB Community Server10.6.To configure APT package repositories:
Checksums of the various releases of the
mariadb_repo_setupscript can be found in the Versions section at the bottom of the MariaDB Package Repository Setup and Usage page. Substitute${checksum}in the example above with the latest checksum.
Install some additional dependencies for ColumnStore.
On Debian 10 and Ubuntu 20.04, install the following:
On Debian 9 and Ubuntu 18.04, install the following:
Install MariaDB ColumnStore and package dependencies:
Configure MariaDB ColumnStore.
Installation only loads MariaDB ColumnStore to the system. MariaDB ColumnStore requires configuration and additional post-installation steps before the database server is ready for use.
ColumnStore Configuration
MariaDB ColumnStore requires configuration after it is installed. The configuration file location depends on your operating system.
Community Server Configuration
MariaDB Community Server can be configured in the following ways:
System variables and options can be set in a configuration file (such as
/etc/my.cnf). MariaDB Community Server must be restarted to apply changes made to the configuration file.System variables and options can be set on the command-line.
If a system variable supports dynamic changes, then it can be set on-the-fly using the SET statement.
Configuration Files
MariaDB's packages include several bundled configuration files. It is also possible to create custom configuration files.
On RHEL and CentOS, MariaDB's packages bundle the following configuration files:
/etc/my.cnf/etc/my.cnf.d/client.cnf/etc/my.cnf.d/mysql-clients.cnf/etc/my.cnf.d/server.cnf
And on RHEL and CentOS, custom configuration files from the following directories are read by default:
/etc/my.cnf.d/
On Debian and Ubuntu, MariaDB's packages bundle the following configuration files:
/etc/mysql/my.cnf/etc/mysql/mariadb.cnf/etc/mysql/mariadb.conf.d/50-client.cnf/etc/mysql/mariadb.conf.d/50-mysql-clients.cnf/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf/etc/mysql/mariadb.conf.d/50-server.cnf/etc/mysql/mariadb.conf.d/60-galera.cnf
And on Debian and Ubuntu, custom configuration files from the following directories are read by default:
/etc/mysql/conf.d//etc/mysql/mariadb.conf.d/
Configuring MariaDB for ColumnStore
Determine which system variables and options you need to configure.
Mandatory system variables and options for single-node MariaDB ColumnStore include:
Set this system variable to utf8
Set this system variable to utf8_general_ci
columnstore_use_import_for_batchinsert
Set this system variable to ALWAYS to always use cpimport for LOAD DATA INFILE and INSERT...SELECT statements.
Choose a configuration file in which to configure your system variables and options.
We recommend not making custom changes to one of the bundled configuration files. Instead, create a custom configuration file in one of the included directories. Configuration files in included directories are read in alphabetical order. If you want your custom configuration file to override the bundled configuration files, it is a good idea to prefix the custom configuration file's name with a string that will be sorted last, such as z-.
On RHEL and CentOS, a good custom configuration file would be:
/etc/my.cnf.d/z-custom-my.cnfOn Debian and Ubuntu, a good custom configuration file would be:
/etc/mysql/mariadb.conf.d/z-custom-my.cnf
Set your system variables and options in the configuration file. They need to be set in a group that will be read by mariadbd, such as
[mariadb]or[server]. For example:
Configure Cross Engine Joins
When a cross engine join is executed, the ExeMgr process connects to the server using the root user with no password by default. MariaDB Community Server 10.6 will reject this login attempt by default. If you plan to use Cross Engine Joins, you need to configure ColumnStore to use a different user account and password. These directions are for configuring the cross engine join user. Directions for creating the cross engine join user are in the Create the Cross Engine Join User section.
To configure cross engine joins, perform the following steps, use the mcsSetConfig command.
For example, to configure ColumnStore to use the cross_engine user account to connect to the server at 127.0.0.1:
Configure the S3 Storage Manager
MariaDB ColumnStore can use S3-compatible storage, but it is not required. S3-compatible storage must be configured before it can be used.
To configure ColumnStore to use S3-compatible storage, edit /etc/columnstore/storagemanager.cnf:
The default local cache size is 2 GB.
The default local cache path is
/var/lib/columnstore/storagemanager/cache.Ensure that the local cache path has sufficient store space to store the local cache.
The
bucketoption must be set to the name of the bucket that you created in the Create an S3 Bucket step.To use an IAM role, you must also uncomment and set
iam_role_name,sts_region, andsts_endpoint.
Start the ColumnStore Processes
The Community Server and ColumnStore processes can be started using the systemctl command. In case the processes were started during the installation process, use the restart command to ensure that the processes pick up the new configuration. Perform the following procedure.
Start the MariaDB Community Server process and configure it to start automatically:
Start the MariaDB ColumnStore processes and configure them to start automatically:
Create User Accounts
For single-node ColumnStore deployments, only a single user account needs to be created.
Create the Cross Engine Join User
The credentials for cross engine joins were previously configured in the Cross Engine Joins section. The user account must also be created and granted the necessary privileges to access data.
Connect to the server using MariaDB Client using the
root@localhostuser account:Create the user account with the CREATE USER statement:
Grant the user account
SELECTprivileges on all databases with the GRANT statement:
Bulk Import Data
Now that the ColumnStore system is running, you can bulk import your data.
Import the Schema
Before data can be imported into the tables, the schema needs to be created.
Connect to the server using mariadb Client using the
root@localhostuser account:For each database that you are importing, create the database with the CREATE DATABASE statement:
For each table that you are importing, create the table with the CREATE TABLE statement:
cpimport
MariaDB ColumnStore includes cpimport, which is a command-line utility that is designed to efficiently load data in bulk.
To import your data from a TSV (tab-separated values) file with cpimport:
LOAD DATA INFILE
When data is loaded with the LOAD DATA INFILE statement, MariaDB ColumnStore loads the data using cpimport, which is a command-line utility that is designed to efficiently load data in bulk.
To import your data from a TSV (tab-separated values) file with LOAD DATA INFILE statement:
Import from Remote Database
MariaDB ColumnStore can also import data directly from a remote database. A simple method is to query the table using the SELECT statement, and then pipe the results into cpimport, which is a command-line utility that is designed to efficiently load data in bulk.
To import your data from a remote MariaDB database:
Configure the Linux Security Module
If you stopped the Linux Security Module (LSM) during installation, you can restart the module and configure.
The specific steps to configure the security module depend on the operating system.
Configure SELinux (RHEL, CentOS)
We set SELinux to permissive mode in the SELinux section, but we have to create an SELinux policy for ColumnStore before re-enabling it. This will ensure that SELinux does not interfere with ColumnStore's functionality. A policy can be generated while SELinux is still in permissive mode using the audit2allow command.
To configure SELinux, you have to install the packages required for
audit2allow.On RHEL 7 and CentOS 7, install the following:
On RHEL 8, install the following:
Allow the system to run under load for a while to generate SELinux audit events.
After the system has taken some load, generate an SELinux policy from the audit events using
audit2allow:If no audit events were found, this will print the following:
If audit events were found, the new SELinux policy can be loaded using
semodule:Set SELinux to enforcing mode by setting
SELINUX=enforcingin/etc/selinux/config:Reboot the system.
Confirm that SELinux is in enforcing mode using
getenforce:
Configure AppArmor (Debian, Ubuntu)
We disabled AppArmor in the AppArmor section, but we have to create an AppArmor profile for ColumnStore before re-enabling it. This will ensure that AppArmor does not interfere with ColumnStore's functionality.
For information on how to create a profile, see How to create an AppArmor Profile on ubuntu.com.
Administration
ColumnStore has several components. Each of those components needs to be administered.
Community Server Administration
MariaDB Community Server uses systemctl to start and stop the server processes:
Start
sudo systemctl start mariadb
Stop
sudo systemctl stop mariadb
Restart
sudo systemctl restart mariadb
Enable during startup
sudo systemctl enable mariadb
Disable during startup
sudo systemctl disable mariadb
Status
sudo systemctl status mariadb
ColumnStore Administration
MariaDB ColumnStore uses systemctl to start and stop the ColumnStore processes:
Start
sudo systemctl start mariadb-columnstore
Stop
sudo systemctl stop mariadb-columnstore
Restart
sudo systemctl restart mariadb-columnstore
Enable during startup
sudo systemctl enable mariadb-columnstore
Disable during startup
sudo systemctl disable mariadb-columnstore
Status
sudo systemctl status mariadb-columnstore
Testing
When you have MariaDB ColumnStore up and running, you should test it to ensure that it is in working order and that there were not any issues during startup.
Checking Server Status
Connect to the server using mariadb Client using the
root@localhostuser account:
This page is: Copyright © 2025 MariaDB. All rights reserved.
Last updated
Was this helpful?

