Wdrożenie Master/Slave i nadzór replikacji w PmaControl

Replikacja w 2026: wciąż fundament

Replikacja master/slave pozostaje fundamentalnym elementem każdej infrastruktury MariaDB / MySQL na produkcji. Wysoka dostępność, rozproszone odczyty, gorące kopie zapasowe — wszystko na niej opiera. A mimo to większość poważnych incydentów bazodanowych dotyczy uszkodzonej replikacji lub niewykrytego opóźnienia.

Ten artykuł obejmuje dwa aspekty replikacji: jak ją prawidłowo skonfigurować, a następnie jak nadzorować ją w PmaControl, by nigdy nie być zaskoczonym.

Konfiguracja replikacji

Wymagania po stronie mastera

Master musi mieć włączony binlog i unikatowy server-id:

[mysqld]
server-id = 1
log-bin = /var/log/mysql/mysql-bin
binlog-format = ROW
gtid_strict_mode = ON          # MariaDB
# enforce_gtid_consistency = ON  # MySQL
# gtid_mode = ON                 # MySQL

Tworzenie użytkownika replikacji:

CREATE USER 'repl'@'10.0.1.%' IDENTIFIED BY 'secret_replication_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.1.%';

Wymagania po stronie slave'a

Slave potrzebuje własnego server-id i relay logu:

[mysqld]
server-id = 2
relay-log = /var/log/mysql/relay-bin
read-only = ON
log-slave-updates = ON

log-slave-updates jest niezbędny, jeśli planujesz łańcuchowanie slave'ów (slave ze slave'a) lub używanie Galera.

Uruchomienie replikacji

Z GTID (zalecane)

Na MariaDB:

CHANGE MASTER TO
  MASTER_HOST = '10.0.1.1',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'secret_replication_password',
  MASTER_USE_GTID = slave_pos;

START SLAVE;

Na MySQL 8.0+:

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.1.1',
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'secret_replication_password',
  SOURCE_AUTO_POSITION = 1;

START REPLICA;

Bez GTID (tryb klasyczny)

Jeśli GTID nie jest włączone, trzeba zanotować pozycję binlogu mastera:

-- Na masterze
SHOW MASTER STATUS;
-- File: mysql-bin.000042, Position: 154

-- Na slave'ie
CHANGE MASTER TO
  MASTER_HOST = '10.0.1.1',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'secret_replication_password',
  MASTER_LOG_FILE = 'mysql-bin.000042',
  MASTER_LOG_POS = 154;

START SLAVE;

Weryfikacja działania

SHOW SLAVE STATUS\G

Dwa kluczowe wskaźniki:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

Jeśli Slave_IO_Running to No, slave nie może połączyć się z masterem (sieć, dane uwierzytelniające, firewall). Jeśli Slave_SQL_Running to No, slave nie może zastosować zdarzeń (błąd SQL, naruszone ograniczenie).

Dodawanie serwerów do PmaControl

Przez interfejs webowy

1. Przejdź do Serwery → Dodaj serwer
2. Wypełnij IP, port (3306), dane uwierzytelniające SSH i MySQL
3. PmaControl automatycznie wykrywa rolę (master lub slave) po pierwszym cyklu zbierania

Przez REST API

# Dodanie mastera
curl -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ip": "10.0.1.1", "port": 3306, "name": "db-prod-master", "ssh_key_id": 1}' \
  https://pmacontrol.example.com/api/v1/servers

# Dodanie slave'a
curl -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ip": "10.0.1.2", "port": 3306, "name": "db-prod-slave-01", "ssh_key_id": 1}' \
  https://pmacontrol.example.com/api/v1/servers

PmaControl uruchamia cykl zbierania w ciągu minuty. Slave pojawia się wtedy z plakietką "Slave" w dashboardzie.

Strona Slave w PmaControl

Nadzór replikacji jest dostępny przez route:

/{lang}/slave/show/{id}/{name}/

Na przykład: /fr/slave/show/42/db-prod-slave-01/

Kontroler Slave.php udostępnia dwie główne akcje:

• show(): strona główna z bieżącym stanem i wykresem opóźnień
• showGraphDay(): dane AJAX do załadowania dodatkowego dnia wykresu

Monitorowane zmienne

PmaControl zbiera wszystkie zmienne z SHOW SLAVE STATUS i przechowuje je w tabelach szeregów czasowych. Najkrytyczniejsze:

Dla MySQL 8.0+ PmaControl zarządza też przemianowanymi odpowiednikami:

PmaControl automatycznie normalizuje obie nazwy wewnętrznie.

Wykres opóźnień

Wykres opóźnień to serce strony slave. Wyświetla ostatnie 5 dni Seconds_Behind_Master jako krzywą Chart.js.

Cechy:

• Rozdzielczość: jeden punkt na minutę (1440 punktów dziennie)
• Stopniowe ładowanie: bieżący dzień ładowany natychmiast, poprzednie dni przez AJAX "Load previous day"
• Automatyczna skala: oś Y dostosowuje się do maksymalnego zaobserwowanego opóźnienia
• Strefa zielona: < 10 sekund, normalne działanie
• Strefa bursztynowa: 10-60 sekund, umiarkowane opóźnienie
• Strefa czerwona: > 60 sekund, krytyczne opóźnienie

Pasek zdrowia (Health Strip)

Nad wykresem poziomy pasek podsumowuje stan każdej minuty w ciągu 24h kodem kolorystycznym:

To natychmiastowy wskaźnik wizualny: jedno spojrzenie wystarczy, by zobaczyć, czy ostatnia doba była stabilna, czy chaotyczna.

