Postavljanje MySQL replikacije bez zaustavljanja čarobnjaka. Šta je replikacija u MySQL-u? Postavljanje replikacije sa mysql administratorom

Sa Linux Wiki

Postavljanje replikacije

Glavni server

  • my.cnf na glavnom serveru:

[mysqld]# ID servera. Mora biti jedinstven na svakom linku servera (i master i slave). # Je broj u rasponu od 1 do 4294967295 (2 ^32 -1 ) server-id = 1 # Putanja do binarnih dnevnika gdje se čuvaju sve promjene u bazi podataka glavnog servera. Trebalo bi da ima dovoljno prostora za ove dnevnike log-bin = /var/lib/mysql/mysql-bin # Koliko dana držati binarne dnevnike na masteru. Na neki način, ovo također određuje koliko slave može zaostajati za masterom # expire_logs_days = 10 # Veličina binlog datoteke (svake pojedinačne datoteke) # max_binlog_size = 1024M # Omogući kompresiju dnevnika poslanih slave-u slave_compressed_protocol = 1 # Naziv baza podataka za koju treba izvršiti replikaciju. Ako trebate replicirati nekoliko baza podataka, ponovite opciju sa željenim imenom baze podataka replicate-do-db = testdb # Osim ove opcije, postoji još opcija "obrnuti izbor"- da isključite izbor baza podataka # replicate-ignore-db= database_name # kao i opcije za repliciranje pojedinačnih tabela (slično - odaberite jednu/više ; isključiti jedan/više, kao i definiciju imena putem zamjenskih znakova)# Ova opcija je potrebna u slučaju da je ovaj glavni server podređen drugom - tako da slave za ovog glavnog (sub-slave glavnog glavnog) također prima ažuriranja # Može biti korisno kada se replicira master-master s jednim slave # log -slave -ažuriranja

  • Dajemo prava slave serveru da se replicira iz ovoga. Da bismo to učinili, u mysql konzoli dajemo naredbu:

mysql> GRANT replikacijski slave ON * .* TO "repluser" @"replhost" IDENTIFIKOVANO OD "replpass" ;

  • repluser- korisničko ime za povezivanje. Korisnik se kreira u trenutku izvršavanja naredbe.
  • replhost- IP adresa ili host domena slave servera koji će se povezati na ovaj master i uvoziti promjene sa njega.
  • replpass- lozinka za povezivanje
Ograničenje baze za replikaciju u grant replikaciji izgleda ne funkcionira - tj. dozvoljavamo sve, a u konfiguraciji navodimo samo bazu/baze koje su potrebne

Ponovo pokrećemo server, nakon čega možete pokrenuti naredbu u konzoli

mysql> PRIKAŽI MASTER STATUS ;

koji će pokazati binarnu datoteku dnevnika sa kojom master trenutno radi i trenutnu poziciju u dnevniku, kao i bazu(e) koja se replicira.

Slave server

  • Dodajte potrebne opcije u konfiguraciju my.cnf na slave serveru:

[mysqld]# ID servera za ovaj paket servera - pogledajte opis iznad server-id = 2 # Relay logs - logovi preuzeti sa glavnog servera # Odredite putanju za ove dnevnike ; trebalo bi da ima dovoljno prostora za njihovo skladištenje.#relay-log= /var/lib/mysql/mysql-relay-bin#relay-log-index= /var/lib/mysql/mysql-relay-bin.index# Ime baze podataka koja se replicira replicate-do-db = testdb # Omogući kompresiju dnevnika poslanih Slave slave_compressed_protocol = 1

Ponovo pokrenite server da primijenite promjene

Pokreni replikaciju

Na masteru zaključavamo tabele za pisanje kako bismo dobili potpuno ispravan dump:

mysql> FLUSH TABLE SA ZAKLJUČAVANJEM ČITANJA ; mysql> POSTAVI GLOBALNO read_only = ON ;

Spajamo dump sa servera. Na nekim mjestima obično pišu o tome da je potrebno pogledati poziciju i naziv dnevnika na masteru - to nije potrebno i rješava se ključem --master-data za mysqldump, koji će pisati potrebne informacije u sam dump:

mysqldump --master-data -hmasterhost -umasteruser -pmasterpass masterdbname > dump.sql

Nakon toga pokrećemo čarobnjaka da radi:

mysql> SET GLOBAL read_only = OFF;

(iako se nameće misao - da li je zaista potrebno zaključati bazu podataka prilikom dampanja? Čim se dump sa --master-data počne praviti, u njega se ubacuje ime i pozicija dnevnika, a tabele se automatski zaključavaju za pisanje - tj. sve je isto, samo u automatskom režimu)

mysql -hslavehost -uslaveuser -pslavepass slavedbname< dump.sql

U ovom slučaju, slavedbname = masterdbname, iako ako želite, možete napraviti replikaciju baze podataka pod drugim imenom.

Odredite adresu glavnog servera podređenom:

mysql> CHANGE MASTER TO MASTER_HOST = "masterip" , MASTER_USER = "repluser" , MASTER_PASSWORD = "replpass" ;

Gdje masterip- IP adresa ili domena glavnog servera, a preostale opcije su one koje su gore navedene prilikom podešavanja glavnog servera. Ime log fajla i pozicija preuzimaju se iz dumpa, ali po želji se mogu ručno specificirati preko opcija MASTER_LOG_FILE = "log_name", MASTER_LOG_POS = pozicija

