1 of 80

Architecture

Understand MariaDB Server's architecture. Explore its components, storage engines, and how they interact to provide a high-performance, reliable database solution.

Topologies

This section explains various deployment architectures, including standalone, replication, and clustering, to help you design scalable and highly available database solutions.

Topologies Overview

MariaDB offers varied deployment topologies by workload and technology, each named and diagrammed with benefits listed. Custom configurations are also supported.

MariaDB products can be deployed in many different topologies. The topologies described in this section are representative. MariaDB products can be deployed to form other topologies, leverage advanced product capabilities, or combine the capabilities of multiple topologies.

Topologies are the arrangement of nodes and links to achieve a purpose. This documentation describes a few of the many topologies that can be deployed using MariaDB database products.

We group topologies by workload (transactional, analytical, hybrid) and technologies (Enterprise Spider). Single-node topologies are listed separately.

To help you select the correct topology:

Each topology is named and this name is used consistently throughout the documentation.
A thumbnail diagram provides a small-scale summary of the topology's architecture.
Finally, we provide a list of the benefits of the topology.

Although multiple topologies are listed on this page, the listed topologies are not the only options. MariaDB products are flexible, configurable, and extensible, so it possible to deploy different topologies that combine the capabilities of multiple topologies listed on this page. The topologies listed on this page are primarily intended to be representative of the most commonly requested use cases.

Transactional (OLTP)

Primary/Replica Topology

Diagram

Features

Galera Cluster Topology

Diagram

Features

Analytical (OLAP, Data Warehousing, DSS)

ColumnStore Object Storage Topology

Diagram

Features

ColumnStore Shared Local Storage Topology

Diagram

Features

Hybrid Workloads

HTAP Topology

Diagram

Features

Spider Topologies

Spider Federated Topology

Diagram

Features

Spider Sharded Topology

Diagram

Features

Single Node Topologies

Compatibility

Operating System support varies by product and product version. Operating System support is detailed in MariaDB plc Engineering Policies.

Step 3: Install MariaDB Enterprise Server

Overview

This page details step 3 of the 9-step procedure "".

This step installs MariaDB Enterprise Server, MariaDB Enterprise ColumnStore 23.10, CMAPI, and dependencies.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 6: Install MariaDB MaxScale

Overview

This page details step 6 of the 9-step procedure "".

This step installs MariaDB MaxScale 22.08.

ColumnStore Object Storage requires 1 or more MaxScale nodes.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 9: Import Data

Overview

This page details step 9 of the 9-step procedure "".

This step bulk imports data to Enterprise ColumnStore.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 3: Install MariaDB Enterprise Server

Overview

This page details step 3 of the 9-step procedure "".

This step installs MariaDB Enterprise Server, MariaDB Enterprise ColumnStore 23.10, CMAPI, and dependencies.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 6: Install MariaDB MaxScale

Overview

This page details step 6 of the 9-step procedure "".

This step installs MariaDB MaxScale 22.08.

ColumnStore Object Storage requires 1 or more MaxScale nodes.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 9: Import Data

Overview

This page details step 9 of the 9-step procedure "".

This step bulk imports data to Enterprise ColumnStore.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 1: Install MariaDB Enterprise Server

Overview

This page details step 1 of the 6-step procedure "".

This step installs MariaDB Enterprise Server.

MariaDB Enterprise Server installations support MariaDB Enterprise Cluster, powered by Galera. MariaDB Enterprise Cluster uses the Galera Enterprise 4 wsrep provider plugin.

MariaDB Enterprise Cluster requires an odd number of 3 or more nodes. Nodes must meet requirements.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 4: Install MariaDB MaxScale

Overview

This page details step 4 of the 6-step procedure "Deploy Galera Cluster Topology".

This step installs MariaDB MaxScale.

MariaDB Enterprise Cluster requires 1 or more MaxScale nodes.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Retrieve Customer Download Token

MariaDB Corporation provides package repositories for YUM (RHEL / CentOS), APT (Debian / Ubuntu), and ZYpp (SLES). A download token is required to access the MariaDB Enterprise Repository.

Customer Download Tokens are customer-specific and are available through the MariaDB Customer Portal.

To retrieve the token for your account:

Navigate to
Log in.
Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

On the MaxScale node, install the prerequisites for downloading the software from the Web.

Install on CentOS / RHEL (YUM):

Install on Debian / Ubuntu (APT):

Install on SLES (ZYpp):

On the MaxScale node, configure package repositories and specify MariaDB MaxScale 25.01:

Checksums of the various releases of the 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.

Install MaxScale

On the MaxScale node, install MariaDB MaxScale.

Install on CentOS / RHEL (YUM):

Install on Debian / Ubuntu (APT):

Install on SLES (ZYpp):

Next Step

Navigation in the procedure "Deploy Galera Cluster Topology":

This page was step 4 of 6.

Next: Step 5: Start and Configure MariaDB MaxScale

Step 1: Prepare ColumnStore Node

Overview

This page details step 1 of the 4-step procedure "".

This step prepares the system to host MariaDB Enterprise Server and MariaDB Enterprise ColumnStore 23.10.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 2: Install MariaDB Enterprise Server

Overview

This page details step 2 of the 4-step procedure "Deploy HTAP Topology".

This step installs MariaDB Enterprise Server MariaDB Enterprise ColumnStore 23.10, and dependencies.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Retrieve Download Token

MariaDB Corporation provides package repositories for CentOS / RHEL (YUM) and Debian / Ubuntu (APT). A download token is required to access the MariaDB Enterprise Repository.

Customer Download Tokens are customer-specific and are available through the MariaDB Customer Portal.

To retrieve the token for your account:

Navigate to
Log in.
Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

On each Enterprise ColumnStore node, install the prerequisites for downloading the software from the Web. Install on CentOS / RHEL (YUM):

Install on Debian / Ubuntu (APT):

On each Enterprise ColumnStore node, configure package repositories and specify Enterprise Server:

Install Enterprise Server and Enterprise ColumnStore

On each Enterprise ColumnStore node, install additional dependencies: Install on CentOS / RHEL (YUM)

Install of Debian 10 and Ubuntu 20.04 (APT):

Install on Debian 9 and Ubuntu 18.04 (APT):

On the Enterprise ColumnStore node, install MariaDB Enterprise Server and MariaDB Enterprise ColumnStore:

Install on CentOS / RHEL (YUM):

Install on Debian / Ubuntu (APT):

Next Step

Navigation in the procedure "Deploy HTAP Topology".

This page was step 2 of 4.

Next: Step 3: Start and Configure MariaDB Enterprise Server.

Step 1: Install MariaDB Enterprise Server

Overview

This page details step 1 of the 7-step procedure "".

This step installs MariaDB Enterprise Server

The Primary/Replica topology requires 3 or more MariaDB Enterprise Server nodes for High Availability (HA). Nodes must meet requirements.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 5: Install MariaDB MaxScale

Overview

This page details step 5 of the 7-step procedure "Deploy Primary/Replica Topology".

This step install MariaDB MaxScale 25.01.

The MaxScale node must meet requirements.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Retrieve Customer Download Token

MariaDB Corporation provides package repositories for YUM (RHEL, CentOS), APT (Debian, Ubuntu), and ZYpp (SLES). A download token is required to access the MariaDB Enterprise Repository.

Customer Download Tokens are customer-specific and are available through the MariaDB Customer Portal.

To retrieve the token for your account:

Navigate to
Log in.
Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

On the MaxScale node, install the prerequisites for downloading the software from the Web.

Install on CentOS / RHEL (YUM):

Install on Debian / Ubuntu (APT):

Install on SLES (ZYpp):

On the MaxScale node, configure package repositories and specify MariaDB MaxScale 25.01:

Install MaxScale

On the MaxScale node, install MariaDB MaxScale.

Install on CentOS / RHEL (YUM):

Install on Debian / Ubuntu (APT):

Install on SLES (ZYpp):

Next Step

Navigation in the procedure "Deploy Primary/Replica Topology":

This page was step 5 of 7.

Next: Step 6: Start and Configure MariaDB MaxScale

Single Node Topologies

Overview

Installation and configuration instructions are available for the deployment of single-node topologies of MariaDB Enterprise Server and MariaDB Community Server.

MariaDB ColumnStore

These instructions detail a single-node deployment of a columnar data store, for MariaDB Community Server, with data optionally stored on S3-compatible object storage:

For high availability and scalability, see "" or "".

MariaDB Community Server

These instructions detail a single-node deployment of MariaDB Community Server:

MariaDB Enterprise ColumnStore with Local Storage

These instructions detail a single-node deployment of a columnar data store:

For high availability and scalability, see "".

MariaDB Enterprise ColumnStore with Object Storage

These instructions detail a single-node deployment of a columnar data store for MariaDB Enterprise Server, with data stored on S3-compatible object storage:

For high availability and scalability, see "".

MariaDB Enterprise Server

These instructions detail a single-node deployment of MariaDB Enterprise Server:

Step 2: Install Enterprise ColumnStore

Overview

This page details step 2 of a 5-step procedure for deploying Single-Node Enterprise ColumnStore with Local storage.

This step installs MariaDB Enterprise Server and MariaDB Enterprise ColumnStore 23.10.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Retrieve Download Token

MariaDB Corporation provides package repositories for CentOS / RHEL (YUM) and Debian / Ubuntu (APT). A download token is required to access the MariaDB Enterprise Repository.

Customer Download Tokens are customer-specific and are available through the MariaDB Customer Portal.

To retrieve the token for your account:

Navigate to
Log in.
Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

On each Enterprise ColumnStore node, install the prerequisites for downloading the software from the Web. Install on CentOS / RHEL (YUM):

Install on Debian / Ubuntu (APT):

On each Enterprise ColumnStore node, configure package repositories and specify Enterprise Server:

Install Enterprise ColumnStore

Install additional dependencies:

Install on CentOS / RHEL (YUM)

Install of Debian 10 and Ubuntu 20.04 (APT):

Install on Debian 9 and Ubuntu 18.04 (APT):

Install MariaDB Enterprise Server and MariaDB Enterprise ColumnStore:

Install on CentOS / RHEL (YUM):

Install on Debian / Ubuntu (APT):

Next Step

Navigation in the Single-Node Enterprise ColumnStore topology with Local storage deployment procedure:

This page was step 2 of 5.

Next: Step 3: Start and Configure MariaDB Enterprise ColumnStore.

Step 4: Test Enterprise ColumnStore

Overview

This page details step 4 of a 5-step procedure for deploying .

This step tests MariaDB Enterprise Server and MariaDB Enterprise ColumnStore 23.10.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 5: Bulk Import of Data

Overview

This page details step 5 of a 5-step procedure for deploying Single-Node Enterprise ColumnStore with Local storage.

This step bulk imports data to Enterprise ColumnStore.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Import the Schema

Before data can be imported into the tables, create a matching schema.

On the primary server, create the schema:

For each database that you are importing, create the database with the statement:

For each table that you are importing, create the table with the statement:

Import the Data

Enterprise ColumnStore supports multiple methods to import data into ColumnStore tables.

cpimport

