Replicare- o tehnică utilizată în arhitectura sistemelor care funcționează sub sarcină, al cărei rezultat este distribuția încărcării atunci când se lucrează cu o bază de date pe mai multe servere. Replicarea MySQL MASTER SLAVE este folosită mai des, dar este folosit și un al doilea tip de replicare - Master-Master.

Ce este replicarea MySQL MASTER SLAVE și pentru ce este folosită?

Replicare Stăpân-Sclav implică duplicarea datelor pe un server MySQL slave. Dacă serverul Master eșuează, funcțiile sale sunt comutate la Slave.

Replicarea poate fi efectuată și pentru a îmbunătăți performanța sistemului, dar performanța este aproape întotdeauna secundară aici.
Când o aplicație funcționează cu o bază de date, cele mai frecvente operațiuni sunt SELECTAȚI- solicitări de citire a datelor, de modificare a datelor - solicitări ȘTERGE, INTRODUCE, ACTUALIZAȚI, MODIFICA Statistic, se întâmplă mult mai rar.

Pentru a preveni pierderea datelor dacă unul dintre servere eșuează, operațiunile de modificare a informațiilor din tabele sunt întotdeauna procesate de serverul Master. Schimbările sunt apoi replicate la Slave. Citirea se poate face de pe un server care joacă rolul de Slave.
Datorită acestui fapt, puteți obține un câștig în performanță împreună cu fiabilitate.

Soluția este populară, dar nu întotdeauna aplicabilă, deoarece pot exista întârzieri în timpul replicării - dacă se întâmplă acest lucru, informațiile trebuie citite și de pe serverul Master.

Dirijarea cererilor de un anumit tip către un anumit server de bază de date este în orice caz implementată la nivel de aplicație.

Dacă separați interogările SELECT și toate celelalte la nivel de program trimițându-le către serverul necesar Dacă unul dintre ele eșuează, aplicația pe care o deservește infrastructura va fi inoperabilă. Pentru ca acest lucru să funcționeze, trebuie să oferi mai mult schema complexași rezervați fiecare dintre servere.

Replicarea este pentru toleranța la erori, nu pentru scalare.

Replicare MySQL MASTER SLAVE - configurare pe Debian

Vom folosi două servere cu adrese:

Server principal 192.168.0.1
Server slave 192.168.0.2

Pentru demonstrație, sunt utilizate VDS conectate la o rețea locală.
Pentru a ști întotdeauna cu siguranță pe ce server executăm această sau acea comandă, vom edita fișierele /etc/hosts de pe ambele servere

192.168.0.1 master

192.168.0.2 sclav

Să înlocuim valorile existente în /etc/hostname cu master și respectiv slave, astfel încât modificările să aibă efect și să repornească serverul.

1. Facem setări pe serverul principal.

root@master:/#

Editarea celui principal Fișier de configurare server de baze de date

mcedit /etc/mysql/my.cnf

Selectați ID-ul serverului - puteți specifica orice număr, implicit este 1 - doar decomentați linia

server-id = 1

Setați calea către jurnalul binar - specificat și implicit, decomentați-o

Setați numele bazei de date pe care o vom replica pe un alt server

binlog_do_db = db1

Reporniți Mysql astfel încât fișierul de configurare să fie recitit și modificările să aibă efect:

/etc/init.d/mysql reporniți

2. Setați drepturile necesare utilizatorului

Accesați consola serverului de baze de date:

Oferim utilizatorului de pe serverul slave drepturile necesare:

Acordați slave de replicare pe *.* „slave_user”@”%” IDENTIFICAT DE „123”;

Blocarea tuturor tabelelor din baza de date

MASELE CU BLOCARE DE CITIRE;

Verificarea stării serverului Master:

3. Creați un dump de bază de date pe server

Creați un dump de bază de date:

mysqldump -u root -p db1 > db1.sql

Deblocați tabele în consola mysql:

4. Transferați descărcarea bazei de date pe serverul Slave

scp db1.sql [email protected]:/Acasă

Efectuăm acțiuni suplimentare pe serverul Slave

root@slave:/#

5. Crearea unei baze de date

Încărcarea gunoiului:

mysql -u root -p db1< db1.sql

6. Efectuați modificări la my.cnf

mcedit /etc/mysql/my.cnf

Atribuim un ID prin creșterea valorii setate pe serverul Master

server-id = 2

Setați calea către jurnalul de releu

relay-log = /var/log/mysql/mysql-relay-bin.log

și calea către jurnalul bin pe serverul Master

log_bin = /var/log/mysql/mysql-bin.log

Specificați baza

binlog_do_db = db1

Repornirea serviciului

/etc/init.d/mysql reporniți

7. Configurați o conexiune la serverul Master

CHANGE MASTER TO MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;

Începem replicarea pe serverul slave:

Puteți verifica funcționarea replicării pe Slave cu următoarea solicitare:

************************** 1. rând ******************** * *****
Slave_IO_State: Se așteaptă ca master să trimită evenimentul
Master_Host: 192.168.0.1
Master_User: utilizator_slave
Master_Port: 3306
Conectare_Reîncercați: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Da
Slave_SQL_Running: Da
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Ultima_eroare: 0
Ultima_eroare:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 555
Until_Condition: Niciunul
Până la_Log_File:
Până la_Log_Pos: 0
Master_SSL_Allowed: Nu
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Secunde_În spatele_Maestrului: 0
Master_SSL_Verify_Server_Cert: Nu
Ultima_IO_Errno: 0
Ultima_IO_Eroare:
Last_SQL_Errno: 0
Ultima_eroare_SQL:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 rând în set (0,00 sec)

