Viszonylag nemrégiben ismerkedtem meg a MySQL szerverek replikációjával, és mivel különféle kísérleteket végeztem a beállításokkal, le is írtam, hogy mit csináltam. Amikor sok volt az anyag, felmerült az ötlet, hogy megírjam ezt a cikket. Megpróbáltam tippeket és megoldásokat összeszedni azokra a legalapvetőbb problémákra, amelyekkel találkoztam. Útközben adok hivatkozásokat a dokumentációhoz és más forrásokhoz. Nem tehetek úgy, mintha teljes lennék, de remélem, hogy a cikk hasznos lesz.

Egy kis bevezető

A replikáció (a latin replico szóból – ismétlem) az adatváltozások replikálása a fő adatbázis-kiszolgálóról egy vagy több függő szerverre. A főszerver meg lesz hívva fő-, és függő replikák.
A mesteren előforduló adatmódosítások megismétlődnek a replikákon (de nem fordítva). Ezért az adatok megváltoztatására irányuló lekérdezések (INSERT, UPDATE, DELETE stb.) csak a mesteren futnak le, míg az adatok olvasására irányuló lekérdezések (más szóval: SELECT) végrehajthatók replikákon és a mesteren is. Az egyik replikán a replikációs folyamat nincs hatással a többi replika működésére, és gyakorlatilag nincs hatással a mester működésére.
A replikáció a mesteren karbantartott bináris naplók használatával történik. Elmentik az összes olyan lekérdezést, amely az adatbázis változásaihoz vezet (vagy potenciálisan vezethet) (a lekérdezések nincsenek kifejezetten tárolva, így ha látni szeretné őket, akkor a mysqlbinlog segédprogramot kell használnia). A binlogok átkerülnek a replikákba (a mesterről letöltött binlogot "relay binlog"-nak nevezik), és a tárolt lekérdezések egy adott pozícióból indulva végrehajtásra kerülnek. Fontos megérteni, hogy a replikáció nem magát a megváltozott adatokat továbbítja, hanem csak a változásokat okozó kéréseket.
A replikáció során az adatbázis tartalma több szerveren duplikálódik. Miért szükséges a duplikáció használata? Ennek több oka is van:

teljesítmény és skálázhatóság. Előfordulhat, hogy az egyik kiszolgáló nem tudja kezelni az adatbázis egyidejű olvasása és írása okozta terhelést. A replikák létrehozásának előnye annál nagyobb lesz, minél több írási olvasás olvasható a rendszerben.
hibatűrés. A replika meghibásodása esetén az összes olvasási kérés biztonságosan átvihető a mesterre. Ha a mester meghibásodik, az írási kérelmek átvihetők a replikára (a mester visszaállítása után átveheti a replika szerepét).
adatmentés. A replikát egy időre "le lehet lassítani" a mysqldump végrehajtásához, de a master nem.
lusta értékelés. A nehéz és lassú SQL-lekérdezések külön replikán is futtathatók anélkül, hogy félnének attól, hogy megzavarják a teljes rendszer normál működését.

Ezen kívül van még néhány érdekes funkció. Mivel nem maguk az adatok kerülnek a replikákba, hanem azok a lekérdezések, amelyek változást okoznak, ezért a masteren és a replikákon eltérő táblaszerkezetet használhatunk. Különösen a táblázat típusa (motor) vagy az indexek halmaza különbözhet. Például teljes szöveges keresés végrehajtásához használhatjuk a MyISAM táblatípust a replikán, annak ellenére, hogy a mester az InnoDB-t fogja használni.

Replikáció beállítása

Tegyük fel, hogy van egy működő adatbázisunk MySQL adatok, már adatokkal feltöltve és a műben szerepel. A fent leírt okok egyike miatt engedélyezni fogjuk a replikációt a szerverünkön. Kiinduló adataink:

A fő IP-címe 192.168.1.101, a replika 192.168.1.102.
MySQL telepítve és konfigurálva
be kell állítania a testdb adatbázis-replikációt
egy időre szüneteltethetjük a varázslót
természetesen mindkét gépen root van

Varázsló beállításai

