Primary-Secondary Replication
MySQL / MariaDB / Percona Primary-Secondary Replication
Primary-secondary replication copies updates from one primary database server to one or more secondary servers. It can support scale-out reads, backups, analytics, data distribution, security, and failover-oriented architectures.

Replication Use Cases
- Backups: back up a secondary without stopping the primary.
- Scale-out: distribute read-heavy workloads across secondary servers.
- Analytics: run analysis on replicated data away from the primary workload.
- Data distribution: replicate selected data to different locations or teams.
- Failover alleviation: monitor the primary and redirect applications if it fails.
- Security: SSL can encrypt replication traffic when both ends support SSL.
Automatic Installation
- Click New Environment.
- Select MySQL, MariaDB, or Percona.
- Enable Auto-Clustering.
- Select Primary-Secondary from the Scheme list.
- Adjust the remaining environment parameters and click Create.

You can also install a preconfigured MySQL/MariaDB/Percona Cluster from Marketplace and choose the required replication type during installation.

Manual Installation
The manual workflow below is applicable to both MySQL and MariaDB. Create two identical environments: one for the primary and one for the secondary. The source example names them primary-db and secondary-db.



Configure the Primary Database
Open Config for the primary database and update my.cnf:
server-id = 1 log-bin = mysql-bin binlog-format = mixed
mixed binlog format. The source guide specifically warns against the statement format for this setup because it can cause replication errors with foreign-key operations.

Save the configuration and restart MariaDB.

Open phpMyAdmin, go to User accounts, create a replication user, and grant the replication client and replication slave administration privileges.



Open the Status tab and record the binary-log File and Position values. These values are required on the secondary.

Configure the Secondary Database
Open my.cnf on the secondary database and add:
server-id = 2 slave-skip-errors = all
slave-skip-errors = all for its example but explicitly says this is generally not recommended. In production, ignore only specific errors when necessary so critical replication problems are not hidden.
Then add this option to /etc/phpMyAdmin/config.inc.php:
$cfg['AllowArbitraryServer'] = true;

Save the changes, restart the secondary database, open Web SSH, and connect to MySQL/MariaDB:
mysql -u root -p

Set the Replication Source
Use the primary database host, replication username/password, binary-log file, and log position recorded earlier.
MariaDB
CHANGE MASTER TO
MASTER_HOST='node410337-primary-db.domain.com',
MASTER_USER='replication',
MASTER_PASSWORD='passw0rd',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=865;
MySQL 8.0.22+ and Percona
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='node410337-primary-db.domain.com',
SOURCE_USER='replication',
SOURCE_PASSWORD='passw0rd',
SOURCE_LOG_FILE='mysql-bin.000001',
SOURCE_LOG_POS=865;

Start replication with:
START REPLICA;
For MySQL versions before 8.0.22 and MariaDB before 10.5.1, the source guide uses:
START SLAVE;

Open the secondary database Status tab and confirm that replication is running.

Check the Replication
Create a new database such as replication_test on the primary.

Open the secondary database. The same database should appear there after replication.

Expected Result
The primary database records updates in its binary log and the secondary receives and applies those updates. A database created on the primary is reproduced on the secondary, confirming that replication is working.
