dexblog.ro
Acces rapid: Învață AI Învață Programare Specificații Dispozitive Comparații
SQL Toate comenzile MySQL

Arhitecturi de Replicare și High Availability: GTID, Semisincron și InnoDB Cluster în MySQL

Informații despre server și sesiune MySQL 8.0+

Ghid complet pentru disponibilitate înaltă în MySQL: replicare bazată pe GTID, replicare semisincronă lossless împotriva pierderii de date și arhitectura MySQL InnoDB Cluster cu MySQL Router.

Sintaxă 
CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION = 1; START REPLICA;

Pentru a asigura funcționarea neîntreruptă a unei aplicații (99.99% uptime) și scalarea citirilor pe zeci de mii de utilizatori concurenți, un singur server MySQL nu este suficient. Replicarea permite distribuirea datelor de pe un nod principal (Source / Primary) către unul sau mai multe noduri secundare (Replicas / Secondaries). Acest ghid acoperă arhitecturile moderne de replicare recomandate în MySQL 8.0 și 8.4 LTS.

Cum funcționează replicarea clasică MySQL
-- Fluxul datelor în replicare:
-- 1. Serverul Sursă comite o tranzacție și o scrie în 'Binary Log' (binlog).
-- 2. Conexiunea 'Replica I/O Thread' citește evenimentele din binlog-ul sursei și le scrie pe nodul Replica în 'Relay Log'.
-- 3. Firul 'Replica SQL Thread' (sau worker threads paralele) citește din Relay Log și execută tranzacțiile pe nodul Replica.

-- Comanda de monitorizare în timp real:
SHOW REPLICA STATUS\G  -- Sau 'SHOW SLAVE STATUS\G' în versiuni mai vechi

Replicarea Tradițională vs. GTID (Global Transaction Identifiers)

În trecut, replicarea se baza pe indicarea manuală a numelui fișierului de log și a offset-ului octetului (ex: MASTER_LOG_FILE='binlog.00010', MASTER_LOG_POS=450). În caz de cădere a nodului primar, promovarea unei replici necesita calcule matematice complexe pentru a găsi punctul de sincronizare comun.

GTID asociază fiecărei tranzacții un identificator unic global de forma UUID:SequenceNumber (ex: 3E11FA47-71CA-11E1-9E33-C80AA9429562:23). Când o replică se conectează la sursă, ele își negociază automat tranzacțiile lipsă folosind SOURCE_AUTO_POSITION = 1!

Configurarea unei replici cu GTID în MySQL 8
-- Pe serverul Replica:
CHANGE REPLICATION SOURCE TO
    SOURCE_HOST = '192.168.1.50',
    SOURCE_USER = 'repl_user',
    SOURCE_PASSWORD = 'ParolaSiguraReplica2026!',
    SOURCE_AUTO_POSITION = 1,      -- Magia GTID: sincronizare automată fără offset!
    SOURCE_SSL = 1;

-- Pornim procesele de replicare:
START REPLICA;

-- Verificăm starea de sănătate:
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
-- Seconds_Behind_Source: 0  (Replicarea este la zi!)

Moduri de Replicare: Asincronă vs. Semisincronă

Tip Replicare Mecanism de Acknowledgment Performanță Risc Pierdere Date
Asincronă
(Default)		 Sursa scrie tranzacția în binlog, o comite pe disc și răspunde clientului fără a aștepta confirmare de la replici. Maximă (zero latență adăugată tranzacțiilor). Dacă sursa cade brusc, tranzacțiile aflate în tranzit care nu au ajuns la replici sunt pierdute.
Semisincronă (Lossless)
(After-Sync)		 Sursa scrie în binlog, trimite evenimentul la replică și așteaptă confirmarea că cel puțin o replică a scris evenimentul în Relay Log înainte de a returna COMMIT către client. Ușor scăzută (cost de latență de rețea RTT între noduri). Zero pierderi de date (RPO=0) la căderea nodului sursă.

Standardul Modern: MySQL InnoDB Cluster

Pentru o infrastructură cu adevărat tolerantă la defecte și capabilă de failover automat în sub 5 secunde fără intervenție umană, Oracle recomandă stiva MySQL InnoDB Cluster, compusă din trei componente complementare:

  1. MySQL Group Replication: Oferă replicare sincronă multi-master sau single-master bazată pe algoritmul de consens Paxos. Tranzacțiile sunt validate și comise printr-un cvorum majoritar de noduri (minim 3 servere).
  2. MySQL Shell: Utilitar administrativ care permite crearea, configurarea și adăugarea de noduri în cluster prin comenzi declarative simple în Python sau JavaScript (ex: dba.createCluster('prodCluster')).
  3. MySQL Router: Un proxy de rețea inteligent și ultra-ușor instalat direct pe mașinile serverelor web de aplicație. El rutează automat interogările de scriere (port 6446) către nodul Primary și interogările de citire (port 6447) pe nodurile Secondary în regim round-robin. Dacă nodul Primary suferă un crash, Router-ul redirecționează instant traficul către noul lider ales de consens.

Monitorizarea și Depanarea Replicării

Indicatori esențiali din ieșirea comenzii SHOW REPLICA STATUS\G:

  • Replica_IO_Running: Yes → Indică conectarea cu succes la nodul sursă și recepționarea stream-ului de date. Dacă este No sau Connecting, verificați firewall-ul, utilizatorul de replicare sau certificatul SSL.
  • Replica_SQL_Running: Yes → Indică faptul că tranzacțiile primite sunt executate pe baza locală. Dacă devine No, a apărut o coliziune (ex: cheie duplicată creată manual pe replică).
  • Seconds_Behind_Source → Latența de replicare. Dacă această valoare crește continuu, activați replicarea paralelă multi-threaded pe replică prin replica_parallel_workers = 8 și replica_parallel_type = LOGICAL_CLOCK.