MariaDB Enterprise ColumnStore includes , which is a command-line utility designed to efficiently load data in bulk. Alternative methods are available.

To import your data from a TSV (tab-separated values) file, on the primary server run :

LOAD DATA INFILE

When data is loaded with the statement, MariaDB Enterprise ColumnStore loads the data using , which is a command-line utility designed to efficiently load data in bulk. Alternative methods are available.

To import your data from a TSV (tab-separated values) file, on the primary server use statement:

Import from Remote Database

MariaDB Enterprise ColumnStore can also import data directly from a remote database. A simple method is to query the table using the statement, and then pipe the results into , which is a command-line utility that is designed to efficiently load data in bulk. Alternative methods are available.

To import your data from a remote MariaDB database:

Next Step

Navigation in the Single-Node Enterprise ColumnStore topology with Local storage deployment procedure:

This page was step 5 of 5.

This procedure is complete.

Step 1: Prepare Systems for Enterprise ColumnStore Nodes

Overview

This page details step 1 of a 5-step procedure for deploying .

This step prepares the system to host MariaDB Enterprise Server and MariaDB Enterprise ColumnStore 23.10.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 2: Install Enterprise ColumnStore

Overview

This page details step 2 of a 5-step procedure for deploying .

This step installs MariaDB Enterprise Server and MariaDB Enterprise ColumnStore 23.10.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Step 5: Bulk Import of Data

Overview

This page details step 5 of a 5-step procedure for deploying .

This step bulk imports data to Enterprise ColumnStore.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Spider Storage Engine

Spider Topologies

Spider Federated

MariaDB Enterprise Spider enables reading from and writing to tables on remote Enterprise Server nodes. It uses the Spider storage engine for "virtual" Federated Spider Tables, querying Data Tables on Data Nodes (which use non-Spider engines) via a MariaDB foreign data wrapper. This solution supports transactions and is available with Enterprise Server 10.3+.

Spider Sharded

MariaDB Enterprise Spider facilitates horizontal scalability by sharding tables. It uses the Spider storage engine for partitioned "virtual" Sharded Spider Tables, querying Data Tables on Data Nodes (using non-Spider engines) for each partition via a MariaDB foreign data wrapper. This solution supports transactions and is available with Enterprise Server 10.3+.

MariaDB Enterprise Spider Topologies

Explore MariaDB Enterprise Spider topologies with MaxScale. This section details how it integrates with Spider to manage & route traffic efficiently across sharded & distributed database environments.

Federated MariaDB Enterprise Spider Topology ODBC MariaDB Enterprise Spider Topology Sharded MariaDB Enterprise Spider Topology

Server Constraints

Understand MariaDB Server's architectural constraints. This section details limitations & design considerations, helping you optimize your database deployments for maximum efficiency and scalability.

Server Constraints Overview

MariaDB Enterprise Server provides DDL (Data Definition Language) syntax to create, alter, or drop constraints.

In the context of ISO 9075-2:2016, this page uses "DDL (Data Definition Language)" to refer to SQL statements in the standard's "SQL-schema statements" group.

NOT NULL Constraints

When creating a table, you can define a column with a NOT NULL constraint to prevent null values. This constraint ensures data integrity by guaranteeing that a column must always contain a value. If an attempt is made to insert or update a row with a null value in a NOT NULL column, the operation will be rejected, thus maintaining the integrity of the database.

Overview

MariaDB Server supports NOT NULL constraints to ensure that a column's value is not set to NULL:

When a column is declared with a NOT NULL constraint, Enterprise Server rejects operations that would write a NULL value to the column

CREATE TABLE

CREATE TABLE and NOT NULL Constraints

With MariaDB Server, the statement can be used to create a new table with a NOT NULL constraint on one or more columns:

ALTER TABLE

ALTER TABLE .. MODIFY COLUMN .. NOT NULL

With MariaDB Server, the statement can be used to add the NOT NULL constraint to a column using the MODIFY COLUMN clause:

With MariaDB Server, the statement can be used to remove the NOT NULL constraint from a column using the MODIFY COLUMN clause:

Step 7: Start and Configure MariaDB MaxScale

Overview

This page details step 7 of the 9-step procedure "Deploy ColumnStore Shared Local Storage Topology".

This step starts and configures MariaDB MaxScale 22.08.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Replace the Default Configuration File

MariaDB MaxScale installations include a configuration file with some example objects. This configuration file should be replaced.

On the MaxScale node, replace the default /etc/maxscale.cnf with the following configuration:

For additional information, see "Global Parameters".

Restart MaxScale

On the MaxScale node, restart the MaxScale service to ensure that MaxScale picks up the new configuration:

For additional information, see "Start and Stop Services".

Configure Server Objects

On the MaxScale node, use to create a server object for each Enterprise ColumnStore node:

Configure MariaDB Monitor

MaxScale uses monitors to retrieve additional information from the servers. This information is used by other services in filtering and routing connections based on the current state of the node. For MariaDB Enterprise ColumnStore, use the MariaDB Monitor (mariadbmon).

On the MaxScale node, use to create a MariaDB Monitor:

In this example:

columnstore_monitor is an arbitrary name that is used to identify the new monitor.
mariadbmon is the name of the module that implements the MariaDB Monitor.
user=MAXSCALE_USER sets the user parameter to the database user account that MaxScale uses to monitor the ColumnStore nodes.

Choose a MaxScale Router

Routers control how MaxScale balances the load between Enterprise ColumnStore nodes. Each router uses a different approach to routing queries. Consider the specific use case of your application and database load and select the router that best suits your needs.

Router

Configuration Procedure

Description

Configure Read Connection Router

Use to route connections to replica servers for a read-only pool.

On the MaxScale node, use to create a router:

In this example:

connection_router_service is an arbitrary name that is used to identify the new service.
readconnroute is the name of the module that implements the Read Connection Router.
user=MAXSCALE_USER sets the user parameter to the database user account that MaxScale uses to connect to the ColumnStore nodes.

Configure Listener for the Read Connection Router

These instructions reference TCP port 3308. You can use a different TCP port. The TCP port used must not be bound by any other listener.

On the MaxScale node, use the command to configure MaxScale to use a listener for the :

In this example:

connection_router_service is the name of the readconnroute service that was previously created.
connection_router_listener is an arbitrary name that is used to identify the new listener.
3308 is the TCP port.

Configure Read/Write Split Router for Queries

MaxScale performs query-based load balancing. The router routes write queries to the primary and read queries to the replicas.

On the MaxScale node, use the maxctrl create service command to configure MaxScale to use the :

In this example:

query_router_service is an arbitrary name that is used to identify the new service.
readwritesplit is the name of the module that implements the Read/Write Split Router.
user=MAXSCALE_USER sets the user parameter to the database user account that MaxScale uses to connect to the ColumnStore nodes.

Configure a Listener for the Read/Write Split Router

These instructions reference TCP port 3307. You can use a different TCP port. The TCP port used must not be bound by any other listener.

On the MaxScale node, use the command to configure MaxScale to use a listener for the :

In this example:

query_router_service is the name of the readwritesplit service that was previously created.
query_router_listener is an arbitrary name that is used to identify the new listener.
3307 is the TCP port.
protocol=MariaDBClient

Start Services

To start the services and monitors, on the MaxScale node use :

Next Step

Navigation in the procedure "Deploy ColumnStore Shared Local Storage Topology".

This page was step 7 of 9.

Next: Next: Step 8: Test MariaDB MaxScale.

Step 6: Start and Configure MariaDB MaxScale

Overview

This page details step 6 of the 7-step procedure "Deploy Primary/Replica Topology".

This step starts and configures MariaDB MaxScale.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Replace the Default Configuration File

MariaDB MaxScale installations include a configuration file with some example objects. This configuration file should be replaced.

On the MaxScale node, replace the default /etc/maxscale.cnf with the following configuration:

For additional information, see "".

Restart MaxScale

On the MaxScale node, restart the MaxScale service to ensure that MaxScale picks up the new configuration:

For additional information, see "".

Configure Server Objects

On the MaxScale node, use server to create a server object for each MariaDB Enterprise Server:

Configure MariaDB Monitor

On the MaxScale node, use to create a MariaDB Monitor:

In this example:

mdb_monitor is an arbitrary name that is used to identify the new monitor.
mariadbmon is the name of the module that implements the MariaDB Monitor.
user=MAXSCALE_USER sets the user parameter to the database user account that MaxScale uses to monitor the ES nodes.

Choose a MaxScale Router

Routers control how MaxScale balances the load between Enterprise Server nodes. Each router uses a different approach to routing queries. Consider the specific use case of your application and database load and select the router that best suits

Router

Configuration Procedure

Description

Configure Read Connection Router

Use MaxScale Read Connection Router (readconnroute) to route connections to replica servers for a read-only pool.

On the MaxScale node, use maxctrl create service to create a router:

In this example:

connection_router_service is an arbitrary name that is used to identify the new service.
readconnroute is the name of the module that implements the Read Connection Router.
user=MAXSCALE_USER sets the user parameter to the database user account that MaxScale uses to connect to the ES nodes.

Configure Listener for the Read Connection Router

These instructions reference TCP port 3308. You can use a different TCP port. The TCP port used must not be bound by any other listener.

On the MaxScale node, use the maxctrl create listener command to configure MaxScale to use a listener for the Read Connection Router (readconnroute):

In this example:

connection_router_service is the name of the readconnroute service that was previously created.
connection_router_listener is an arbitrary name that is used to identify the new listener.
3308 is the TCP port.

Configure Read/Write Split Router for Queries

MaxScale Read/Write Split Router (readwritesplit) performs query-based load balancing. The router routes write queries to the primary and read queries to the replicas.

On the MaxScale node, use the maxctrl create service command to configure MaxScale to use the Read/Write Split Router (readwritesplit):

In this example:

query_router_service is an arbitrary name that is used to identify the new service.
readwritesplit is the name of the module that implements the Read/Write Split Router.
user=MAXSCALE_USER sets the user parameter to the database user account that MaxScale uses to connect to the ES nodes.

Configure a Listener for the Read/Write Split Router

These instructions reference TCP port 3307. You can use a different TCP port. The TCP port used must not be bound by any other listener.

On the MaxScale node, use the maxctrl create listener command to configure MaxScale to use a listener for the Read/Write Split Router (readwritesplit):

In this example:

query_router_service is the name of the readwritesplit service that was previously created.
query_router_listener is an arbitrary name that is used to identify the new listener.
3307 is the TCP port.

Start Services

To start the services and monitors, on the MaxScale node use maxctrl start services:

Next Step

Navigation in the procedure "Deploy Primary/Replica Topology":

This page was step 6 of 7.

Next: Step 7: Test MariaDB MaxScale

Step 5: Start and Configure MariaDB MaxScale

Overview

This page details step 5 of the 6-step procedure "Deploy Galera Cluster Topology".

This step configures MariaDB MaxScale to route connections to MariaDB Enterprise Cluster.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Replace the Default Configuration File

MariaDB MaxScale installations include a configuration file with some example objects. This configuration file should be replaced.

On the MaxScale node, replace the default /etc/maxscale.cnf with the following configuration:

