itthon PC szoftver Replikáció beállítása a mysql admin segítségével. Mi az a MySQL MASTER SLAVE replikáció és mire használják. MySQL replikációs beállítások

Replikáció beállítása a mysql admin segítségével. Mi az a MySQL MASTER SLAVE replikáció és mire használják. MySQL replikációs beállítások

A MySQL replikáció beállítása a varázsló leállítása nélkül.

1. Fő szerver beállítása:

Megnézzük, hol kell lennie a konfigurációnak.

# ps aux | grep my.cnf

mysql 51189 0,0 0,0 17064 1912 - 18:35 0:00,05 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file= /var/db/mysql/my.cnf--user=mysql --datadir=/var/db/mysql

Ha a fájl hiányzik, kimásolhatja a példából.

# cp /usr/local/share/mysql/my-small.cnf /var/db/mysql/my.cnf

Vagy hozzon létre egy üreset.

# érintse meg a /var/db/mysql/my.cnf gombot

A szakaszban létrehozott konfigurációhoz mi írunk.

#Egyedi szerverazonosító. A mesternek a replika alatt kell lennie, és nem duplikálható

szerver - azonosító = 1

#napló formátum

binlog - formátum = vegyes

#Útvonal, ahol a binlog található (Alapértelmezés szerint egy napló mérete 1g)

#Binlog tárolási idő

expire_logs_days = 30

replikátum-do-db=adatbázis_1

replikátum-do-db=adatbázis_2

replikátum-do-db=adatbázis_3

replikátum-do-db=adatbázis_4

#Hibanapló

Ezt szerkesztéssel zárjuk, és újraindítjuk a MySQL-t egy új konfigurációval.

# /usr/local/etc/rc.d/mysql-server újraindítás

Most hozzá kell adnia egy felhasználót a Slave szerver mesteréhez.

A replikációhoz a REPLICATION SLAVE jogok elegendőek. Jelentkezzen be root felhasználóként a MySQL szerverre.

# mysql -uroot -p

Felhasználó létrehozása:

mysql> használd a mysql-t;

mysql>FELHASZNÁLÓ LÉTREHOZÁSA 'replica'@'ip_address_slave_server';

mysql>GRANT REPLIKÁCIÓS SLAVE BE*.* TO 'replica'@'ip_address_slave_server' AZONOSÍTVA 'password_for_user_replica';

Most vagy újraindíthatja a szervert, vagy kimondhatja

mysql>FLUSH JOGOSULTSÁGOK;

2. Hozzon létre egy kiíratot a szükséges adatbázisokból:

Minden alap.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -A > /usr/home/Timur/dump.sql

bizonyos alapok.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -B DATABASE DATABASE1 DATABASE2 DATABASE3 > /usr/home/Timur/dump .sql

3. Megnézzük, hogy melyik binlogot használjuk, és mi a helyzete:

# head -n80 /usr/home/Timur/dump.sql | grep "MASTER_LOG_POS"

- MESTER MÓDOSÍTÁSA MASTER_LOG_FILE-RE=' mysql-bin.000049‘,MASTER_LOG_POS= 107 ;

Kérlek írd le!!!

4. Kattintson a kiíratásra, és vigye át a Slave szerverre:

# gzip /usr/home/Timur/dump.sql

Mi átutaljuk.

# scp /usr/home/Timur/dump.sql.gz _address_slave_server:/usr/home/Timur

5. A slave szerver (my.cnf) beállítása.

szerverazonosító=2

binlog - formátum = vegyes

log-bin=/var/log/mysql/mysql-bin

expire_logs_days = 30

#Binglog Slave

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

#Utasítja a lefelé irányuló kiszolgálót, hogy rögzítse a lefelé irányuló kiszolgálón előforduló frissítéseket egy bináris naplóban. Ez az opció alapértelmezés szerint le van tiltva. Engedélyezni kell, ha a szolgakiszolgálókat láncba szeretné kötni.

log-slave-updates=1

#Állítsa be az adatbázisokat írásvédettre. Ez a lehetőség szuperfelhasználókra nem vonatkozik!!!

csak olvasható = 1

#Az ismétlődő bejegyzések kihagyása. Miután a Seconds_Behind_Master 0 lesz, írd ki a megjegyzéseket, és indítsd újra a SLAVE-ot

slave-skip-errors=all

# Adja meg, mely adatbázisokat kell replikálnunk

replikátum-do-db=adatbázis_1

replikátum-do-db=adatbázis_2

replikátum-do-db=adatbázis_3

replikátum-do-db=adatbázis_4

#Hibanapló

log-error=/var/log/mysql/mysqld-error.log

#Hogy a Slave ne induljon el, amikor a szerver elindul. Kézzel is elindíthatja START SLAVE;

skip-slave-start = Be

Indítsa újra a szervert (MySQL).

6. Töltse fel a kiíratást a Slave-be, és indítsa el a replikációt:

Csomagoljuk ki.

# gunzip /usr/local/Timur/dump.sql.gz

A szeméttelep betöltése.

# mysql -uroot -p< /usr/local/Timur/dump.sql

Megmondjuk a Slave-nek, hogy honnan kell lekérni az adatokat, és elkezdjük. A MASTER_LOG_FILE és a MASTER_LOG_POS átveszi, amit felírtunk, amikor a bázisokat kiíratja a Masterre 😉

mysql>MESTER MÓDOSÍTÁSA A MASTER_HOST-RA= ‘<>' , MASTER_USER = 'replica' , MASTER_PASSWORD = 'password_for_user_replica', MASTER_LOG_FILE= ‘mysql-bin.000049‘ , MASTER_LOG_POS = 107 ; START SLAVE ;

Csapatként nézünk SLAVE ÁLLAPOT MUTATÁSA\G Mind elkezdtük?