Feltétlenül adja meg az egyedi szerverazonosítót, a bináris naplók elérési útját és a replikációhoz szükséges adatbázis nevét a következő részben:
szerverazonosító = 1
log-bin = /var/lib/mysql/mysql-bin
replikate-do-db=testdb
Győződjön meg arról, hogy van elég lemezterülete a bináris naplók számára.

Adjuk hozzá a replikációs felhasználót, akinek a jogai alapján a replikáció végrehajtásra kerül. A "replikációs slave" jogosultság elegendő:
[e-mail védett]> GRANT replikációs slave ON "testdb".* TO "replication"@"192.168.1.102" A "jelszó" AZONOSÍTÁSA;

Indítsa újra a MySQL-t, hogy a konfigurációs változások életbe lépjenek:
[e-mail védett]# service mysqld újraindítás

Ha minden jól ment, a "show master status" parancsnak valami ilyesmit kell mutatnia:
[e-mail védett]> MESTER ÁLLAPOT MUTATÁSA\G
Fájl: mysql-bin.000003
Pozíció: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
A pozícióértéknek növekednie kell, ha a mester adatbázisában módosításokat hajtanak végre.

Replika beállítások

Adja meg a kiszolgáló azonosítóját, a replikációhoz szükséges adatbázis nevét és a továbbítási binlogok elérési útját a konfigurációs részben, majd indítsa újra a MySQL-t:
szerverazonosító = 2
relay-log=/var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replikate-do-db=testdb

[e-mail védett]# service mysqld újraindítás

Adatátvitel

Itt zárolnunk kell az adatbázist az íráshoz. Ehhez leállíthatja az alkalmazások futtatását, vagy használhatja a csak olvasható jelzőt a mesteren (megjegyzés: ez a jelző nem érinti a SUPER jogosultsággal rendelkező felhasználókat). Ha MyISAM tábláink vannak, akkor "flush tables"-t is készítünk:
[e-mail védett]> A TÁBLÁZATOK ÖBLÍTÉSE OLVASÁSZÁRVAL;
[e-mail védett]> SET GLOBAL csak olvasható = BE;

Nézzük meg a mester állapotát a "show master status" paranccsal, és emlékezzünk a Fájl és a Pozíció értékeire (a mester sikeres blokkolása után ezek nem változhatnak):
Fájl: mysql-bin.000003
Pozíció: 98

Adatbázis kiíratást készítünk, és a művelet befejezése után eltávolítjuk a fő zárolást:
[e-mail védett]> SET GLOBAL read_only = OFF;

A kiíratást átvisszük a replikára, és visszaállítjuk az adatokat.
Végül elindítjuk a replikációt a "change master to" és a "start slave" paranccsal, és megnézzük, hogy minden rendben ment-e:
[e-mail védett]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replikáció", MASTER_PASSWORD = "jelszó", MASTER_LOG_FILE = "mysql-bin.000003", MASTER_LOG_POS = 98;
[e-mail védett]> szolga indítása;
A MASTER_LOG_FILE és MASTER_LOG_POS értékeket a mestertől vesszük.

Nézzük meg, hogyan megy a replikáció a "show slave status" paranccsal:
[e-mail védett]> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G
Slave_IO_State: Várakozás, hogy a mester elküldje az eseményt
Master_Host: 192.168.1.101
Master_User:replikáció
Master_Port: 3306
Connect_Retry: 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: Igen
Slave_SQL_Running: Igen
Replicate_Do_DB: testdb,testdb
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: 98
Relay_Log_Space: 235
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: 5

A legérdekesebb értékeket emeltem ki most. A replikáció sikeres elindítása után az értékeknek megközelítőleg meg kell egyezniük a listában szereplővel (lásd a "Show slave status" parancs leírását a dokumentációban). A Seconds_Behind_Master értéke tetszőleges egész szám lehet.
Ha a replikáció jól megy, a replika követi a mestert (a Master_Log_File naplószáma és az Exec_Master_Log_Pos pozíciója nő). Ideális esetben a mester másolata mögötti időnek (Seconds_Behind_Master) nullának kell lennie. Ha nem csökken vagy növekszik, lehetséges, hogy a replika terhelése túl magas - egyszerűen nincs ideje megismételni a mesteren előforduló változásokat.
Ha a Slave_IO_State üres, és a Seconds_Behind_Master értéke NULL, akkor a replikáció nem indult el. Nézze meg a MySQL naplót, hogy megtudja az okot, javítsa ki, és indítsa újra a replikációt:
[e-mail védett]> szolga indítása;