For additional information, see "Global Parameters".

Restart MaxScale

On the MaxScale node, restart the MaxScale service to ensure that MaxScale picks up the new configuration:

For additional information, see "Start and Stop Services".

Create MaxScale User Account

MariaDB MaxScale connects to Enterprise Cluster through the client port. MaxScale requires its own user account to monitor and orchestrate Enterprise Cluster nodes.

On any Enterprise Cluster node, use the CREATE USER statement to create a new user for MaxScale:

Use the GRANT statement to grant required privileges to the MaxScale user:

Enterprise Cluster replicates the new user and privileges to the other Enterprise Cluster nodes.

Configure Server Objects

MariaDB MaxScale uses server objects to define the connections it makes to MariaDB Enterprise Servers.

On the MaxScale node, use maxctrl to create a server object for each MariaDB Enterprise Server:

Configure the Galera Monitor

On the MaxScale node, use maxctrl to create a Galera Monitor for the cluster:

In this example:

cluster_monitor is an arbitrary name that is used to identify the new monitor.
galeramon is the name of the module that implements the Galera Monitor.
user=MAXSCALE_USER sets the user parameter to the database user account that MaxScale uses to monitor the ES nodes.

Choose a MaxScale Router

Routers control how MaxScale balances the load between Enterprise Cluster nodes. Each router uses a different approach to routing queries. Consider the specific use case of your application and database load and select the router that best suits your needs.

Router

Configuration Procedure

Description

Configure Read Connection Router

Use MaxScale Read Connection Router (readconnroute) to route connections to replica servers for a read-only pool.

On the MaxScale node, use maxctrl create service to create a router:

In this example:

connection_router_service is an arbitrary name that is used to identify the new service.
readconnroute is the name of the module that implements the Read Connection Router.
user=MAXSCALE_USER sets the user parameter to the database user account that MaxScale uses to connect to the ES nodes.

Configure Listener for the Read Connection Router

These instructions reference TCP port 3308. You can use a different TCP port. The TCP port used must not be bound by any other listener.

On the MaxScale node, use the maxctrl create listener command to configure MaxScale to use a listener for the Read Connection Router (readconnroute):

In this example:

connection_router_service is the name of the readconnroute service that was previously created.
connection_router_listener is an arbitrary name that is used to identify the new listener.
3308 is the TCP port.
protocol=MariaDBClient

Configure Read/Write Split Router for Queries

MaxScale Read/Write Split Router (readwritesplit) performs query-based load balancing. The router routes write queries to the primary and read queries to the replicas.

On the MaxScale node, use the maxctrl create service command to configure MaxScale to use the Read/Write Split Router (readwritesplit):

In this example:

query_router_service is an arbitrary name that is used to identify the new service.
readwritesplit is the name of the module that implements the Read/Write Split Router.
user=MAXSCALE_USER sets the user parameter to the database user account that MaxScale uses to connect to the ES nodes.

Configure a Listener for the Read/Write Split Router

These instructions reference TCP port 3307. You can use a different TCP port. The TCP port used must not be bound by any other listener.

On the MaxScale node, use the maxctrl create listener command to configure MaxScale to use a listener for the Read/Write Split Router (readwritesplit):

In this example:

query_router_service is the name of the readwritesplit service that was previously created.
query_router_listener is an arbitrary name that is used to identify the new listener.
3307 is the TCP port.
protocol=MariaDBClient

Start Services

To start the services and monitors, on the MaxScale node use maxctrl start services:

Next Step

Navigation in the procedure "Deploy Galera Cluster Topology":

This page was step 5 of 6.

Next: Step 6: Test MariaDB MaxScale

Step 2: Start and Configure MariaDB Enterprise Server

Overview

This page details step 2 of the 6-step procedure "Deploy Galera Cluster Topology".

This step configures MariaDB Enterprise Servers to operate as Enterprise Cluster nodes and starts MariaDB Enterprise Cluster.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Stop the Enterprise Server Service

The installation process might have started the Enterprise Server service. The service should be stopped prior to making configuration changes.

On each Enterprise Cluster node, stop the MariaDB Enterprise Server service:

Acquire TLS Certificate

By default, MariaDB Enterprise Cluster requires data-in-transit encryption to secure Galera replication traffic.

MariaDB Enterprise Cluster encrypts the data using the Transport Layer Security (TLS) protocol, which is a newer version of the Secure Socket Layer (SSL) protocol.

In MariaDB Enterprise Cluster 10.5 and earlier, TLS was supported, but not required. For backward compatibility, MariaDB Enterprise Cluster supports the Provider WSREP TLS Mode, which is equivalent to Enterprise Cluster's TLS implementation in ES 10.5 and earlier. For additional information, see "WSREP TLS Modes".

TLS configuration requires 3 files.

Example Filename

Description

Self-signed certificates are supported. However, in environments where security is critical, it is recommended to use certificates signed by a trusted Certificate Authority (CA).

For additional information, see "Data-in-Transit Encryption".

Configure Enterprise Cluster

MariaDB Enterprise Server installations support MariaDB Enterprise Cluster, powered by Galera. MariaDB Enterprise Cluster uses the Galera Enterprise 4 wsrep provider plugin. The path to the wsrep provider plugin must be configured using the system variable.

Required System Variables and Options

Enterprise Cluster nodes require that you set the following system variables and options:

System Variable/Option

Description

Example Configuration

Edit a configuration file and set these system variables and options:

For additional information, see "MariaDB Enterprise Server Configuration Management".

Configure MariaDB Replication

MariaDB Enterprise Cluster can be deployed alongside MariaDB Replication. Deploying MariaDB Enterprise Cluster with MariaDB Replication enables integrating Enterprise Cluster with other products and clusters, for example as separate clusters in different data centers, or as a small dedicated write cluster with two larger dedicated read clusters.

For additional information, see "Replication Configuration".

Bootstrap the Primary Component

When an Enterprise Cluster node starts, it checks the addresses in the system variable to establish connections with other nodes. The node does not become active until it finds a node that belongs to the Primary Component.

To start the cluster when all nodes are down, you must bootstrap the Primary Component on one node. This allows the other nodes to connect to a working cluster.

On one Enterprise Cluster node, when all nodes are down, bootstrap the Primary Component.

Bootstrap the Primary Component:

For additional information, see "Bootstrap a Galera Cluster".

Connect with MariaDB Client:

The sudo command is used here to connect to the Enterprise Server node using the root@localhost user account, which authenticates using the unix_socket authentication plugin. Other user accounts can be used by specifying the --user and --password command-line options.

Use the SHOW STATUS statement to check the status variable:

The Enterprise Cluster node launches as the Primary Component of a single-node cluster.

Add Nodes to the Cluster

To add nodes to a cluster that has a Primary Component running, complete the following procedure for each Enterprise Cluster node to be added. Nodes should be added one at a time.

On the Enterprise Cluster node being added, start MariaDB Enterprise Server:

For additional information, see "Start and Stop Services".

On the Enterprise Cluster node being added, connect with MariaDB Client:

On the bootstrapped Enterprise Cluster node, use the SHOW STATUS statement to check the status variable:

On the Enterprise Cluster node being added, use the SHOW STATUS statement to check the status variable. If is SYNCED, the node has been successfully added, and the Add Node procedure can be repeated to add more nodes.

When each new Enterprise Cluster node joins the cluster, it requests the current cluster position. If the new node is missing transactions, it initiates either a State Snapshot Transfer (SST) or an Incremental State Transfer (IST) from a donor node to synchronize its data with the Primary Component. Depending on the value of , the donor node may or may not be blocked during an SST.

When the new Enterprise Cluster node finishes its state transfer, the node updates the status variable to SYNCED. MaxScale registers the change and begins routing connections or queries to the new node.

Next Step

Navigation in the procedure "Deploy Galera Cluster Topology":

This page was step 2 of 6.

Next: Step 3: Test MariaDB Enterprise Server

Step 2: Configure Spider Node and Data Nodes

Overview

This page details step 2 of the 3-step procedure "Deploy Spider Sharded Topology".

This step configures the Spider Node and Data Nodes and creates the Spider Table and Data Tables.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Create Spider User

The data node requires a user account that the Spider Node uses to connect.

On each Data Node, create the Spider user account for the Spider Node using the statement:

Privileges will be granted to the user account in .

Test Spider User

On the Spider Node, confirm that the Spider user account can connect to the Data Node using MariaDB Client:

Configure Connection Details

The Spider Node requires connection details for each Data Node.

On the Spider Node, create a server object to configure the connection details for each Data Node using the statement:

Create a Server object to configure the connection details for the Data Node at the headquarters branch:\
Create a server object to configure the connection details for the Data Node at the eastern branch:\
Create a server object to configure the connection details for the Data Node at the western branch:

The Data Node runs MariaDB Enterprise Server, so the FOREIGN DATA WRAPPER is set to mariadb.

Using a server object for connection details is optional. Alternatively, the connection details for the Data Node can be specified in the COMMENT table option of the statement when .

Create the Data Tables

When queries read and write to a Spider Table, Spider reads and writes to the Data Tables for each partition on the on the Data Nodes. The Data Tables must be created on the Data Nodes with the same structure as the .

If your Data Tables already exist, to the Spider user.

On each Data Node, create the Data Tables:

On the Data Node for the headquarters server, create a database and table and add sample data:
The Spider Node reads and writes to the Data Table using the server and user account configured in "". The user account must have .
On the Data Node for the eastern branch of the business, create a database and table and add sample data:\
The Spider Node reads and writes to the Data Table using the server and user account configured in "". The user account must have .\
On the Data Node for the western branch of the business, create a database and table and add sample data:\

Grant Privileges

The Spider Node connects to the Data Nodes with the user account configured in "".

On each Data Node, grant the Spider user sufficient privileges to operate on the Data Table:

Privileges for Spider BKA Mode

By default, the Spider user also requires the CREATE TEMPORARY TABLES privilege on the database containing the Data Table. The CREATE TEMPORARY TABLES privilege is required, because Spider uses temporary tables to optimize read queries when Spider BKA Mode is 1.

Spider BKA Mode is configured using the following methods:

The session value is configured by setting the system variable on the Spider Node. The default value is -1. When the session value is -1, the value for each is used.
The value for each Spider Table is configured by setting the bka_mode option in the COMMENT table option. When the bka_mode option is not set, the implicit value is 1.

The default value is -1, and the implicit Spider Table value is 1, so the default Spider BKA Mode is 1.

On the Data Node, grant the Spider user the CREATE TEMPORARY TABLES privilege on the database:

Create the Spider Table

The Spider Table must be created on the Spider Node with the same structure as the . The Spider Table must have a partition for each Data Table.

On the Spider Node, create the Spider Table and reference the Data Node in the COMMENT table option:

The COMMENT partition option is used to configure the Data Node and the Data Table for each partition. Set the server option to the server object for the partition configured in "". Set the table option to the for the partition.

An alternative syntax is available. When you don't want to create a server object, the connection details for the Data Nodes can be specified in the COMMENT partition option:

Next Step

Navigation in the procedure "Deploy Spider Sharded Topology":

This page was step 2 of 3.