mysql> SLAVE ÁLLAPOT MUTATÁSA\G
********************************** 1. sor ****************** **********
Slave_IO_State: Várakozás, hogy a mester elküldje az eseményt
Master_Host: Ez a főkiszolgáló címe
Master_User: replika
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000049
Read_Master_Log_Pos: 1919771
Relay_Log_File: mysql-relay.000050
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000049
Slave_IO_Running: Igen
Slave_SQL_Running: Igen
Replicate_Do_DB: adatbázis_1,adatbázis_2,adatbázis_3,adatbázis_4,adatbázis_1,adatbázis_2,adatbázis_3,adatbázis_4
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1919771
Relay_Log_Space: 3125
Until_Condition: Nincs
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Nem
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: Nem
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 5
1 sor a készletben (0,00 mp)

Minden beindult.

Növekednie kell Exec_Master_Log_Pos: 1919771

Ha hiba történik, kihagyhatja a következő futtatásával:

mysql> STOP SLAVE;GLOBÁLIS SQL_SLAVE_SKIP_COUNTER BEÁLLÍTÁSA = 1;SZOLGÁLTATÁS INDÍTÁSA;

Nemrég felkértek, hogy beszéljek róla replikáció a MySQL-ben. Úgy döntöttem, hogy ez a téma sokak számára hasznos lehet, ezért ebben a cikkben arról fogok beszélni, hogyan mi a replikáció a MySQL-ben, mikor van rá szükség és hogyan kell beállítani.

A replikáció fő feladata az egyesítsék több szerver erejét. Tegyük fel, hogy a webhelyén van egy dedikált szerver, de idővel nagyon látogatott lesz, és már nem bírja a terhelést. Ennek eredményeként a fékek és a rendszeres szerverösszeomlás kezdődik. A legegyszerűbb módja egy erősebb szerver vásárlása, és a legtöbben ezt teszik. De előbb-utóbb eljön az a pillanat, amikor a szerver árának emelésének költsége nem felel meg a teljesítmény növekedésének, így jövedelmezőbb a vásárlás 2 különböző szerverek kevesebb pénzért.

Ennek eredményeként a bázisod egyszerre két szerveren lesz. Ha az egyik fő szerver (más néven a fő) már nem tud megbirkózni, akkor át kell váltani a tartalékra.

Összes az adatbázis-frissítési kérések mindig a fő kiszolgálóhoz érkeznek. A master szerver frissítése után az erről szóló információkat egy külön fájlba helyezi, ahonnan minden információt a slave szerverek veszik. De a fetch műveletek, amelyek általában többségben vannak, és ezek a leglassabbak, már átvihetők a slave szerverekre, mivel az adatok ott-ott ugyanazok.

Most találjuk ki hogyan kell beállítani a replikációt mysql-ben:

Telepítse a legtöbbet a MySQL legújabb verziói minden szerverre.
Hozzon létre egy felhasználót a főkiszolgálón a jogosultsággal CSERE SLAVE. Címként, ahonnan csatlakozhat, adja meg a " összes".
Állítsa le az összes szervert.
A beállításokban MySQL(fájlban my.cnf) Fejezetben add hozzá a következő sorokat: log-bin
server-id=1 Kérjük, vegye figyelembe szerver-azonosító minden szerveren eltérőnek kell lennie. Valójában ez különbözteti meg az egyik szervert a másiktól.
A slave szervereken adja hozzá a beállításokat MySQL a következő sorokat: master-host=master_host_name
master-user=bejelentkezés_létrehozott_felhasználó
master-password=a_létrehozott_felhasználó jelszava
master-port=port_to_connect_to_master_server
szerver-azonosító=ez_szolga_kiszolgáló_azonosítója
Tegye át az összes alapot a mester szervertől a szolgákig.
Fuss master szerver, majd az összes slave.

Jelentésem azoknak szól, akik ismerik a "replikáció" szót, még azt is tudják, hogy a MySQL-ben van, és talán egyszer beállították, 15 percet töltöttek, és elfelejtették. Semmi többet nem tudnak róla.

A jelentés nem:

Mindez az interneten van, nincs értelme a szintaxis elemzésének.

Kicsit átnézzük az elméletet, megpróbáljuk elmagyarázni, hogyan is működik belül ez az egész, és utána háromszoros erővel merülhetsz bele a dokumentációba.

Mi a replikáció elvileg? Ez a módosítások másolata. Van egy példányunk az adatbázisból, valamiért szeretnénk egy másik példányt.

A replikáció számos formában létezik. Különböző összehasonlítási tengelyek:

a változások szinkronizálási foka (szinkron, aszinkron, félszinkron);
rögzítő szerverek száma (M/S, M/M);
formátum módosítása (kimutatás alapú (SBR), soralapú (RBR), vegyes);
elméletileg az átviteli modell megváltoztatása (push, pull).

Vicces tény, hogy ha egy kicsit belegondolunk, a replikáció elméletileg alapvető okokból segít a csak olvasható skálázásban. Itt van egy kissé nem nyilvánvaló következtetés. Ennek az az oka, hogy ha bizonyos számú módosítást kell önteni ugyanazon az adatmásolaton, és az adatoknak ezt a másolatát ugyanaz a szerver szolgálja ki, akkor ez a szerver képes másodpercenként bizonyos számú frissítést kibírni, és nincs több feltöltés. A szerver másodpercenként 1000 rekordot képes frissíteni, 2000 rekordot viszont nem. Mi változik attól a ténytől, hogy egy replikát teszel erre a szerverre, függetlenül attól, hogy mester-szolga vagy mester-mester módban van? Képes lesz a második ezer frissítést erre a megjegyzésre önteni? A helyes válasz: nem.

