Sa zicem ca avem o baza de date mysql care vrem sa fie slave. Pasii pe care i-am facut ar fi cam acestia (plus trial and error)
Avem nevoie de structura bazei de date cu tabele si date in ele. Se poate obtine cu mysqldump. mysqldump -h db_ip -u ednadb -p --no-data my_db > my_db_no_data.sql
sau direct cu date cu tot.
Trebuie verificat in my.cnf sa fie urmatoarele directive
server-id=3
#gtid-mode = ON
#enforce-gtid-consistency = ON
replicate-wild-do-table=my_db.% #vreau doar my_db sa fie replicata
slave-skip-errors = 1062,1032 --aici puteti sa mai adaugati erori care pot sa apara cand dati show slave status
si apoi restart.
Pe baza de date master rulam show master status si notam File si Position
mysql-bin.000004 - fisierul din care se citeste
901802477 - pozitia
Pe serverul slave executam
CHANGE MASTER TO
MASTER_HOST='master_ip',
MASTER_USER='user',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000004', -- fisierul
MASTER_LOG_POS=901802477; -- pozitia
start slave;\G
show slave status;\G
Verificam daca este totul bine.
Erori care pot sa apara
nu gaseste inregistrarea respectiva
nu gaseste tabelul
In caz ca master-ul foloseste gtid la tranzactii, acesta trebuie sa fie on si pe slave, iar la mysqldump o sa spuna el ce flag este nevoie.
Ca nota:
Am facut cu ajutorul Google si incercare si eroare, deci nu-i ceva perfect sau de productie, dar pentur servere de demo, test, personal should suffice
Postarea este wiki, deci daca gasiti erori de orice fel, va invit sa le corectati.
Astept lectia “am invatat sa repar o baza de date replicata, dupa ce a picat masterul”. E din ciclul “platforma e oprita o zi ca sa se termine repararea/indexarea”.
Ceva de genul a fost si in situatia mea, doar ca picase slave-ul, nu master-ul, si mai exact, devenise outdated. Probabil din ceva motive de networking.
Motivul pentru care asta a fost posibil, a fost din cauza ca replication-ul a fost setat doar pe un primul nivel - streaming replication, care merge doar prin TCP, si care, daca se depaseste un anumit delay, destul de mic (dar configurabil) iese din sync.
Solutia a fost setarea/activarea a unui al doilea nivel de replication, cel de (wal archiving) log shipping, care presupunea copierea wal file-urile prin SSH, catre slave.
Doar in momentul in care slave-ul la face restore la acele fisiere, doar atunci vor fi sterse de pe master.
Prin urmare, cu aceasta solutie, esti sigur ca nu pierzi, definitiv, sync-ul dintre master si slave. Chiar si daca slave-ul e down o saptamana, in momentul in care-l pornesti, va face restore la log-urile primite, pana ajunge in sync, iar in momentul ala va face switch in mod automat la streaming replication, care e mult mai realtime.
E rau si daca se strica masterul, si daca se strica replica. Ca sa refaci replica tre sa opresti masterul cat faci dump, or daca db-ul e mare (cum sunt de obicei DB-urile care necesita replicare) lucrul asta dureaza. si nu se poate face fara downtime.
Daca folosesti pg_basebackup in loc de pg_dump, nu e nevoie sa opresti db-ul. Postgres stie sa faca un checkpoint in momentul in care a inceput backup-ul si iti salveaza acele wal-uri, pana se termina backup-ul. Iar in momentul in care faci restore la acest backup, pornesti db-ul in recovery_mode si iti replica, in mod automat, acele wal-uri, lipsa.
Prin urmare, poti face si fara downtime.
Daca ai un sistem de failover, ceea ce nu ar trebui sa lipseasca, atunci si daca se strica master-ul, automat el va deveni slave, prin urmare, poti face operatiuni pe el, in mod safe.
MySQL-ul, din moment ce poate fi un cluster, ar presupune ca are horizontal scaling. Ce vrei tu sa zici ca nu e Multi-Master / Master-Master ci e doar Master-Slave. Aia da. Asa e si PostgreSQL-ul.
Daca ai nevoie de asa ceva, atunci ar trebui sa te indrepti spre AWS Aurora, sau chiar CockrouchDB, daca vrei sa ai si optiune de self-hosted.
A trebuit să fac un sistem redundant. Pt o aplicație django. Cu postgres.
Faza e că django ORM se bazează pe ID-urile de primary key din DB.
Am descoperit că master/master replication, sau promovarea slave-ului ca master este cam complicată. De asemenea soluțiile postgresql de replicare postgres nu sunt free
Am mers pe un drbd cluster cu două noduri. Care practic face filesystem replication la directorul postgresql. Mergea drăguț, mai puțin în rețeaua clientului care avea laag. Iar pt DRBD async trebuia licență.
Până la urmă am făcut tuning la rețea și am mărit toleranța la DRBD la ping-ul intre noduri.
A trecut testele dar nu sunt chiar mulțumit.
Le-am spus că fără monitorizare continua a cluster-ului este posibil să se desincronizeze.
Cloud-ul nu era o opțiune pt ei și nici buget pt licențe pro nu aveau.
Ce vreau să zic e că am avut câteva săptămâni cam agitate
Aș fi curios dacă a avut cineva “battle-tested” database recovery & failover. Și experiențe de împărtășit.
Adaug aici ca poate e folositoare informatia. Am folosit https://proxysql.com/ pentru un client cu trafic foarte mare si am redus drastic loadul pe db.
Am cautat cele mai frecvent utilizate queries si le-am pus in proxysql care le pune in cache si nu mai are treaba cu db.
Stiu ca nu e acelasi lucru ca un slave db dar ajuta.
