Set Up MariaDB Replication on Ubuntu 26.04 LTS

This tutorial shows how to set up MariaDB replication on Ubuntu 26.04 LTS for a dedicated server pair, with one primary and one replica keeping data in sync.

You will install MariaDB, configure replication identifiers and binary logging, seed the replica from an initial snapshot, start replication, and verify that the replica is following the primary at the expected binary log position.

Prerequisites

Two Ubuntu 26.04 LTS dedicated servers: one primary and one replica
Root access or a normal administrative user with sudo privileges on both servers
Network reachability from the replica to the primary MariaDB service
Enough disk space on the replica to restore the initial database snapshot
Access to the primary and replica IP addresses used in the replication configuration

Tutorial steps

Install MariaDB on both servers and make sure the service is enabled and running under systemd.

sudo apt update

sudo apt install mariadb-server mariadb-client

sudo systemctl enable --now mariadb

Confirm the service state on each server before moving on.

sudo systemctl status mariadb

On the primary server, open the MariaDB client and verify that replication-required settings are in place.

sudo mariadb

SHOW VARIABLES LIKE 'server_id';

SHOW VARIABLES LIKE 'log_bin';

The primary must have binary logging enabled and a unique server ID. If those values are not already set in the MariaDB configuration, define them before continuing.

Still on the primary, capture the current binary log coordinates that the replica will use as its starting point.

SHOW MASTER STATUS;

Create a dedicated replication account that the replica will use to read binary logs from the primary. Replace REPLICA_IP with the replica server address.

CREATE USER 'repl'@'REPLICA_IP' IDENTIFIED BY 'strong_password';

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'REPLICA_IP';

FLUSH PRIVILEGES;

Record the File and Position values from SHOW MASTER STATUS;; you will need them when you configure the replica source.

Take an initial snapshot of the primary so the replica starts from an identical dataset. Run the dump command on the primary or from a host that can reach it and preserve the generated file.

mysqldump -u root -p --single-transaction --all-databases --master-data=2 > mariadb-backup.sql

On the replica server, restore the snapshot into the local MariaDB instance.

mariadb -u root -p < mariadb-backup.sql

On the replica, verify the local service is active and confirm that its server ID differs from the primary. If you use relay or binary log settings on the replica, verify those values are present as expected before starting replication.

sudo systemctl status mariadb

sudo mariadb

SHOW VARIABLES LIKE 'server_id';

Configure the replica to point at the primary. Replace PRIMARY_IP, binlog_name, and binlog_position with the values collected from the primary.

CHANGE REPLICATION SOURCE TO SOURCE_HOST='PRIMARY_IP', SOURCE_USER='repl', SOURCE_PASSWORD='strong_password', SOURCE_LOG_FILE='binlog_name', SOURCE_LOG_POS=binlog_position;

Start replication on the replica.

START REPLICA;

Verification

Check replication status on the replica and confirm that both threads are running.

SHOW REPLICA STATUS\G

Verify that Replica_IO_Running: Yes and Replica_SQL_Running: Yes appear in the output. Confirm that the reported source coordinates match the binary log file and position you recorded from the primary, and review the lag fields to ensure the replica is caught up or within the expected delay.

Also confirm that MariaDB is running on both dedicated servers through systemd and that the initial snapshot imported without errors.

If the replica is not following the primary, use the status output to compare the configured source host, log file, and log position against the values from SHOW MASTER STATUS;.

Troubleshooting

If Replica_IO_Running is No, check that the replication user, password, and REPLICA_IP match the account created on the primary, and confirm the replica can reach the primary MariaDB service.

If Replica_SQL_Running is No, inspect the replica status output for the last SQL error. A snapshot taken without --single-transaction or restored from the wrong starting position can cause divergence.

If the source coordinates do not match the expected binary log position, repeat the snapshot and restore process so the replica starts from the same point in time as the primary.

Rollback

If you need to stop replication and return the replica to an unconfigured state, stop the replica threads first.

STOP REPLICA;

Then remove the replication connection metadata on the replica.

RESET REPLICA ALL;

After rollback, the replica no longer follows the primary and can be reconfigured later with fresh source coordinates and a new snapshot if needed.

Conclusion

You have set up MariaDB replication on Ubuntu 26.04 LTS for a dedicated server deployment, configured the primary and replica roles, restored the initial snapshot, and started the replication stream.

You can now verify that MariaDB is running on both servers, that the primary has binary logging enabled with a unique server ID, and that the replica reports healthy replication status with the expected source coordinates.