Deoarece nu au apărut erori, putem concluziona că replicarea este configurată corect.

Este un instrument bun scalare, dar principalul dezavantaj este desincronizarea copierii datelor și întârzierile, care pot fi critice.

Utilizarea unei soluții mai moderne vă permite să le evitați complet. Este ușor de configurat, fiabil și elimină nevoia de a copia manual depozitele bazei de date.

Iată o scurtă descriere a modului de a configura replicarea completă a serverului dvs. MySQL. Se presupune că toate bazele de date vor fi replicate și replicarea nu a fost configurată anterior. Pentru a finaliza pașii de aici, va trebui să opriți serverul principal pentru o perioadă scurtă de timp.

Acesta este cel mai simplu mod de a instala un server slave, dar nu este singurul mod. De exemplu, dacă există deja o imagine a serverului master, serverul master are deja un ID de server setat și înregistrare, serverul slave poate fi instalat fără a opri serverul master sau chiar a seta blocări de actualizare (pentru mai multe informații, consultați secțiunea 4.10). .7 Întrebări frecvente privind replicarea frecventă.

Pentru a deveni un adevărat guru al replicării MySQL, vă recomandăm să învățați, să înțelegeți și să încercați mai întâi toate comenzile menționate în secțiunea 4.10.6 Comenzi SQL legate de replicare. De asemenea, ar trebui să revizuiți opțiunile de pornire a replicării din fișierul `my.cnf' în Vezi secțiunea 4.10.5 Opțiuni de replicare din fișierul `my.cnf'.

Asigurați-vă că cea mai recentă versiune de MySQL este instalată pe serverele master și slave. Utilizați versiunea 3.23.29 sau o versiune ulterioară. Versiunile anterioare au folosit un alt format de jurnal binar și conțineau erori care au fost remediate în versiunile mai noi. O cerere mare: vă rugăm să nu trimiteți rapoarte de eroare fără a verifica dacă eroarea este prezentă în ultima versiune.
Configurați un utilizator de replicare separat pe serverul principal cu privilegiul FILE (în versiunile MySQL anterioare 4.0.2) sau REPLICATION SLAVE în versiunile MySQL mai noi. Acest utilizator trebuie să aibă, de asemenea, permisiunea de a se conecta de la toate serverele slave. Dacă utilizatorul va efectua doar replicare (recomandat), atunci nu trebuie să i se acorde privilegii suplimentare. De exemplu, pentru a crea un utilizator numit repl care poate accesa serverul principal de pe orice gazdă, puteți folosi următoarea comandă: mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY " ";
Închideți MySQL pe serverul principal. mysqladmin -u root -p oprire
Creați o imagine a tuturor datelor de pe serverul principal. Cel mai simplu mod de a face acest lucru (pe Unix) este să creați gudron arhiva întregului director de date. Locația exactă a directorului de date depinde de instalarea dvs. tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir Utilizatorii Windows pot folosi WinZIP sau un alt program similar pentru a crea o arhivă de director de date.
În my.cnf de pe serverul principal, adăugați intrări la secțiunea de intrare log-bin și server-id=număr unic la secțiune și reporniți serverul. Este foarte important ca ID-ul serverului slave să fie diferit de ID-ul serverului master. Putem considera că server-id joacă rolul unei adrese IP - identifică în mod unic serverul printre participanții la replicare. log-bin server-id=1
Reporniți MySQL pe serverul principal.
Adăugați următoarele la my.cnf pe serverul(e) slave: master-host= master-user= master-parola= master-port= server-id= înlocuind valorile cu valorile adecvate pentru sistemul dvs. . Valorile server-id trebuie să fie diferite pe fiecare server care participă la replicare. Dacă valoarea server-id nu este definită, aceasta va fi setată la 1, dacă nu este definită nici valoarea master-host, aceasta va fi setată la 2. Rețineți că dacă valoarea server-id este omisă, atunci serverul master va refuza conexiunile la toate serverele slave, iar serverul slave refuză să se conecteze la serverul principal. Prin urmare, puteți omite setarea valorii server-id numai dacă faceți o copie de rezervă folosind un jurnal binar.
Copiați datele instantanee în directorul de date de pe serverele slave. Asigurați-vă că privilegiile de fișier și director sunt corecte. Utilizatorul care rulează MySQL trebuie să fie capabil să citească și să scrie date în ele în același mod ca pe serverul principal.
Reporniți serverele slave.

După parcurgerea acestor pași, serverul(ele) slave trebuie să se conecteze la serverul principal și să își ajusteze datele la orice modificări care au avut loc pe serverul principal după ce imaginea a fost acceptată.

Dacă serverul -id pentru serverul slave nu este setat, următoarea eroare va fi înregistrată:

Avertisment: ar trebui să setați server_id la o valoare non-0 dacă master_host este setat. Serverul nu va acționa ca un sclav. (Avertisment: dacă este specificat master_host, server_id ar trebui să fie setat la o valoare diferită de zero. Serverul nu va acționa ca un server slave.)

Dacă ID-ul serverului principal nu este setat, serverele slave nu se vor putea conecta la serverul principal.

Dacă un server slave nu se poate replica din orice motiv, mesajele de eroare pot fi găsite în jurnalul de erori de pe serverul slave.

Odată ce serverul slave începe replicarea, un fișier „master.info” va apărea în același director ca și jurnalul de erori. prelucrate. Nu ștergeți sau editați acest fișier decât dacă sunteți sigur că este necesar. Chiar dacă aveți atâta încredere, este totuși mai bine să utilizați comanda CHANGE MASTER TO.