Akcje korekcyjne z PmaControl

Strona slave nie ogranicza się do obserwacji. PmaControl pozwala działać bezpośrednio na replikacji.

START / STOP SLAVE

Dwa przyciski do uruchamiania lub zatrzymywania replikacji. STOP SLAVE jest przydatny do:

• Przeprowadzenia konserwacji na slave'ie (ciężki ALTER TABLE)
• Wykonania spójnej kopii zapasowej (snapshot z zatrzymaną replikacją)
• Diagnozy problemu opóźnień (zatrzymanie, by zbadać binlog)

SKIP error

Gdy replikacja zatrzymuje się na błędzie SQL (zduplikowane ograniczenie, brakująca tabela), PmaControl proponuje pominięcie zdarzenia:

SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

Uwaga: ta akcja wymaga wyraźnego potwierdzenia. Pominięcie zdarzenia oznacza zaakceptowanie rozbieżności między masterem a slave'em. PmaControl loguje akcję z użytkownikiem, datą i pominiętym błędem dla śledzenia.

Parallel workers (replikacja równoległa)

PmaControl oferuje suwak do regulacji liczby workerów replikacji równoległej:

• Minimum: 1 (klasyczna replikacja sekwencyjna)
• Maksimum: 50 lub CPU × 2 (mniejsza z dwóch wartości)

STOP SLAVE;
SET GLOBAL slave_parallel_workers = 8;
START SLAVE;

Zwiększenie workerów pozwala szybciej nadrobić opóźnienie, ponieważ wiele transakcji jest stosowanych równolegle. Ale uwaga: działa to dobrze tylko z replikacją równoległą LOGICAL_CLOCK (MariaDB) lub WRITESET (MySQL 8.0+).

Algorytm ETA nadrabiania

Gdy slave ma opóźnienie, natychmiastowe pytanie brzmi: ile czasu do nadrobienia?

PmaControl oblicza szacunek (ETA) na podstawie:

1. Bieżącego opóźnienia w sekundach
2. Zaobserwowanej prędkości nadrabiania (zmiana opóźnienia w ostatnich 10 minutach)
3. Ekstrapolacji liniowej

Jeśli opóźnienie spada z 3600s do 3000s w 10 minut:
  Prędkość = 600s nadrobione / 10min = 60s/min
  ETA = 3000s / 60s/min = 50 minut

ETA jest wyświetlane na górze strony slave z paskiem postępu. Jeśli prędkość nadrabiania jest zerowa lub ujemna (opóźnienie rośnie), PmaControl wyświetla "ETA: divergent" na czerwono — znak, że trzeba interweniować.

Obsługa GTID

PmaControl automatycznie wykrywa tryb GTID:

• MariaDB: odczyt Using_Gtid w SHOW SLAVE STATUS. Możliwe wartości: No, Slave_Pos, Current_Pos
• MySQL: odczyt Auto_Position w SHOW SLAVE STATUS. Możliwe wartości: 0, 1

Gdy GTID jest aktywny, PmaControl wyświetla dodatkowe informacje:

• Zbiór GTID mastera (Gtid_Slave_Pos lub Executed_Gtid_Set)
• Zbiór GTID slave'a
• Delta między nimi (liczba transakcji do nadrobienia)

Delta GTID jest często bardziej wymowna niż Seconds_Behind_Master: podaje dokładną liczbę transakcji do nadrobienia, niezależnie od czasu trwania każdej transakcji.

Dobre praktyki

1. Zawsze używaj GTID

Tryb pozycji binlogu (plik + pozycja) jest kruchy: zbyt wcześnie usunięty plik, failover, i replikacja jest uszkodzona. GTID jest idempotentne i przeżywa failovery.

2. Włącz read_only na slave'ach

SET GLOBAL read_only = ON;
SET GLOBAL super_read_only = ON;  -- MySQL 5.7.8+ / MariaDB 10.3.16+

Bez read_only przypadkowy zapis na slave'ie powoduje cichą rozbieżność.

3. Monitoruj opóźnienie, nie tylko stan

Slave_IO_Running: Yes i Slave_SQL_Running: Yes to za mało. Slave może "działać" z 2 godzinami opóźnienia. PmaControl monitoruje jedno i drugie: stan I opóźnienie.

4. Skonfiguruj alerty

W PmaControl skonfiguruj progi alertów:

• Warning: opóźnienie > 60 sekund przez 5 minut
• Critical: opóźnienie > 300 sekund LUB IO/SQL zatrzymane

Alerty są wysyłane przez Telegram z nazwą serwera, bieżącym opóźnieniem i bezpośrednim linkiem do strony slave.

5. Planuj duże operacje

ALTER TABLE na wolumenowych tabelach generuje tymczasowy pik opóźnień. Używaj pt-online-schema-change lub gh-ost dla DDL na produkcji i poinformuj PmaControl, umieszczając slave w trybie konserwacji, by uniknąć fałszywych alarmów.

Podsumowanie

Replikacja MariaDB / MySQL jest prosta do konfiguracji, ale trudna do utrzymania w dłuższym czasie. PmaControl wypełnia lukę między "replikacja działa" a "replikacja jest zdrowa", dostarczając:

• Widok w czasie rzeczywistym opóźnień z historią 5 dni
• Zintegrowane akcje korekcyjne (start/stop, skip, parallel workers)
• Szacunek nadrabiania (ETA) do antycypacji
• Automatyczną detekcję GTID
• Proaktywne alerty przez Telegram

Celem nie jest zastąpienie DBA — to danie mu narzędzi do reagowania w minuty zamiast godzin.