Next: Step 3: Test Spider Sharded Topology.

Step 3: Start and Configure MariaDB Enterprise Server

Overview

This page details step 3 of the 4-step procedure "Deploy HTAP Topology".

This step starts and configures MariaDB Enterprise Server and MariaDB Enterprise ColumnStore 23.10.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Stop the Enterprise ColumnStore Services

The installation process might have started some of the ColumnStore services. The services should be stopped prior to making configuration changes.

On each Enterprise ColumnStore node, stop the MariaDB Enterprise Server service:

On each Enterprise ColumnStore node, stop the MariaDB Enterprise ColumnStore service:

On each Enterprise ColumnStore node, stop the CMAPI service:

Configure Enterprise ColumnStore

On each Enterprise ColumnStore node, configure Enterprise Server.

Connector

MariaDB Connector/R2DBC

Example Configuration

Configure the S3 Storage Manager

Configure Enterprise ColumnStore S3 Storage Manager to use S3-compatible storage by editing the /etc/columnstore/storagemanager.cnf configuration file:

The S3-compatible object storage options are configured under [S3]:

The bucket option must be set to the name of the bucket that you created in "Create an S3 Bucket".
The endpoint option must be set to the endpoint for the S3-compatible object storage.
The aws_access_key_id and aws_secret_access_key options must be set to the access key ID and secret access key for the S3-compatible object storage.
To use a specific IAM role, you must uncomment and set

The local cache options are configured under [Cache]:

The cache_size option is set to 2 GB by default.
The path option is set to /var/lib/columnstore/storagemanager/cache by default.
Ensure that the specified path has sufficient storage space for the specified cache size.

Start the Enterprise ColumnStore Services

Start and enable the MariaDB Enterprise Server service, so that it starts automatically upon reboot:

Start and enable the MariaDB Enterprise ColumnStore service, so that it starts automatically upon reboot:

For additional information, see "".

Create User Accounts

The HTAP topology requires several user accounts.

Create the Utility User

Enterprise ColumnStore requires a mandatory utility user account. By default, it connects to the server using the root user with no password. MariaDB Enterprise Server 10.6 will reject this login attempt by default, so you will need to configure Enterprise ColumnStore to use a different user account and password and create this user account on Enterprise Server.

On the Enterprise ColumnStore node, create the user account with the CREATE USER statement:

On the Enterprise ColumnStore node, grant the user account SELECT privileges on all databases with the GRANT statement:

Configure Enterprise ColumnStore to use the utility user:

Set the password:

For details about how to encrypt the password, see "".

Passwords should meet your organization's password policies. If your MariaDB Enterprise Server instance has a password validation plugin installed, then the password should also meet the configured requirements.

Create the Replication User

Enterprise HTAP uses to replicate writes between InnoDB tables and ColumnStore tables.

Create a replication user and grant it the required privileges:

Use the statement to create replication users for each replica server:

Grant the user account several global privileges with the statement.

Configure MariaDB Replication

Set the GTID position by setting the system variable. If this is a new deployment, then it would be set to the empty string:

Use the CHANGE MASTER TO statement to configure the server to replicate from itself starting from this position:

Start replication using the START REPLICA statement:

Confirm that replication is working using the SHOW REPLICA STATUS statement:

Configure Linux Security Modules (LSM)

The specific steps to configure the security module depend on the operating system.

Configure SELinux (CentOS, RHEL)

Configure SELinux for Enterprise ColumnStore:

To configure SELinux, you have to install the packages required for audit2allow. On CentOS 7 and RHEL 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=enforcing in /etc/selinux/config.

For example, the file will usually look like this after the change:

Set SELinux to enforcing mode:

Configure AppArmor (Ubuntu)

For information on how to create a profile, see on ubuntu.com.

Next Step

Navigation in the procedure "Deploy HTAP Topology".

This page was step 3 of 4.

Next: Step 4: Test MariaDB Enterprise Server.

PRIMARY KEY Constraints

Using an AUTO_INCREMENT column as the primary key in MariaDB is beneficial for ensuring unique row identification and efficient data retrieval. This approach automatically generates a unique integer for each new row, simplifying primary key management. It is especially useful in tables where data insertion occurs frequently, as it facilitates quick indexing and minimizes storage overhead due to its numeric nature. This practice helps maintain optimal performance in database operations, particularly when combined with clustered indexing in InnoDB.

Overview

MariaDB Server supports PRIMARY KEY constraints to uniquely identify rows:

There can only be a single primary key for a given table.

InnoDB uses the primary key as a clustered index, which means that InnoDB stores table data in the order determined by the primary key.
Primary key indexes are B+ trees, which are very efficient for searching for exact values, performing range scans, and checking uniqueness.
If no primary key is defined for a table, then InnoDB will use the table's first NOT NULL unique index as the table's primary key.

Using an AUTO_INCREMENT Column as the Primary Key

If your table does not have a column or a set of columns that could act as a natural primary key, then you can define a single AUTO_INCREMENT column, which can serve as the table's primary key. See for more details.

Using a Sequence-backed Column as the Primary Key

If your table does not have a column or a set of columns that could act as a natural primary key, then you can use a sequence to generate an integer value to use as the table's primary key. Sequences were first added in MariaDB Server 10.3 and MariaDB Community Server 10.3. See for more details.

Creating an InnoDB Table with a Single Column Primary Key

Let's key after confirming that the default storage engine is InnoDB:

Connect to the server using MariaDB Client:

Confirm that the default storage engine is InnoDB by checking the using the statement:

If the database does not exist, then create the database for the table using the statement:

Create the table using the statement and specify the primary key with the PRIMARY KEY() clause:

For a single column primary key, the primary key can also be specified with the PRIMARY KEY column option:

Creating an InnoDB Table with a Composite Primary Key

Let's create an InnoDB table with a composite (multi-column) primary key after confirming that the default storage engine is InnoDB:

Connect to the server using MariaDB Client:

Confirm that the default storage engine is InnoDB by checking the using the statement:

If the database does not exist, then create the database for the table using the statement:

Create the table using the statement and specify the primary key with the PRIMARY KEY() clause:

Adding a Primary Key to an InnoDB Table

Let's , and then add a primary key to it:

Connect to the server using MariaDB Client:

Confirm that the default storage engine is InnoDB by checking the using the statement:

If the database does not exist, then create the database for the table using the statement:

Create the table without a primary key using the statement:

Alter the table using the statement and specify the new primary key with the ADD PRIMARY KEY() clause:

Dropping a Primary Key from an InnoDB Table

Let's drop the primary key from the table created in the section:

Alter the table using the statement and specify the DROP PRIMARY KEY clause:

Changing a Primary Key for an InnoDB Table

Let's change the primary key from the table created in the section:

Alter the table using the statement and specify the DROP PRIMARY KEY clause to drop the old primary key, and specify the new primary key with the ADD PRIMARY KEY() clause:

Finding Tables without Primary Keys

For best performance, every InnoDB table should have a primary key. It is possible to find tables without a primary key using a basic statement.

Let's create an InnoDB table without a primary key, and then use a statement to confirm that it does not have one:

Connect to the server using MariaDB Client:

Confirm that the default storage engine is InnoDB by checking the using the statement:

If the database does not exist, then create the database for the table using the statement:

Create the table without a primary key using the statement:

Query the .TABLES and tables to find InnoDB tables that do not have a primary key:

To add a primary key, alter the table using the statement, and specify the primary key with the ADD PRIMARY KEY() clause:

Handling Duplicate Key Errors

A primary key uniquely identifies every row. Therefore, if a second row is inserted with an identical value, it will fail.

Let's try to insert two identical primary key values into the table created in the section:

Insert a row with the statement:

Insert a second row that has the same primary key value with the statement:

This will fail with the ER_DUP_ENTRY error code:

Fix the problem by inserting the row with a unique primary key value:

To easily generate unique values for a primary key, consider using one of the following options:

Installing Enterprise Server

A guide to installing MariaDB Enterprise Server on various operating systems using package managers (YUM, APT, ZYpp) or binary tarballs.

Overview

These instructions detail the deployment of MariaDB Enterprise Server in a Single Standalone Server configuration on a range of supported Operating Systems.

These instructions detail how to deploy a single-node row database, which is suited for a transactional or OLTP workload that does not require high availability (HA). This deployment type is generally for non-production use cases, such as for development and testing.

MariaDB Database Products

These instructions detail the deployment of the following MariaDB database products:

Component

Description

MariaDB Enterprise Server Components

These instructions detail the deployment of the following components:

Component

Description

Term Definitions

Term

Definition

Installation

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

Install via YUM (CentOS, RHEL, Rocky)

Retrieve your Customer Download Token at and substitute for CUSTOMER_DOWNLOAD_TOKEN in the following directions.
Configure the YUM package repository.

Pass the version to install using the --mariadb-server-version flag to mariadb_es_repo_setup. The following directions reference 11.4. To configure YUM package repositories:

Checksums of the various releases of the 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.
Install MariaDB Enterprise Server and package dependencies:

Configure MariaDB.

Installation only loads MariaDB Enterprise Server to the system. MariaDB Enterprise Server requires configuration before the database server is ready for use. See .

Install via APT (Debian, Ubuntu)

Retrieve your Customer Download Token at and substitute for CUSTOMER_DOWNLOAD_TOKEN in the following directions.
Configure the APT package repository.

Pass the version to install using the --mariadb-server-version flag to mariadb_es_repo_setup. The following directions reference

To configure APT package repositories:

Checksums of the various releases of the 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.
Install MariaDB Enterprise Server and package dependencies:

Configure MariaDB.

Installation only loads MariaDB Enterprise Server to the system. MariaDB Enterprise Server requires configuration before the database server is ready for use. See .

Install via ZYpp (SLES)

Retrieve your Customer Download Token at and substitute for CUSTOMER_DOWNLOAD_TOKEN in the following directions.
Configure the ZYpp package repository.

Pass the version to install using the --mariadb-server-version flag to mariadb_es_repo_setup. The following directions reference 11.4.

To configure ZYpp package repositories:

Checksums of the various releases of the 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.
Install MariaDB Enterprise Server and package dependencies:

Configure MariaDB.

Installation only loads MariaDB Enterprise Server to the system. MariaDB Enterprise Server requires configuration before the database server is ready for use. See .

Configuration

MariaDB Enterprise Server can be configured in the following ways:

and can be set in a configuration file (such as /etc/my.cnf). MariaDB Enterprise Server must be restarted to apply changes made to the configuration file.
and can be set on the command-line.
If a system variable supports dynamic changes, then it can be set on-the-fly using the statement.

Configuration Files

MariaDB's packages include several bundled configuration files. It is also possible to create custom configuration files.

On RHEL, CentOS, and SLES, MariaDB's packages bundle the following configuration files:

/etc/my.cnf
/etc/my.cnf.d/client.cnf
/etc/my.cnf.d/mariadb-enterprise.cnf

And on RHEL, CentOS, and SLES, 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

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/

Configure MariaDB

Determine which system variables and options you need to configure.

Useful system variables and options for MariaDB Enterprise Server include:

System Variable/Option

Description