Természetesen master-master módban további frissítéseket is tud majd önteni egy replikára, más dolog az, hogy amikor nem érkeznek meg az első mesterhez, és megpróbálnak második ezer frissítést végrehajtani rajta, akkor nem lesz elég kapacitás. Meg kell érteni és nem összekeverni két szinte nyilvánvaló pontot, hogy a replikáció egy dologról szól, hanem arról, hogy az adatokat fel kell osztani, és ha nem az olvasást, hanem az írást kell skálázni, akkor csináljon valami mást, és a replikáció nem igazán fogja menteni a .

Azok. a replikáció inkább az olvasásról szól.

A szinkronizálásról.

A szinkronizálás a rendelkezésre állás és az elérhetőség garanciája. Rendelkezésre állás abban az értelemben, hogy a véglegesítésünk lejárt, a tranzakció véglegesítve, minden rendben van, ezek az adatok a fürt egy vagy több csomópontja számára láthatóak, részt vehetnek a következő kérésekben. Az elérhetőség az, hogy az adatok elvileg több szerveren vannak, de talán a tranzakció nem veszett el, és nem elérhető.

Itt nincs a „sikeresen befejeződött, mit jelent ez?” refrén. A szinkron véglegesítés azt jelenti, hogy a helyi és távoli véglegesítésünk (legalább egy replikán) véget ért, azaz. leköteleztünk valamit a gépen, ha van szinkron replikációs módunk, akkor ezek a változtatások sikeresen véglegesítésre kerülnek, a helyi gépen láthatók a későbbi kéréseknél, távoli gépen (legalább az egyiken) is láthatóak. Ez azt jelenti, hogy ha standard kontingencia következik be, pl. feszítővas berepült az egyik szerverbe, és mindent átszúrt - a processzortól a csavarig, majd ennek ellenére az adatokat nemcsak egy távoli szerverre másolják, hanem azonnal, további késedelem nélkül, részt venni a későbbi tranzakciókban.

Ez mind általános terminológia, és semmi köze a MySQL-hez. Minden elosztott rendszerben ez így lesz elrendezve.

Aszinkron véglegesítés – nincs további garancia, ha szerencséd van.

A félszinkron commit egy jó köztes megoldás, ilyenkor a helyi commit lejárt, a távoli commitról nem tudunk semmit - lehet, hogy a rabszolga utolérte, vagy nem, de legalább megerősítést kaptunk, hogy ezek az adatok van valahol, akkor elrepültek, ott elfogadták, és valószínűleg feliratkoztak is.

A rögzítéshez szükséges szerverről. Melyek a replikáció típusai.

Master-slave klasszikus, az összes változtatást egy szerverre öntik, majd a replikák tömegére másolják.

Igaz mester-mester - amikor a változások egyszerre özönlenek egy csomó mesterbe, és valahogy egyikről a másikra, a másikról a harmadikra és mindannyiuk között, ami számos örömet és számos automatikus problémát okoz. . Nyilvánvaló, hogy ha van egy "arany másolata" és több replikája van belőle, amelyeknek (ideális esetben azonnal) meg kell ismételnie ezt az "arany másolatot", akkor minden viszonylag egyszerű az adatok oda-vissza továbbítása és mit kell tennie. minden egyes példányon. Érdekes "fejfájás" kezdődik a master-masterrel, és hangsúlyozom, nem kifejezetten a MySQL esetében, hanem pusztán elméleti. Mi lenne, ha egyszerre két csomóponton ugyanazt a tranzakciót próbálnák lefuttatni, amely ugyanazokat az adatokat változtatja meg, sőt, a példa egyszerűsége kedvéért különböző módon módosítja azokat. Nyilvánvaló, hogy ezt a két változtatást nem alkalmazhatjuk egyszerre. Abban a pillanatban, amikor elkezdünk valamit megváltoztatni az egyik csomóponton, a második csomóponton még mindig nincs semmi. Konfliktus. Az egyik tranzakciót vissza kell vonni. Ezenkívül külön "táncok" kezdődnek az órák egyeztetésével stb.

Egy érdekes pont – még annak a lehetőségnek is, amikor az összes változtatást az összes mestertől megkapja, fokozatosan mindenhol el kell terjednie, ez még mindig nem segít ugyanazon az írási sávszélességen. Kár, de ez van.

Egy jó lehetőség az úgynevezett "Master-slave + útválasztási kérések". Annyiban kellemes, hogy könnyen belül programozható, van egy főpéldányod, azt sokszorosítod egy csomó gépre. Ez sokkal egyszerűbb, mint egy master-master környezetben, ahol mindenki egyenlő, stb., de az alkalmazás szempontjából még mindig úgy tűnik, hogy sok írási pontod van. Bármely csomóponthoz érkezel, az tudja, hova kell irányítani, és sikeresen vezet. Nos, a leolvasások méretezhetők – ez a replikáció boldogsága. Minden pontból mindig és mindig olvashatsz.

Most közelebb az adatbázisokhoz, a "varázslatos" utasítás alapú, sor alapú formátumokhoz stb. A változtatások formátumáról.

Mit lehet tenni? Elküldheti magukat a kéréseket, vagy csak a módosított sorokat küldheti el. Hangsúlyozom, hogy bár még nem merültünk el a MySQL vadjaiban, minden olyan DBMS, amely nagy (vagy nem túl) számú változtatást generáló lekérdezéseket tartalmaz, képes erre. sok adat frissítése. Felmerül a kérdés – mit fogunk pontosan másolni? A kéréseket oda-vissza mozgathatja a csomópontok között, vagy csak a módosított adatokat. Érdekes módon így és úgy nagyon rossz! Még mindig megpróbálhatja keverni.