Ezekkel az egyszerű lépésekkel olyan replikát kapunk, amelynek adatai megegyeznek a mester adataival.
Egyébként a master zárolási ideje az az idő, amikor a dump létrejött. Ha elfogadhatatlanul sok időt vesz igénybe a létrehozás, próbálkozzon a következővel:

blokkolja az írást a masternek az read_only jelzővel, emlékezzen a pozícióra, és állítsa le a MySQL-t.
ezt követően másolja át az adatbázis fájlokat a replikába, és kapcsolja be a mestert.
indítsa el a replikációt a szokásos módon.

Számos módja van a replika létrehozásának a mester leállítása nélkül, de ezek nem mindig működnek.

Replikák hozzáadása

Tegyük fel, hogy már van egy működő master és replika, és hozzá kell adnunk egy másikat. Ez még egyszerűbb, mint az első replikát hozzáadni a mesterhez. És sokkal kellemesebb, hogy ehhez nem kell megállítani a mestert.
Először állítsuk be a MySQL-t a második replikán, és győződjön meg arról, hogy megadtuk a szükséges paramétereket a konfigurációban:
szerverazonosító = 3
replikate-do-db=testdb

Most állítsa le a replikációt az első replikán:
[e-mail védett]> stop slave;

A replika továbbra is normálisan fog működni, de a rajta lévő adatok már nem lesznek naprakészek. Nézzük meg az állapotot, és emlékezzünk a mester pozíciójára, amelyhez a replika elért a replikáció leállítása előtt:
[e-mail védett]> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G

Szükségünk lesz a Master_Log_File és az Exec_Master_Log_Pos értékekre:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155

Hozzon létre egy adatbázis kiíratást, és folytassa a replikációt az első replikán:
[e-mail védett]> START SLAVE;

Állítsuk vissza az adatokat a kiíratásból a második replikán. Ezután engedélyezze a replikációt:
[e-mail védett]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replikáció", MASTER_PASSWORD = "jelszó", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155;
[e-mail védett]> START SLAVE;

A MASTER_LOG_FILE és MASTER_LOG_POS értékek a Master_Log_File és az Exec_Master_Log_Pos értékek az első replikán lévő show slave status parancs eredményéből.
A replikációt onnan kell kezdeni, ahol az első replikát leállították (és ennek megfelelően a kiíratást létrehozták). Így két másolatunk lesz azonos adatokkal.

Replikák kombinálása

Néha előfordul ez a helyzet: két adatbázis van a mesteren, amelyek közül az egyik az egyik replikán, a második a másikon replikálódik. Hogyan állíthat be két adatbázis replikációját mindkét replikán anélkül, hogy kiírná őket a mesterre és anélkül, hogy leállítaná? Elég egyszerű, a "start slave till" paranccsal.
Tehát van egy mesterünk a testdb1 és testdb2 adatbázisokkal, amelyek replikálódnak a replika-1 és a replika-2 replikákon. Állítsuk be mindkét adatbázis replikációját a replika-1-en a fő leállítása nélkül.
Állítsa le a replikációt a 2. replikán a paranccsal, és emlékezzen a mester pozíciójára:
[e-mail védett]> STOP SLAVE;
[e-mail védett]> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231

Hozzuk létre a testdb2 adatbázis kiíratását, és folytassuk a replikációt (itt ért véget a replika-2-vel végzett manipuláció). A kiíratást a rendszer visszaállítja a replika-1-re.

A helyzet a replika-1 esetében a következő: a testdb1 adatbázis a mester egyik pozíciójában található, és folytatja a replikációt, a testdb2 adatbázist egy másik pozícióból származó kiíratból állították vissza. Szinkronizáljuk őket.

Állítsa le a replikációt, és emlékezzen a mester pozíciójára:
[e-mail védett]> STOP SLAVE;
[e-mail védett]> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G
Exec_Master_Log_Pos: 501