Choose a configuration file in which to configure your system variables and options.

It is not recommended to make custom changes to one of the bundled configuration files. Instead, it is recommended to 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, then 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, CentOS, and SLES, a good custom configuration file would be: /etc/my.cnf.d/z-custom-my.cnf
On 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 , such as [mariadb] or [server].

For example:

Start the Server

MariaDB Enterprise Server includes configuration to start, stop, restart, enable/disable on boot, and check the status of the Server using the operating system default process management system.

For distributions that use systemd (most supported OSes), you can manage the Server process using the systemctl command:

Operation

Command

Test MariaDB Enterprise Server

When MariaDB Enterprise Server is up and running on your system, you should test that it is working and there weren't any issues during startup.

Connect to the server using using the root@localhost user account:

HTAP

Overview

Software Version

Diagram

Features

Enterprise Server 10.5
Enterprise Server 10.6
Enterprise Server 11.4

Single-stack hybrid transactional/analytical workloads

ColumnStore for analytics with scalable S3-compatible object storage
InnoDB for transactions
Cross-engine JOINs
Enterprise Server 10.5, Enterprise ColumnStore 5, MaxScale 2.5

This procedure describes the deployment of the HTAP topology with MariaDB Enterprise Server and MariaDB Enterprise ColumnStore.

MariaDB Enterprise ColumnStore is a columnar storage engine for MariaDB Enterprise Server. This topology is best suited for Hybrid Transactional-Analytical Processing (HTAP) workloads.

This procedure has 4 steps, which are executed in sequence.

This procedure represents the basic product capability and uses 1 Enterprise ColumnStore node.

This page provides an overview of the topology, requirements, and deployment procedures.

Please read and understand this procedure before executing.

Procedure Steps

Step

Description

Support

Customers can obtain support by

Components

The following components are deployed during this procedure:

Component

Function

MariaDB Enterprise Server Components

Component

Description

Topology

The MariaDB Enterprise ColumnStore HTAP topology is designed for hybrid transactional-analytical processing (HTAP) workloads.

The topology consists of:

One MaxScale node
One ColumnStore node running ES and Enterprise ColumnStore

The MaxScale node:

Monitors the health and availability of the ColumnStore node using the MariaDB Monitor (mariadbmon)
Accepts client and application connections
Routes queries to the ColumnStore node using the Read/Write Split Router (readwritesplit)

The ColumnStore node:

Receives queries from MaxScale
Executes queries
Uses a row-based storage engine, such as to handle transactional queries
Uses Enterprise ColumnStore as the columnar storage engine to handle analytical queries

Requirements

These requirements are for the HTAP topology when deployed with MariaDB Enterprise Server 11.4 and MariaDB Enterprise ColumnStore.

Operating System

In alignment to the , the HTAP topology with MariaDB Enterprise Server 11.4 and MariaDB Enterprise ColumnStore is provided for:

Debian 11 (x86_64, ARM64)
Debian 12 (x86_64, ARM64)
Red Hat Enterprise Linux 8 (x86_64, ARM64)
Red Hat Enterprise Linux 9 (x86_64, ARM64)

S3-Compatible Object Storage Option

The HTAP topology can use S3-compatible object storage to store ColumnStore data, but it is not required.

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.

For the preferred S3-compatible object storage providers that provide cloud and hardware solutions, see the following sections:

The use of non-cloud and non-hardware providers is at your own risk.

If you have any questions about using specific S3-compatible object storage with MariaDB Enterprise ColumnStore, .

Preferred Object Storage Providers: Cloud

Amazon Web Services (AWS) S3
Google Cloud Storage
Azure Storage
Alibaba Cloud Object Storage Service

Preferred Object Storage Providers: Hardware

Cloudian HyperStore
Dell EMC
Seagate Lyve Rack
Quantum ActiveScale

Limitations

Cross-Database Queries

This implementation relies on replicate_rewrite_db, so it does not support cross-database queries with statement-based replication.

For example, if the replicated database is selected by the USE, then the query will replicate properly:

However, if the replicated database is not selected, and it is instead prefixed the table name in the query, then the query will not replicate properly:

Semi-Synchronous Replication

This implementation has not been tested with semi-synchronous replication.

Parallel Replication

This implementation has not been tested with parallel replication.

Row-Based Replication

This implementation requires the system variable to be set to STATEMENT. Row-based replication is not currently supported.

Quick Reference

MariaDB Enterprise Server Configuration Management

Method

Description

MariaDB Enterprise Server packages are configured to read configuration files from different paths, depending on the operating system. Making custom changes to Enterprise Server default configuration files is not recommended because custom changes may be overwritten by other default configuration files that are loaded later.

To ensure that your custom changes will be read last, create a custom configuration file with the z- prefix in one of the include directories.

Distribution

Example Configuration File Path

MariaDB Enterprise Server Service Management

The systemctl command is used to start and stop the MariaDB Enterprise Server service.

Operation

Command

For additional information, see "".

MariaDB Enterprise Server Logs

MariaDB Enterprise Server produces log data that can be helpful in problem diagnosis.

Log filenames and locations may be overridden in the server configuration. The default location of logs is the data directory. The data directory is specified by the datadir system variable.

Log

System Variable/Option

Default Filename

Enterprise ColumnStore Service Management

The systemctl command is used to start and stop the ColumnStore service.

Operation

Command

Next Step

Navigation in the procedure "Deploy HTAP Topology".

Next: Step 1: Prepare ColumnStore Node.

AUTO_INCREMENT Constraints

Learn about AUTO_INCREMENT constraints in MariaDB Server. This section details how to automatically generate unique, sequential values for table columns, simplifying data management.

To define an AUTO_INCREMENT column, select an integer data type to accommodate the range of anticipated values. Common choices include INT, BIGINT, TINYINT, SMALLINT, and MEDIUMINT, depending on size requirements. Ensure the chosen type provides sufficient capacity to avoid overflow while optimizing storage efficiency.

Overview

MariaDB Enterprise Server supports AUTO_INCREMENT constraints:

A column with an AUTO_INCREMENT constraint can act as a table's primary key when a natural primary key is not available
Generated values for auto-increment columns are guaranteed to be unique and monotonically increasing
Auto-increment columns provide compatibility with schemas designed for MariaDB Enterprise Server and MySQL

Alternatively, MariaDB Enterprise Server can use as the primary key instead of columns with AUTO_INCREMENT constraints. Sequences are compliant with the SQL standard, while AUTO_INCREMENT constraints are not, so sequences are the better option for applications that require standard-compliant features.

Choosing a Data Type for an `AUTO_INCREMENT` Column

When designing a schema, AUTO_INCREMENT columns should use integer data types. The following types can be used:

Data Type

Signed Range

Unsigned Range

To determine which type to use, consider the following points:

Do you want to be able to manually insert negative values? If not, then specify the UNSIGNED attribute for the column.

InnoDB can't generate negative AUTO_INCREMENT values, so it is only beneficial to use a signed integer column if you want the option to manually insert negative values, which would bypass the AUTO_INCREMENT handling.

How large will your table grow?

If your AUTO_INCREMENT column is being used as the table's primary key, then the maximum value for the chosen data type should be considered the maximum number of rows that can fit in the table:

Data Type

Signed Range

Unsigned Range

If you want to give your table the most room to grow, then it would be best to choose BIGINT UNSIGNED.

Creating an InnoDB Table with an AUTO_INCREMENT Column

Let's after confirming that the is InnoDB:

Connect to the server using MariaDB Client:

Confirm that the default storage engine is InnoDB by checking the using the statement:

If the database does not exist, then create the database for the table using the statement:

Create the table using the statement:

Inserting a Row with an AUTO_INCREMENT Column

If a column is specified as AUTO_INCREMENT, then its value will be automatically generated. There are multiple ways to insert rows with these automatically generated values.

Omitting the Column

If the column is not specified, then InnoDB will automatically generate the value.

Let's insert a row into the table created in the section:

Connect to the server using MariaDB Client:

Insert a row with the statement, but do not specify the AUTO_INCREMENT column:

Select the same row with the statement to confirm that a value was automatically generated:

Specifying the Column's Value as 0

If the column's value is specified as 0, then InnoDB will automatically generate the value if the system variable does not contain NO_AUTO_VALUE_ON_ZERO.

Let's insert a row into the table created in the section:

Connect to the server using MariaDB Client:

Confirm that the session's value of the sql_mode system variable does not contain NO_AUTO_VALUE_ON_ZERO with the statement:

Insert a row with the statement, and specify the AUTO_INCREMENT column's value as 0:

Select the same row with the statement to confirm that a value was automatically generated:

Specifying the Column's Value as NULL

If the column's value is specified as NULL, then InnoDB will automatically generate the value if the column is defined as NOT NULL.

Let's insert a row into the table created in the section:

Connect to the server using MariaDB Client:

Insert a row with the statement, and specify the AUTO_INCREMENT column's value as NULL:

Select the same row with the statement to confirm that a value was automatically generated:

Getting the Last Inserted AUTO_INCREMENT Value

After InnoDB inserts an automatically generated value into an AUTO_INCREMENT column, the application sometimes needs to know what value it inserted. For example, the application may need to use the value to insert a foreign key column in a dependent table. The function can be used to get the lasted inserted value for an AUTO_INCREMENT column without re-reading the row from the table.

Let's insert a row into the table created in the section and then use the function:

Connect to the server using MariaDB Client:

Insert a row with the statement, but do not specify the AUTO_INCREMENT column:

Execute the function to get the AUTO_INCREMENT value for the new row:

Select the same row with the statement to confirm that the AUTO_INCREMENT column has the same value:

Choosing an AUTO_INCREMENT Lock Mode for InnoDB

When multiple rows are inserted into a table concurrently, InnoDB needs to be able to generate multiple values concurrently in a safe manner. It has several different modes that can be used to do this, and each mode has its own advantages and disadvantages.

InnoDB's AUTO_INCREMENT lock mode is configured with the system variable. Users can choose between 3 different values:

Value

Description

• In interleaved lock mode, InnoDB never holds a table-level lock while generating AUTO_INCREMENT values. • Interleaved lock mode is not safe to use if binlog_format is set to STATEMENT.|

Configuring the AUTO_INCREMENT Lock Mode for InnoDB

The system variable configures the AUTO_INCREMENT Lock Mode for InnoDB.

Choose a configuration file for custom changes to system variables and options.

It is not recommended to make custom changes to Enterprise Server's default configuration files, because your custom changes can be overwritten by other default configuration files that are loaded after.

Ensure that your custom changes are read last by creating a custom configuration file in one of the included directories. Configuration files in included directories are read in alphabetical order. Use the z- prefix in the file name to ensure that your custom configuration file is read last.

Some example configuration file paths for different distributions are shown in the following table:

Distributions

Example configuration file path

Set the system variable in the configuration file. It needs to be set in a group that will be read by MariaDB Server, such as [mariadb] or [server].

For example:

Restart the server:

Setting a Table's Next AUTO_INCREMENT Value

A table's next AUTO_INCREMENT value can be set with the statement. The value is set using the AUTO_INCREMENT table option.