Még egy pont a replikációkról. Az elosztási modellről. Valószínűleg valahol még nem halt ki teljesen a Push alapú modell, amikor a változtatásokat végrehajtó csomópont köteles azokat elküldeni az összes többi csomópontnak. Az "s" állapot programozása és nyomon követése szempontjából ez még mindig gondot okoz. Ezért Pull-alapú szabályok. Egy adott csomópontról történő frissítéseket sokkal könnyebb programozni, mint a replikák kaotikus fürtjének megfigyelését egy csomóponton.

Néhány általános kifejezés bevezetésre került. Térjünk át arra, hogyan csináltuk ezt a MySQL-ben.

A MySQL önmagában is átverés. Létezik egy MySQL nevű logikai réteg, amely az adattárolástól kezdve mindenféle általános és elszigetelt esettel foglalkozik - hálózat, optimalizáló, gyorsítótár, stb. Az adatok tárolásáért felelős konkrét fizikai réteg egy emelettel lejjebb található. Több beépített, vannak beépülő modulok. De még a beépített MyISAM, InnoDB stb. a fizikai síkon élni. A beépülő modul architektúrája klassz, felvehetsz egy új motort, de azonnal feltűnik némi nem optimalitás. Elvileg a tranzakciós előreírási napló "és (WAL), amelyet egyébként a fizikai tárolóréteg ír, jó lenne replikációhoz használni, és ha a rendszer tudja, hogy van egy bizonyos fizikai réteg, vagy elég jól kapcsolódik ehhez. fizikai réteg , akkor lehetne logikai szinten nem külön naplót írni, hanem ugyanazt a WAL-t használni... De a MySQL-ben ez fogalmilag lehetetlen, vagy ha a PSE-ben megváltoztatod az interfészt úgy, hogy koncepcionálisan lehetségessé váljon , akkor sok munka lesz.

A replikáció a MySQL szintjén valósul meg. Van ebben egy jó dolog - a tárolómotor mélyen belső adatainak formájában lévő egy napló mellett van egy többé-kevésbé logikus napló, talán az utasítás szintjén, amelyet ettől a motortól külön karbantartanak. az "extra" biztonság stb. plusz, mivel belül nincsenek korlátozások, bármiféle kreatívot csinálhatsz, mint például a motort menet közben.

A MySQL 4.1-ben bevezetett kifejezésekkel valósult meg: master-slave, pull alapú, szigorúan aszinkron és szigorúan SBR. Ha az ősi 4.x korszakban ragadtál, akkor valószínűleg bajban vagy. Az 5.x verziók már majdnem 10 évesek – ideje lenne frissíteni.

Vicces követni azokat a változatokat, ahogy az emberek rátapostak mindenféle gereblyére, és amikor nem lehetett mit tenni, új gereblyét csavartak ezekre a gereblyékre, hogy ne legyen olyan fájdalmas az élet. Tehát az 5.1-es verzióban becsavarták az RBR-t, hogy kompenzálják az SBR elkerülhetetlen problémáit, és becsavarták a kevert módot. Az 5.6-os verzióban még néhány szép dolog került be: félszinkron, késleltetett slave, GTID.

Még egy pillanat. Mivel a MySQL egyrészt egyfajta közös réteg, másrészt egy rakás bedugható motor, beleértve a beépítetteket is, egy bizonyos pillanattól jön egy isteni NDB klaszter, amiről menőt beszélnek. Létezik egy teljesen szinkron master-master replikáció, egy nagyon hozzáférhető, memórián belüli adatbázis... De van egy figyelmeztetés – amint elkezdi keresni azokat az embereket, akik az NDB-fürtöt használják a termelésben, nagyon kevés ilyen ember van.

Mit tesz a mester, ha úgy dönt, hogy engedélyezi a replikációt? Elég sok extra mozgás történik a mesteren. Szokás szerint a hálózaton keresztül fogadjuk a kéréseket, elemezzük azokat, lefuttatjuk a tranzakciókat, javítjuk őket stb. Ezen túlmenően a MySQL logikai szintjén a mester bináris naplót kezd vezetni - egy fájlt, nem egészen egy szöveges fájlt, amelybe az összes módosítás belekerül. A mester ezeket a naplókat a hálózaton keresztül is elküldheti. Minden nagyon egyszerű, és úgy tűnik, működik.

Mit csinál a Slave? Jobb, ha nem küldi el a változtatásokat a slave-nek, mert valami érthetetlen dologba kerülhet. A rabszolgának van még egy kis dolga. Amellett, hogy egy további naplót vezet, és kérésre kiküldi, van egy szál is, amely egy távoli mesterhez megy, talán nem is egy, és letölti a bináris naplót "és onnan. Megoldás" menjünk több távoli mesterhez és onnan. különböző naplók letöltése" kétértelmű. Egyrészt nem rossz, másrészt kiderül, hogy azonnali eltérés. Egyszerűen lehetetlen fizikailag fájlokat másolni SCP-vel, már kiderül egy napló a szerveren, saját pozíciói vannak, lokálisan a rács mentén húzzuk, külön naplóba rakjuk, egy külön szál is fut és próbálja lejátszani ezeket a helyi naplókat. A legpokolibb dolog szerintem az, hogy az 5.6-os verzióig , egy adott tranzakció azonosítása a naplóban a fájlnév és a masteren lévő pozíció alapján történt.Érdekes megoldás.

Íme az írási útvonal, amelyet egy egyszerű beszúrás replikáció nélkül bejár:

Az alkalmazás csatlakozik a szerverhez, tedd egy táblázatba és tedd le.

A replikációnak számos további lépése van:

Az író alkalmazás ugyanígy megy a masterhez, de ezen felül ezek az adatok ilyen vagy olyan formában bekerülnek a bináris naplóba, majd a hálózaton keresztül letöltődnek a közvetítőnaplóba, majd a relénaplóból "és fokozatosan visszajátszik (ha szerencsénk van és a slave nem marad le, azonnal visszajátsszák) a slave-en lévő táblázatba, utána minden elérhető az olvasóban.

Az, hogy konkrétan mi kerül be a bináris naplóba, az SBR/RBR/vegyes beállításoktól függ. Honnan nő ez az egész? Tegyünk úgy, mintha egy adatbázis lennénk. Egy egyszerű kérést kaptunk „egy adott rekord frissítése” – UPDATE users SET x=123 WHERE id=456

Mit kell írni a bináris naplóba? Alapvetően teljesen mindegy. Rögzíthetünk egy rövid lekérdezést, vagy (és egy rekordot frissített) valamilyen módon rögzíthetjük a változást ilyen vagy olyan formában.

Egy másik helyzet. Képzeljük el, hogy ugyanazt a kérést kaptuk, ami önmagában kicsi, de sok adatot megváltoztat - UPDATE users SET bonus=bonus+100

Itt egyetlen hatékony lehetőség van - magát a kérést megírni, mert a kérés pontosan 32 bájt, és tetszőleges számú rekordot tud frissíteni - 1000, 100 000, 1 000 000, amennyit csak akar... Nem hatékony a a megváltozott rekordokat írja be a naplóba.

És mi történik, ha egy ilyen egyszerű kérést beírunk a naplóba, hogy "tiltsuk le az összes olyan felhasználót, aki hosszú ideje nem jelentkezett be" - UPDATE users SET enabled=1 WHERE last_login

Hirtelen horror támad. A probléma az, hogy ha magát a kérést ideálisan replikáljuk, akkor először is, az idő soha nem szinkron két csomópont között, ráadásul mivel a felvételi út olyan hosszú, az újrajátszáskor ez a "MOST" szétszórni. A replika hirtelen nem ért egyet a mesterrel, és minden későbbi változtatás formálisan már nem biztonságos, bármihez vezethet.

Általánosságban elmondható, hogy az ilyen kérésekhez, függetlenül a megváltozott adatmennyiségtől, ideális esetben magukat a sorokat kell másolni. Ebben a konkrét esetben nem másolhatja át magukat a sorokat, hanem rögzítheti az állandót, és nem "MOST" írhat a naplóba, hanem egy adott időbélyeget, amelyet a mester használt a replikáció idején.

Érdekes tények, amelyeket véletlenül megtudhat, miközben a replikáció vadonjába merül. Sőt, sekélyen is merülhetsz – azonnal belefutsz hozzájuk. Véletlenszerű sorrendben ezek a következők:

a master többszálas, de a slave nem. Nyilvánvaló, hogy ha a mester a terhelést négy magba önti, a slave-nek nincs ideje ezt a terhelést egy magba önteni. Minden elég rossz;
a slave állapotot a mesterfájlban lévő pozíciónév határozza meg. Gondoljunk csak bele - a fürt egyik csomópontjának állapotát a fájl neve és a fürt másik csomópontján lévő pozíció határozza meg, amellyel bármi megtörténhet, bármilyen okból!
RBR "megmentése". Kiderült, hogy alapértelmezés szerint a teljes sor előtt/utána képek vannak odaírva, pl. megváltoztattunk egy oszlopot egy öt kilobájtos sorban, hoppá! - 10 Kb forgalom és 20-40 overhead byte soronként, akkor op! - az előző verzió ilyen vastag vonala megy, op! – megy ennek a verziónak az új értékekkel utána. Az adminisztrátorok kórusban üvöltenek! Néhány perverz alkalmazás szempontjából azonban egyszerűen fantasztikus, mint például a külső olvasók, amelyek megpróbálnak rácsatlakozni a MySQL szerverre, adatokat gyűjtenek onnan, és csinálnak vele valamit, például egy teljes szövegű indexbe töltik be. Bármilyen rossz is az adatbázis-adminisztráció szempontjából, amelyben egy három bájtos változtatás 10 Kb forgalmat generál a csavaron, majd 10 Kb hálózati forgalmat szolgánként, ugyanolyan jó minden teljes szöveges kereséshez. típusú rendszerek, mint például a Sphinx, amelyeknek nincs helyi másolata az adatokról, és nem kívánják a MySQL-t a semmiből megvalósítani. A MySQL 5.6-ban megvalósították és elkészítették a binlog_row_image-et (de alapértelmezés szerint full, nem minimal vagy noblob).

Röviden: nincs minden ravaszul elrendezve - egy bot, egy kötél, egy rönk, a második tuskó. És még ebben a naplóban is elég viccesek a "gyermekkori" betegségek:

Egy olyan személy számára, aki két napig replikációt használ, mindez ijesztő és nehéz. De elvileg, ha ismerjük, milyen egyszerű, egyértelmű, hogyan kell együtt élni vele:

Először is, nem hiszünk a mulasztásokban;
alaposan nézze meg a beállításokat, gondolja át, mit akarunk - SBR, RBR stb.

És jobb, ha azonnal beállítod, hogy később ne szedd szét a furcsa tölteléket.

A "rohadt a napló, a pozíció elment, nem tudni, mi történik" helyzetben van egy bizonyos eszköztár - nézzük az eseményeket, próbáljuk megérteni, melyik tranzakció csúszott már, melyik nem, az egészet el kell menteni vagy visszaállítani stb. Ha a GTID "Ha sikerült előre bekapcsolni, akkor az élet könnyebbé válik.

A replikáció másik megfigyelési pontja. Érdekes látni, hogy a belső görbe eszköz nem csak a versenyt, hanem további termékek létrehozását is kiváltja. A "varázslatos" volfrámreplikátor szerintük jól megoldja az "egyszálú szolga rossz" problémát, és ha nem lennének az eredendő nehézségek, nem lenne olyan további termék, amely lehetővé teszi ennek a mechanizmusnak a használatát, adatátvitelt. egyrészt más rendszerekre, másrészt pedig számos, a meglévő rendszerbe épített problémát megold.

