When a MariaDB Replica on a Second VPS Is Worth It

A replica is a second MariaDB instance that applies the primary's binary log. It is not automatic failover, not a substitute for dumps, and not a reason to double every VPS on day one. It is worth it when you can name the job: take backups off the primary, isolate long reads, or keep a warm copy in the same Lucknow DC01 network for a planned promotion. If the job is "high availability" and you have not written a promotion runbook, the replica will give you lag and a false sense of safety.

Two Ubuntu VPS nodes, private connectivity, ROW binlogs, and a replica user with a tight host are the whole architecture for most applications. You do not need a cluster to get that.

The cases that pay for a second instance

Backups that do not lock or load the primary. mariadb-dump --single-transaction is already gentle, but a replica lets you stop the SQL thread, dump a frozen view, and start it again without touching production connections. That is the cleanest reason to add a second VPS.

Read offload for a report, an analytics query, or a search indexer that scans more than the primary's buffer pool can hide. Point those clients at the replica with a DSN they cannot write to. If the application cannot split reads, a replica will not magically make writes faster.

A rehearsal box for schema changes. Apply the ALTER on the replica first, watch lag, then decide. This is not online schema change by itself, but it is cheaper than discovering a 20 minute rewrite on the primary.

What does not pay: a replica as your only backup, a replica you never monitor for Seconds_Behind_Source, or a replica on the public internet with 3306 open "so failover is easy." Keep both instances bound to private addresses or localhost-plus-tunnel, the same way you would a single primary.

Async replica, one primary, no drama

On the primary, binary logs are already on, server-id is 1, and a dump with coordinates exists. Create a replica user that can only connect from the replica's private IP.

-- on primary
CREATE USER 'repl'@'10.8.0.21' IDENTIFIED BY 'rotate-repl-secret';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.8.0.21';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;

On the replica, server-id must differ. Restore the dump, then point the replica at the primary's coordinates. MariaDB 10.11+ prefers CHANGE MASTER... still on many installs; 11.x also accepts CHANGE REPLICATION SOURCE. Use the syntax your series documents.

# /etc/mysql/mariadb.conf.d/95-replica.cnf on the replica only
# [mysqld]
# server-id = 2
# relay_log = /var/log/mysql/relay-bin
# read_only = 1
# super_read_only = 1

CHANGE MASTER TO
  MASTER_HOST='10.8.0.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='rotate-repl-secret',
  MASTER_LOG_FILE='mariadb-bin.000214',
  MASTER_LOG_POS=194;
START SLAVE;
SHOW SLAVE STATUS;

Read Slave_IO_Running, Slave_SQL_Running, Last_Error, and Seconds_Behind_Master (names vary by series). Both threads Yes and behind-source near 0 is healthy. SQL thread No with an error is a broken replica; do not "just START SLAVE" without reading the error. Duplicate key after a split-brain is a rebuild, not a restart.

read_only and super_read_only on the replica stop accidental writes from a mis-pointed app. They do not stop a user with SUPER. Keep SUPER off the application account.

Promotion is a runbook, not a DNS flip you invent at 2 a.m.

Async replication can lose the last events if the primary dies before they reach the replica. If that is unacceptable you need a different design (semi-sync, or a single primary with PITR). For most apps the trade is acceptable if you:

• Monitor lag and disk on both VPS nodes.
• Never write to the replica.
• Promote by: stop writes to the old primary, wait for the replica to catch up, SHOW MASTER STATUS on the replica, point apps at it, keep the old primary off until you rebuild it as a replica.

Two nodes in the same Lucknow facility share facility risk. A replica is not an off-site backup. Keep dumps somewhere that is not those two disks.

If the application still fits in a 4 GB buffer pool and backups finish in minutes, stay on one VPS. Add the second instance when a named job appears, not when a blog post says HA.

Add a replica when you can name the job it does: dumps, long reads, or a rehearsed promotion. Two VPS nodes with ROW binlogs and a tight repl user are enough. You can provision that pair on Netbay in Lucknow in under a minute each from the dashboard or the API at netbayhosts.in.