Let's alter the AUTO_INCREMENT value for the table created in the section and then insert a row into the table, so we can confirm that it uses the new value:

Connect to the server using MariaDB Client:

Alter the table's next AUTO_INCREMENT value with the statement:

Insert a row with the statement, but do not specify the AUTO_INCREMENT column:

Execute the function to get the AUTO_INCREMENT value for the new row:

Select the same row with the statement to confirm that the AUTO_INCREMENT column has the same value:

Configure the Offset and Increment Values

The offset and increment values can be configured by setting the system variables.

When Galera Cluster is used, the offset and increment values are managed automatically by default. They can be managed manually by disabling the system variable.

FOREIGN KEY Constraints

In MariaDB Server, FOREIGN KEY constraints are key elements in defining relationships between InnoDB tables: they ensure referential integrity by maintaining valid associations between rows in parent and child tables. Changes in the parent table can either be restricted or propagated to maintain consistency with child tables.

Overview

MariaDB Server supports FOREIGN KEY constraints to define referential constraints between InnoDB tables:

Referential constraints allow the database to automatically ensure that each row in the child table is associated with a valid row in the parent table
If the row in the parent table changes, MariaDB Server can block the change to protect child rows, or propagate the change to the child rows

Term Definitions

Term

Definition

Uses Cases for Foreign Keys

Foreign keys allow the database to handle certain types of referential constraint checks, so that the application does not have to handle them. As a consequence, application logic can be simplified.

Some example use cases are described below.

Managing Accounts Use Case

Many different applications have account management features. Foreign keys can be used to simplify certain aspects of managing accounts, such as:

If an account is deleted, foreign keys can be used to automatically delete data associated with the account.
If an account is deleted, foreign keys can be used to automatically disassociate its data, so that it is no longer associated with any account.
If an account's user name or user ID is updated, foreign keys can be used to automatically associate its data with the new user name or user ID.

Managing Store Inventory Use Case

Foreign keys can also be used to simplify certain aspects of managing a store inventory, such as:

If a product is deleted, foreign keys can be used to automatically delete data associated with the product, such as reviews and images.
If a product's name is changed, foreign keys can be used to automatically associate the new name with the product's other data.
If a customer purchases a product, foreign keys can be used to associate the order with the product.
If a customer reviews a product, foreign keys can be used to associate the review with the product.

Operating on InnoDB Tables with Foreign Keys

When an InnoDB table has a foreign key or when it is referenced by a foreign key, InnoDB performs a referential constraint check when certain types of operations try to write to the table. The specific details depend on whether the table is a parent table or a child table.

Operating on a Parent Table

When an InnoDB table has a foreign key, it is known as a parent table. InnoDB performs referential constraint checks for the following operations on parent tables:

When InnoDB performs a referential constraint check, the outcome depends on several factors. The following table describes the details:

Operation

Result of Constraint Check

Action

Consequence

Operating on a Child Table

When an InnoDB table is referenced by a foreign key, it is known as a child table. InnoDB performs referential constraint checks for the following operations on child tables:

When InnoDB performs a referential constraint check, the outcome depends on several factors. The following table describes the details:

Operation

Result of Constraint Check

Consequence

Creating InnoDB Tables with a Foreign Key Constraint

Let's create InnoDB tables with a foreign key constraint after confirming that the is InnoDB:

Connect to the server using MariaDB Client:

Confirm that the default storage engine is InnoDB by checking the using the statement:

If the database does not exist, then create the database for the sequence and table using the statement:

Create the parent table using the statement:

Create the child table using the statement:

Insert some rows into the parent table using the statement:

Insert a row into the child table for each row in the parent table using the statement:

Attempt to delete a row from the parent table that has a corresponding row in the child table using the DELETE statement:

This will fail with the error code as explained in the Operating on a Parent Table section:

Attempt to insert a row into the child table for a non-existent row in the parent table using the INSERT statement:

This will fail with the error code as explained in the Operating on a Child Table section:

Adding a Foreign Key Constraint to an InnoDB Table

Let's create InnoDB tables after confirming that the is InnoDB, and then let's add a foreign key constraint between them:

Connect to the server using MariaDB Client:

Confirm that the default storage engine is InnoDB by checking the using the statement:

If the database does not exist, then create the database for the sequence and table using the statement:

Create the parent table using the statement:

Create the child table using the statement:

Alter the child table to add the foreign key constraint using the statement:

Insert some rows into the parent table using the statement:

Insert a row into the child table for each row in the parent table using the statement:

Attempt to delete a row from the parent table that has a corresponding row in the child table using the statement:

This will fail with the error code as explained in the Operating on a Parent Table section:

Attempt to insert a row into the child table for a non-existent row in the parent table using the statement:

This will fail with the error code as explained in the Operating on a Child Table section:

Dropping a Foreign Key Constraint from an InnoDB Table

Let's drop the foreign key constraint from the child table created in the section:

Connect to the server using MariaDB Client:

Obtain the name of the foreign key constraint by querying the table:

Drop the foreign key constraint from the child table using the statement:

Temporarily Disabling Foreign Key Constraint Checks

When performing bulk data loads, dropping a table, or rebuilding a table, it can improve performance to temporarily disable foreign key constraint checks. Foreign key constraint checks can be temporarily disabled by setting the session value for the foreign_key_checks system variable. If foreign key constraint checks are temporarily disabled, then rows can be inserted that violate the constraint, so users must proceed with caution. This feature is most useful when you are loading a data set that is known to be valid.

Let's temporarily disable foreign key constraint checks, and then perform some tasks with the tables created in the section:

Connect to the server using MariaDB Client:

Temporarily disable foreign key constraint checks by setting the system variable with the statement:

If you want to test how to introduce inconsistencies, then attempt to delete a row from the parent table that has a corresponding row in the child table using the statement:

This operation would usually fail with the error code as explained in the Operating on a Parent Table section, but if foreign key constraint checks are disable, then it will succeed.

If you want to test how to introduce inconsistencies, then also attempt to insert a row into the child table for a non-existent row in the parent table using the statement:

This operation would usually fail with the error code as explained in the section, but if foreign key constraint checks are disable, then it will succeed.

Re-enable foreign key constraint checks by setting the system variable with the statement:

Special Cases

Foreign Key Constraint Namespace

When a foreign key constraint is created without a name, InnoDB implicitly gives it a name in the format:

If foreign key constraints are explicitly created with names in the same format, it is possible for collisions to occur during table renames. In that case, the would contain messages like the following:

Dependence on an Index

A foreign key constraint requires an index on the column. If a foreign key constraint is added to a column without an index, InnoDB will automatically create an index to enforce the foreign key constraint.

When the system variable is disabled, it is possible to drop the index used by a foreign key constraint. When the system variable is re-enabled, InnoDB will have no way to enforce the foreign key constraint, so all operations that could potentially violate the foreign key constraint will fail.

Step 8: Test MariaDB MaxScale

Overview

This page details step 8 of the 9-step procedure "Deploy ColumnStore Object Storage Topology".

This step tests MariaDB MaxScale 22.08.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Check Global Configuration

Use command to view the global MaxScale configuration.

This action is performed on the MaxScale node:

Output should align to the global MaxScale configuration in the new configuration file you created.

Check Server Configuration Use the and commands to view the configured server objects.

This action is performed on the MaxScale node:

Obtain the full list of servers objects:

For each server object, view the configuration:

Output should align to the Server Object configuration you performed.

Check Monitor Configuration

Use the and commands to view the configured monitors.

This action is performed on the MaxScale node:

Obtain the full list of monitors:

For each monitor, view the monitor configuration:

Output should align to the MariaDB Monitor (mariadbmon) configuration you performed.

Check Service Configuration

Use the and commands to view the configured routing services.

This action is performed on the MaxScale node:

Obtain the full list of routing services:

For each service, view the service configuration:

Output should align to the or configuration you performed.

Test Application User

Applications should use a dedicated user account. The user account must be created on the primary server.

When users connect to MaxScale, MaxScale authenticates the user connection before routing it to an Enterprise Server node. Enterprise Server authenticates the connection as originating from the IP address of the MaxScale node.

The application users must have one user account with the host IP address of the application server and a second user account with the host IP address of the MaxScale node.

The requirement of a duplicate user account can be avoided by enabling the proxy_protocol parameter for MaxScale and the proxy_protocol_networks for Enterprise Server.

Create a User to Connect from MaxScale

This action is performed on the primary Enterprise ColumnStore node:

Connect to the primary Enterprise ColumnStore node:

Create the database user account for your MaxScale node:

Replace 192.0.2.10 with the relevant IP address specification for your MaxScale node.

Passwords should meet your organization's password policies.

Grant the privileges required by your application to the database user account for your MaxScale node:

The privileges shown are designed to allow the tests in the subsequent sections to work. The user account for your production application may require different privileges.

Create a User to Connect from the Application Server

This action is performed on the primary Enterprise ColumnStore node:

Create the database user account for your application server:

Replace 192.0.2.11 with the relevant IP address specification for your application server.

Passwords should meet your organization's password policies.

Grant the privileges required by your application to the d database user account for your application server:

The privileges shown are designed to allow the tests in the subsequent sections to work. The user account for your production application may require different privileges.

Test Connection with Application User

To test the connection, use the MariaDB Client from your application server to connect to an Enterprise ColumnStore node through MaxScale.

This action is performed on a client connected to the MaxScale node:

Test Connection with Read Connection Router

If you configured the Read Connection Router, confirm that MaxScale routes connections to the replica servers.

On the MaxScale node, use the command to view the available listeners and ports:

Open multiple terminals connected to your application server, in each, use MariaDB Client to connect to the listener port for the Read Connection Router (in the example, 3308):

Use the application user credentials you created for the --user and --password options.

In each terminal, query the hostname and server_id system variable and option to identify to which you're connected:

Different terminals should return different values since MaxScale routes the connections to different nodes.

Since the router was configured with the slave router option, the Read Connection Router only routes connections to replica servers.

Test Write Queries with Read/Write Split Router

If you configured the Read/Write Split Router, confirm that MaxScale routes write queries on this router to the primary Enterprise ColumnStore node.

on the MaxScale node, use the command to view the available listeners and ports:

Open multiple terminals connected to your application server, in each, use MariaDB Client to connect to the listener port for the Read/Write Split Router (in the example, 3307):

Use the application user credentials you created for the --user and --password options.

In one terminal, create the test table:

In each terminal, issue an insert.md statement to add a row to the example table with the values of the hostname and server_id system variable and option:

In one terminal, issue a SELECT statement to query the results:

While MaxScale is handling multiple connections from different terminals, it routed all connections to the current primary Enterprise ColumnStore node, which in the example is mcs1#.

Test Read Queries with Read/Write Split Router

If you configured the , confirm that MaxScale routes read queries on this router to replica servers.

On the MaxScale node, use the command to view the available listeners and ports:

In a terminal connected to your application server, use MariaDB Client to connect to the listener port for the (in the example, 3307):

Use the application user credentials you created for the --user and --password options.

Query the hostname and server_id to identify which server MaxScale routed you to.

Resend the query:

Confirm that MaxScale routes the SELECT statements to different replica servers.

For more information on different routing criteria, see slave_selection_criteria

Next Step

Navigation in the procedure "Deploy ColumnStore Object Storage Topology":

This page was step 8 of 9.

Next: Step 9: Import Data

Step 4: Start and Configure MariaDB Enterprise Server

Overview

This page details step 4 of the 9-step procedure "Deploy ColumnStore Object Storage Topology".

This step starts and configures MariaDB Enterprise Server, and MariaDB Enterprise ColumnStore 23.10.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Stop the Enterprise ColumnStore Services

The installation process might have started some of the ColumnStore services. The services should be stopped prior to making configuration changes.

On each Enterprise ColumnStore node, stop the MariaDB Enterprise Server service:

On each Enterprise ColumnStore node, stop the MariaDB Enterprise ColumnStore service:

On each Enterprise ColumnStore node, stop the CMAPI service:

Configure Enterprise ColumnStore

On each Enterprise ColumnStore node, configure Enterprise Server.

Connector

MariaDB Connector/R2DBC

Mandatory system variables and options for ColumnStore Object Storage include:

Example Configuration

Configure the S3 Storage Manager

On each Enterprise ColumnStore node, configure S3 Storage Manager to use S3-compatible storage by editing the /etc/columnstore/storagemanager.cnf configuration file:

The S3-compatible object storage options are configured under [S3]:

The bucket option must be set to the name of the bucket that you created in "Create an S3 Bucket".
The endpoint option must be set to the endpoint for the S3-compatible object storage.
The aws_access_key_id and aws_secret_access_key options must be set to the access key ID and secret access key for the S3-compatible object storage.
To use a specific IAM role, you must uncomment and set

The local cache options are configured under [Cache]:

The cache_size option is set to 2 GB by default.
The path option is set to /var/lib/columnstore/storagemanager/cache by default.

Ensure that the specified path has sufficient storage space for the specified cache size.

Start the Enterprise ColumnStore Services

On each Enterprise ColumnStore node, start and enable the MariaDB Enterprise Server service, so that it starts automatically upon reboot:

On each Enterprise ColumnStore node, stop the MariaDB Enterprise ColumnStore service:

After the CMAPI service is installed in the next step, CMAPI will start the Enterprise ColumnStore service as-needed on each node. CMAPI disables the Enterprise ColumnStore service to prevent systemd from automatically starting Enterprise ColumnStore upon reboot.

On each Enterprise ColumnStore node, start and enable the CMAPI service, so that it starts automatically upon reboot:

For additional information, see "".

Create User Accounts

The ColumnStore Object Storage topology requires several user accounts. Each user account should be created on the primary server, so that it is replicated to the replica servers.

Create the Utility User

Enterprise ColumnStore requires a mandatory utility user account to perform cross-engine joins and similar operations.

On the primary server, create the user account with the CREATE USER statement:

On the primary server, grant the user account SELECT privileges on all databases with the GRANT statement:

On each Enterprise ColumnStore node, configure the ColumnStore utility user:

On each Enterprise ColumnStore node, set the password:

For details about how to encrypt the password, see "".

Create the Replication User

ColumnStore Object Storage uses MariaDB Replication to replicate writes between the primary and replica servers. As MaxScale can promote a replica server to become a new primary in the event of node failure, all nodes must have a replication user.

The action is performed on the primary server.

Create the replication user and grant it the required privileges:

Use the CREATE USER statement to create replication user.

Replace the referenced IP address with the relevant address for your environment.

Ensure that the user account can connect to the primary server from each replica.

Grant the user account the required privileges with the GRANT statement.

Create MaxScale User

ColumnStore Object Storage 23.10 uses MariaDB MaxScale 22.08 to load balance between the nodes.

This action is performed on the primary server.

Use the statement to create the MaxScale user:

Replace the referenced IP address with the relevant address for your environment.

Ensure that the user account can connect from the IP address of the MaxScale instance.

Use the statement to grant the privileges required by the router:

Use the statement to grant privileges required by the MariaDB Monitor.

Configure MariaDB Replication

On each replica server, configure MariaDB Replication:

Use the CHANGE MASTER TO statement to configure the connection to the primary server:

Start replication using the START REPLICA statement:

Confirm that replication is working using the SHOW REPLICA STATUS statement:

Ensure that the replica server cannot accept local writes by setting the read_only system variable to ON using the SET GLOBAL statement:

Initiate the Primary Server with CMAPI

Initiate the primary server using CMAPI.

Create an API key for the cluster. This API key should be stored securely and kept confidential, because it can be used to add cluster nodes to the multi-node Enterprise ColumnStore deployment.

For example, to create a random 256-bit API key using openssl rand:

This document will use the following API key in further examples, but users should create their own:

Use CMAPI to add the primary server to the cluster and set the API key. The new API key needs to be provided as part of the X-API-key HTML header.

For example, if the primary server's host name is mcs1 and its IP address is 192.0.2.1, use the following node command:

Use CMAPI to check the status of the cluster node:

Add Replica Servers with CMAPI

Add the replica servers with CMAPI:

For each replica server, use to add the replica server to the cluster. The previously set API key needs to be provided as part of the X-API-key HTML header.

For example, if the primary server's host name is mcs1 and the replica server's IP address is 192.0.2.2, use the following node command:

After all replica servers have been added, use CMAPI to confirm that all cluster nodes have been successfully added:

Configure Linux Security Modules (LSM)

The specific steps to configure the security module depend on the operating system.

Configure SELinux (CentOS, RHEL)

Configure SELinux for Enterprise ColumnStore:

To configure SELinux, you have to install the packages required for audit2allow. On CentOS 7 and RHEL 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:

Set SELinux to enforcing mode by setting SELINUX=enforcing in /etc/selinux/config.

For example, the file will usually look like this after the change:

Confirm that SELinux is in enforcing mode:

Configure AppArmor (Ubuntu)

For information on how to create a profile, see on Ubuntu.com.

Configure Firewalls

The specific steps to configure the firewall service depend on the platform.

Configure firewalld (CentOS, RHEL)

Configure firewalld for Enterprise Cluster on CentOS and RHEL:

Check if the firewalld service is running:

If the firewalld service was stopped to perform the installation, start it now:

For example, if your cluster nodes are in the 192.0.2.0/24 subnet:

Open up the relevant ports using firewall-cmd:

Reload the runtime configuration:

Configure UFW (Ubuntu)

Configure UFW for Enterprise ColumnStore on Ubuntu:

Check if the UFW service is running:

If the UFW service was stopped to perform the installation, start it now:

Open up the relevant ports using ufw.

For example, if your cluster nodes are in the 192.0.2.0/24 subnet in the range 192.0.2.1 - 192.0.2.3:

Reload the runtime configuration:

Next Step

Navigation in the procedure "Deploy ColumnStore Object Storage Topology":

This page was step 4 of 9.

Next: Step 5: Test MariaDB Enterprise Server.

Step 7: Test MariaDB MaxScale

Overview

This page details step 7 of the 7-step procedure "Deploy Primary/Replica Topology".

This step tests MariaDB MaxScale.

Interactive commands are detailed. Alternatively, the described operations can be performed using automation.

Check Global Configuration

Use command to view the global MaxScale configuration.

This action is performed on the MaxScale node:

Output should align to the global MaxScale configuration in the new configuration file you created.

Check Server Configuration

Use the and commands to view the configured server objects.

This action is performed on the MaxScale node:

Obtain the full list of servers objects:

For each server object, view the configuration:

Output should align to the Server Object configuration you performed.

Check Monitor Configuration

Use the and commands to view the configured monitors.

This action is performed on the MaxScale node:

Obtain the full list of monitors:

For each monitor, view the monitor configuration:

Output should align to the Galera Monitor (galeramon) configuration you performed.

Check Service Configuration

Use the and commands to view the configured routing services.

This action is performed on the MaxScale node:

Obtain the full list of routing services:

For each service, view the service configuration:

Output should align to the Read Connection Router (readconnroute) or Read/Write Split Router (readwritesplit) configuration you performed.

Test Application User

Applications should use a dedicated user account. The user account must be created on the primary server.

The application users must have one user account with the host IP address of the application server and a second user account with the host IP address of the MaxScale node.

The requirement of a duplicate user account can be avoided by enabling the proxy_protocol parameter for MaxScale and the proxy_protocol_networks for Enterprise Server.

Create a User to Connect from MaxScale

This action is performed on any Enterprise Cluster node:

Connect to the node:

Create the database user account for your MaxScale node:

Replace 192.0.2.104 with the relevant IP address specification for your MaxScale node.

Passwords should meet your organization's password policies.

Grant the privileges required by your application to the database user account for your MaxScale node:

The privileges shown are designed to allow the tests in the subsequent sections to work. The user account for your production application may require different privileges.

Create a User to Connect from the Application Server

This action is performed on any Enterprise Cluster node:

Create the database user account for your application server:

Replace 192.0.2.11 with the relevant IP address specification for your application server.

Passwords should meet your organization's password policies.

Grant the privileges required by your application to the database user account for your application server:

The privileges shown are designed to allow the tests in the subsequent sections to work. The user account for your production application may require different privileges.

Test Connection with Application User

To test the connection, use the MariaDB Client from your application server to connect to an Enterprise Cluster node through MaxScale.

This action is performed on the application server:

Test Connection with Read Connection Router

If you configured the Read Connection Router, confirm that MaxScale routes connections to the replica servers.

On the MaxScale node, use the command to view the available listeners and ports:

Open multiple terminals connected to your application server, in each use MariaDB Client to connect to the listener port for the Read Connection Router (in the example 3308):

Use the application user credentials you created for the --user and --password options.

In each terminal, query the hostname system variable to identify to which you're connected:

Different terminals should return different values since MaxScale routes the connections to different nodes.

Since the router was configured the slave router option, the Read Connection Router only routes connections to replica servers.

Test Write Queries with the Read/Write Split Router

If you configured the Read/Write Split Router, confirm that readwritesplit correctly routes write queries.

This action is performed with multiple client connections to the MaxScale node.

On the MaxScale node, use the command to identify the Enterprise Cluster node currently operating as the primary server:

The server listed as Master is currently operating as the primary server.

On the MaxScale node, use the command to identify the correct listener port:

In the example, the listener port for the Read/Write Split router is 3307.

Use the MariaDB Client to establish multiple connections to the listener configured for the Read/Write Split routing service, query_router_listener, on the MaxScale node:

The database user account for your application server should be specified by the --user option.

Using any client connection, create a test table:

Using each client connection, insert the values of the hostname system variable into the table using the INSERT statement to identify the node that executes the statement:

Using any client connection, query the table using the SELECT statement:

The output shows the hostname from the Enterprise Cluster node operating as the primary server. (Enterprise Cluster offsets auto-increment values by node to avoid write conflicts.)

Confirm that MaxScale is routing write queries to the Enterprise Cluster node operating as the primary server by checking that the test table only contains the hostname of the correct Enterprise Cluster node.

Test Read Queries with the Read/Write Split Router

If you configured the Read/Write Split Router, confirm that readwritesplit properly routes read queries to multiple replica servers.

This action is performed with multiple clients connected to the MaxScale node.

On the MaxScale node, use to identify the Enterprise Cluster nodes that are currently operating as replica servers:

The servers listed as Slave are currently operating as replica servers.

On the MaxScale node, use the command to identify the correct listener port:

In the example, the listener port for the Read/Write Split router is 3307.

Use the MariaDB Client to establish multiple connections to query_router_listener which is the listener configured for the Read/Write Split routing service on the MaxScale node:

The database user account for your application server should be specified by the --user option.

Using each client connection, query the hostname system variable to identify the node that executes the statement:

Confirm that MaxScale routes the SELECT statements to different replica servers.

For more information on different routing criteria, see slave_selection_criteria

Next Step

Navigation in the procedure "Deploy Primary/Replica Topology":

This page was step 7 of 7.

This procedure is complete.

Columnstore Object Storage

Overview

Enterprise Server 10.5
Enterprise Server 10.6
Enterprise Server 11.4

Columnar storage engine with S3-compatible object storage

Highly available
Automatic failover via MaxScale and CMAPI
Scales reads via MaxScale
Bulk data import

This procedure describes the deployment of the ColumnStore Object Storage topology with MariaDB Enterprise Server 10.5, MariaDB Enterprise ColumnStore 5, and MariaDB MaxScale 2.5.

MariaDB Enterprise ColumnStore 5 is a columnar storage engine for MariaDB Enterprise Server 10.5. Enterprise ColumnStore is suitable for Online Analytical Processing (OLAP) workloads.

This procedure has 9 steps, which are executed in sequence.

This procedure represents basic product capability and deploys 3 Enterprise ColumnStore nodes and 1 MaxScale node.

This page provides an overview of the topology, requirements, and deployment procedures.

Please read and understand this procedure before executing.

Procedure Steps

Step

Description

Support

Customers can obtain support by submitting a support case.

Components

The following components are deployed during this procedure:

Component

Function

MariaDB Enterprise Server Components

Component

Description

MariaDB MaxScale Components

Component

Description

Topology

The MariaDB Enterprise ColumnStore topology with Object Storage delivers production analytics with high availability, fault tolerance, and limitless data storage by leveraging S3-compatible storage.

The topology consists of:

One or more MaxScale nodes
An odd number of ColumnStore nodes (minimum of 3) running ES, Enterprise ColumnStore, and CMAPI

The MaxScale nodes:

Monitor the health and availability of each ColumnStore node using the MariaDB Monitor (mariadbmon)
Accept client and application connections
Route queries to ColumnStore nodes using the Read/Write Split Router (readwritesplit)

The ColumnStore nodes:

Receive queries from MaxScale
Execute queries
Use for data
Use shared local storage for the Storage Manager directory

Requirements

These requirements are for the ColumnStore Object Storage topology when deployed with MariaDB Enterprise Server 10.5, MariaDB Enterprise ColumnStore 5, and MariaDB MaxScale 2.5.

Node Count
Operating System
Minimum Hardware Requirements
Recommended Hardware Requirements

Node Count

MaxScale nodes, 1 or more are required.
Enterprise ColumnStore nodes, 3 or more are required for high availability. You should always have an odd number of nodes in a multi-node ColumnStore deployment to avoid split brain scenarios.

Operating System

In alignment to the , the ColumnStore Object Storage topology with MariaDB Enterprise Server 10.5, MariaDB Enterprise ColumnStore 5, and MariaDB MaxScale 2.5 is provided for:

CentOS Linux 7 (x86_64)
Debian 10 (x86_64)
Red Hat Enterprise Linux 7 (x86_64)
Red Hat Enterprise Linux 8 (x86_64)

Minimum Hardware Requirements

MariaDB Enterprise ColumnStore's minimum hardware requirements are not intended for production environments, but the minimum hardware requirements can be appropriate for development and test environments. For production environments, see the instead.

The minimum hardware requirements are:

Component

CPU

Memory

MariaDB Enterprise ColumnStore will refuse to start if the system has less than 3 GB of memory.

If Enterprise ColumnStore is started on a system with less memory, the following error message will be written to the ColumnStore system log called crit.log:

And the following error message will be raised to the client:

Recommended Hardware Requirements

MariaDB Enterprise ColumnStore's recommended hardware requirements are intended for production analytics.

The recommended hardware requirements are:

Component

CPU

Memory

Storage Requirements

The ColumnStore Object Storage topology requires the following storage types:

Storage Type

Description

S3-Compatible Object Storage Requirements

The ColumnStore Object Storage topology uses S3-compatible object storage to store data.

For the preferred S3-compatible object storage providers that provide cloud and hardware solutions, see the following sections:

The use of non-cloud and non-hardware providers is at your own risk.

If you have any questions about using specific S3-compatible object storage with MariaDB Enterprise ColumnStore, contact us.

Preferred Object Storage Providers: Cloud

Amazon Web Services (AWS) S3
Google Cloud Storage
Azure Storage
Alibaba Cloud Object Storage Service

Preferred Object Storage Providers: Hardware

Cloudian HyperStore
Cohesity S3
Dell EMC
IBM Cloud Object Storage

Shared Local Storage Directories

The ColumnStore Object Storage topology uses shared local storage for the to store metadata.

The Storage Manager directory is located at the following path by default:

/var/lib/columnstore/storagemanager

Shared Local Storage Options

The most common shared local storage options for the ColumnStore Object Storage topology are:

Shared Local Storage

Common Usage

Description

Recommended Storage Options

For best results, MariaDB Corporation would recommend the following storage options:

Environment

Object Storage For Data

Shared Local Storage For Storage Manager

Enterprise ColumnStore Management with CMAPI

Enterprise ColumnStore's CMAPI (Cluster Management API) is a REST API that can be used to manage a multi-node Enterprise ColumnStore cluster.

Many tools are capable of interacting with REST APIs. For example, the curl utility could be used to make REST API calls from the command-line.

Many programming languages also have libraries for interacting with REST APIs.

The examples below show how to use the CMAPI with curl.

URL Endpoint Format for REST API

For example:

https://mcs1:8640/cmapi/0.4.0/cluster/shutdown
https://mcs1:8640/cmapi/0.4.0/cluster/start
https://mcs1:8640/cmapi/0.4.0/cluster/status

With CMAPI 1.4 and later:

https://mcs1:8640/cmapi/0.4.0/cluster/node

With CMAPI 1.3 and earlier:

https://mcs1:8640/cmapi/0.4.0/cluster/add-node
https://mcs1:8640/cmapi/0.4.0/cluster/remove-node

Required Request Headers

'x-api-key': '93816fa66cc2d8c224e62275bd4f248234dd4947b68d4af2b29671dd7d5532dd'
'Content-Type': 'application/json'

x-api-key can be set to any value of your choice during the first call to the server. Subsequent connections will require this same key.

Get Status

curl examples remain valid but are now considered legacy.

$ mcs cluster status

Start Cluster

$ mcs cluster start --timeout 20

Stop Cluster

$ mcs cluster shutdown --timeout 20

Add Node

With CMAPI 1.4 and later:

With CMAPI 1.3 and earlier:

Remove Node

With CMAPI 1.4 and later:

With CMAPI 1.3 and earlier:

Quick Reference

MariaDB Enterprise Server Configuration Management

Method

Description

To ensure that your custom changes will be read last, create a custom configuration file with the z- prefix in one of the include directories.

Distribution

Example Configuration File Path

MariaDB Enterprise Server Service Management

The systemctl command is used to start and stop the MariaDB Enterprise Server service.

Operation

Command

For additional information, see "".

MariaDB Enterprise Server Logs

MariaDB Enterprise Server produces log data that can be helpful in problem diagnosis.

Log filenames and locations may be overridden in the server configuration. The default location of logs is the data directory. The data directory is specified by the datadir system variable.

Log

System Variable/Option

Default Filename

Enterprise ColumnStore Service Management

The systemctl command is used to start and stop the ColumnStore service.

Operation

Command

In the ColumnStore Object Storage topology, the mariadb-columnstore service should not be enabled. The CMAPI service restarts Enterprise ColumnStore as needed, so it does not need to start automatically upon reboot.

Enterprise ColumnStore CMAPI Service Management

The systemctl command is used to start and stop the CMAPI service.

Operation

Command

For additional information on endpoints, see "CMAPI".

MaxScale Configuration Management

MaxScale can be configured using several methods. These methods make use of MaxScale's .

Method

Benefits

The procedure on these pages configures MaxScale using MaxCtrl.

MaxScale Service Management

The systemctl command is used to start and stop the MaxScale service.

Operation

Command

For additional information, see "".

Next Step

Navigation in the procedure "Deploy ColumnStore Object Storage Topology":

Next: Step 1: Prepare ColumnStore Nodes.

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:

Component

Description

Term Definitions

Term

Definition

High Availability

Single-node ColumnStore 6 does not support high availability.

For high availability and scalability, instead see "" or "".

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.conf file with the following contents:
Set the same kernel parameters at runtime using the sysctl command:

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 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=permissive in /etc/selinux/config.
For example, the file will usually look like this after the change:
Reboot the system.
Confirm that SELinux is in permissive mode using getenforce

Remember to after the installation is complete.

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:

Remember to after the installation is complete.

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-8 by executing localedef:

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.

If you have any questions about using specific S3-compatible object storage with MariaDB ColumnStore, .

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 section.

The specific steps to create the S3 bucket will depend on what S3-compatible storage you are using.

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 6 is available on MariaDB Community Server 10.6.
To configure YUM package repositories:
1. Checksums of the various releases of the mariadb_repo_setup script can be found in the section at the bottom of the page. Substitute

Install ColumnStore via APT (Debian, Ubuntu)

Configure the APT package repository.
MariaDB ColumnStore 6 is available on MariaDB Community Server 10.6.
To configure APT package repositories:
1. Checksums of the various releases of the mariadb_repo_setup script can be found in the section at the bottom of the page. Substitute

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:

and 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.
and can be set on the command-line.
If a system variable supports dynamic changes, then it can be set on-the-fly using the 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

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

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 and you need to configure.
Mandatory system variables and options for single-node MariaDB ColumnStore include:

Connector

MariaDB Connector/R2DBC

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.cnf
On 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 , 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 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:

Please choose a password that meets your organization's password policies. If your MariaDB Community Server instance has a password validation plugin installed, then the password should also meet the configured requirements.

Configure the S3 Storage Manager

MariaDB ColumnStore can use , 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 bucket

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 section. The user account must also be created and granted the necessary privileges to access data.

Connect to the server using using the root@localhost user account:
Create the user account with the statement:

Please choose the same user name and password that was configured in the section.

Grant the user account SELECT privileges on all databases with the 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 using the root@localhost user account:
For each database that you are importing, create the database with the statement:
For each table that you are importing, create the table with the 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 statement, MariaDB ColumnStore loads the data using , 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 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 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 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:

Configure AppArmor (Debian, Ubuntu)

We disabled AppArmor in the 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 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:

Operation

Command

ColumnStore Administration

MariaDB ColumnStore uses systemctl to start and stop the ColumnStore processes:

Operation

Command

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 using the root@localhost user account: