Deploy a Replicated MariaDB Cluster with Quick Start in InMotion Central

Introduction

A single database server is a single point of failure. If it goes down, every application that depends on it goes down too. A replicated cluster keeps a full copy of your data on several servers, so the database keeps working when one of them fails.

The Replicated MariaDB Quick Start template in InMotion Central builds that cluster for you. It launches three Ubuntu 24.04 LTS servers running MariaDB with Galera replication, so every server holds the same data and accepts both reads and writes. A private load balancer gives your applications one address to connect to and spreads connections across all three servers.

In this tutorial, we'll show you how to deploy the cluster, connect to it from another server on your private network, and confirm all three servers are replicating.

Steps to Deploy the Replicated MariaDB Template

1. Open Quick Start in Your Cloud Project

1. Log in to InMotion Central and select Projects from the left navigation bar.
2. Open your cloud project and click Quick Start in the project sidebar.
3. Locate the Replicated MariaDB template card and click Deploy.

2. Configure Your Deployment Settings

In the Deploy Replicated MariaDB dialog, review or customize the settings:

Basic

• Stack name: Enter a name for this deployment (for example, mariadb-cluster). Use letters, numbers, dots, underscores, or hyphens.
• Cluster name: Enter a base name for the three servers (defaults to mariadb). The servers are named mariadb-1, mariadb-2, and mariadb-3.
• Image: Choose Ubuntu 24.04 LTS.
• Flavor: Choose the size for each of the three database servers.

Application

• Database password: Enter a password of at least 8 characters for the db user. Your applications use this user to connect from the private network.

Networking

• If your project already has a private network, select it from the Private network dropdown. If not, InMotion Central offers to create a Private Network + Router deployment first.
• Private network CIDR: The address range allowed to reach the database and the replication ports (defaults to 192.168.10.0/24). Use the same range as your private network.

The cluster has no public IP address. Only servers on your private network can reach it.

SSH

• SSH key: Select an existing SSH key, click Generate New Key, or click Paste Public Key. You need a key to sign in to the server.
• SSH whitelist: Confirm the comma-separated IP addresses or CIDR ranges allowed on port 22 (prefilled with your current public IP address). Leave this field empty if you want port 22 closed.

Because the database servers have no public IP addresses, you can only SSH to them from inside the private network. To allow that, add your private network range (for example, 192.168.10.0/24) to the whitelist.

3. Launch and Monitor Your Deployment

1. Click Deploy (or Create Network And Deploy if you are creating a private network at the same time).
2. Scroll down to My Deployments at the bottom of the Quick Start page to track progress.
3. Wait about five minutes while the three servers boot, install MariaDB, and join the cluster one at a time. When setup finishes, the Status column for mariadb-cluster changes to CREATE_COMPLETE.

4. Copy the Cluster Address

1. Next to your mariadb-cluster deployment under My Deployments, click Outputs.
2. Copy the cluster_address value. This is the private address of the load balancer. Your applications connect to this address on port 3306 as the db user.

How to Know the Installation Was Successful

Sign in to any other server on the same private network (for example, a Single Server deployment) and install the MariaDB client if it doesn't have one:

1$ sudo apt-get install -y mariadb-client
Copy

Then ask the cluster how many servers are connected and whether they are in sync. Replace <cluster_address> with the address you copied, and enter your database password when asked:

1$ mariadb -h <cluster_address> -u db -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'; SHOW STATUS LIKE 'wsrep_local_state_comment';"
Copy

Our test deployment returned:

Variable_name       Value
wsrep_cluster_size  3
Variable_name              Value
wsrep_local_state_comment  Synced

A cluster size of 3 means all three servers joined, and Synced means the server you reached has a complete, up-to-date copy of the data.

Check that the load balancer uses all three servers

1$ for i in 1 2 3; do mariadb -h <cluster_address> -u db -p'<password>' -N -e 'SELECT @@hostname'; done
Copy

mariadb-1
mariadb-3
mariadb-2

Each new connection goes to the next server in turn. In our test, a row written through the load balancer could be read back immediately from a different server, which confirms the data is replicated.

What Was Automatically Set Up

• Three database servers (mariadb-1, mariadb-2, and mariadb-3) running Ubuntu 24.04 LTS and MariaDB 10.11.14 with Galera replication. Every server accepts reads and writes, and each change is copied to the other two before it is confirmed.
• A db user with full privileges and the password you chose, allowed to connect from anywhere on the private network.
• A private load balancer that listens on port 3306 at the cluster_address, takes turns sending each new connection to the three servers (round robin), and stops using a server that fails its health check.
• A firewall that allows MariaDB (port 3306) and the replication ports (4444, 4567, and 4568) only from your private network range, SSH (port 22) only from your whitelist, and ping.

The cluster keeps working if one server goes down, because the other two still form a majority. Point your applications at the cluster_address, not at a single server's address, so they keep working if one server is unavailable.