Szokás szerint nem lehet tanácsot adni. Valakinek segít, valaki sokat köp. De azt mondják, vannak olyan helyzetek, amikor a Tungsten jól megbirkózik az elkerülhetetlen egyszálú késéssel. Biztos vagyok benne, hogy vannak más trükkös trükkök is, de egy belső egyszálas slave nehéz.

Mi a teendő, ha valamilyen okból replikákat használt biztonsági másolatként? Szerintem verd a fejed a falba, mert a replika és a tartalék két különböző dolog. Ennek ellenére, ha kreatív srácok vagy, és egy meglehetősen új verziót használsz, egyrészt a késleltetett replikáció kíméli, másrészt, ha nem készítesz teljes biztonsági másolatot, úgysem ment meg semmi.

Aztán a kreativitás újabb eleme. Könnyen elképzelhető egy olyan helyzet, amikor a mester a teljes 10 PB-s felhőlemezt naplózta naplókkal, vagy a teljes hálózatot megtöltötte ezeknek a naplóknak a terjesztésével, miközben nekünk nincs szükségünk ezeknek a frissítéseknek a 90%-ára, mert minket érdekel a replikáció, Például egy tábla konkrétan vagy egy konkrét adatbázis, és alapértelmezés szerint minden egy tengelyben egy bináris naplóba esik - minden változás minden adatbázisban, minden táblában, mindenben. A megoldás kreativitásában ismét feltűnő. Egyrészt van négy beállítás - (binlog|replicate)_(do|ignore)_db, amelyek lehetővé teszik a masteren történő szűrést -, hogy mi kerül naplózásra és mi kerül figyelmen kívül. A slave, illetve lehetővé teszi, hogy ugyanezt. Azok. a masteren azt tudjuk szűrni, hogy mi kerül a bináris naplóba - ebbe a tölcsérbe, ami aztán beolvad a hálózatba, a slave-en pedig egy bejövő szűrőt rakhatunk a hálózatról érkezőkre. Vagy csak az adatok egy részét írja a lemezre, majd játssza le ismét csak az adatok egy részét a slave-en. Hirtelen még ebben az egyszerű történetben is betör a horror, mert a kombináció - egy adatbázist használunk, és egy érdekes szintaxison keresztül frissítjük a táblát egy másik adatbázisban - valahogy úgy viselkedik... De hogy pontosan hogyan, az nem ismert, mert. különböző szűrők különböző időpontokban működnek.

Nincsenek beépített szép dolgok, amiket "a mester újraválasztása, ha hirtelen meghalt", kézzel kell felemelni. A klasztermenedzsment eszközeinek hiánya - ez véleményem szerint jó - versenyt generál, további termékek létrehozását generálja. Valóban, ha egy nagyon klassz master-master replikáció ideális esetben működne a normál MySQL-ben, vagy legalábbis a hibák utáni automatikus emelésben, akkor miért lenne szükség Galera, Percona / MariaDB Cluster stb.

Még néhány trükk. A replikáció érdekes megvalósítása, ami egyrészt egyszerű, mint egy bot és egy kötél, mindenféle ellenőrzés nélkül, másrészt pedig a replikáló szolgafürt kellemesebb kezeléséhez szükséges eszközök nélkül. Ez rossz. Viszont ebből lehet manuálisan olyan érdekes konfigurációkat faragni, hogy aki később jön és szétszedi, az összeborzong.

Konfiguráció #1. A MySQL-stílusú master-master a következőképpen történik:

Ami megrémít, hogy mennyi idióta van a világon! Google "MySQL Replication Wizard" - minden második link ilyen. A pokol és a holokauszt.

A 2-es számú fókusz – mindenre kiterjedő rabszolga – kellemesebb. Nincsenek szükségtelen ellenőrzések – mi kitől repül, kihez jut el, és mit kezdjünk vele. Emiatt lehet vicces dolgokat csinálni, például egy szolgát, amelyhez vagy egy csomó szerver adatának egy részét célirányosan egyesítik, vagy az összes szerver összes adatát célirányosan egyesítik - egy szerver minden biztonsági mentéssel. De, ismétlem, van replikáció, pl. van valami alapeszköz ami az A táblát másolja B helyett és ennyi.

És végül a 3-as fókusz - mindent kicserélünk. Emlékezzünk vissza, hogy a replikáció logikai szinten működik, aminek semmi köze a fizikai tárolási szinthez. Emiatt rendkívül érdekes lehet a csavarodás. Érthetetlen célokra "menet közben" lehet motort cserélni – itt az igaz történet, hogy az InnoDB adatbázisokból a MyISAM táblákra való replikáció csak azért van, hogy a teljes szöveges keresés legalább valahogy működjön. Van egy kreatív trükk, az úgynevezett "sémaváltás replikáción keresztül". Nem vagyok hajlandó megérteni, mi a zsír, de vannak ilyen trükkök. Nos, van egy érthető és érdekes működési mód, az úgynevezett "paranoid verziófrissítés replikáción keresztül".

Az előadás során megtudhattuk:

Ennek ellenére együtt tud élni ezzel a pokollal, ha legalább nagyjából megérti, hogyan működik.

A fő üzenet a következő:

2015-ben a HighLoad++ Junior konferencián Andrey Aksyonov felolvasta a MySQL replikációs eszközéről szóló jelentésének új verzióját. Blogunkban is megfejtettük.

replikáció- a terhelés alatt működő rendszerek architektúrájában alkalmazott technika, melynek eredménye a terhelés elosztása, ha egy adatbázissal több szerveren dolgozunk. A MySQL MASTER SLAVE replikációt gyakrabban használják, de egy második típusú replikációt is használnak - Master-Master.

Mi az a MySQL MASTER SLAVE replikáció, és mire használják?

replikáció mesterszolga Ez magában foglalja az adatok megkettőzését egy MySQL slave szerverre, az ilyen sokszorosítás leginkább a megbízhatóság biztosítása érdekében történik. A Master szerver meghibásodása esetén a funkciói a Slave-re kapcsolódnak.

A replikáció is végrehajtható a rendszer teljesítményének javítása érdekében, de a teljesítmény itt szinte mindig másodlagos.
Amikor egy alkalmazás adatbázissal dolgozik, a leggyakrabban a műveletek a műveletek KIVÁLASZTÁS- adatleolvasási, adatmódosítási kérések - kérések TÖRÖL, BESZÁLLÍTÁS, FRISSÍTÉS, VÁLTOZTAT statisztikailag sokkal ritkábban fordul elő.

Az egyik kiszolgáló meghibásodása esetén bekövetkező adatvesztés elkerülése érdekében a táblákban lévő információk megváltoztatására irányuló műveleteket mindig a főkiszolgáló dolgozza fel. A változtatásokat ezután a Slave replikálja. Az olvasás a Slave szerepét betöltő szerverről történhet.
Ennek köszönhetően teljesítménynövekedést érhet el a megbízhatóság mellett.

A megoldás népszerű, de nem mindig alkalmazható, mivel a replikáció késéseket tapasztalhat – ha ez megtörténik, akkor a Master szerverről is ki kell olvasni az információkat.

Egy bizonyos típusú kérések egy adott adatbázis-kiszolgálóhoz való irányítása minden esetben az alkalmazás szintjén valósul meg.

Ha a SELECT lekérdezéseket és az összes többit program szinten szétválasztjuk úgy, hogy elküldjük a kívánt szerverre, ha valamelyik meghiúsul, az infrastruktúrát kiszolgáló alkalmazás működésképtelenné válik. Ahhoz, hogy ez működjön, bonyolultabb sémát kell megadnia, és le kell foglalnia az egyes kiszolgálókat.

A replikáció a hibatűrést szolgálja, nem a méretezést.

MySQL MASTER SLAVE replikáció – beállítás Debianon

Két szervert fogunk használni címekkel:

Főszerver 192.168.0.1
Slave szerver 192.168.0.2

A demonstrációhoz helyi hálózathoz csatlakoztatott VDS-t használnak.
Hogy mindig biztosan tudjuk, melyik szerveren hajtjuk végre ezt vagy azt a parancsot, mindkét szerveren szerkesztjük az /etc/hosts fájlokat.

192.168.0.1master

192.168.0.2 rabszolga

Az /etc/hostname fájl meglévő értékeit lecseréljük a masterre és a slave-re, így a változtatások érvénybe lépnek, és a szerver újraindul.

1. A mester szerveren végezzük el a beállításokat.

[e-mail védett]:/#

A fő adatbázis-kiszolgáló konfigurációs fájljának szerkesztése

mcedit /etc/mysql/my.cnf

Válassza ki a szerver azonosítóját - bármilyen számot megadhat, az alapértelmezett 1 - csak törölje a sor megjegyzését

szerverazonosító = 1

Állítsa be a bináris napló elérési útját - alapértelmezés szerint szintén megadva, megjegyzés nélkül

Beállítjuk annak az adatbázisnak a nevét, amelyet egy másik szerverre replikálunk

binlog_do_db = db1

Indítsa újra a Mysql-t a konfigurációs fájl újraolvasásához és a módosítások érvénybe lépéséhez:

/etc/init.d/mysql újraindítás

2. Állítsa be a felhasználónak a szükséges jogokat

Lépjen az adatbázis-kiszolgáló konzoljára:

A slave szerveren lévő felhasználónak megadjuk a szükséges jogokat:

REPLIKÁCIÓS SLAVE MEGHATÁROZÁSA *.* A "slave_user"@"%"-hoz, ME AZONOSÍTJA: "123";

Minden tábla zárolása az adatbázisban

ÖBLÍTÉS A TÁBLÁZATOK OLVASÁSZÁRRA;

Ellenőrizze a főkiszolgáló állapotát:

3. Hozzon létre egy adatbázis kiíratást a kiszolgálón

Hozzon létre egy adatbázis kiíratást:

mysqldump -u root -p db1 > db1.sql

Táblázatok feloldása a mysql konzolban:

4. Vigye át az adatbázis-kiíratást a slave szerverre

scp db1.sql [e-mail védett]:/itthon

További műveleteket hajtunk végre a Slave szerveren

[e-mail védett]:/#

5. Adatbázis létrehozása

A szeméttelep betöltése:

mysql -u root -p db1< db1.sql

6. A my.cnf módosítása

mcedit /etc/mysql/my.cnf

Rendeljen hozzá egy azonosítót a főkiszolgálón beállított érték növelésével

szerverazonosító = 2

Állítsa be a relénapló elérési útját

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

és a főkiszolgálón lévő napló bin elérési útja

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

Adja meg az alapot

binlog_do_db = db1

A szolgáltatás újraindítása

/etc/init.d/mysql újraindítás

7. Állítsa be a kapcsolatot a főkiszolgálóval

MASTER MÓDOSÍTÁSA MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;

Elkezdjük a replikációt a slave szerveren:

A replikáció működését a Slave-en a következő lekérdezéssel ellenőrizheti:

********************************** 1. sor ****************** **********
Slave_IO_State: Várakozás, hogy a mester elküldje az eseményt
Master_Host: 192.168.0.1
master_user: slave_user
Master_Port: 3306
Connect_Retry: 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: Igen
Slave_SQL_Running: Igen
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 555
Until_Condition: Nincs
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Nem
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: Nem
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 sor a készletben (0,00 mp)