Győződjön meg arról, hogy a replika-1 konfigurációjában a szakasz tartalmazza a második adatbázis nevét:
replikate-do-db=testdb2

Indítsa újra a MySQL-t, hogy a konfigurációs változások életbe lépjenek. Egyébként egyszerűen újraindíthatná a MySQL-t a replikáció leállítása nélkül - a naplóból megtudhatnánk, hogy a fő replikáció melyik pozíciójában állt le.

Most replikáljuk azt a pozíciót, ahol a replika-2 felfüggesztésre került, oda, ahol éppen felfüggesztettük a replikációt:
[e-mail védett]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replikáció", MASTER_PASSWORD = "jelszó", MASTER_LOG_FILE = "mysql-bin.000015", MASTER_LOG_POS = 231;
[e-mail védett]> szolga indítása addig, amíg MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;

A replikáció azonnal véget ér, amint a replika eléri a megadott pozíciót a amíg szakaszban, majd mindkét adatbázisunk ugyanannak a fő pozíciónak felel meg (ahol a replikát leállítottuk a replika-1-en). Győződjünk meg erről:
[e-mail védett]> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G
[e-mail védett]> START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Adjuk hozzá mindkét adatbázis nevét a replica-1 konfigurációjához a következő szakaszban:
replicate-do-db=testdb1
replikate-do-db=testdb2

Fontos: minden adatbázist külön sorban kell felsorolni.
Indítsa újra a MySQL-t, és folytassa a replikációt:
[e-mail védett]> CHANGE MASTER TO MASTER_HOST = "192.168.1.101", MASTER_USER = "replikáció", MASTER_PASSWORD = "jelszó", MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;
Miután a replika-1 utoléri a mestert, az adatbázisuk tartalma azonos lesz. A replika-2 adatbázist hasonló módon vagy a replika-1 teljes kiíratásával egyesítheti.

Castling mester és replika

Szükség lehet a replika mester módba kapcsolására, például ha a mester meghibásodik, vagy ha a műszaki munka. Egy ilyen kapcsoló engedélyezéséhez a replikát mesterként kell konfigurálnia, vagy el kell készítenie passzív mester.

Engedélyezze a bináris naplózást (a binlogok továbbítása mellett) a konfigurációban a következő szakaszban:
log-bin = /var/lib/mysql/mysql-bin

És adjon hozzá egy felhasználót a replikációhoz:
[e-mail védett]> GRANT replikációs slave ON 'testdb'.* TO 'replication'@'192.168.1.101' A "jelszó" AZONOSÍTÁSA;

A passzív mester úgy replikál, mint egy normál replika, de bináris naplókat is készít – vagyis elindíthatjuk belőle a replikációt. Erről győződjünk meg a "show master status" paranccsal:
[e-mail védett]> MESTER ÁLLAPOT MUTATÁSA\G
Fájl: mysql-bin.000001
Pozíció: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Most, hogy a passzív mester aktív módba kerüljön, le kell állítania rajta a replikációt, és engedélyeznie kell a replikációt a korábbi aktív mesteren. Annak érdekében, hogy az adatok ne vesszenek el a váltáskor, aktív mesterírászároltnak kell lennie.
[e-mail védett]> ÖBLÍTSE EL A TÁBLÁZATOKAT OLVASÁSZÁRVAL
[e-mail védett]> SET GLOBAL csak olvasható = BE;
[e-mail védett]> STOP SLAVE;
[e-mail védett]> MESTER ÁLLAPOT MUTATÁSA;
Fájl: mysql-bin.000001
Pozíció: 61
[e-mail védett]> CHANGE MASTER TO MASTER_HOST = "192.168.1.102", MASTER_USER = "replikáció", MASTER_PASSWORD = "jelszó", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 61;
[e-mail védett]> szolga indítása;
Ez az, ezért lecseréltük az aktív mestert. Eltávolítható belőle egykori mester blokkolása.

Következtetés

Kicsit foglalkoztunk a replikáció beállításával a MySQL-ben és néhány alapvető művelet végrehajtásával. Sajnos a következő fontos kérdések a cikk keretein kívül maradtak:

