MySQL replication master-slave — konfiguracja krok po kroku

Opublikowano: 9 kwietnia 2026 · Kategoria: Bazy danych

Twoja baza MySQL jest pojedynczym punktem awarii? Jeden pad serwera i cała aplikacja offline? Replication to pierwszy krok do High Availability. Master obsługuje zapisy, repliki automatycznie otrzymują wszystkie zmiany i mogą obsługiwać zapytania SELECT — odciążając master i zapewniając backup "na żywo".

Jak działa replication

MySQL replication opiera się na binary log — pliku zawierającym wszystkie zmiany danych (INSERT, UPDATE, DELETE, ALTER). Przepływ:

• Master zapisuje każdą zmianę do mysql-bin.000001 (binary log)
• Replika uruchamia dwa wątki: I/O thread pobiera binary log z mastera i zapisuje do lokalnego relay-bin
• SQL thread czyta relay log i wykonuje zapytania na lokalnej bazie repliki
• Dane na replice są identyczne jak na master (z małym opóźnieniem 0-2s)

Krok 1 — Konfiguracja mastera

Edytuj /etc/mysql/mysql.conf.d/mysqld.cnf na serwerze master:

[mysqld]
# Unikalny ID (musi być różny na master i każdej replice)
server-id = 1

# Włącz binary log
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW

# Retencja logów (7 dni)
binlog_expire_logs_seconds = 604800

# Opcjonalnie: tylko wybrane bazy do replikacji
# binlog_do_db = moja_baza

# Bind na LAN IP (nie localhost) — replika musi się połączyć
bind-address = 10.0.0.1

sudo systemctl restart mysql

# Utwórz użytkownika dla replikacji
mysql -u root -p

-- Na serwerze MASTER
CREATE USER 'replica_user'@'10.0.0.2' IDENTIFIED WITH mysql_native_password BY 'SilneHaslo2026!';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'10.0.0.2';
FLUSH PRIVILEGES;

-- Zablokuj tabele i zapisz pozycję binary log
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

-- Zanotuj File i Position, np.:
-- File: mysql-bin.000003 | Position: 157

Krok 2 — Dump danych

W drugim terminalu (master nadal zablokowany) zrób dump całej bazy i przenieś na replikę:

# Na master
mysqldump -u root -p --all-databases --master-data=2 --single-transaction > dump.sql

# Prześlij na replikę
scp dump.sql [email protected]:/tmp/

# Wróć do MySQL na master i odblokuj
mysql -u root -p -e "UNLOCK TABLES;"

Krok 3 — Konfiguracja repliki

Na serwerze repliki edytuj /etc/mysql/mysql.conf.d/mysqld.cnf:

[mysqld]
# Inny server-id niż master
server-id = 2

# Relay log
relay_log = /var/log/mysql/mysql-relay-bin.log

# Tylko do odczytu — nikt nie zapisuje na replice ręcznie
read_only = ON
super_read_only = ON

# Opcjonalnie: włącz binary log żeby robić kaskadową replikację
log_bin = /var/log/mysql/mysql-bin.log

# Restart i import dumpu
sudo systemctl restart mysql
mysql -u root -p < /tmp/dump.sql

# Ustaw źródło replikacji
mysql -u root -p

-- Na REPLICE (MySQL 8.0+)
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.0.0.1',
  SOURCE_USER='replica_user',
  SOURCE_PASSWORD='SilneHaslo2026!',
  SOURCE_LOG_FILE='mysql-bin.000003',
  SOURCE_LOG_POS=157;

START REPLICA;
SHOW REPLICA STATUS\G

Monitoring replikacji

Kluczowe pola w SHOW REPLICA STATUS:

Typowe problemy

• Duplicate entry błąd — ktoś zapisał na replice (brak read_only). Rozwiązanie: STOP REPLICA; SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START REPLICA; lub reseed.
• Replika za daleko w tyle — zbyt słaby sprzęt. Rozwiązanie: więcej RAM/CPU lub włącz parallel replication: replica_parallel_workers = 4.
• Binary log się przepełnił — retencja za długa, dysk pełny. Skróć binlog_expire_logs_seconds lub ręcznie: PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;
• Replika po restarcie nie startuje automatycznie — dodaj skip_replica_start = OFF w my.cnf.

Uwaga: Dla produkcji rozważ semi-synchronous replication (plugin rpl_semi_sync_source) lub MySQL Group Replication (MySQL 8.0+) dla prawdziwego HA z automatycznym failover.

Najczęstsze pytania