Nakon ove naredbe, informacije o masteru se spremaju u datoteku master.info u direktoriju baze podataka mysql servera. Ako želite, možete odrediti ove opcije u konfiguraciji slave servera:

master-host=masterip master-user=repluser master-password=replpass master-port=3306

Nakon toga pokrećemo slave server preko mysql konzole:

mysql> START SLAVE;

Sada možete provjeriti status slave servera pomoću naredbe

mysql> PRIKAŽI SLAVE STATUS ;

Od zanimljivih informacija mogu postojati polja:

  • Slave_IO_State: Čeka se da master pošalje događaj, Slave_IO_Pokreće: Da I Slave_SQL_Pokreće: Da- sve dobro radi :)
  • Seconds_Behind_Master- koliko je rob iza gospodara. U normalnom modu bi trebao biti 0, ali u stvarnom kašnjenju može biti i 0 ako se napravi puno promjena na masteru, a kanal između master i slave je uzak i potonji nema vremena za preuzimanje binlogs od mastera. U ovom slučaju, "0" je tačan, ali samo za ono što je uspjelo preuzeti iz dnevnika.

I druge trenutne informacije kao što su bez grešaka, trenutna pozicija i naziv dnevnika servera, slave dnevnik, itd.

Razno

Postoje 2 opcije za mysqldump da upiše ime dnevnika i poziciju u damp fajl: --master-data I --dump-slave. Drugi nije svuda:

[email protected]:~# mysqldump --pomoć | grep "dump-slave" [email protected]:~# mysqldump --verzija mysqldump Ver 10.13 Distrib 5.1.61, za portbld-freebsd8.2 (amd64)

Dump-slave[=value] Ova opcija je slična --master-data osim što se koristi za dump replikacionog slave servera za proizvodnju dump datoteke koja se može koristiti za postavljanje drugog servera kao slavea koji ima isti master kao bačeni server. To dovodi do toga da izlaz dampa uključuje naredbu CHANGE MASTER TO koja ukazuje na binarne koordinate dnevnika (ime datoteke i poziciju) mastera bačenog slave-a (a ne koordinate bačenog servera, kao što to čini --master- data opcija).Ovo su koordinate glavnog servera od kojih bi slave trebao početi replicirati.Ova opcija je dodana u MySQL 5.5.3.

U skladu s tim, jedna opcija je za kloniranje podređenog, a druga za stvaranje subslavea. Drugim riječima, dump-slave vam omogućava da kreirate (koristeći slave1) još jedan slave1 u lancu master-slave1-slave2 (pozicija u dnevniku i log fajlu u odnosu na glavne dnevnike će biti upisana u dump), master- data vam omogućava da kreirate slave2 - poziciju/log u odnosu na binlogove slave1.

Greške u replikaciji

Kada je replikacija pokrenuta, mogu se pojaviti greške - iz bilo kojeg razloga, na primjer, ručno unošenje podataka na slave server.

Opcije rješenja.

Dobar dan svima! Danas ćemo u našem članku pogledati primjere postavljanja replikacije tipa "master-slave".

Malo teorije

Zašto je potrebna replikacija? Prije svega, ovo je sigurnosna mreža u slučaju kvara glavnog mysql servera, onda se možete prebaciti na slave server i nastaviti s radom. Drugo, to je prilika da se smanji opterećenje glavnog Mysql servera, koristeći glavni server samo za pisanje i obavljanje operacija čitanja na slave serveru. Kako se replikacija odvija? Glavni server upisuje binlogove, u kojima označava operacije koje se izvode na bazi podataka (baze podataka) i pamti pomak u dnevniku od njegovog početka do trenutnog zapisa (pozicije). Slave server se povezuje sa glavnim serverom, upoređuje vrednosti pozicije i čita promene u dnevniku počevši od sopstvene vrednosti pozicije i završavajući sa vrednošću pozicije mastera. Primjenjuje promjene (naredbe) na baze podataka na slave serveru.

Instalacija i konfiguracija Master

Promijenite my.cnf na glavnom serveru:

Server-id = 1 - navedite id servera log_bin = /var/log/mysql/mysql-bin.log - ime dnevnika i putanju

Malo pojašnjenje: po defaultu, čarobnjak piše binlogove za sve baze podataka, ovo se može promijeniti pomoću "binlog-do-db". Vrijednosti će se upisivati ​​u dnevnike kada se koristi određena baza podataka, promjene u drugim bazama podataka neće biti zabilježene. Ovdje također možete odrediti koliko dana treba čuvati dnevnike, koja je njihova maksimalna veličina (parametri expire_logs_days i max_binlog_size). Dodajte korisnika u MySQL pod čijim pravima će se izvršiti replikacija:

GRANT slave replikacije ON *.* TO server_username@ip_slave IDENTIFIED BY "password";

replication slave - privilegija koja omogućava korisniku da čita binlogove. ip_slave_server - ip servera sa kojeg će se korisnik povezati. Ponovo pokrenite mysql server:

/etc/init.d/mysql restart

Provjera rada čarobnjaka:

prikaži status glavnog;

Trebali biste vidjeti binlog ime i poziciju u njemu. Prilikom izvršavanja naredbi u bazi podataka, pozicija će se promijeniti.

Slave setup

Pravimo promjene u my.cnf fajlu:

Server-id = 2 - ID slave-servera mora se razlikovati od glavnog ID-a. relay-log = /var/lib/mysql/mysql-relay-bin - kao i binarni dnevnik, sastoji se od skupa numerisanih datoteka koje sadrže događaje koji opisuju promjene u bazi podataka. relay-log-index = /var/lib/mysql/mysql-relay-bin.index je indeksna datoteka koja sadrži imena svih korištenih datoteka dnevnika releja. replicate-do-db = DB za repliciranje.

Važna napomena! Prilikom organiziranja unakrsne baze podataka (kada se koristi jedna baza podataka, a podaci se ažuriraju u drugoj bazi podataka), ne morate specificirati binlog-do-db u postavkama glavnog servera, binlog-and treba biti napisan za sve baze podataka i u slave postavke koje trebate zamijeniti replicate-do -db specificiraju replicate-wild-do-table=db_name.%, gdje je db_name ime replicirane baze podataka. Ponovo pokrenite mysql server:

/etc/init.d/mysql restart

Omogući replikaciju

SET GLOBAL read_only = ON;

Gledamo stanje master-a:

prikaži status glavnog;

Pamtimo vrijednosti datoteke i pozicije (i bolje je da ih zapišemo). Trenutno se vrijednost pozicije ne bi trebala mijenjati. Izbacujemo master pomoću naredbe mysqldump:

mysqldump -uname -ppassword db_master_name > dump_db,

gdje je ime - korisničko ime, lozinka - lozinka, db_master_name - ime baze podataka, dump_db - ime dumpa. Nakon što se dump završi, dozvoljavamo pisanje u bazu podataka:

SET GLOBAL read_only = OFF;

Prebacujemo dump na slave i postavljamo

mysql -uname -ppassword db_slave_name< dump_db

Postavljanje replikacije

CHANGE MASTER TO MASTER_HOST = "master's ip", MASTER_USER = "korisničko ime", MASTER_PASSWORD = "password", MASTER_LOG_FILE = "log name", MASTER_LOG_POS = pozicija;

ip-master - ip servera na kojem se nalazi master, user_name - korisničko ime koje smo kreirali na masteru, log name - vrijednost datoteke na masteru kada je baza podataka izbačena, pozicija - vrijednost pozicije na masteru kada je baza podataka je bačen. Pokrećemo rob:

start slave;

Gledamo kako se odvija replikacija: Na master: SHOW MASTER STATUS\G Na slave: SHOW SLAVE STATUS\G

Sigurnosne postavke na glavnom serveru

Opcija bind-address u /etc/mysql/my.cnf specificira koju IP adresu će mysql server slušati dok čeka vezu. Obično ima vrijednost bind-address = 127.0.0.1. Ali nakon konfigurisanja slave servera, moramo dozvoliti vezu sa slave servera i istovremeno, lokalne veze. Vezana adresa može dozvoliti vezu samo sa jednog IP-a ili sa svih. Jer moramo navesti više od jednog ip-a za vezu, komentarišemo red sa bind-address = 127.0.0.1. Sada će mysql server prihvatati veze sa svih ip adresa, što je veoma opasno. iptables će nam pomoći da riješimo ovaj problem:

Iptables -I INPUT -p tcp -s ip_slave_server-a --dport 3306 -j ACCEPT - na početku dozvoljavamo vezu sa ip adrese slave servera iptables -I INPUT -p tcp --dport 3306 -j DROP - zatim odbijamo vezu sa svim ostalim IP adresama.

Sada ćemo imati 2 MySQL servera u master-slave modu, što značajno povećava pouzdanost stranice i, za neke Drupal stranice, pomaže u povećanju brzine rada. U sljedećem članku ćemo razmotriti prebacivanje između glavnog i slave moda u slučaju pada glavnog servera.

Replikacija je mehanizam za sinkronizaciju sadržaja više kopija objekta. Ovaj proces se odnosi na kopiranje podataka iz jednog izvora u mnoge druge i obrnuto.

Oznake:

  • master - glavni server čije podatke treba duplicirati;
  • replika - popravljeni server koji pohranjuje kopiju master podataka

Da biste postavili replikaciju u MySQL, morate slijediti dolje opisani slijed radnji, ali to nije dogma i parametri se mogu mijenjati ovisno o okolnostima.

Na glavnom serveru uredite my.cnf datoteku, dodajte sljedeće redove u mysqld odjeljak:

server-id=log-bin=mysql-bin log-bin-index=mysql-bin.index log-error=mysql-bin.err relay-log=relay-bin relay-log-info-file=relay-bin. info relay-log-index = relay-bin.index expire_logs_days=7 binlog-do-db =

  • - Jedinstveni identifikator MySQL servera, broj u rasponu 2 (0-31)
  • - naziv baze podataka, informacija o kojoj će biti upisana u binarni dnevnik, ako postoji nekoliko baza podataka, tada svaka zahtijeva poseban red s parametrom binlog_do_db

Na slave-u uredite my.cnf datoteku, dodajte sljedeće redove u mysqld odjeljak:

server-id=master-host=master master-user=replikacija master-password=password master-port=3306 relay-log=relay-bin relay-log-info-file=relay-log.info relay-log-index= relay-log.index replicate-do-db =

Na glavnom serveru dodajte korisnika za replikaciju s pravima repliciranja podataka:

GRAANT REPLICATION SLAVE NA *.* TO "replication"@"replica" IDENTIFICIRANO "password"

Blokirajmo replicirane baze podataka na glavnom serveru od promjene podataka, programski ili korištenjem MySQL funkcionalnosti:

[email protected]> FLUSH TABLE SA READ LOCK; [email protected]> SET GLOBAL read_only = ON;

Komanda za otključavanje je:

[email protected]> POSTAVI GLOBALNO samo za čitanje = ISKLJUČENO;

Napravimo sigurnosne kopije svih baza podataka na glavnom serveru (ili onih koje su nam potrebne):

[email protected]# tar -czf mysqldir.tar.gz /var/lib/mysql/

ili pomoću uslužnog programa mysqldump:

[email protected]# mysqldump -u root -p --lock-all-tables > dbdump.sql

Zaustavimo oba servera (u nekim slučajevima možete i bez toga):

[email protected]# mysqlamdin -u root -p isključivanje [email protected]# mysqlamdin -u root -p isključivanje

Vratimo replicirane baze podataka na slave server kopiranjem direktorija. Prije početka replikacije, baze podataka moraju biti iste:

[email protected]# cd /var/lib/mysql [email protected]# tar -xzf mysqldir.tar.gz

ili mysql funkcionalnost, tada nije bilo potrebe da se mysql zaustavlja na slave serveru:

[email protected]# mysql -u root -p< dbdump.sql

Pokrenimo mysql na glavnom serveru (a onda na slave, ako je potrebno):

[email protected]# /etc/init.d/mysql start [email protected]# /etc/init.d/mysql start

Provjerimo rad glavnog i slave servera:

[email protected]> start slave; [email protected]> PRIKAŽI SLAVE STATUS\G [email protected]> PRIKAŽI MASTER STATUS\G

Na slave serveru provjerite logove u datoteci master.info, oni bi trebali sadržavati zahtjeve za promjenu podataka u bazi podataka. Dakle, ova binarna datoteka mora se prvo pretvoriti u tekstualni format:

[email protected]# mysqlbinlog master.info > master_info.sql

Ako dođe do greške, možete koristiti naredbe:

[email protected]> stop slave; [email protected]> RESET SLAVE; [email protected]> RESET MASTER;

i ponovite sve radnje počevši od zaključavanja baze podataka.

Za vruće dodavanje servera za replikaciju, možete koristiti sintaksu:

[email protected]> PRIKAŽI SLAVE STATUS\G [email protected]> PRIKAŽI MASTER STATUS\G [email protected]> CHANGE MASTER TO MASTER_HOST = "master", MASTER_USER = "replikacija", MASTER_PASSWORD = "password", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155; [email protected]> START SLAVE;

Informacije iz statusa će pokazati poziciju i ime trenutnog log fajla.

U slučaju asinkrone replikacije, ažuriranje jedne replike se propagira na druge nakon nekog vremena, a ne u istoj transakciji. Stoga, asinhrona replikacija uvodi kašnjenje, ili vremensko ograničenje, tokom kojeg pojedinačne replike možda zapravo nisu identične. Ali ova vrsta replikacije ima i pozitivne aspekte: glavni server ne mora brinuti o sinhronizaciji podataka, možete blokirati bazu podataka (na primjer, za kreiranje backup) na slave mašini, nema problema za korisnike.

Spisak korištenih izvora

  1. Habrahabr.ru - Osnove replikacije u MySQL (http://habrahabr.ru/blogs/mysql/56702/)
  2. Wikipedia (http://ru.wikipedia.org/wiki/Replication_(computer_engineering))

Kada koristite bilo koji materijal sa stranice, u cjelini ili djelomično, morate eksplicitno navesti vezu ka izvoru.

Sa replikacijom MySQL servera sam se upoznao relativno nedavno, i kako sam radio razne eksperimente sa podešavanjima, zapisao sam šta sam uradio. Kada je bilo puno materijala, pojavila se ideja da napišem ovaj članak. Pokušao sam sastaviti savjete i rješenja za neke od najosnovnijih problema s kojima sam se susreo. Usput ću dati linkove do dokumentacije i drugih izvora. Ne mogu se pretvarati da sam kompletan, ali se nadam da će članak biti od koristi.

Mali uvod

Replikacija (od latinskog replico - ponavljam) je replikacija promjena podataka sa glavnog servera baze podataka na jedan ili više zavisnih servera. Glavni server će biti pozvan majstor, i zavisna replike.
Promjene podataka koje se događaju na masteru ponavljaju se na replikama (ali ne i obrnuto). Stoga se upiti za promjenu podataka (INSERT, UPDATE, DELETE, itd.) izvršavaju samo na masteru, dok se upiti za čitanje podataka (drugim riječima, SELECT) mogu izvršavati i na replikama i na masteru. Proces replikacije na jednoj od replika ne utječe na rad drugih replika i praktično ne utječe na rad mastera.
Replikacija se vrši korištenjem binarnih dnevnika koji se održavaju na masteru. Oni spremaju sve upite koji dovode (ili potencijalno dovode) do promjena u bazi podataka (upiti se ne pohranjuju eksplicitno, pa ako želite da ih vidite, morat ćete koristiti uslužni program mysqlbinlog). Binlogovi se prenose u replike (binlog preuzet sa mastera naziva se "relay binlog") i pohranjeni upiti se izvršavaju počevši od određene pozicije. Važno je shvatiti da replikacija ne prenosi same promijenjene podatke, već samo zahtjeve koji uzrokuju promjene.
Tokom replikacije, sadržaj baze podataka se duplira na nekoliko servera. Zašto je potrebno koristiti dupliranje? Postoji nekoliko razloga:
  • performanse i skalabilnost. Jedan server možda neće moći podnijeti opterećenje uzrokovano istovremenim čitanjem i pisanjem baze podataka. Prednost kreiranja replika će biti veća što je više čitanja po zapisu u vašem sistemu.
  • tolerancije grešaka. U slučaju kvara replike, svi zahtjevi za čitanje mogu se sigurno prenijeti na master. Ako master ne uspije, zahtjevi za pisanje mogu se prenijeti na repliku (nakon što se master vrati, može preuzeti ulogu replike).
  • backup podataka. Replika se može "usporiti" na neko vrijeme da izvrši mysqldump, ali master ne može.
  • lijena evaluacija. Teški i spori SQL upiti mogu se izvoditi na zasebnoj replici bez straha od ometanja normalan rad cijeli sistem.
Osim toga, tu su i neke druge zanimljive karakteristike. Pošto se u replike ne prenose sami podaci, već upiti koji uzrokuju njihovu promjenu, možemo koristiti drugačiju strukturu tablice na masteru i replikama. Konkretno, može se razlikovati tip tablice (motor) ili skup indeksa. Na primjer, da izvršimo pretraživanje punog teksta, možemo koristiti tip tablice MyISAM na replici, uprkos činjenici da će master koristiti InnoDB.

Postavljanje replikacije

Recimo da imamo radnu MySQL bazu podataka koja je već popunjena podacima i puštena u rad. I iz jednog od gore opisanih razloga, omogućit ćemo replikaciju na našem serveru. Naši početni podaci:
  • IP adresa mastera je 192.168.1.101, replika je 192.168.1.102.
  • MySQL instaliran i konfigurisan
  • morate postaviti replikaciju testdb baze podataka
  • možemo pauzirati čarobnjaka na neko vrijeme
  • naravno imamo root na obe mašine
Postavke čarobnjaka
Obavezno navedite jedinstveni ID servera, putanju za binarne dnevnike i naziv baze podataka za replikaciju u odjeljku:
server-id = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db=testdb
Provjerite imate li dovoljno prostora na disku za binarne zapise.

Dodajmo korisnika replikacije pod čijim pravima će se vršiti replikacija. Privilegija "slave replikacije" će biti dovoljna:
[email protected]> GRANT slave replikacije NA "testdb".* NA "replikaciju"@"192.168.1.102" IDENTIFIKOVANO OD "lozinke";

Ponovo pokrenite MySQL da bi promjene konfiguracije stupile na snagu:
[email protected]# servis mysqld restart

Ako je sve prošlo dobro, naredba "show master status" bi trebala pokazati nešto poput ovoga:
[email protected]> PRIKAŽI MASTER STATUS\G
Fajl: mysql-bin.000003
Pozicija: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Vrijednost pozicije bi se trebala povećavati kako se izvrše promjene u bazi podataka na masteru.

Postavke replike
Navedite ID servera, ime baze podataka za replikaciju i putanju do relejnih binlogova u odjeljku konfiguracije, a zatim ponovo pokrenite 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

[email protected]# servis mysqld restart

Prijenos podataka
Ovdje ćemo morati zaključati bazu podataka za pisanje. Da biste to učinili, možete ili zaustaviti pokretanje aplikacija ili koristiti oznaku read_only na glavnom (napomena: ova zastavica ne utiče na korisnike sa privilegijom SUPER). Ako imamo MyISAM tabele, uradićemo i "flush table":
[email protected]> FLUSH TABLE SA READ LOCK;
[email protected]> POSTAVI GLOBALNO read_only = ON;

Pogledajmo status mastera pomoću naredbe "show master status" i zapamtimo vrijednosti datoteke i pozicije (nakon uspješnog blokiranja mastera, one se ne bi trebale mijenjati):
Fajl: mysql-bin.000003
Pozicija: 98

Napravimo dump baze podataka, a nakon što je operacija završena, uklanjamo glavnu bravu:
[email protected]> POSTAVI GLOBALNO samo za čitanje = ISKLJUČENO;

Prenosimo dump u repliku i vraćamo podatke iz nje.
Konačno, počinjemo replikaciju s naredbama "change master to" i "start slave" i vidimo da li je sve prošlo dobro:
[email protected]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replikacija", MASTER_PASSWORD = "password", MASTER_LOG_FILE = "mysql-bin.000003", MASTER_LOG_POS = 98;
[email protected]> start slave;
Od mastera preuzimamo vrijednosti MASTER_LOG_FILE i MASTER_LOG_POS.

Pogledajmo kako ide replikacija s naredbom "show slave status":
[email protected]> PRIKAŽI SLAVE STATUS\G
Slave_IO_State: Čeka se da master pošalje događaj
Master_Host: 192.168.1.101
Glavni_Korisnik:replikacija
Glavni_port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Poz: 98
Relay_Log_File: mysql-relay-bin.001152
Relay_Log_Poz: 235
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Pokreće: Da
Slave_SQL_Pokreće: Da
Replicate_Do_DB: testdb,testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Zadnja_Errno: 0
Zadnja_Greška:
Brojač_skip: 0
Exec_Master_Log_Poz: 98
Relay_Log_Space: 235
Do_Stanje: Nema
Do_Log_File:
Do_log_Poz: 0
Master_SSL_Dozvoljeno: Ne
Master_SSL_CA_File:
Master_SSL_CA_Puta:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Sekunde_Iza_Majstora: 5

Istaknuo sam sada najzanimljivije vrijednosti. Nakon uspješnog početka replikacije, njihove vrijednosti bi trebale biti približno iste kao na listi (pogledajte opis naredbe "show slave status" u dokumentaciji). Vrijednost Seconds_Behind_Master može biti bilo koji cijeli broj.
Ako replikacija ide dobro, replika će pratiti master (broj dnevnika u Master_Log_File i pozicija Exec_Master_Log_Pos će se povećati). Vrijeme iza replike od mastera (Seconds_Behind_Master), idealno, treba biti jednako nuli. Ako se ne smanjuje ili raste, moguće je da je opterećenje na replici previsoko - jednostavno nema vremena ponoviti promjene koje se javljaju na masteru.
Ako je Slave_IO_State prazan, a Seconds_Behind_Master je NULL, replikacija nije započela. Pogledajte MySQL dnevnik da saznate uzrok, popravite ga i ponovo započnite replikaciju:
[email protected]> start slave;

Kroz ove jednostavne korake dobijamo repliku čiji su podaci identični podacima na masteru.
Usput, vrijeme zaključavanja mastera je vrijeme kada je napravljen dump. Ako je potrebno nedopustivo dugo vremena za kreiranje, možete pokušati ovo:

  • blokirajte pisanje masteru sa zastavicom read_only, zapamtite poziciju i zaustavite MySQL.
  • nakon toga kopirajte datoteke baze podataka u repliku i uključite master.
  • započnite replikaciju na uobičajeni način.
Postoji nekoliko načina da napravite repliku bez zaustavljanja mastera, ali oni ne rade uvijek.

Dodavanje replika

Pretpostavimo da već imamo radni master i repliku i da im trebamo dodati još jednu. Ovo je čak lakše nego dodavanje prve replike u master. I mnogo je ugodnije što nema potrebe zaustavljati majstora zbog toga.
Prvo, postavimo MySQL na drugu repliku i uvjerimo se da smo unijeli potrebne parametre u konfiguraciju:
server-id = 3
replicate-do-db=testdb

Sada zaustavite replikaciju na prvoj replici:
[email protected]> stop slave;

Replika će nastaviti normalno funkcionirati, ali podaci na njoj više neće biti ažurirani. Pogledajmo status i zapamtimo poziciju mastera do koje je replika stigla prije zaustavljanja replikacije:
[email protected]> PRIKAŽI SLAVE STATUS\G

Trebat će nam vrijednosti Master_Log_File i Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Poz: 155

Kreirajte dump baze podataka i nastavite replikaciju na prvoj replici:
[email protected]> START SLAVE;

Vratimo podatke iz dumpa na drugu repliku. Zatim omogućite replikaciju:
[email protected]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replikacija", MASTER_PASSWORD = "lozinka", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155;
[email protected]> START SLAVE;

Vrijednosti MASTER_LOG_FILE i MASTER_LOG_POS su vrijednosti Master_Log_File i Exec_Master_Log_Pos iz rezultata naredbe show slave status na prvoj replici.
Replikacija bi trebala početi od pozicije na kojoj je prva replika zaustavljena (i, prema tome, kreiran je dump). Tako ćemo imati dvije replike sa identičnim podacima.

Kombinovanje replika

Ponekad se javlja ova situacija: postoje dvije baze podataka na masteru, od kojih je jedna replicirana na jednoj replici, a druga na drugoj. Kako postaviti replikaciju dvije baze podataka na obje replike, a da ih ne izbacujete na master i bez gašenja? Dovoljno jednostavno, koristeći naredbu "pokreni slave do ".
Dakle, imamo master sa bazama podataka testdb1 i testdb2, koje se repliciraju na replika-1 i replika-2 replike. Postavimo replikaciju obje baze podataka na repliku-1 bez zaustavljanja mastera.
Zaustavite replikaciju na replici-2 naredbom i zapamtite poziciju mastera:
[email protected]> STOP SLAVE;
[email protected]> PRIKAŽI SLAVE STATUS\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Poz: 231

Kreirajmo dump testdb2 baze podataka i nastavimo replikaciju (tu su se završile manipulacije sa replikom-2). Dump će biti vraćen na repliku-1.

Situacija na replici-1 je sljedeća: baza podataka testdb1 nalazi se na jednoj poziciji mastera i nastavlja da se replicira, baza podataka testdb2 je vraćena iz dumpa sa druge pozicije. Sinhronizujemo ih.

Zaustavite replikaciju i zapamtite poziciju mastera:
[email protected]> STOP SLAVE;
[email protected]> PRIKAŽI SLAVE STATUS\G
Exec_Master_Log_Poz: 501

Uvjerite se da u konfiguraciji na replici-1 odjeljak sadrži ime druge baze podataka:
replicate-do-db=testdb2

Ponovo pokrenite MySQL da bi promjene konfiguracije stupile na snagu. Usput, mogli biste jednostavno ponovo pokrenuti MySQL bez zaustavljanja replikacije - iz dnevnika bismo saznali na kojoj poziciji je zaustavljena glavna replikacija.

Sada replicirajmo sa pozicije na kojoj je replika-2 suspendovana na poziciju na kojoj smo upravo obustavili replikaciju:
[email protected]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replikacija", MASTER_PASSWORD = "lozinka", MASTER_LOG_FILE = "mysql-bin.000015", MASTER_LOG_POS = 231;
[email protected]> pokreni slave dok MASTER_LOG_FILE = "mysql-bin.000016 ", MASTER_LOG_POS = 501;

Replikacija će se završiti čim replika dostigne navedenu poziciju u sekciji do, nakon čega će obje naše baze podataka odgovarati istoj master poziciji (gdje smo zaustavili replikaciju na replici-1). Uvjerimo se u ovo:
[email protected]> PRIKAŽI SLAVE STATUS\G
[email protected]> START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Poz: 501

Dodajmo imena obje baze podataka u konfiguraciju na replici-1 u odjeljku:
replicate-do-db=testdb1
replicate-do-db=testdb2

Važno: svaka baza podataka mora biti navedena u posebnom redu.
Ponovo pokrenite MySQL i nastavite replikaciju:
[email protected]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replikacija", MASTER_PASSWORD = "lozinka", MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;
Nakon što replika-1 sustigne master, sadržaj njihove baze podataka će biti identičan. Možete spojiti bazu podataka na replici-2 ili na sličan način, ili tako što ćete napraviti puni dump replike-1.

Majstor kastinga i replika

Možda će biti potrebno prebaciti repliku u glavni način rada, na primjer, ako master ne uspije ili kada se izvodi a tehnički rad. Da biste omogućili takav prekidač, morate konfigurirati repliku kao master ili je napraviti pasivni gospodar.

Omogućite binarno evidentiranje (pored relejnih binlogova) u konfiguraciji u odjeljku:
log-bin = /var/lib/mysql/mysql-bin

I dodajte korisnika za replikaciju:
[email protected]> ODOBRITE slave replikacije NA 'testdb'.* TO 'replication'@'192.168.1.101′ IDENTIFIKOVANO "lozinkom";

Pasivni master se replicira kao obična replika, ali također kreira binarne dnevnike - to jest, možemo započeti replikaciju iz njega. Uvjerimo se u to naredbom "show master status":
[email protected]> PRIKAŽI MASTER STATUS\G
Fajl: mysql-bin.000001
Pozicija: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Sada, da biste pasivni master doveli u aktivni mod, morate zaustaviti replikaciju na njemu i omogućiti replikaciju na bivšem aktivnom masteru. Kako biste osigurali da se podaci ne izgube u trenutku prebacivanja, aktivni majstor mora biti zaključan za pisanje.
[email protected]> FLUSH TABLE SA ZAKLJUČAVANJEM ZA ČITANJE
[email protected]> POSTAVI GLOBALNO read_only = ON;
[email protected]> STOP SLAVE;
[email protected]> PRIKAŽI MASTER STATUS;
Fajl: mysql-bin.000001
Pozicija: 61
[email protected]> CHANGE MASTER TO MASTER_HOST = "192.168.1.102", MASTER_USER = "replikacija", MASTER_PASSWORD = "lozinka", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 61;
[email protected]> start slave;
To je to, pa smo promijenili aktivni master. Možete ukloniti bravu sa bivšeg majstora.

Zaključak

Pokrili smo malo o tome kako postaviti replikaciju u MySQL i izvesti neke osnovne operacije. Nažalost, sljedeća važna pitanja ostala su izvan okvira članka:

  • eliminacija pojedinačnih tačaka kvara (SPF, Single Points of Failure). Kada se koristi samo jedan MySQL server, njegov kvar je doveo do kvara cijelog sistema. Kada koristite više servera, kvar bilo kog od njih će rezultirati kvarom sistema, osim ako se za to posebno ne pobrinemo. Moramo osigurati rukovanje situacijom kvara glavnog i replika. Jedan od postojećih alata - MMM, međutim, treba doraditi fajlom.
  • balansiranje opterećenja. Kada koristimo više replika, bilo bi zgodno da koristimo transparentan mehanizam za balansiranje, posebno ako performanse replika nisu iste. Pod Linuxom je moguće koristiti standardno rješenje - LVS.
  • mijenja logiku aplikacije. U idealnom slučaju, zahtjevi za čitanje podataka trebali bi se slati replikama, a promjene na master. Međutim, zbog mogućeg zaostatka replika, takva shema je često neizvediva i potrebno je identificirati takve zahtjeve za čitanje koje još treba izvršiti na masteru.
Nadam se da ću rasvijetliti ova pitanja u budućim člancima.
Hvala vam na pažnji!

Replikacija podataka MySQL omogućava vam da imate tačnu kopiju baze podataka sa jednog servera - glavnog servera (master server) na jednom ili više drugih servera (slave server). Po defaultu, Mysql replikacija je asinhrona.
Što znači da glavni server ni na koji način ne kontroliše i ne zna da li slave serveri čitaju log fajl i da li to rade ispravno.
Postoje i druge vrste sinhronizacije, sinhrone i polusinhrone, gdje se ovi procesi kontroliraju.
Ovisno o postavkama, možete replicirati i cijele baze podataka i pojedinačne tablice baze podataka.

Za šta možete koristiti replikaciju:
1. Balansiranje opterećenja između hostova radi poboljšanja performansi.
U takvoj šemi, glavni čvor će obavljati operacije čitanja i pisanja, čvorovi koji imaju pretplatu na glavnom čvoru će pružiti bazu za čitanje, tako da ćemo glavni server rasteretiti iz operacija čitanja
2. Sigurnost podataka i lakoća održavanja, budući da slave čvor sadrži podatke samo za čitanje, tada će promjene podataka na pretplatniku biti ograničene, lakoća održavanja - mogućnost pokretanja procesa koji opslužuju bazu bez prekidanja aplikacija
3. Distribucija podataka na velikim udaljenostima. Možete kreirati kopiju podataka na bilo kojem hostu, bez obzira na njegovu lokaciju
MySQL podržava sljedeće metode replikacije:
Tradicionalna – metoda je zasnovana na repliciranju događaja iz binarne datoteke evidencije mastera i zahtijeva datoteke evidencije. Položaji između glavnog i slave servera moraju biti sinkronizirani.
Metoda koja koristi globalne GTID-ove (transakciona metoda)
MySQL podržava sljedeće vrste sinhronizacije:
asinhrona (jednosmjerna sinhronizacija)
polusinhroni (djelimična kontrola pretplatnika)
sinhroni (potpuna kontrola pretplatnika)

Postavljanje replikacije Mysql baze podataka tradicionalnim metodom

Princip rada
Glavni server sadrži bin log datoteke koje bilježe sve promjene koje se događaju u glavnoj bazi podataka, datoteka koja opisuje imena bin datoteke, kao i poziciju u logu gdje su zadnji master podaci upisani
Slave čvor prima podatke od mastera koji imaju informacije o imenima bin datoteke i poziciju u log datoteci.

Podešavanje čarobnjaka
my.ini mora sadržavati jedinstveni identifikator - broj od 1 do 2 na stepen od 32 - 1, server-id.
Podrazumevano, server-id=0, što znači da se ne prihvataju pretplate sa nizvodnih servera

log-bin=mysql-bin
server-id=1

Ove dvije linije su dovoljne za pokretanje
Napomena: međutim, ako se koristi InnoDB, dodatno se preporučuje dodavanje
innodb_flush_log_at_trx_commit=1
sync_binlog=1

I morate provjeriti da mogućnost rada s mrežom nije onemogućena, parametar skip-networking nije postavljen
Slave server se povezuje sa glavnim serverom koristeći korisničko ime i lozinku, tako da prvo kreiramo korisnika na glavnom serveru
CREATE USER [email protected]%.mydomain.com IDENTIFIKOVANO OD slavepass;
GRANT REPLICATION SLAVE NA *.* TO [email protected]%.mydomain.com;

Gledamo stanje
PRIKAŽI MASTER STATUS
Ako je procedura za kreiranje binarnih dnevnika već pokrenuta, tada za InnoDB tabele prvo morate zaključati tabele u jednoj od sesija
FLUSH TABLE SA READ LOCK;
Ako izađete iz sesije, zaključavanje stola se automatski oslobađa.
U drugoj sesiji dobijte vrijednosti imena bin logo i pozicija
Obje vrijednosti predstavljaju koordinate replikacije na kojima stanje pripravnosti treba početi čitati iz datoteke na ispravnoj lokaciji kako bi započelo replikaciju.
Sljedeći korak ovisi o tome da li postoje podaci na slave serveru, podaci sa mastera
Ako jesu, onda ostavljamo tabele zaključane, stvaramo dump(ovo je preporučeni način kada koristite InnoDB)
Tip baze podataka možete saznati pomoću naredbe
mysqlshow -u mysql_user -p -i ime-baze podataka
Ako je baza podataka pohranjena u binarnim datotekama, onda se one mogu kopirati sa glavnog na slave server
Doing dump
mysqldump --sve-baze podataka --master-data dbdump.db
da odaberete baze mysqldump --baze podataka --master-data dbdump.db
parametar master-data, automatski dodan PROMIJENI GLASNOG U na slave čvoru, ako parametar nije dodan, tada je potrebno ručno zaključati sve tabele u sesiji
Uklonite bravu
UNLOCK TABLES;

Podešavanje slave čvora A
Dodaj my.ini server-id je privatan od glavnog i od drugih čvorova

server-id=2

Kreirajte pretplatu
PROMIJENI GLASNOG U
MASTER_HOST=master_host_name,
MASTER_USER=replication_user_name,
MASTER_PASSWORD=lozinka_replikacije,
MASTER_LOG_FILE=ime_zapisa_log_datoteke,
MASTER_LOG_POS=snimljena_log_pozicija;

Prilikom postavljanja replikacije s postojećim podacima, morate prenijeti snimak s glavnog na podređeni prije početka replikacije
Koristimo mysqldump
1.Pokrenite slave čvor koristeći --skip-slave-start opcija da se ne pokrene replikacija
2.Uvezite dump datoteku
mysql fulldb.dump
3. Pokrenite proces pretplate
START SLAVE;
Provjera statusa replikacije
PRIKAŽI SLAVE STATUS\G
Slave_IO_State: - trenutno stanje slave uređaja
Slave_IO_Running: - je tok podataka koji se čita sa mastera
Slave_SQL_Running: - da li rade sql upiti, mora biti da

Primjer Konfigurirajmo glavni (vodeći) server - ip 11.11.11.10 V my.ini
[
mysqld] log-bin=mysql-bin server-id=1
Kreirajte korisnika mysql -u root -p GRANT REPLICATION SLAVE NA *.* TO [email protected]% IDENTIFIKOVANO lozinkom; FLUSH PRIVILEGES;
Zatim zaključajte sve tabele u bazi podataka FLUSH TABLE SA READ LOCK;
Gledamo status PRIKAŽI MASTER STATUS; Pamtimo naziv datoteke i poziciju, koristit ćemo ih na Slave serveru za pretplatu

Na Slave B my.ini
log-bin=mysql-bin server-id=2

Kreirajte pretplatu PROMIJENI MASTER U MASTER_HOST=11.11.11.10, MASTER_PORT=3306,
MASTER_USER=replika, MASTER_PASSWORD=lozinka,
MASTER_LOG_FILE=server-mysql-bin.000002,
MASTER_LOG_POS=1151664, MASTER_CONNECT_RETRY=10;
START SLAVE;
Status replikacije PRIKAŽI SLAVE STATUS\G

mob_info