egyedi hibapontok (SPF, Single Points of Failure) kiküszöbölése. Használata egyetlen szerver A MySQL meghibásodása az egész rendszer meghibásodásához vezetett. Ha több szervert használunk, bármelyikük meghibásodása rendszerhibát eredményez, kivéve, ha kifejezetten gondoskodunk róla. Gondoskodnunk kell a master és a replika meghibásodási helyzetének kezeléséről. Az egyik meglévő eszközt - az MMM-et azonban fájllal kell véglegesíteni.
terhelés elosztás. Több replika használatakor célszerű lenne egy átlátható kiegyenlítő mechanizmust alkalmazni, különösen, ha a replikák teljesítménye nem azonos. Linux alatt használható átlagos megoldás— Lvs.
az alkalmazás logikájának megváltoztatása. Ideális esetben az adatolvasási kérelmeket replikákra kell küldeni, a módosításokat pedig a mesterre. A replikák lehetséges lemaradása miatt azonban egy ilyen séma gyakran nem működik, és azonosítani kell azokat az olvasási kéréseket, amelyeket még végre kell hajtani a mesteren.

Remélem, hogy a következő cikkekben fényt deríthetek ezekre a kérdésekre.
Köszönöm a figyelmet!

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 =

- egyedi azonosító MySQL szerverek, egy szám a 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:

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

Mindkét szerver leállítása egyedi esetek meg tudod csinálni nélküle):