Nu cu mult timp în urmă mi s-a cerut să vorbesc despre replicare în MySQL. Am decis că acest subiect ar putea fi util multora, așa că în acest articol voi vorbi despre ce este replicarea în MySQL, când este necesară și cum se configurează.

Sarcina principală a replicării este combina puterea mai multor servere. Să presupunem că site-ul tău are un server dedicat, dar în timp devine foarte vizitat și nu mai suportă încărcarea. Ca urmare, serverul începe să încetinească și să se blocheze în mod regulat. Cea mai simplă modalitate este să cumpărați un server mai puternic și asta este ceea ce fac majoritatea oamenilor. Dar, mai devreme sau mai târziu, vine un moment în care costul creșterii prețului unui server nu corespunde creșterii performanței acestuia, deci este mai profitabil să cumpărați 2 servere diferite pentru mai puțini bani.

Ca rezultat, baza de date va fi pe două servere simultan. Când un server principal (denumit și serverul principal) nu mai poate face față, acesta trece la unul de rezervă.

Toate Solicitările de actualizare a bazei de date ajung întotdeauna la serverul principal. După actualizarea serverului principal, plasează informații despre acest lucru în dosar separat, de unde serverele slave obțin toate informațiile. Dar operațiunile de eșantionare, care sunt de obicei majoritare și sunt cele mai lente, pot fi deja transferate pe serverele slave, deoarece datele sunt aceleași în ambele.

Acum să ne dăm seama cum se configurează replicarea în MySQL:

Instalați cel mai mult cele mai recente versiuni de MySQL la toate serverele.
Creați un utilizator cu privilegii pe serverul principal ÎNLOCUIRE SLAVE. Pentru adresa de la care se poate conecta, specificați „ Toate".
Opriți toate serverele.
În setări MySQL(în dosar my.cnf) În capitolul adăugați următoarele rânduri: log-bin
server-id=1 Vă rugăm să rețineți că server-id trebuie să fie diferit pe toate serverele. De fapt, acesta este ceea ce distinge un server de altul.
Pe serverele slave, adăugați la setări MySQL următoarele rânduri: master-host=master_host_name
master-user=login al utilizatorului_creat
master-password=parola utilizatorului_creat
master-port=port_pentru_conectarea_la_serverul_master
server-id=id_of_this_slave_server
Mutați toate bazele de la serverul principal la sclavi.
Alerga serverul principal, apoi toți sclavii.

Pentru a utiliza cu succes replicarea în MySQL trebuie să:

