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:

1. Navigate to

2. Log in.

3. Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

1. 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):

1. 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 Primary/Replica Topology":

This page was step 5 of 7.

Next: Step 6: Start and Configure MariaDB MaxScale

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.

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.

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.

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:

See Also

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

Overview

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

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.

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:

1. Navigate to

2. Log in.

3. Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

1. 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):

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

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 Enterprise Server and Enterprise ColumnStore

1. On each Enterprise ColumnStore node, install additional dependencies:

Install on CentOS and RHEL (YUM):

Install on Debian 9 and Ubuntu 18.04 (APT)

Install on Debian 10 and Ubuntu 20.04 (APT):

1. On each 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 ColumnStore Object Storage Topology".

This page was step 3 of 9.

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

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

Galera Cluster Topology

Analytical (OLAP, Data Warehousing, DSS)

ColumnStore Object Storage Topology

ColumnStore Shared Local Storage Topology

Hybrid Workloads

HTAP Topology

Spider Topologies

Spider Federated Topology

Spider Sharded Topology

Single Node Topologies

Overview

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

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.

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:

1. Navigate to

2. Log in.

3. Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

1. 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):

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

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 Enterprise Server

1. On each Enterprise Cluster node, install MariaDB Enterprise Server and MariaDB Enterprise Backup.

Install via CentOS / RHEL (YUM):

Install via Debian / Ubuntu (APT):

Install via SLES (ZYpp):

Next Step

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

This page was step 1 of 7.

Next: Step 2: Start and Configure MariaDB Enterprise Server on Primary Server

Overview

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

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.

Retrieve Customer 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:

1. Navigate to

2. Log in.

3. Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

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

Install on Debian / Ubuntu (APT):

1. On the MaxScale node, configure package repositories and specify MariaDB MaxScale 22.08:

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):

Next Step

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

This page was step 6 of 9.

Next: Step 7: Start and Configure MariaDB MaxScale.

Overview

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

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

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

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.

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.

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.

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

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.

Overview

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

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.

Test S3 Connection

MariaDB Enterprise ColumnStore 23.10 includes a testS3Connection command to test the S3 configuration, permissions, and connectivity.

This action is performed on each Enterprise ColumnStore node.

Test the S3 configuration by executing the following:

If the testS3Connection command does not return OK, investigate the S3 configuration.

Test Enterprise Server Service

Use Systemd to test whether the MariaDB Enterprise Server service is running.

This action is performed on each Enterprise ColumnStore node.

Check if the MariaDB Enterprise Server service is running by executing the following:

If the service is not running on any node, start the service by executing the following on that node:

Test Local Client Connections

Use to test the local connection to the Enterprise Server node.

This action is performed on each Enterprise ColumnStore node:

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.

Test ColumnStore Storage Engine Plugin

Query the table to confirm that the ColumnStore storage engine is loaded.

This action is performed on each Enterprise ColumnStore node.

Execute the following query:

The PLUGIN_STATUS column for each ColumnStore-related plugin should contain ACTIVE.

Test CMAPI Service

Use Systemd to test whether the CMAPI service is running.

This action is performed on each Enterprise ColumnStore node.

Check if the CMAPI service is running by executing the following:

If the service is not running on any node, start the service by executing the following on that node:

Test ColumnStore Status

Use CMAPI to request the ColumnStore status. The API key needs to be provided as part of the X-API-key HTML header.

This action is performed with the CMAPI service on the primary server.

Check the ColumnStore status using curl by executing the following:

Test DDL

Use MariaDB Client to test DDL.

1. On the primary server, use the MariaDB Client to connect to the node:

1. Create a test database and ColumnStore table:

1. On each replica server, use the MariaDB Client to connect to the node:

1. Confirm that the database and table exist:

If the database or table do not exist on any node, then check the replication configuration.

Test DML

Use MariaDB Client to test DML.

1. On the primary server, use the MariaDB Client to connect to the node:

1. Insert sample data into the table created in the DDL test:

1. On each replica server, use the MariaDB Client to connect to the node:

1. Execute a query to retrieve the data:

If the data is not returned on any node, check the ColumnStore status and the storage configuration.

Next Step

Navigation in the procedure 'Deploy ColumnStore Object Storage Topology".

This page was step 5 of 9.

Next: Step 6: Install MariaDB MaxScale.

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

Overview

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

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.

Test Enterprise Server Service

Use Systemd to test whether the MariaDB Enterprise Server service is running.

This action is performed on each Enterprise ColumnStore node.

Check if the MariaDB Enterprise Server service is running by executing the following:

If the service is not running on any node, start the service by executing the following on that node:

Test Local Client Connections

Use to test the local connection to the Enterprise Server node.

This action is performed on each Enterprise ColumnStore node:

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.

Test ColumnStore Storage Engine Plugin

Query the table to confirm that the ColumnStore storage engine is loaded.

This action is performed on each Enterprise ColumnStore node.

Execute the following query:

The PLUGIN_STATUS column for each ColumnStore-related plugin should contain ACTIVE.

Test CMAPI Service

Use Systemd to test whether the CMAPI service is running.

This action is performed on each Enterprise ColumnStore node.

Check if the CMAPI service is running by executing the following:

If the service is not running on any node, start the service by executing the following on that node:

Test ColumnStore Status

Use CMAPI to request the ColumnStore status. The API key needs to be provided as part of the X-API-key HTML header.

This action is performed with the CMAPI service on the primary server.

Check the ColumnStore status using curl by executing the following:

Test DDL

Use MariaDB Client to test DDL.

1. On the primary server, use the MariaDB Client to connect to the node:

1. Create a test database and ColumnStore table:

1. On each replica server, use the MariaDB Client to connect to the node:

1. Confirm that the database and table exist:

If the database or table do not exist on any node, then check the replication configuration.

Test DML

Use MariaDB Client to test DML.

1. On the primary server, use the MariaDB Client to connect to the node:

1. Insert sample data into the table created in the DDL test:

1. On each replica server, use the MariaDB Client to connect to the node:

1. Execute a query to retrieve the data:

If the data is not returned on any node, check the ColumnStore status and the storage configuration.

Next Step

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

This page was step 5 of 9.

Next: Step 6: Install MariaDB MaxScale.

Overview

This page details step 7 of the 9-step procedure "Deploy ColumnStore Object 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.

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 Object Storage Topology":

This page was step 7 of 9.

Next: Step 8: Test MariaDB MaxScale

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

Overview

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

This step configures shared local storage on systems hosting Enterprise ColumnStore 23.10.

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

Directories for Shared Local Storage

In a ColumnStore Object Storage topology, MariaDB Enterprise ColumnStore requires the Storage Manager directory to be located on shared local storage.

The Storage Manager directory is at the following path:

• /var/lib/columnstore/storagemanager

The Storage Manager directory must be mounted on every ColumnStore node.

Choose a Shared Local Storage Solution

Select a Shared Local Storage solution for the Storage Manager directory:

For additional information, see "".

Configure EBS Multi-Attach

EBS is a high-performance block-storage service for AWS (Amazon Web Services). EBS Multi-Attach allows an EBS volume to be attached to multiple instances in AWS. Only clustered file systems, such as GFS2, are supported.

For Enterprise ColumnStore deployments in AWS:

• EBS Multi-Attach is a recommended option for the Storage Manager directory.

• Amazon S3 storage is the recommended option for data.

• Consult the vendor documentation for details on how to configure EBS Multi-Attach.

Configure Elastic File System (EFS)

EFS is a scalable, elastic, cloud-native NFS file system for AWS (Amazon Web Services)

For deployments in AWS:

• EFS is a recommended option for the Storage Manager directory.

• Amazon S3 storage is the recommended option for data.

• Consult the vendor documentation for details on how to configure EFS.

Configure Filestore

Filestore is high-performance, fully managed storage for GCP (Google Cloud Platform).

For Enterprise ColumnStore deployments in GCP:

• Filestore is the recommended option for the Storage Manager directory.

• Google Object Storage (S3-compatible) is the recommended option for data.

• Consult the vendor documentation for details on how to configure Filestore.

Configure GlusterFS

GlusterFS is a distributed file system.

GlusterFS is a shared local storage option, but it is not one of the recommended options.

For more information, see "".

Install GlusterFS

On each Enterprise ColumnStore node, install GlusterFS.

Install on CentOS / RHEL 8 (YUM):

Install on CentOS / RHEL 7 (YUM):

Install on Debian (APT):

Install on Ubuntu (APT):

Start the GlusterFS Daemon

Start the GlusterFS daemon:

Probe the GlusterFS Peers

Before you can create a volume with GlusterFS, you must probe each node from a peer node.

1. On the primary node, probe all of the other cluster nodes:

1. On one of the replica nodes, probe the primary node to confirm that it is connected:

1. On the primary node, check the peer status:

Configure and Mount GlusterFS Volumes

Create the GlusterFS volumes for MariaDB Enterprise ColumnStore. Each volume must have the same number of replicas as the number of Enterprise ColumnStore nodes.

1. On each Enterprise ColumnStore node, create the directory for each brick in the /brick directory:

1. On the primary node, create the GlusterFS volumes:

1. On the primary node, start the volume:

1. On each Enterprise ColumnStore node, create mount points for the volumes:

1. On each Enterprise ColumnStore node, add the mount points to /etc/fstab:

1. On each Enterprise ColumnStore node, mount the volumes:

Configure Network File System (NFS)

NFS is a distributed file system. NFS is available in most Linux distributions. If NFS is used for an Enterprise ColumnStore deployment, the storage must be mounted with the sync option to ensure that each node flushes its changes immediately.

For on-premises deployments:

• NFS is the recommended option for the Storage Manager directory.

• Any S3-compatible storage is the recommended option for data.

Consult the documentation for your NFS implementation for details on how to configure NFS.

Next Step

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

This page was step 2 of 9.

Next: Step 3: Install MariaDB Enterprise Server.

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

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:

1. Navigate to

2. Log in.

3. Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

1. 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):

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

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 Enterprise Server and Enterprise ColumnStore

1. 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):

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

Overview

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

This step configures shared local storage on systems hosting Enterprise ColumnStore 23.10.

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

Directories for Shared Local Storage

In a ColumnStore Object Storage topology, MariaDB Enterprise ColumnStore requires the Storage Manager directory to be located on shared local storage.

The Storage Manager directory is at the following path:

• /var/lib/columnstore/storagemanager

The N in dataN represents a range of integers that starts at 1 and stops at the number of nodes in the deployment. For example, with a 3-node Enterprise ColumnStore deployment, this would refer to the following directories:

• /var/lib/columnstore/data1

• /var/lib/columnstore/data2

• /var/lib/columnstore/data3

The DB Root directories must be mounted on every ColumnStore node.

Choose a Shared Local Storage Solution

Select a Shared Local Storage solution for the Storage Manager directory:

• EBS (Elastic Block Store) Multi-Attach

• EFS (Elastic File System)

• Filestore

• GlusterFS

For additional information, see "Shared Local Storage Options".

Configure EBS Multi-Attach

EBS is a high-performance block-storage service for AWS (Amazon Web Services). EBS Multi-Attach allows an EBS volume to be attached to multiple instances in AWS. Only clustered file systems, such as GFS2, are supported.

For Enterprise ColumnStore deployments in AWS:

• EBS Multi-Attach is a recommended option for the Storage Manager directory.

• Amazon S3 storage is the recommended option for data.

• Consult the vendor documentation for details on how to configure EBS Multi-Attach.

Configure Elastic File System (EFS)

EFS is a scalable, elastic, cloud-native NFS file system for AWS (Amazon Web Services)

For deployments in AWS:

• EFS is a recommended option for the Storage Manager directory.

• Amazon S3 storage is the recommended option for data.

• Consult the vendor documentation for details on how to configure EFS.

Configure Filestore

Filestore is high-performance, fully managed storage for GCP (Google Cloud Platform).

For Enterprise ColumnStore deployments in GCP:

• Filestore is the recommended option for the Storage Manager directory.

• Google Object Storage (S3-compatible) is the recommended option for data.

• Consult the vendor documentation for details on how to configure Filestore.

Configure GlusterFS

GlusterFS is a distributed file system.

GlusterFS is a shared local storage option, but it is not one of the recommended options.

For more information, see "".

Install GlusterFS

On each Enterprise ColumnStore node, install GlusterFS.

Install on CentOS / RHEL 8 (YUM):

Install on CentOS / RHEL 7 (YUM):

Install on Debian (APT):

Install on Ubuntu (APT):

Start the GlusterFS Daemon

Start the GlusterFS daemon:

Probe the GlusterFS Peers

Before you can create a volume with GlusterFS, you must probe each node from a peer node.

1. On the primary node, probe all of the other cluster nodes:

1. On one of the replica nodes, probe the primary node to confirm that it is connected:

1. On the primary node, check the peer status:

Number of Peers: 2

Configure and Mount GlusterFS Volumes

Create the GlusterFS volumes for MariaDB Enterprise ColumnStore. Each volume must have the same number of replicas as the number of Enterprise ColumnStore nodes.

1. On each Enterprise ColumnStore node, create the directory for each brick in the /brick directory:

1. On the primary node, create the GlusterFS volumes:

1. On the primary node, start the volume:

1. On each Enterprise ColumnStore node, create mount points for the volumes:

1. On each Enterprise ColumnStore node, add the mount points to /etc/fstab:

1. On each Enterprise ColumnStore node, mount the volumes:

Configure Network File System (NFS)

NFS is a distributed file system. NFS is available in most Linux distributions. If NFS is used for an Enterprise ColumnStore deployment, the storage must be mounted with the sync option to ensure that each node flushes its changes immediately.

For on-premises deployments:

• NFS is the recommended option for the Storage Manager directory.

• Any S3-compatible storage is the recommended option for data.

Consult the documentation for your NFS implementation for details on how to configure NFS.

Next Step

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

This page was step 2 of 9.

Next: Step 3: Install MariaDB Enterprise Server.

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

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 Replication, use the MariaDB Monitor (mariadbmon).

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

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

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:

1. Navigate to

2. Log in.

3. Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

1. 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):

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

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

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:

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

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

Overview

This page details step 2 of a 5-step procedure for deploying Single-Node Enterprise ColumnStore with Object 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:

1. Navigate to

2. Log in.

3. Copy the Customer Download Token.

Substitute your token for CUSTOMER_DOWNLOAD_TOKEN when configuring the package repositories.

Set Up Repository

1. 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):

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

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 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 Object storage deployment procedure:

This page was step 2 of 5.

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

Overview

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

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

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

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 1: Prepare Systems for Enterprise ColumnStore Nodes

Overview

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

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.

Overview

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

This step tests MariaDB Enterprise Server.

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

Test Enterprise Server Service

Use Systemd to test whether the MariaDB Enterprise Server service is running.

This action is performed on each Enterprise Cluster node.

Check if the MariaDB Enterprise Server service is running by executing the following:

If the service is not running on any node, start the service by executing the following on that node:

Test Local Client Connections

Use to test the local connection to the Enterprise Server node.

This action is performed on each Enterprise Cluster node:

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.

Test Cluster Status

MariaDB Enterprise Cluster is operational when the cluster has a Primary Component. Query the status variable with SHOW GLOBAL STATUS to confirm that each node belongs to the Primary Component.

This action is performed on each Enterprise Cluster node.

Check the cluster status by executing the following:

If the Value column does not contain Primary on any node, then the node is not part of the Primary Component. Investigate network connectivity between the node and the nodes in the Primary Component.

Test Cluster Size

MariaDB Enterprise Cluster maintains a count of the cluster size. Query the status variable with SHOW GLOBAL STATUS to confirm the number of nodes currently in the cluster.

This action is performed on each Enterprise Cluster node.

Check the cluster size by executing the following:

If the Value column does not contain the expected number of nodes, then some nodes might not be in the cluster. Check the value of the on each node to confirm that all nodes are in the same cluster.

Test DDL

Use MariaDB Client to test DDL.

1. On a single Enterprise Cluster node, use the MariaDB Client to connect to the node:

Create a test database and InnoDB table:

1. On each other Enterprise Cluster node, use the MariaDB Client to connect to the node:

1. Confirm that the database and table exist:

If the database or table do not exist on any node, then check that:

The nodes are in the Primary Component of the same cluster.

The wsrep_osu_method system variable is not set to RSU.

Test DML

Use MariaDB Client to test DML.

1. On a single Enterprise Cluster node, use the MariaDB Client to connect to the node:

1. Insert sample data into the table created in the DDL test:

1. On each other Enterprise Cluster node, use the MariaDB Client to connect to the node:

1. Execute a query to retrieve the data:

If the data is not returned on any node, then check that:

• The nodes are in the Primary Component of the same cluster.

• The table uses the InnoDB storage engine.

• The wsrep_on system variable is set to ON.

Next Step

Navigation in the procedure "Deploy Galera Cluster Topology":

This page was step 3 of 6.

Next: Step 4: Install MariaDB MaxScale

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.

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:

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.

1. Bootstrap the Primary Component:

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

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

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

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

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

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

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

Overview

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

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.

Configure Enterprise ColumnStore

Mandatory system variables and options for Single-Node Enterprise ColumnStore include:

Example Configuration

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:

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.

1. On the Enterprise ColumnStore node, create the user account with the statement:

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

1. Configure Enterprise ColumnStore to use the utility user:

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

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:

1. 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:

1. Allow the system to run under load for a while to generate SELinux audit events.

2. 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:

1. If audit events were found, the new SELinux policy can be loaded using semodule:

1. 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:

1. 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 Single-Node Enterprise ColumnStore topology with Local storage deployment procedure:

This page was step 3 of 5.

Next: Step 4: Test MariaDB Enterprise ColumnStore.

This procedure describes the deployment of the Single-Node Enterprise ColumnStore topology with Local storage.

MariaDB Enterprise ColumnStore 23.10 is a columnar storage engine for MariaDB Enterprise Server 10.6. Enterprise ColumnStore is best suited for Online Analytical Processing (OLAP) workloads.

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

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

Please read and understand this procedure before executing.

Procedure Steps

Support

Customers can obtain support by .

Components

The following components are deployed during this procedure:

MariaDB Enterprise Server Components

Topology

The Single-Node Enterprise ColumnStore topology provides support for Online Analytical Processing (OLAP) workloads to MariaDB Enterprise Server.

The Enterprise ColumnStore node:

• Receives queries from the application

• Executes queries

• Uses the local disk for storage.

High Availability

Single-Node Enterprise ColumnStore does not provide high availability (HA) for Online Analytical Processing (OLAP). If you would like to deploy Enterprise ColumnStore with high availability, see .

Requirements

These requirements are for the Single-Node Enterprise ColumnStore, when deployed with MariaDB Enterprise Server 10.6 and MariaDB Enterprise ColumnStore 23.10.

Operating System

• 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)

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:

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:

Quick Reference

MariaDB Enterprise Server Configuration Management

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.

MariaDB Enterprise Server Service Management

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

Next Step

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

• Next: Step 1: Install MariaDB Enterprise ColumnStore 23.10.

Overview

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

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.

Test S3 Connection

MariaDB Enterprise ColumnStore 23.10 includes a testS3Connection command to test the S3 configuration, permissions, and connectivity.

On each Enterprise ColumnStore node, test the S3 configuration:

If the testS3Connection command does not return OK, investigate the S3 configuration.

Test Local Connection

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

Test ColumnStore Plugin Status

Query and confirm that the ColumnStore storage engine plugin is ACTIVE:

Test ColumnStore Table Creation

1. Create a test database, if it does not exist:

1. Create a ColumnStore table:

1. Add sample data into the table:

1. Read data from table:

Test Cross Engine Join

1. Create an InnoDB table:

1. Add data to the table:

1. Perform a cross-engine join:

Next Step

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

This page was step 4 of 5.

Next: Step 5: Bulk Import of Data.

Overview

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

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

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 the 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 the Data Node.

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

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 Table

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

If your Data Table already exists, grant privileges on the table to the Spider user.

On the Data Node, create the Data Table:

The Spider Node reads and writes to the Data Table using the server and user account configured in "". The user account must have .

Grant Privileges

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

On the 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 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 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 Data Table.

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

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

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

Next Step

Navigation in the procedure "Deploy Spider Federated Topology":

This page was step 2 of 3.

Next: Step 3: Test Spider Federated Topology.

Overview

This page details step 1 of the 3-step procedure "Deploy Spider Federated Topology".

This step installs the Enterprise Spider storage engine plugin on the Spider Node.

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

Allow Interconnect

MariaDB Enterprise Spider depends on interconnect between the Spider Node and the Data Node. This may require adjustment to firewall and security settings.

Install Spider Package

The plugin is not installed with MariaDB Enterprise Server by default. An additional package must be installed.

Install via YUM (CentOS, RHEL)

On the Spider Node, install MariaDB Enterprise Spider:

Install via APT (Debian, Ubuntu)

On the Spider Node, install MariaDB Enterprise Spider:

Install via ZYpp (SLES)

On the Spider Node, install MariaDB Enterprise Spider:

Load the Spider Plugin

The plugin must be loaded by MariaDB Enterprise Server.

On the Spider Node, use one of the following methods to configure MariaDB Enterprise Server to load the Enterprise Spider storage engine plugin:

Load Spider with Configuration File

On the Spider Node, set the plugin_load_add option to ha_spider in a configuration file. This option configures MariaDB Enterprise Server to load the Enterprise Spider storage engine plugin. The Spider Node must be restarted to detect the configuration change.

1. 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 will be read last by creating a custom configuration file in one of the included directories. Configuration files in included directories are read in alphabetical order. Ensure that your custom configuration file is read last by using the z- prefix in the file name. Some example configuration file paths for different distributions are shown in the following table:

1. Set the plugin_load_add option in the configuration file. It must be set in a group that will be read by MariaDB Server, such as [mariadb] or [server]. For example:

1. Restart MariaDB Enterprise Server:

Load Spider with INSTALL SONAME

On the Spider Node, execute the statement with the library name ha_spider. The INSTALL SONAME statement configures MariaDB Enterprise Server to load the Enterprise Spider storage engine plugin. The INSTALL SONAME statement requires the SUPER privilege.

The INSTALL SONAME statement adds the Enterprise Spider storage engine to the system table. When the Spider Node is restarted, MariaDB Enterprise Server reads the system table and reloads the plugin, so the statement only needs to be executed once.

1. Connect to the Spider Node using :

1. Use the INSTALL SONAME statement to install the Enterprise Spider storage engine plugin:

Test Plugin Installation

On the Spider Node, confirm that the Enterprise Spider storage engine plugin is loaded by querying the information_schema.PLUGINS table:

When the Enterprise Spider storage engine is loaded, the PLUGIN_NAME column contains the value SPIDER and the PLUGIN_STATUS column contains the value ACTIVE.

Next Step

Navigation in the procedure "Deploy Spider Federated Topology''.

This page was step 1 of 3.

Next: Step 2: Configure Spider Node and Data Node

Overview

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

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.

Optimize Linux Kernel Parameters

MariaDB Enterprise ColumnStore performs best with Linux kernel optimizations.

On each server to host an Enterprise ColumnStore node, optimize the kernel:

1. Set the relevant kernel parameters in a sysctl configuration file. To ensure proper change management, use an Enterprise ColumnStore-specific configuration file.

Create a /etc/sysctl.d/90-mariadb-enterprise-columnstore.conf file:

1. Use the sysctl command to set the kernel parameters at runtime

Temporarily Configure Linux Security Modules (LSM)

The Linux Security Modules (LSM) should be temporarily disabled on each Enterprise ColumnStore node during installation.

The LSM will be configured and re-enabled later in this deployment procedure.

The steps to disable the LSM depend on the specific LSM used by the operating system.

CentOS / RHEL Stop SELinux

SELinux must be set to permissive mode before installing MariaDB Enterprise ColumnStore.

To set SELinux to permissive mode:

1. Set SELinux to permissive mode:

1. 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:

1. Confirm that SELinux is in permissive mode:

SELinux will be configured and re-enabled later in this deployment procedure. This configuration is not persistent. If you restart the server before configuring and re-enabling SELinux later in the deployment procedure, you must reset the enforcement to permissive mode.

Debian / Ubuntu AppArmor

AppArmor must be disabled before installing MariaDB Enterprise ColumnStore.

1. Disable AppArmor:

1. Reboot the system.

2. Confirm that no AppArmor profiles are loaded using aa-status:

AppArmor will be configured and re-enabled later in this deployment procedure.

Configure Character Encoding

When using MariaDB Enterprise ColumnStore, it is recommended to set the system's locale to UTF-8.

1. On RHEL 8, install additional dependencies:

1. Set the system's locale to en_US.UTF-8 by executing localedef:

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.

S3 bucket configuration will be performed later in this procedure.

Next Step

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

This page was step 1 of 5.

Next: Step 2: Install MariaDB Enterprise ColumnStore.

Overview

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

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.

Overview

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

This step starts and configures MariaDB MaxScale 22.08.

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

Overview

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

This step tests MariaDB Enterprise Server

Several actions require connection to MariaDB Enterprise Server. A command-line client (mariadb) was included with your ES installation. These instructions describe connection via Unix domain socket. Alternatively, a different client and connection method could be used.

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

Overview

This procedure describes the deployment of the Galera Cluster topology

Overview

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

This step starts and configures a MariaDB Enterprise Server to operate as a primary server in MariaDB Replication.

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

Overview