[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 állapotokból származó információk a pozíciót és a nevet mutatják aktuális fájl log.

Aszinkron replikáció esetén az egyik replika frissítése egy idő után továbbadódik másoknak, és nem ugyanabban a tranzakcióban. Így az aszinkron replikáció késleltetést vagy időtúllépést vezet be, amely alatt az egyes replikák valójában nem azonosak. De ennek a replikációs típusnak vannak pozitív oldalai is: a fő szervernek nem kell aggódnia az adatszinkronizálás miatt, blokkolhatja az adatbázist (pl. biztonsági mentés) a slave gépen, nem probléma a felhasználók számára.

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.

A replikáció kifejezés az adatok több másolatának szinkronizálására szolgáló mechanizmusra utal, amely növeli az információbiztonságot, a hibatűrést és a rendszer teljesítményét. Kiváló példa erre az adatbázis-replikáció két kiszolgáló között.

Master-slave MySQL replikáció

A Master-Slave terminológiában a master az elsődleges szerver az adatbázissal, ez ír az adatbázisba, de az olvasás a rendszer terhelésétől függően megoszlik a master és a slave között, ami növeli a hibatűrést és a teljesítményt. Ezen túlmenően ennek a megközelítésnek köszönhetően az adatbázis egy példánya mindig kéznél van, és az egyik szerver meghibásodása esetén visszaállítható.

Milyen helyzetekben lehet szükség slave szerverre? Például amikor egy nagy adattömb érkezik az adatbázisba írandó adatokhoz, és a főszervernek egyszerűen nincs ideje olvasni, és a kliensnek meg kell várnia az írás végét, ami a slave szervernek köszönhetően elkerülhető.

Vannak olyan helyzetek, amikor a mesterszerver meghibásodik, ilyenkor a szolgaszerver átveszi a mester összes funkcióját, és egyedül működik a visszaállításig. Az ügyfél valószínűleg semmit sem fog észrevenni, és biztosan nem fog egy-két-három órát várni, hogy a mesterek megjavítsák.

A replikáció beállítása egyáltalán nem nehéz, mivel a mechanizmus kezdettől fogva be van építve a MySQL-be.

Beállítás a Master szerveren

Kezdjük a my.cnf konfigurációs fájl szerkesztésével, amely leggyakrabban az /etc/mysql/my.cnf címen található. Meg kell találni és ki kell venni a megjegyzéseket (eltávolítani a #-t), vagy meg kell írni az ilyen sorokat.

bind-cím = 0.0.0.0 szerverazonosító = 1 log_bin = /var/log/mysql/mysql-bin.log

Fontos! Ha a bind-cím már regisztrálva van, akkor azt módosítani kell, különben nem lehet kapcsolatot létesíteni a szerverek között.

Közvetlenül ezután újraindítjuk az adatbázist a szerveren.

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

Most létre kell hoznia egy felhasználót, aki jogosult az adatbázisunk replikálására, ezt megteheti a MySQL konzol root alól a paranccsal

REPLIKÁCIÓS SLAVE MEGHATÁROZÁSA *.* A "slave_user"@"%"-hoz. A "slave_password" AZONOSÍTÁSA; FLUSH KIVÁLTSÁGOK;

Ahol a "slave_user" és a "slave_password" helyett a slave felhasználónevét és jelszavát kell beírni.

Most lássuk a mester adatait

MESTER ÁLLAPOT MUTATÁSA;

Oszlopértékek Fájl És Pozíció emlékeznie kell arra, hogy a rabszolga beállításához fogják használni, amelyre most továbblépünk.

Beállítás a Slave szerveren

Az első lépés egy olyan adatbázis létrehozása, amelynek neve megegyezik azzal, amelyet replikálni fogunk. Ez egy fontos lépés, és nem szabad elhanyagolni. Ezután lépjen a már ismert konfigurációs fájlra my.cnf és írja be a beállításokat.

szerverazonosító = 2 relay-log = /var/log/mysql/mysql-relay-bin.log bin-log = /var/log/mysql/mysql-bin.log

Fontos! A bin log elérési útja a bin-logban van írva a gazdagépen . A szerver azonosítónak különböznie kell a fő azonosítótól, kényelmesen 1-gyel többre állíthatja.

MÓDOSÍTSA MEG A MASTER-T MASTER_HOST="1.1.1.1", MASTER_USER="slave_user", MASTER_PASSWORD="slave_password", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 107; START SLAVE;

Ahol a host a mester IP-címe, a bejelentkezési név és a jelszó megfelel annak, amit a mesteren hoztunk létre, a master_log_file és a master_log_pos tele van információkkal a főkiszolgáló konfigurációjának utolsó eleme .

Ezentúl az adatbázisban végrehajtott összes változás átkerül a masterről a slave-re.

Replikációs állapot ellenőrzése

Kivéve a SHOW MASTER STATUS parancsot; van egy hasonló a slave SHOW SLAVE STATUS\G számára, amely egy táblázatot jelenít meg az információkkal. A szerverek csatlakoztatásának és megfelelő működésének fő jele az ilyen vonalak jelenléte

replikáció- a terhelés alatt működő rendszerek architektúrájában használt 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 megcsinálod az elválasztást SELECT lekérdezések a többit pedig programszinten, a kívánt szerverre küldve, ha valamelyik meghibásodik, 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.1 mester

192.168.0.2 rabszolga

Az /etc/hostname fájlban lévő meglévő értékeket lecseréljük masterre és slave-re, hogy a változtatások érvénybe lépjenek, újraindítjuk a szervert.

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.

Is jó eszköz skálázás, de fő hátránya az adatmásolás deszinkronizálása és a késések, ami kritikus lehet.

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

Egy kis bevezető

teljesítmény és skálázhatóság. Előfordulhat, hogy az egyik kiszolgáló nem tudja kezelni az adatbázis egyidejű olvasása és írása okozta terhelést. A replikák létrehozásának előnye annál nagyobb lesz, minél több írási olvasás olvasható a rendszerben.
hibatűrés. A replika meghibásodása esetén az összes olvasási kérés biztonságosan átvihető a mesterre. Ha a mester meghibásodik, az írási kérelmek átvihetők a replikára (a mester visszaállítása után átveheti a replika szerepét).
adatmentés. A replikát egy időre "le lehet lassítani" a mysqldump végrehajtásához, de a master nem.
lusta értékelés. A nehéz és lassú SQL-lekérdezések külön replikán is futtathatók anélkül, hogy félnének attól, hogy megzavarják a teljes rendszer normál működését.

Replikáció beállítása

Tegyük fel, hogy van egy működő MySQL adatbázisunk, amely már fel van töltve adatokkal, és munkába áll. A fent leírt okok egyike miatt engedélyezni fogjuk a replikációt a szerverünkön. Kiinduló adataink:

A fő IP-címe 192.168.1.101, a replika 192.168.1.102.
MySQL telepítve és konfigurálva
be kell állítania a testdb adatbázis-replikációt
egy időre szüneteltethetjük a varázslót
természetesen mindkét gépen root van

Varázsló beállításai

Indítsa újra a MySQL-t, hogy a konfigurációs változások életbe lépjenek:
[e-mail védett]# service mysqld újraindítás

Replika beállítások

[e-mail védett]# service mysqld újraindítás

Adatátvitel

Adatbázis kiíratást készítünk, és a művelet befejezése után eltávolítjuk a fő zárolást:
[e-mail védett]> SET GLOBAL read_only = OFF;

blokkolja az írást a masternek az read_only jelzővel, emlékezzen a pozícióra, és állítsa le a MySQL-t.
ezt követően másolja át az adatbázis fájlokat a replikába, és kapcsolja be a mestert.
indítsa el a replikációt a szokásos módon.

Számos módja van a replika létrehozásának a mester leállítása nélkül, de ezek nem mindig működnek.

Replikák hozzáadása

Most állítsa le a replikációt az első replikán:
[e-mail védett]> stop slave;

Szükségünk lesz a Master_Log_File és az Exec_Master_Log_Pos értékekre:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155

Hozzon létre egy adatbázis kiíratást, és folytassa a replikációt az első replikán:
[e-mail védett]> START SLAVE;

Replikák kombinálása

Hozzuk létre a testdb2 adatbázis kiíratását, és folytassuk a replikációt (itt ért véget a replika-2-vel végzett manipuláció). A kiíratást a rendszer visszaállítja a replika-1-re.

Állítsa le a replikációt, és emlékezzen a mester pozíciójára:
[e-mail védett]> STOP SLAVE;
[e-mail védett]> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G
Exec_Master_Log_Pos: 501

Győződjön meg arról, hogy a replika-1 konfigurációjában a szakasz tartalmazza a második adatbázis nevét:
replikate-do-db=testdb2

Adjuk hozzá mindkét adatbázis nevét a replica-1 konfigurációjához a következő szakaszban:
replicate-do-db=testdb1
replikate-do-db=testdb2

Castling mester és replika

Szükséges lehet a replika fő módba kapcsolása, például ha a mester meghibásodik, vagy a rajta végzett karbantartási munkák során. Egy ilyen kapcsoló engedélyezéséhez a replikát mesterként kell konfigurálnia, vagy el kell készítenie passzív mester.

Engedélyezze a bináris naplózást (a binlogok továbbítása mellett) a konfigurációban a következő szakaszban:
log-bin = /var/lib/mysql/mysql-bin

És adjon hozzá egy felhasználót a replikációhoz:
[e-mail védett]> GRANT replikációs slave ON 'testdb'.* TO 'replication'@'192.168.1.101' A "jelszó" AZONOSÍTÁSA;

Következtetés

Kicsit foglalkoztunk a replikáció beállításával a MySQL-ben és néhány alapvető művelet végrehajtásával. Sajnos a következő fontos kérdések a cikk keretein kívül maradtak:

egyedi hibapontok (SPF, Single Points of Failure) kiküszöbölése. Egyetlen MySQL szerver használatakor annak meghibásodása az egész rendszer meghibásodásához vezetett. Ha több szervert használunk, bármelyikük meghibásodása rendszerhibát eredményez, kivéve, ha kifejezetten gondoskodunk róla. Gondoskodnunk kell a master és a replika meghibásodási helyzetének kezeléséről. Az egyik meglévő eszközt - az MMM-et azonban fájllal kell véglegesíteni.
terhelés elosztás. Több replika használatakor célszerű lenne egy átlátható kiegyenlítő mechanizmust alkalmazni, különösen, ha a replikák teljesítménye nem azonos. Linux alatt lehetőség van a standard megoldás - LVS - használatára.
az alkalmazás logikájának megváltoztatása. Ideális esetben az adatolvasási kérelmeket replikákra kell küldeni, a módosításokat pedig a mesterre. A replikák lehetséges lemaradása miatt azonban egy ilyen séma gyakran nem működik, és azonosítani kell azokat az olvasási kéréseket, amelyeket még végre kell hajtani a mesteren.

Remélem, hogy a következő cikkekben fényt deríthetek ezekre a kérdésekre.
Köszönöm a figyelmet!

Tematikus anyagok: