Create a Database Cluster

Create a Database Cluster

Choose from the list of database cluster technology, vendors, and versions to deploy a new database cluster. The following database cluster types are supported:

• MySQL/MariaDB (standalone or replication)
  • Oracle MySQL
  • Percona Server for MySQL
  • MariaDB Server
• Galera Cluster
  • Percona XtraDB Cluster
  • MariaDB Cluster
• PostgreSQL (standalone or streaming replication)
• TimescaleDB (standalone or streaming replication)
• MongoDB (Replica Set or Sharded Cluster)
  • MongoDB
  • Percona Server for MongoDB
• Redis
  • Sentinel
  • Cluster
• Microsoft SQL Server for Linux
• Elasticsearch
• Valkey Cluster

There are prerequisites that need to be fulfilled prior to the deployment:

• Passwordless SSH (SSH using key-based authentication) is configured from the ClusterControl node to all database nodes. See Passwordless SSH.
• Verify that sudo is working properly if you are using a non-root user. See Operating System User.

ClusterControl will trigger a deployment job and the progress can be monitored under ClusterControl v2 → Activity Center → Jobs.

MySQL Replication

Deploys a new MySQL/MariaDB Replication or a standalone MySQL/MariaDB server. The database cluster will be automatically added into ClusterControl once deployed. A minimum of two nodes is required for MySQL/MariaDB replication. If only one database IP address or hostname is provided, ClusterControl will deploy it as a standalone MySQL/MariaDB server with binary log enabled.

The following vendors and versions are supported for a new deployment:

• Oracle MySQL – 8.0.
• Percona Server for MySQL – 8.0.
• MariaDB Server – 10.4, 10.5, 10.6, 10.11 and 11.4 LTS.

By default, ClusterControl deploys MySQL/MariaDB replication with the following configurations:

• MySQL GTID with log_slave_updates enabled (MySQL and Percona only).
• MariaDB GTID with log_slave_updates enabled (MariaDB only).
• All database nodes will be configured with read_only=ON and super_read_only=ON (if supported). The chosen primary will be promoted by disabling the read-only in the runtime.
• ClusterControl will create and grant necessary privileges for two MySQL/MariaDB users – cmon for monitoring and management and backupuser for backup and restore purposes.
• The generated account credentials are stored inside secrets-backup.cnf under the MySQL configuration directory.

If you would like to customize the above configurations, modify the template base file to suit your needs before proceeding to the deployment. See  Base Template Files for details.

It is possible to set up a primary-primary replication from scratch under the Add Nodes section. You can also add more replicas later after the deployment is completed.

 

MySQL Galera

Deploys a new MySQL/MariaDB Galera Cluster. The database cluster will be automatically added into ClusterControl once deployed. A minimal setup is comprised of one Galera node (no high availability, but this can later be scaled with more nodes). However, a minimum of three nodes is recommended for high availability. Garbd (an arbitrator) can be added later after the deployment completes if needed.

The following vendors and versions are supported for a new deployment:

• Percona XtraDB Cluster – 8.0.
• MariaDB Cluster – 10.4, 10.5, 10.6, 10.11 and 11.4 LTS.

By default, ClusterControl deploys MySQL Galera with the following configurations:

• Use xtrabackup-v2 or mariabackup (depending on the vendor chosen) for wsrep_sst_method.
• Binary logging is enabled.
• ClusterControl will create and grant necessary privileges for two MySQL users – cmon for management, cmonexporter for monitoring and backupuser for backup and restore purposes.
• Generated account credentials are stored inside /etc/mysql/secrets-backup.cnf.

 

PostgreSQL

Deploys a new PostgreSQL standalone or streaming replication cluster from ClusterControl. A minimum of two nodes is required for PostgreSQL streaming replication. The following vendors and versions are supported for a new deployment:

• PostgreSQL – 12, 13, 14, 15, and 16.

By default, ClusterControl deploys PostgreSQL instances with the following configurations:

• Configure and load the pg_stat_statements module.
• The WAL level is set to hot_standby.
• ClusterControl will configure the PostgreSQL instance with SSL encryption for client-server connections.
• ClusterControl will create and grant necessary privileges for an additional PostgreSQL user – cmon_replication for PostgreSQL streaming replication, and cmonexporter for monitoring.

ClusterControl now supports pgvector which can be enabled with our PostgreSQL deployment wizard through an additional extensions step. While we intend to add more extensions to PostgreSQL in future releases, pgvector is the only extension currently available for selection.

 

TimescaleDB

Deploys a new TimescaleDB standalone or streaming replication cluster from ClusterControl. A minimum of two nodes is required for TimescaleDB streaming replication. The following vendors and versions are supported for a new deployment:

• TimescaleDB – 12, 13,14 and 15.

By default, ClusterControl deploys TimescaleDB with the following configurations:

• Configure and load the pg_stat_statements and timescaledb modules.
• The WAL level is set to hot_standby.
• ClusterControl will configure the TimescaleDB instance with SSL encryption for client-server connections.
• ClusterControl will create and grant necessary privileges for an additional TimescaleDB user – cmon_replication for streaming replication and cmonexporter for monitoring.

 

MongoDB ReplicaSet

Deploys a new MongoDB Replica Set. The database cluster will be automatically added to ClusterControl once deployed. A minimum of three nodes (including mongo arbiter) is recommended. The following vendors and versions are supported for a new deployment:

• MongoDB – 4.4, 5.0, 6.0 and 7.0
• Percona – 4.4, 5.0, 6.0 and 7.0

By default, ClusterControl deploys MongoDB Replica Set members with the following configurations:

• Configure setParameter.enableLocalhostAuthBypass: true inside MongoDB configuration file.
• ClusterControl will create and grant necessary privileges for an additional MongoDB user – admin.cmon_backup for backup and restore purposes.

 

MongoDB Shards

Deploys a new MongoDB Sharded Cluster. The database cluster will be automatically added to ClusterControl once deployed. For production deployment, it is recommended to have at least 8 nodes for high availability setup:

• 2 nodes for the mongos (router),
• 3 nodes for the config server (replica set),
• 3 nodes per shard (replica set).

The following vendors and versions are supported for a new deployment:

• MongoDB Enterprise – 4.4, 5.0, 6.0 and 7.0
• MongoDB – 4.4, 5.0, 6.0 and 7.0
• Percona – 4.4, 5.0, 6.0 and 7.0

By default, ClusterControl deploys MongoDB Shards with the following configurations:

• Configure setParameter.enableLocalhostAuthBypass: true inside MongoDB configuration file.
• ClusterControl will create and grant necessary privileges for an additional MongoDB user – admin.cmon_backup for backup and restore purposes.

 

Redis Sentinel

Deploys new Redis instances with Redis Sentinel. A minimum of 3 nodes is recommended for high availability and automatic failover. The following vendors and versions are supported for a new deployment:

• Redis Sentinel – v6 and v7

By default, ClusterControl deploys Redis instances with the following configurations:

• ClusterControl will configure the Redis instance with appendonly enabled.
• ClusterControl will secure the instance with AUTH enabled and configure the requirepass and masterauth options.
• The configuration maxMemory (70% of node’s RAM, rounded to the nearest power of 2) and maxMemoryPolicy=allkeys-lru will be set.

Redis Cluster

Deploy a new Redis Cluster. A minimum of 3 nodes is recommended for high availability and automatic failover. For production deployment, it is recommended to have at least 6 nodes for high availability setup:

• 2 nodes (1 primary + 1 replica) for shard 1
• 2 nodes (1 primary + 1 replica) for shard 2
• 2 nodes (1 primary + 1 replica) for shard 3

The following vendors and versions are supported for a new deployment:

• Redis Cluster – v6 and v7

By default, ClusterControl deploys Redis cluster instances with the following configurations:

• ClusterControl will configure the Redis instance with appendonly enabled.
• ClusterControl will secure the instance with AUTH enabled and configure the requirepass and masterauth options.
• ClusterControl will enable TLS encryption. To access the cluster, one must use the --tls flag to connect.
• The configuration maxMemory (70% of node’s RAM, rounded to the nearest power of 2) and maxMemoryPolicy=allkeys-lru will be set.

 

SQL Server

Deploys a new Microsoft SQL Server AlwaysOn high availability setup. A minimum of 3 nodes is required. The following vendors and versions are supported for a new deployment:

• Microsoft SQL Server for Linux – 2019 and 2022

By default, ClusterControl deploys MySQL Galera with the following configurations:

• Enforces the SQL Server user’s password policy as shown here.
• At the moment, ClusterControl only deploys AlwaysOn with asynchronous-commit mode, where it does not wait for any secondary replica to write incoming transaction log records to disk.

 

Elasticsearch

Deploys a new Elasticsearch standalone or clustered setup. For a clustered Elasticsearch setup, 3 nodes are required with 3 eligible masters and 2 data nodes (co-located with the masters). The following vendor and versions are supported for a new deployment:

• Elastic – 7.17, 8.0, 8.1 and 8.3

By default, ClusterControl deploys Elasticsearch with the following configurations:

• For clustered setup, ClusterControl will configure an NFS server on one of the Elasticsearch nodes and mount the shared filesystem on all data nodes. This is for snapshot backup and restoration.
• For standalone setup, ClusterControl will create a local path for snapshot backup and restoration.

 

Valkey Cluster

Deploy a new Valkey Cluster. A minimum of 3 nodes is recommended for high availability and automatic failover. For production deployment, it is recommended to have at least 6 nodes for high availability setup:

• 2 nodes (1 primary + 1 replica) for shard 1
• 2 nodes (1 primary + 1 replica) for shard 2
• 2 nodes (1 primary + 1 replica) for shard 3

The following vendors and versions are supported for a new deployment:

• Valkey Cluster – v7.2.5

By default, ClusterControl deploys Valkey cluster instances with the following configurations:

• ClusterControl will configure the Redis instance with appendonly enabled.
• ClusterControl will secure the instance with AUTH enabled and configure the requirepass and masterauth options.
• ClusterControl will enable TLS encryption. To access the cluster, one must use the --tls flag to connect.
• The configuration maxMemory (70% of node’s RAM, rounded to the nearest power of 2) and maxMemoryPolicy=allkeys-lru will be set.

Base Template Files

All services configured by ClusterControl use a base configuration template available under /usr/share/cmon/templates on the ClusterControl node. You can directly modify the file to suit your deployment policy however, this directory will be replaced after a package upgrade.

To make sure your custom configuration template files persist across upgrades, store your template files under the /etc/cmon/templates directory (ClusterControl 1.6.2 and later). When ClusterControl loads up the template file for deployment, files under /etc/cmon/templates will always have higher priority over the files under /usr/share/cmon/templates. If two files having identical names exist on both directories, the one located under /etc/cmon/templates will be used.

Here is an example of how one would create a custom configuration template file:

# on the ClusterControl node, as privileged user
mkdir -p /etc/cmon/templates
cp /usr/share/cmon/templates/my.cnf.repl80 /etc/cmon/templates/my.cnf.repl80-custom
vi /etc/cmon/templates/my.cnf.repl80-custom     # make your changes and save

Go to the ClusterControl and start deploying a database cluster. Choose the created configuration file above from the Configuration template dropdown.

Dynamic Variables

Inside the provided template files, many configuration variables are configurable dynamically by ClusterControl during deployment. These variables are represented with a capital letter enclosed by @, for example, @DATADIR@. The following shows the list of variables supported by the ClusterControl, grouped by the cluster type: