Introduction

A MySQL replication lab should be cheap to recreate and realistic enough to expose operational problems before production does. You do not need a huge cluster to test replication behavior well. A small source-and-replica environment is usually enough to validate configuration, observe lag, and rehearse failure handling.

Build a Small Topology You Can Reset Quickly

For development work, one source and one replica container is a good default. The important part is not scale. It is reproducibility. Each server needs a unique server-id, and the source must have binary logging enabled so there is actually something to replicate.

1version: "3.9"
2services:
3  mysql-source:
4    image: mysql:8.0
5    ports:
6      - "3307:3306"
7    environment:
8      MYSQL_ROOT_PASSWORD: rootpw
9    command:
10      - --server-id=1
11      - --log-bin=mysql-bin
12      - --binlog-format=ROW
13
14  mysql-replica:
15    image: mysql:8.0
16    ports:
17      - "3308:3306"
18    environment:
19      MYSQL_ROOT_PASSWORD: rootpw
20    command:
21      - --server-id=2
22      - --relay-log=relay-bin
23      - --read-only=ON

Using stable port numbers and container names makes every later script easier to reuse. It also makes reset workflows predictable.

Configure Replication With a Dedicated Account

Do not test replication with the root account just because it is a lab. Replication is easier to reason about when it uses the same least-privilege pattern you would expect in a real environment.

CREATE USER 'repl'@'%' IDENTIFIED BY 'replpw';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

Then configure the replica to follow the source:

1CHANGE REPLICATION SOURCE TO
2  SOURCE_HOST='mysql-source',
3  SOURCE_PORT=3306,
4  SOURCE_USER='repl',
5  SOURCE_PASSWORD='replpw';
6
7START REPLICA;
8SHOW REPLICA STATUS\G

After that, verify both replication threads are healthy and check that lag remains near zero during normal testing.

Seed Data and Verify Real Workloads

A replication setup is not validated just because it starts. You need deterministic test data that exercises inserts, updates, and deletes. Keep those statements in version control so every developer runs the same workload.

1CREATE DATABASE IF NOT EXISTS lab;
2USE lab;
3
4CREATE TABLE orders (
5  id INT PRIMARY KEY,
6  status VARCHAR(20),
7  amount DECIMAL(10,2)
8);
9
10INSERT INTO orders VALUES (1, 'new', 25.00), (2, 'new', 50.00);
11UPDATE orders SET status = 'paid' WHERE id = 1;
12DELETE FROM orders WHERE id = 2;

Then query the replica and confirm that the table state matches. If it does not, inspect replication status before changing configuration blindly. Many replication bugs are really setup mistakes that status output would have revealed immediately.

Test Lag and Failure on Purpose

A good lab should also support negative testing. Stop the source, restart it, and confirm the replica reconnects. Add a burst of writes and watch how lag behaves. If schema changes are part of your normal workflow, run them through the replication lab too so you can see whether they increase apply time or block the replica unexpectedly.

Useful status commands make this easier:

mysql -h 127.0.0.1 -P 3307 -uroot -prootpw -e "SHOW MASTER STATUS;"
mysql -h 127.0.0.1 -P 3308 -uroot -prootpw -e "SHOW REPLICA STATUS\\G"

These checks belong in the development routine, not just in outage response. If replication is part of production operations, the test environment should exercise those operational instincts regularly.

Add a Reset Workflow

Replication labs become unreliable when they accumulate old state. Keep a reset path that destroys both containers, recreates them, reapplies the configuration, and reseeds the test data. That way, each engineer can start from the same baseline before testing a migration or a runbook change.

Snapshot imports can speed up larger labs, but do not let shortcuts hide the important configuration steps. The point is to learn whether replication will behave correctly, not merely to avoid setup time.

Common Pitfalls

The most common mistakes are duplicate server-id values, missing binary log settings on the source, and using root for replication because it is convenient. Teams also often test only inserts, ignore lag behavior, or skip reset automation and end up debugging stale state instead of real replication issues.

Summary

• Keep the topology small and easy to rebuild.
• Give each server a unique identity and enable binary logging on the source.
• Use a dedicated replication account even in development.
• Seed repeatable data and test more than simple inserts.
• Practice lag, restart, and reset scenarios as part of normal verification.