Asigurați-vă că versiunea MySQL >= versiunea instalată pe Master este instalată pe serverul care acționează ca Slave. Replicarea este posibilă și în ordine inversă, un Maestru având mai mult versiune noua pe Slave cu unul mai vechi, dar funcționalitatea acestei opțiuni nu este garantată.
Verificați conexiunea de la serverul MySQL Slave la Master (# mysql -hMASTERHOST -uroot -p), deoarece poate fi închisă în firewall.

Replicarea master-slave a unei baze de date MySQL

Acesta este un exemplu simplu replica master-slave a unuia baze de date MySQL . Cei care fac acest lucru pentru prima dată ar trebui să înceapă cu acest exemplu și să urmeze întocmai instrucțiunile.

În primul rând, trebuie să înregistrați ID-uri diferite pentru serverele Master și Slave. Pe serverul Master trebuie să activați jurnalul binar (log-bin), să specificați baza de date pentru replicare și să creați un utilizator de server slave, prin care serverul slave va primi date de la master. Pe server sclav jurnalul de releu este pornit, baza de date pentru replicare este specificată și replicarea slave este pornită.

MASTER: Acțiuni efectuate pe serverul MySQL Master.

Editați my.cnf - fișierul de configurare MySQL. Locația sa depinde de sistem de operareși setările MySQL în sine. În my.cnf, se adaugă următorii parametri la secțiuni:

server-id= 1

# Calea către jurnalul binar.
# Numele fișierului este scris, fără extensie, deoarece extensia va fi instalată oricum
# De către serverul MySQL automat (.000001, .000002, etc.)
# Este recomandabil să localizați mysql-bin în rădăcina directorului în care sunt stocate toate bazele de date,
# pentru a evita problemele de permisiuni.
log- bin =/ var/ lib/ mysql/ mysql- bin

# Numele bazei de date MySQL care va fi replicată

După modificarea my.cnf, ar trebui să reporniți MySQL. Unul sau mai multe fișiere mysql-bin.000001, mysql-bin.000002, ... ar trebui să apară în directorul pentru stocarea jurnalului binar (log-bin).

Acum trebuie să vă conectați la MySQL ca utilizator cu drepturi maxime și să creați un utilizator (rpluser_s500) cu o parolă (înlocuiți PASSW), prin care serverul Slave va primi date despre actualizările bazei de date:

mysql> GRANT replication slave ON * .* TO "rpluser _s500"@"% " IDENTIFICAT DE „PASSW” ;
mysql> PRIVILEGII FLUSH ;

$ mysqldump -- master- data - hHOST - uUSER - p dbreplica > dbreplica.sql

Un dump poate fi preluat dintr-o bază de date sub încărcare, dar trebuie remarcat că, dacă baza de date este mare, atunci în timp ce dump-ul este scris, baza de date nu va putea fi scrisă.

SALVE: Acțiuni efectuate pe serverul MySQL Slave.

În primul rând, trebuie să editați my.cnf în secțiunea:

# ID server principal (un număr de la 1 la 4294967295)
server- id= 500

# Calea către jurnalul de retransmisie, care stochează datele primite de la serverul Master
# Cerințele sunt aceleași ca pentru un jurnal binar.
relay- log =/ var/ lib/ mysql/ mysql- relay- bin
relay- log- index =/ var/ lib/ mysql/ mysql- relay- bin .index

# Numele bazei de date în care vor fi scrise toate modificările,
# apar în baza de date cu același nume pe serverul Master
replica-do-db= „dbreplica”

După modificarea my.cnf, reporniți MySQL.

mysql> CREATE DATABASE dbreplica

Acum trebuie să încărcați un dump în el:

$ mysql - uROOT - p dbreplica< dbreplica.sql

Apoi, stabilim o conexiune la serverul Master, unde MASTER_HOSTNAME_OR_IP este înlocuit cu adresa sau ip-ul serverului master MySQL, iar MASTER_USER și PAROLA sunt acreditările utilizatorului create pe serverul Master pentru a se conecta cu Slave:

mysql> CHANGE MASTER TO MASTER_HOST = "MASTER _HOSTNAME_OR_IP", MASTER_USER = "rpluser _s500", PAROLA = „PAROLA” ;

După rularea acestei solicitări, se creează un fișier master.info în directorul în care este stocată baza de date, unde sunt scrise date despre conexiunea la Master.

Acum, pentru a începe replicarea, tot ce rămâne este să trimiteți o solicitare către MySQL:

mysql> START SLAVE;

După aceasta, dacă totul a mers bine, puteți vedea cum apar toate modificările din baza de date de pe serverul Master în baza de date de pe Slave.

Setări de replicare MySQL

Setări pentru fișierul jurnal binar (log-bin)

Jurnal binar MySQL folosit pentru a înregistra modificările care apar în bazele de date server. Pentru replicare, trebuie să fie activat pe serverul Master pe serverele Slave, ar trebui să fie folosit numai dacă Slave este și Master pentru un alt slave MySQL. Log bin este activat prin adăugarea unui parametru la secțiunea mysql.cnf:

log-bin = mysql-bin

În setările exemplu: „Replicare master-slave a unei baze de date MySQL”, înregistrarea binară a fost activată pentru toate bazele de date MySQL. Dacă trebuie să vă înregistrați numai pentru anumite baze de date, de exemplu DB_NAME1 și DB_NAME2, trebuie să adăugați opțiuni la my.cnf ale vrăjitorului binlog-do-db:

binlog- do- db= "DB _NAME1"
binlog- do- db= "DB _NAME2"

Adică, trebuie să enumerați toate numele bazei de date, unde fiecare bază de date are propria linie cu parametrul binlog-do-db. Antonimul acestui operator este binlog-ignore-db="DB_NAME", care îi spune MySQL să înregistreze toate bazele de date, cu excepția celor specificate în parametrii binlog-ignore-db.

Dacă specificați baze de date, separate prin virgule, de exemplu astfel:

Utilizarea incorectă a parametrului binlog-ignore-db!

binlog- ignore- db= "DB _ NAME3, DB_ NAME4"

apoi, la prima vedere, totul va funcționa așa cum ar trebui - nu există erori, dar, de fapt, bazele de date DB_NAME3 și DB_NAME4 nu vor fi excluse din jurnalul binar: MySQL va considera că „DB_NAME3, DB_NAME4” este o bază de date cu numele „ DB_NAME3, DB_NAME4" " (adică există o virgulă și un spațiu în numele bazei de date)!

Înainte de a include sau de a exclude o bază de date din jurnalul binar, trebuie să înțelegeți cum și în ce moduri funcționează jurnalul binar MySQL. Acest lucru determină cât de fiabil va funcționa replicarea, consistența datelor și numărul de erori care apar în timpul implementării acesteia (până la eliminarea lor completă).

Parametrul responsabil pentru formatul de stocare a datelor al jurnalului binar - binlog_format, care începând de la MySQL 5.1 poate lua 3 valori: STATEMENT (utilizat implicit în MySQL = 5.7.7) și MIXED.

STATEMENT - Modul de jurnal binar MySQL

AFIRMAȚIE- în acest mod, interogările SQL obișnuite pentru adăugarea, actualizarea și ștergerea informațiilor cu date suplimentare de serviciu sunt scrise în jurnalul binar. Prin deschiderea unui astfel de login editor de text, puteți găsi în el solicitări de modificare a datelor din baza de date în format text. Avantajele utilizării binlog_format=STATEMENT: dimensiunea relativ mică a fișierului, capacitatea de a vizualiza jurnalul în mysqlbinlog sau PHPMyAdmin. Dezavantajele constă în utilizarea interogărilor SQL, mai multe despre asta mai jos.

Să presupunem că datele sunt adăugate în jurnalul binar pentru o singură bază de date numită utilizatori (binlog - do- db= „utilizatori”). Următoarea interogare, care afectează direct baza de date „utilizatori”, nu va fi înregistrată în jurnalul binar:

Exemplul nr. 1

USE clienți;
UPDATE utilizatori.conturi SET suma= suma+ 5 ;

Acest comportament este cauzat de faptul că este utilizată baza de date implicită „clienți”, care nu este înregistrată în jurnalul binar în modul Statement.

Un alt exemplu este atunci când o solicitare către o bază de date care nu este specificată în binlog-do-db ajunge în jurnalul binar:

Exemplul nr. 2

USE utilizatori;
UPDATE clienti.reduceri SET procente= procente+ 5 ;

Acest lucru se întâmplă în același mod, datorită utilizării bazei de date implicite, dar în acest caz, interogările „greșite”, „extra” sunt scrise în jurnalul binar.

Atât prima, cât și a doua cerere pot duce la consecințe neașteptate atunci când se utilizează replicarea pe serverul Slave. In cazul cererii din primul exemplu, datele de pe serverele Master si Slave vor fi diferite: suma=amount+5 se executa pe Master, dar nu pe Slave. La utilizarea celei de-a doua cereri, va fi trimisă o solicitare către Slave pentru modificarea datelor dintr-o bază de date care nu este înregistrată în lista de sclavi, iar replicarea Master-Slave va eșua dacă baza de date clienți nu există pe slave sau... . va face modificări în tabelul bazei de date, dacă există. Astfel, în timpul replicării Master-Slave în modul Declarație de jurnal binar, puteți face modificări în baza de date a serverului slave, care nu a fost destinată replicării! Se poate doar ghici la ce consecințe pot duce astfel de modificări, așa că trebuie să fii foarte atent când folosești modul de jurnal binar Statement.

O altă problemă la utilizarea unui jurnal binar în modul Declarație poate apărea dacă serverul Slave este configurat să scrie în baze de date cu nume diferite de cel original. De exemplu, o bază de date este replicată de la un master db_countries la un slave, unde aceeași bază de date este numită db_countries_slave (noul nume de bază de date pe serverul Slave este determinat de parametrul replicate-rewrite-db="db_countries->db_countries_slave" și un nou nume de bază de date este deja atribuit pentru replicare: replicate-do-db="db_countries_slave"). În timp ce masterul actualizează datele din baza de date folosind USE db_countries și UPDATE names SET ..., totul este în regulă, dar de îndată ce se face o solicitare care specifică numele bazei de date, de exemplu: UPDATE db_countries.names SET ... replicare pe Slave se oprește cu eroare: Tabelul „db_countries.names” nu există” la interogare. Baza de date implicită: „db_countries_slave”. Interogare: UPDATE db_countries.names SET.... Nu există o astfel de problemă în modul ROW.

ROW - modul de jurnal binar

RÂND- la alegerea acestei metode de stocare a unui jurnal binar, doar modificările pentru bazele de date selectate sunt scrise în fișier în format binar. Datele pot ocupa mult mai mult spațiu decât în modul Declarație. Dar acest tip de replicare are un avantaj principal - în acest mod, replicarea este mult mai sigură decât cu Statement.

Doar datele modificate pentru acele baze de date care sunt definite folosind parametrii binlog-do-db sau binlog-ignore-db sunt scrise în jurnalul binar. Baza de date implicită nu afectează acest comportament. Datorită acestui fapt, după interogările din exemplul 1, datele de actualizare vor ajunge în jurnalul binar, dar sql-ul din al doilea exemplu nu va mai fi înregistrat.

Mai mult descriere detaliata Avantajele și dezavantajele modurilor Statement și Row pot fi adunate din documentația oficială în limba engleză: 17.1.2.1 Avantajele și dezavantajele replicării bazate pe instrucțiuni și rânduri.

MIXED - modul log binar

AMESTECAT- un mod în care jurnalul binar utilizează simultan 2 moduri de replicare: Statement și Row pentru a stoca date despre diverse solicitări. Puteți afla mai multe despre cum funcționează modul de jurnal binar mixt din documentația oficială în limba engleză: 5.4.4.3 Format de înregistrare binar mixt. Acest lucru nu înseamnă că aceasta este o opțiune ideală, dar dacă înțelegeți cum funcționează Mixed, atunci poate fi folosit în practică.

Ștergerea automată a jurnalului binar - expire_logs_days

În mod implicit, jurnalele binare nu sunt niciodată șterse automat. Pentru a curăța automat log-bin, utilizați parametrul expire_logs_days, care specifică numărul de zile în care MySQL va stoca jurnalul binar.

Un exemplu de ștergere automată a unui jurnal binar, au trecut mai mult de 10 zile de la data creării acestuia

expire_logs_days= 10

Alte setări utile pentru jurnalele binare

Utilizatorul trebuie să conecteze Slave la Master

Cu replicarea Master-Slave, este necesar cel puțin un cont de utilizator pe serverul Master, care va fi folosit de către Slave pentru a se conecta. Cerințe pentru drepturile de acces ale unui astfel de cont: singurul privilegiu REPLICATION SLAVE este de a deschide accesul la baze de date, tabele sau de a adăuga orice alte privilegii - nu este necesar. Un utilizator cu REPLICATION SLAVE poate fi folosit de diferite servere slave pentru a primi simultan date de la serverul master sau poate fi creat un utilizator separat pentru fiecare slave.

Nu ar trebui folosit pentru replicare cont dotat cu orice drepturi de acces extinse. Login-ul și parola pentru conectarea la serverul master sunt stocate în text clar pe slave (fișierul master.info în directorul cu baza de date).

mysql> CREATE USER "replicate" @"10.0.0.1" IDENTIFICAT BY "pass" ;
mysql> GRANT REPLICATION SLAVE ON * .* TO "replicat" @"10.0.0.1" ;

Adresa IP 10.0.0.1 este ip-ul serverului Slave, trebuie înlocuit cu unul real. În interogările sql, puteți înlocui adresa IP cu simbolul % special, apoi vă puteți conecta la master de la orice gazdă, dar din motive de securitate, este mai bine să vă limitați la adresa reală a serverului slave.

Setari aditionale

Pentru cea mai corectă replicare a bazelor de date care utilizează tabele și tranzacții de tip InnoDB, trebuie să adăugați următoarele linii la configurația serverului Master (secțiunea my.cnf):

innodb_flush_log_at_trx_commit= 1
sync_binlog= 1

M-am familiarizat cu replicarea serverelor MySQL relativ recent și, pe măsură ce făceam diverse experimente cu configurația, am notat ce a funcționat pentru mine. Când am adunat destul de mult material, mi-a venit ideea să scriu acest articol. Am încercat să adun sfaturi și soluții pentru unele dintre cele mai de bază probleme pe care le-am întâlnit. Voi oferi link-uri către documentație și alte surse pe parcurs. Nu pot pretinde că o descriu complet, dar sper că articolul va fi util.

O scurtă introducere

Replicarea (din latinescul replico - repet) este replicarea modificărilor datelor de la serverul principal al bazei de date pe unul sau mai multe servere dependente. Vom apela serverul principal maestru, și dependent - replici.
Modificările de date care apar pe master sunt repetate pe replici (dar nu invers). Prin urmare, interogările de modificare a datelor (INSERT, UPDATE, DELETE etc.) sunt executate doar pe master, în timp ce interogările de citire a datelor (cu alte cuvinte, SELECT) pot fi executate atât pe replici, cât și pe master. Procesul de replicare pe una dintre replici nu afectează funcționarea altor replici și practic nu afectează munca maestrului.
Replicarea se realizează folosind jurnalele binare menținute pe master. Acestea stochează toate interogările care duc (sau pot duce) la modificări în baza de date (interogările nu sunt salvate în mod explicit, așa că dacă doriți să le priviți, va trebui să utilizați utilitarul mysqlbinlog). Binlog-urile sunt transferate în replici (binlog-ul descărcat de la master se numește „relay binlog”) și interogările stocate sunt executate începând de la o anumită poziție. Este important să înțelegeți că în timpul replicării, nu datele modificate în sine sunt transferate, ci doar cererile care provoacă modificările.
Cu replicare, conținutul bazei de date este duplicat pe mai multe servere. De ce este necesar să se recurgă la duplicare? Există mai multe motive:

performanță și scalabilitate. Este posibil ca un server să nu poată face față sarcinii cauzate de operațiunile simultane de citire și scriere în baza de date. Beneficiile creării de replici vor fi mai mari cu cât aveți mai multe citiri pe scriere pe sistemul dumneavoastră.
toleranta la greseli. În cazul unei erori de replica, toate cererile de citire pot fi transferate în siguranță către master. Dacă masterul eșuează, cererile de scriere pot fi transferate în replică (după restaurarea masterului, acesta poate prelua rolul replicii).
copia de rezerva a datelor. Replica poate fi „încetinită” pentru un timp pentru a efectua mysqldump, dar masterul nu poate.
calcule amânate. Interogările SQL grele și lente pot fi executate pe o replică separată fără teama de interferență operatie normalaîntregul sistem.

În plus, există și alte caracteristici interesante. Deoarece nu datele în sine sunt transferate în replici, ci interogările care le provoacă modificarea, putem folosi diferite structuri de tabel pe master și pe replici. În special, tipul de tabel (motor) sau setul de indici poate diferi. De exemplu, pentru a implementa căutarea textului integral putem folosi tipul de tabel MyISAM pe replică, în ciuda faptului că masterul va folosi InnoDB.

Configurarea replicării

Să presupunem că avem o bază de date MySQL funcțională, deja plină cu date și activată. Și pentru unul dintre motivele descrise mai sus, vom activa replicarea serverului nostru. Datele noastre inițiale:

Adresa IP principală este 192.168.1.101, replicile sunt 192.168.1.102.
MySQL instalat și configurat
trebuie să configurați replicarea bazei de date testdb
putem întrerupe vrăjitorul pentru o vreme
Desigur, avem root pe ambele mașini

Setările expertului

Asigurați-vă că indicați ID-ul unic al serverului, calea pentru jurnalele binare și numele bazei de date pentru replicare în secțiunea:
server-id = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb
Asigurați-vă că aveți suficient spațiu pe disc pentru jurnalele binare.

Să adăugăm utilizatorul de replicare, sub ale cărui drepturi se va efectua replicarea. Privilegiul „sclav de replicare” va fi suficient:
mysql@master> GRANT replication slave ON "testdb".* LA "replication"@"192.168.1.102" IDENTIFICAT BY "parola";

Reporniți MySQL pentru ca modificările din configurație să aibă efect:
root@master# service mysqld restart

Dacă totul a mers bine, comanda „show master status” ar trebui să arate ceva de genul acesta:
mysql@master> ARAȚI STARE MASTER\G
Fișier: mysql-bin.000003
Poziția: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Valoarea poziției ar trebui să crească pe măsură ce se fac modificări în baza de date de pe master.

Setări replica

Să specificăm ID-ul serverului, numele bazei de date pentru replicare și calea către binlog-urile releu în secțiunea de configurare, apoi reporniți MySQL:
server-id = 2
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-do-db = testdb

Root@replica# service mysqld restart

Transferarea datelor

Aici va trebui să blocăm baza de date pentru scriere. Pentru a face acest lucru, puteți fie să opriți aplicațiile, fie să utilizați indicatorul read_only de pe master (atenție: acest flag nu are efect asupra utilizatorilor cu privilegiul SUPER). Dacă avem tabele MyISAM, haideți să „eliminăm tabelele”:
mysql@master> TABELE FLASH CU BLOCARE DE CITIRE;
mysql@master> SET GLOBAL read_only = ON;

Să vedem starea masterului cu comanda „show master status” și să ne amintim valorile Fișier și Poziție (după blocarea cu succes a masterului, acestea nu ar trebui să se schimbe):
Fișier: mysql-bin.000003
Poziția: 98

Eliminam baza de date și, după ce operațiunea este finalizată, eliminăm blocarea masterului:
mysql@master> SET GLOBAL read_only = OFF;

Transferăm dump-ul în replică și restaurăm datele din ea.
În cele din urmă, începem replicarea cu comenzile „change master to” și „start slave” și vedem dacă totul a mers bine:
mysql@replica> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replicare", MASTER_PASSWORD = "parolă", MASTER_LOG_FILE = "mysql-bin.000003", MASTER_LOG_POS = 98;
mysql@replica> start slave;
Preluăm valorile MASTER_LOG_FILE și MASTER_LOG_POS de la master.

Să vedem cum decurge replicarea cu comanda „show slave status”:
mysql@replica> ARAȚI STARE SLAVE\G
Slave_IO_State: Se așteaptă ca master să trimită evenimentul
Master_Host: 192.168.1.101
Master_User: replicare
Master_Port: 3306
Conectare_Reîncercați: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 98
Relay_Log_File: mysql-relay-bin.001152
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Da
Slave_SQL_Running: Da
Replicate_Do_DB: testdb,testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Ultima_eroare: 0
Ultima_eroare:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: Niciunul
Până la_Log_File:
Până la_Log_Pos: 0
Master_SSL_Allowed: Nu
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 5

Am evidențiat cele mai interesante valori acum. Dacă replicarea începe cu succes, valorile lor ar trebui să fie aproximativ aceleași ca în listă (consultați descrierea comenzii „show slave status” din documentație). Valoarea Seconds_Behind_Master poate fi orice număr întreg.
Dacă replicarea este normală, replica va urma masterul (numărul de jurnal din Master_Log_File și poziția Exec_Master_Log_Pos vor crește). Timpul de întârziere al replicii de la master (Seconds_Behind_Master), în mod ideal, ar trebui să fie egal cu zero. Dacă nu scade sau crește, este posibil ca sarcina pe replică să fie prea mare - pur și simplu nu are timp să repete modificările care apar pe master.
Dacă Slave_IO_State este gol și Seconds_Behind_Master este NULL, replicarea nu a început. Consultați jurnalul MySQL pentru a afla motivul, eliminați-l și reporniți replicarea:
mysql@replica> start slave;

Prin acești pași simpli obținem o replică ale cărei date sunt identice cu datele de pe master.
Apropo, momentul în care masterul este blocat este momentul în care este creată dump-ul. Dacă este nevoie de un timp inacceptabil de mult pentru a crea, puteți încerca acest lucru:

blocați scrierea către master cu indicatorul read_only, amintiți-vă poziția și opriți MySQL.
după aceea, copiați fișierele bazei de date în replică și activați masterul.
începe replicarea în modul obișnuit.

Există mai multe moduri de a crea o replică fără a opri deloc masterul, dar nu funcționează întotdeauna.

Adăugarea de replici

Să presupunem că avem deja un master funcțional și o replică și trebuie să mai adăugăm una la ele. Acest lucru este chiar mai ușor de făcut decât adăugarea primei replică la master. Și ceea ce este mult mai frumos este că nu este nevoie să-l oprești pe maestru pentru asta.
Mai întâi, să configuram MySQL pe a doua replică și să ne asigurăm că am intrat parametrii necesari in config:
server-id = 3
replicate-do-db = testdb

Acum să oprim replicarea pe prima replică:
mysql@replica-1> stop slave;

Replica va continua să funcționeze normal, dar datele de pe ea nu vor mai fi actuale. Să ne uităm la starea și să ne amintim poziția principală la care a ajuns replica înainte de a opri replicarea:
mysql@replica-1> ARAȚI STARE SLAVE\G

Valorile de care avem nevoie vor fi Master_Log_File și Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155

Să creăm un dump al bazei de date și să continuăm replicarea pe prima replica:
mysql@replica-1> START SLAVE;

Să restabilim datele din dump pe a doua replică. Apoi activați replicarea:
mysql@replica-2> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replicare", MASTER_PASSWORD = "parola", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155;
mysql@replica-2> START SLAVE;

Valorile MASTER_LOG_FILE și MASTER_LOG_POS sunt valorile Master_Log_File și, respectiv, Exec_Master_Log_Pos, din rezultatul comenzii „show slave status” de pe prima replică.
Replicarea trebuie să înceapă din poziția în care a fost oprită prima replică (și, în consecință, se creează o descărcare). Astfel, vom avea două replici cu date identice.

Fuzionarea replicilor

Uneori apare următoarea situație: există două baze de date pe master, dintre care una este replicată pe o replică, iar a doua pe alta. Cum să configurați replicarea a două baze de date pe ambele replici fără a le arunca pe master sau a le închide? Pur și simplu, folosind comanda „porniți slave până la”.
Deci, avem un master cu baze de date testdb1 și testdb2, care sunt replicate pe replici replica-1 și respectiv replica-2. Să configuram replicarea ambelor baze de date la replica-1 fără a opri masterul.
Opriți replicarea pe replica-2 cu comanda și amintiți-vă poziția masterului:
mysql@replica-2> STOP SLAVE;
mysql@replica-2> ARAȚI STARE SLAVE\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231

Să creăm un dump al bazei de date testdb2 și să reluăm replicarea (acest lucru completează manipulările cu replica-2). Vom restaura dump-ul la replica-1.

Situația pe replica-1 este următoarea: baza de date testdb1 se află la o poziție master și continuă să se replice, baza de date testdb2 a fost restaurată dintr-un dump dintr-o altă poziție. Să le sincronizăm.

Să oprim replicarea și să ne amintim poziția comandantului:
mysql@replica-1> STOP SLAVE;
mysql@replica-1> ARAȚI STARE SLAVE\G
Exec_Master_Log_Pos: 501

Să ne asigurăm că în configurația pentru replica-1 este indicat numele celei de-a doua baze de date în secțiunea:
replicate-do-db = testdb2

Să repornim MySQL pentru ca modificările din configurație să aibă efect. Apropo, am putea pur și simplu reporni MySQL fără a opri replicarea - din jurnal am ști în ce poziție din master s-a oprit replicarea.

Acum să replicăm de la poziția în care replica-2 a fost întreruptă la poziția în care tocmai am întrerupt replicarea:
mysql@replica-1> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replicare", MASTER_PASSWORD = "parola", MASTER_LOG_FILE = "mysql-bin.000015", MASTER_LOG_POS = 231;
mysql@replica-1> porniți slave până la MASTER_LOG_FILE = "mysql-bin.000016 ", MASTER_LOG_POS = 501;

Replicarea se va încheia imediat ce replica ajunge la poziția specificată în secțiunea până, după care ambele baze de date vor corespunde aceleiași poziții master (la care am oprit replicarea pe replica-1). Să ne asigurăm de asta:
mysql@replica-1> ARAȚI STARE SLAVE\G
mysql@replica-1> START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Să adăugăm numele ambelor baze de date la configurația pentru replica-1 în secțiunea:
replicate-do-db = testdb1
replicate-do-db = testdb2

Important: fiecare bază de date trebuie să fie listată pe o linie separată.
Reporniți MySQL și continuați replicarea:
mysql@replica-1> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replicare", MASTER_PASSWORD = "parolă", MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;
După ce replica-1 ajunge din urmă cu masterul, conținutul bazei de date a acestora va fi identic. Puteți îmbina baza de date pe replica-2 fie într-un mod similar, fie făcând un dump complet al replica-1.

Maestru de roca și replică

Poate fi necesar să comutați o replică în modul master, de exemplu, în cazul unei defecțiuni master sau când se efectuează o munca tehnica. Pentru a face posibilă o astfel de schimbare, trebuie să configurați replica ca masterul sau să o faceți maestru pasiv.

Să activăm înregistrarea binară (în plus față de binlog-urile releu) în configurația din secțiunea:
log-bin = /var/lib/mysql/mysql-bin

Și adăugați un utilizator pentru replicare:
mysql@master> GRANT replication slave ON 'testdb'.* TO 'replication'@'192.168.1.101′ IDENTIFICAT BY "parola";

Maestrul pasiv efectuează replicarea ca o replică obișnuită, dar în plus creează logii binare - adică putem începe replicarea de la ea. Să verificăm acest lucru cu comanda „show master status”:
mysql@replica> AFIȚĂ STARE MASTER\G
Fișier: mysql-bin.000001
Poziția: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Acum, pentru a comuta masterul pasiv în modul activ, trebuie să opriți replicarea pe acesta și să activați replicarea pe fostul master activ. Pentru a vă asigura că datele nu se pierd în momentul comutării, maestru activ trebuie să fie blocat la scriere.
mysql@master> TABELE CURSATE CU BLOCARE DE CITIRE
mysql@master> SET GLOBAL read_only = ON;
mysql@replica> STOP SLAVE;
mysql@replica> AFIȚĂ STARE MASTER;
Fișier: mysql-bin.000001
Poziția: 61
mysql@master> CHANGE MASTER TO MASTER_HOST = "192.168.1.102", MASTER_USER = "replicare", MASTER_PASSWORD = "parola", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 61;
mysql@master> start slave;
Asta e, așa că am schimbat masterul activ. Puteți elimina blocul de la fostul maestru.

Concluzie

Am învățat puțin despre cum să configurați replicarea în MySQL și să efectuam câteva operațiuni de bază. Din păcate, următoarele întrebări importante rămân în afara domeniului de aplicare al acestui articol:

eliminarea punctelor unice de eșec (SPF, Single Points of Failure). Când se folosește un singur server MySQL, eșecul acestuia a dus la eșecul întregului sistem. Când utilizați mai multe servere, eșecul oricăruia dintre ele va duce la o defecțiune a sistemului, cu excepția cazului în care ne ocupăm în mod special de acest lucru. Trebuie să asigurăm gestionarea situației cu eșecul masterului și al replicii. Unul dintre instrumentele existente este MMM, cu toate acestea, necesită modificare cu un fișier.
echilibrarea sarcinii. Când folosim mai multe replici, am dori să folosim un mecanism de echilibrare transparent, mai ales dacă performanța replicilor este neuniformă. Sub Linux, este posibil să utilizați o soluție standard - LVS.
schimbarea logicii aplicatiei. Într-o situație ideală, cererile de citire a datelor ar trebui trimise la replici, iar cererile de modificare a datelor ar trebui trimise către master. Cu toate acestea, din cauza posibilului decalaj al replicilor, o astfel de schemă este adesea ineficientă și este necesar să se identifice astfel de solicitări de citire care trebuie încă executate pe master.

Sper să acopăr aceste probleme în articolele viitoare.
Vă mulțumim pentru atenție!