Mivel nem történt hiba, megállapíthatjuk, hogy a replikáció megfelelően van beállítva.

Jó méretezési eszköz, de fő hátránya az adatmásolás deszinkronizálása és a késések, ami kritikus lehet.

Korszerűbb megoldással teljesen elkerülhetők. Könnyen beállítható, megbízható, és nincs szükség az adatbázis-kiíratok kézi másolására.

A replikáció egy olyan mechanizmus, amely egy objektum több példányának tartalmát szinkronizálja. Ez a folyamat az adatok másolását jelenti egyik forrásból sok más forrásba és fordítva.

Megnevezések:

master - a fő szerver, amelynek adatait meg kell másolni;
replika - javított kiszolgáló, amely a fő adatok másolatát tárolja

A replikáció beállításához a MySQL-ben az alábbiakban leírt műveletsort kell követnie, de ez nem dogma, és a paraméterek a körülményektől függően változhatnak.

A fő szerveren szerkessze a my.cnf fájlt, és adja hozzá a következő sorokat a mysqld részhez:

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 =

- MySQL szerver egyedi azonosítója, egy szám 2 (0-31) tartományban
- annak az adatbázisnak a neve, amelynek információi a bináris naplóba kerülnek, ha több adatbázis van, akkor mindegyikhez külön sor szükséges a binlog_do_db paraméterrel

Szerkessze a slaven a my.cnf fájlt, és adja hozzá a következő sorokat a mysqld részhez:

server-id=master-host=master master-user=replication 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 =

A fő kiszolgálón adjon hozzá egy replikációs felhasználót, aki jogosult az adatok replikálására:

GRAANT REPLIKÁCIÓS SLAVE BE *.* A "replikáció"@"replika"-ra, A "jelszó" AZONOSÍTÁSA

Letiltjuk a fő szerveren lévő replikált adatbázisokat az adatok programozással vagy a MySQL funkció használatával történő megváltoztatásától:

[e-mail védett]> A TÁBLÁZATOK ÖBLÍTÉSE OLVASÁSZÁRVAL; [e-mail védett]> SET GLOBAL csak olvasható = BE;

A feloldási parancs a következő:

[e-mail védett]> SET GLOBAL read_only = OFF;

Készítsünk biztonsági másolatot a fő szerveren lévő összes adatbázisról (vagy azokról, amelyekre szükségünk van):

[e-mail védett]# tar -czf mysqldir.tar.gz /var/lib/mysql/

vagy a mysqldump segédprogram használatával:

[e-mail védett]# mysqldump -u root -p --lock-all-tables > dbdump.sql

Állítsuk le mindkét szervert (bizonyos esetekben nélküle is megteheti):

[e-mail védett]# mysqlamdin -u root -p leállítás [e-mail védett]# mysqlamdin -u root -p leállítás

Állítsuk vissza a replikált adatbázisokat a slave szerveren a könyvtár másolásával. A replikáció megkezdése előtt az adatbázisoknak azonosaknak kell lenniük:

[e-mail védett]# cd /var/lib/mysql [e-mail védett]# tar -xzf mysqldir.tar.gz

vagy mysql funkciót, akkor nem kellett leállítani a mysql-t a slave szerveren:

[e-mail védett]# mysql -u root -p< dbdump.sql

Indítsuk el a mysql-t a főszerveren (majd a slave-en, ha szükséges):

[e-mail védett]# /etc/init.d/mysql start [e-mail védett]# /etc/init.d/mysql start

Ellenőrizzük a mester és a szolga szerverek működését:

[e-mail védett]> szolga indítása; [e-mail védett]> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G [e-mail védett]> MESTER ÁLLAPOT MUTATÁSA\G

A slave szerveren ellenőrizze a naplókat a master.info fájlban, ezeknek tartalmazniuk kell az adatbázisban lévő adatok módosítására vonatkozó kéréseket. Tehát ezt a bináris fájlt először szöveges formátumba kell konvertálni:

[e-mail védett]# mysqlbinlog master.info > master_info.sql

Ha hiba történik, használhatja a következő parancsokat:

[e-mail védett]> stop slave; [e-mail védett]> RESET SLAVE; [e-mail védett]> RESET MASTER;

és ismételje meg az összes műveletet az adatbázis zárolásától kezdve.

Replikációs kiszolgálók gyors hozzáadásához használhatja a következő szintaxist:

[e-mail védett]> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G [e-mail védett]> MESTER ÁLLAPOT MUTATÁSA\G [e-mail védett]> CHANGE MASTER TO MASTER_HOST = "mester", MASTER_USER = "replikáció", MASTER_PASSWORD = "jelszó", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155; [e-mail védett]> START SLAVE;

Az állapotok információi megmutatják az aktuális naplófájl pozícióját és nevét.

Aszinkron replikáció esetén az egyik replika frissítése később, és nem ugyanabban a tranzakcióban kerül terjesztésre másoknak. Így az aszinkron replikáció késleltetést vagy időtúllépést vezet be, amely alatt az egyes replikák nem feltétlenül azonosak. Ám ennek a replikációs típusnak vannak pozitív oldalai is: a főszervernek nem kell aggódnia az adatszinkronizálás miatt, az adatbázist zárolhatja (például biztonsági másolat készítéséhez) egy szolgagépen, anélkül, hogy a felhasználók problémát okoznának.

A felhasznált források listája

Habrahabr.ru – A replikáció alapjai a MySQL-ben (http://habrahabr.ru/blogs/mysql/56702/)
Wikipédia (http://ru.wikipedia.org/wiki/Replication_(computer_engineering))

Ha az oldal bármely anyagát részben vagy egészben felhasználja, kifejezetten meg kell jelölnie a hivatkozást forrásként.