A Linux Wikiből

Replikáció beállítása

Mester szerver

my.cnf a fő szerveren:

[mysqld]# Szerverazonosító. Egyedinek kell lennie a kiszolgálók minden egyes kapcsolatán (mind a masteren, mind a slaven). # 1 és 4294967295 közötti szám (2 ^32 -1 ) server-id = 1 # A bináris naplók elérési útja, ahol a főkiszolgáló adatbázisában végrehajtott összes változás mentésre kerül. Elegendő helynek kell lennie ezeknek a naplóknak log-bin = /var/lib/mysql/mysql-bin # Hány napig kell tartani a bináris naplókat a masteren. Valamilyen módon ez azt is meghatározza, hogy a slave mennyivel maradhat le a master mögött # expire_logs_days = 10 # A binlog fájl mérete (minden egyes fájl) # max_binlog_size = 1024M # Engedélyezze a Slave-nek küldött naplók tömörítését slave_compressed_protocol = 1 # az adatbázis, amelyhez replikációt kell végezni. Ha több adatbázist kell replikálnia, ismételje meg a beállítást a kívánt adatbázisnévvel replicate-do-db = testdb # Ezen az opción kívül további lehetőségek állnak rendelkezésre "fordított választás"- az adatbázisok kiválasztásának kizárása # replicate-ignore-db= adatbázis_neve #, valamint az egyes táblák replikálási opciói (hasonlóan - válasszon egyet/többet ; egy / több kizárása, valamint a nevek helyettesítő karakterekkel történő meghatározása)# Erre az opcióra akkor van szükség, ha ez a főszerver egy másik szolgája - hogy ennek a mesternek a szolgája (a fő mester al-szolgája) is kapja a frissítéseket # Hasznos lehet egy szolga mester-mester replikálásakor # napló -slave -frissítések

Jogot adunk a slave szervernek, hogy ebből replikáljon. Ehhez a mysql konzolban a következő parancsot adjuk:

mysql> A replikációs slave MEGBÍZÁSA BE * .* A "repluser"-nek @"replhost" A "replpass" AZONOSÍTJA ;

repluser- felhasználónév a csatlakozáshoz. A felhasználó a parancs végrehajtásakor jön létre.
replhost- Annak a szolga szervernek az IP-címe vagy gazdagéptartománya, amely csatlakozni fog ehhez a mesterhez, és importálja a módosításokat.
replpass- csatlakozási jelszó

Úgy tűnik, hogy a replikációs alap korlátozása az engedélyezési replikációban nem működik - azaz mindent engedélyezünk, és a konfigurációban csak a szükséges alapokat adjuk meg.

Újraindítjuk a szervert, ami után futtathatjuk a parancsot a konzolban

mysql> MESTER ÁLLAPOT MEGJELENÍTÉSE ;

amely megmutatja a bináris naplófájlt, amellyel a mester jelenleg dolgozik, és a naplóban lévő aktuális pozíciót, valamint a replikálandó bázis(oka)t.

Slave szerver

Adja hozzá a szükséges beállításokat a konfigurációban my.cnf a slave szerveren:

[mysqld]# Szerverazonosító ehhez a kiszolgálócsomaghoz - lásd a fenti leírást szerver-id = 2 # Továbbító naplók - naplók letöltve a főkiszolgálóról # Adja meg a naplók elérési útját ; legyen elegendő hely a tárolásukhoz.#relay-log= /var/lib/mysql/mysql-relay-bin#relay-log-index = /var/lib/mysql/mysql-relay-bin.index# A replikálandó adatbázis neve replicate-do-db = testdb # Engedélyezze a Slave-nek küldött naplók tömörítését slave_compressed_protocol = 1

A változtatások alkalmazásához indítsa újra a szervert

Indítsa el a replikációt

A masteren lezárjuk a táblázatokat az íráshoz, hogy teljesen helyes kiírást kapjunk:

mysql> TÁBLÁZATOK ÖBLÍTÉSE OLVASÁSZÁROLÁSSAL ; mysql> SET GLOBAL read_only = ON ;

Egyesítünk egy kiíratást a szerverről. Egyes helyeken általában arról írnak, hogy meg kell nézni a napló pozícióját és nevét a mesteren - ez nem szükséges, és a kulcs megoldja --törzsadatok a mysqldump számára, amely magába a kiíratba írja a szükséges információkat:

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

Ezt követően elindítjuk a varázslót:

mysql> SET GLOBAL read_only = OFF;

(bár felmerül a gondolat - valóban zárolni kell az adatbázist kiírásakor? Amint elkezdődött a kiírat a --master-data-val, a napló neve és pozíciója belekerül, és a táblák automatikusan zárolásra kerülnek írás - azaz minden ugyanaz, csak automatikus módban)

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

BAN BEN ez az eset slavedbname = masterdbname, bár ha kívánja, az adatbázist más néven is replikálhatja.

Adja meg a fő szerver címét a slave számára:

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

Ahol mesteri- A főszerver IP-címe vagy tartománya, és a fennmaradó opciók azok, amelyeket fent a főkiszolgáló beállításakor megadtunk. A naplófájl neve és a pozíció a kiíratból származnak, de ha szükséges, manuálisan is megadhatók a MASTER_LOG_FILE = "naplónév", MASTER_LOG_POS = pozíció opciókkal

A parancs után a mesterrel kapcsolatos információk egy fájlba kerülnek master.info az adatbázis-könyvtárban mysql adatok-szerver. Ha szükséges, megadhatja ezeket a beállításokat a slave szerver konfigurációjában:

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

Ezután elindítjuk a slave szervert a mysql konzolon keresztül:

mysql> START SLAVE;

Most a paranccsal ellenőrizheti a slave szerver állapotát

mysql> SLAVE ÁLLAPOT MEGJELENÍTÉSE ;

Az érdekes információk között lehetnek mezők:

Slave_IO_State: Várakozás, HOGY a mester elküldje az eseményt, Slave_IO_Running: IgenÉs Slave_SQL_Running: Igen- minden jól működik :)
Seconds_Behind_Master- milyen messze van a rabszolga a mester mögött. Normál módban 0-nak kell lennie, de valós késésben 0 is lehet, ha sok változtatás történik a masteren, és szűk a csatorna a master és a slave között, és az utóbbinak nincs ideje letölteni binlogok a mestertől. Ebben az esetben a „0” helyes, de csak arra, amit sikerült letölteni a naplókból.

És egyéb aktuális információk, mint például a hibamentesség, a szervernapló aktuális pozíciója és neve, a szolganapló stb.

Vegyes

A mysqldump kétféleképpen írja be a napló nevét és pozícióját a dump fájlba: --törzsadatokÉs --dump-slave. A második nincs mindenhol:

[e-mail védett]:~# mysqldump --help | grep "dump-slave" [e-mail védett]:~# mysqldump --verzió mysqldump Ver 10.13 Distrib 5.1.61, portbld-freebsd8.2 (amd64)

Dump-slave[=érték] Ez a beállítás hasonló a --master-data beállításhoz, azzal a különbséggel, hogy egy replikációs szolga kiszolgáló kiíratására szolgál, hogy egy kiíratási fájlt hozzon létre, amellyel beállítható egy másik szerver, amely ugyanazzal a mesterrel rendelkezik. mint a dömpingelt szerver. Ez azt eredményezi, hogy a kiíratási kimenet tartalmaz egy CHANGE MASTER TO utasítást, amely a kiírt slave mesterének bináris naplókoordinátáit (fájl nevét és pozícióját) jelzi (nem pedig a kiírt szerver koordinátáit, ahogy azt a --master- teszi. adatopció).Ezek a mester kiszolgáló koordinátái, amelyekről a slave-nek el kell kezdenie a replikációt.Ez az opció a MySQL 5.5.3-ban lett hozzáadva.

Ennek megfelelően az egyik lehetőség a szolga klónozása, a második az alszolga létrehozása. Más szóval, a dump-slave lehetővé teszi egy másik slave1 létrehozását (a slave1 használatával) a master-slave1-slave2 láncban (a naplóban lévő pozíció és a naplófájl a fő naplókhoz viszonyítva a kiíratásra kerül), master- adatok lehetővé teszik a slave2 létrehozását - a pozíció / napló a slave1 binlogjaihoz képest.

Replikációs hibák

A replikáció futása közben hibák léphetnek fel – bármilyen okból, például az adatok kézi bevitele miatt egy szolgakiszolgálón.

Megoldási lehetőségek.

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;GLOBAL SQL_SLAVE_SKIP_COUNTER BEÁLLÍTÁSA = 1;SZOLGÁLTATÁS INDÍTÁSA;

Ez egy rövid leírás a teljes replikáció beállításáról a MySQL-kiszolgálón. Feltételezzük, hogy az összes adatbázis replikálva lesz, és a replikáció korábban nincs konfigurálva. Az itt leírt lépések végrehajtásához meg kell tennie egy kis időállítsa le a főkiszolgálót.

Ez a legegyszerűbb módja a slave szerver telepítésének, de nem ez az egyetlen. Például, ha már van kép a szülőkiszolgálóról, a kiszolgáló azonosítója már be van állítva a szülőkiszolgálón, és a naplózás folyamatban van, a segédkiszolgáló telepíthető anélkül, hogy leállítaná a szülőkiszolgálót, vagy akár frissítési zárakat is be kellene állítania (lásd a részt 4.10.7 Gyakran további információkért). replikáció GYIK.

Ahhoz, hogy valódi MySQL-replikációs guruvá váljon, azt javasoljuk, hogy először tanulja meg, értse meg és próbálja ki a Lásd: 4.10.6 Replikációval kapcsolatos SQL-parancsok című részben említett összes parancsot. Lásd a 4.10.5 Replikációs beállítások részt a `my.cnf-ben.

Győződjön meg arról, hogy a fő és a szolga kiszolgáló(k)on a MySQL legújabb verziója van telepítve. Használja a 3.23.29 vagy újabb verziót. A korábbi kiadások eltérő bináris naplóformátumot használtak, és olyan hibákat tartalmaztak, amelyeket az újabb kiadásokban javítottak. Nagy kérés: kérjük, ne küldjön hibajelentést anélkül, hogy ellenőrizné, hogy ez a hiba megtalálható-e a legújabb kiadásban.
Állítson be egyetlen replikációs felhasználót a főkiszolgálón FILE jogosultsággal (a MySQL 4.0.2 alatti verzióiban) vagy REPLICATION SLAVE jogosultsággal az újabb MySQL verziókban. Ennek a felhasználónak engedéllyel kell rendelkeznie az összes downstream szerverről való csatlakozáshoz is. Ha a felhasználó csak replikációt hajt végre (ajánlott), akkor nem kell további jogosultságokat megadnia. Például egy repl nevű felhasználó létrehozásához, amely bármely gazdagépről hozzáférhet a fejkiszolgálóhoz, használja a következő parancsot: mysql> GRANT FILE ON *.* TO repl@"%" AZONOSÍTJA: " ";
Állítsa le a MySQL-t a főkiszolgálón. mysqladmin -u root -p leállítás
Hozzon létre egy képet a főkiszolgálón lévő összes adatról. Ennek legegyszerűbb módja (Unix-on) a létrehozása kátrány teljes adatkönyvtárának archívuma. Az adatkönyvtár pontos helye a telepítéstől függ. tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir A Windows-felhasználók a WinZIP vagy hasonló program segítségével adatkönyvtár-archívumot hozhatnak létre.
A főszerver my.cnf fájljában adjon hozzá bejegyzéseket a log-bin bejegyzés szakaszhoz és a szerverazonosító=egyedi számhoz, majd indítsa újra a kiszolgálót. Nagyon fontos, hogy a slave szerver azonosítója eltérjen a szülő szerver azonosítójától. A szerverazonosítót tekinthetjük IP-címnek – ez egyedileg azonosítja a szervert a replikációs tagok között. log-bin szerver-id=1
Indítsa újra a MySQL-t a főkiszolgálón.
Adja hozzá a következőt a my.cnf fájlhoz a slave szerver(ek)en: master-host= master-user= master-password= master-port= server-id= az értékek lecserélése a rendszerének megfelelő értékekkel . A szerverazonosító értékeknek különbözniük kell a replikációban részt vevő egyes kiszolgálókon. Ha a szerver azonosítója nincs megadva, akkor 1-re lesz állítva, ha a master-host szintén nincs megadva, akkor 2-re lesz állítva. Vegye figyelembe, hogy ha a szerver azonosítóját kihagyjuk, akkor a főszerver megtagadja a kapcsolatot az összes szolgával szerverek és a szolga szerver - a szülőkiszolgálóhoz való csatlakozás megtagadása. Ezért csak akkor hagyhatja el a szerverazonosító érték beállítását, ha bináris naplóval készít biztonsági mentést.
Másolja a pillanatképet a szolga szerver(ek) adatkönyvtárába. Győződjön meg arról, hogy a fájlok és könyvtárak engedélyei megfelelőek. A MySQL as-t futtató felhasználónak ugyanúgy tudnia kell adatokat olvasni és írni rájuk, mint a főkiszolgálón.
Indítsa újra a slave szerver(ek)et.

Ha ezek a lépések megtörténtek, a downstream szerver(ek)nek csatlakozniuk kell a felfelé irányuló kiszolgálóhoz, és módosítaniuk kell adataikat, hogy tükrözzék a felfelé irányuló szerveren a kép készítése óta bekövetkezett változásokat.

Ha a szerver -id nincs beállítva a downstream szerverhez, a következő hiba kerül naplózásra a hibanaplóban:

Figyelmeztetés: ha a master_host be van állítva, a server_id értéket nem 0-ra kell beállítani. A szerver nem szolgaként fog működni. (Figyelmeztetés: ha a master_host be van állítva, a server_id értéket nullától eltérő értékre kell beállítani. A szerver nem működik szolgakiszolgálóként.)

Ha a főkiszolgáló azonosítója nincs beállítva, a szolga kiszolgálók nem tudnak csatlakozni a főkiszolgálóhoz.

Ha egy downstream szerver bármilyen okból nem képes replikálni, a megfelelő hibaüzenetek megtalálhatók a downstream szerver hibanaplójában.

Miután a szolga szerver elkezdi a replikációt, egy `master.info" fájl fog megjelenni ugyanabban a könyvtárban, mint a hibanapló. A `master.info" fájlt a szolga szerver használja annak nyomon követésére, hogy a fő szerver mely bináris naplóbejegyzései feldolgozták. Ne törölje vagy szerkessze ezt a fájlt, hacsak nem biztos benne, hogy szükséges. Még ha van is ilyen bizalom, akkor is jobb a CHANGE MASTER TO parancs használata.

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 magában foglalja az adatok megkettőzését egy slave-en MySQL szerver, az ilyen sokszorosítást többnyire a megbízhatóság biztosítása érdekében végzik. 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álja az osztá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.1master

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.

Manapság a MySQL adatbázist szinte mindenhol használják, ahol csak lehetséges. Lehetetlen elképzelni egy webhelyet, amely MySQL nélkül működne. Természetesen vannak kivételek, de ez az adatbázis-rendszer foglalja el a piac nagy részét. És a legnépszerűbb megvalósítás a MariaDB. Ha a projekt kicsi, akkor a futtatásához elegendő egyetlen szerver, amelyen minden szolgáltatás található: webszerver, adatbázisszerver, ill. levelezőszerver. De amikor a projekt nagyobbá válik, előfordulhat, hogy minden szolgáltatáshoz külön szervert kell dedikálni, vagy akár egy szolgáltatást több szerverre kell felosztani, például a MySQL-t.

Az adatbázisok szinkron állapotának fenntartása érdekében az összes kiszolgálón a replikációt egyidejűleg kell használni. Ebben a cikkben megvizsgáljuk, hogyan van konfigurálva a MySQL-replikáció a MariaDB Galera Cluster használatával.

MI A MARIADB GALERA?

A MariaDB Galera a MariaDB fő-fő fürtrendszere. A MariaDB 10.1 óta szoftver A Galera Server és a MariaDB Server egy csomagban találhatók, így azonnal megkapja az összes szükséges szoftvert. Tovább Ebben a pillanatban A MariaDB Galera csak InnoDB és XtraDB adatbázismotorokkal tud működni. A replikáció használatának egyik előnye a redundancia hozzáadása a helyadatbázishoz. Ha az egyik adatbázis meghibásodik, azonnal átválthat egy másikra. Minden szerver szinkronizált állapotot tart fenn egymással, és garantálja, hogy nincsenek elveszett tranzakciók.

A MariaDB Galera főbb jellemzői:

Replikáció állandó szinkronizálással;
Csomópontok automatikus összevonása;
Több fő csomópont összekapcsolásának képessége;
Bármely csomópontra való írás támogatása;
Átlátszó párhuzamos replikáció;
Olvasási és írási méretezhetőség, minimális késleltetés;
A sikertelen csomópontok automatikusan leválasztásra kerülnek a fürtről;
Nem blokkolhatja a táblákhoz való hozzáférést.

MYSQL REPLIKÁCIÓ BEÁLLÍTÁSA

Ebben az oktatóanyagban az Ubuntu 16.04 és a MariaDB 10.1 verzióját fogjuk használni a példában. Mielőtt elkezdené, teljesen frissítse a rendszert:

sudo apt-get frissítés-y
sudo apt-get upgrade -y

Mivel konfigurációnkat több csomóponton fogjuk telepíteni, mindegyiken el kell végeznünk a frissítési műveleteket. Ha a MariaDB adatbázis-kiszolgáló még nincs telepítve, akkor telepíteni kell. Először adja hozzá a tárolót és a kulcsát:

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

sudo add-apt-repository "deb http://ftp.utexas.edu/mariadb/repo/10.1/ubuntu xenial main"

sudo apt-get update -y

Amikor a csomaglista frissítése befejeződött, telepítse a MariaDB-t a következő paranccsal:

sudo apt install mariadb-server rsync -y

A közvetlen szinkronizáláshoz szükségünk van az rsync csomagra. A telepítés befejezése után biztonságossá kell tennie az adatbázist a mysql_secure_installation szkript segítségével:

sudo mysql_secure_installation

Alapértelmezés szerint a vendég bejelentkezés engedélyezett, van tesztadatbázis, és nincs beállítva jelszó a root felhasználó számára. Mindezt korrigálni kell. Bővebben a cikkben. Röviden, válaszolnia kell néhány kérdésre:

Adja meg a root jelenlegi jelszavát (ne írja be):
Megváltoztatja a root jelszót? n
Eltávolítja a névtelen felhasználókat? Y
Letiltja a root bejelentkezést távolról? Y
Eltávolítja a tesztadatbázist, és hozzáférhet hozzá? Y
Újratölti a jogosultságtáblázatokat most? Y

Ha minden készen áll, folytathatja a csomópontok beállítását, amelyek között a mysql adatbázisok replikálódnak. Először nézzük meg az első csomópont beállítását. Az összes beállítást megadhatod a my.cnf-ben, de jobb lenne létrehozni külön fájl erre a célra az /etc/mysql/conf.d/ mappában.

Adja hozzá ezeket a sorokat:

binlog_format=ROW

innodb_autoinc_lock_mode=2
kötési cím=0.0.0.0

wsrep_on=BE

wsrep_sst_method=rsync
# Galera Node konfiguráció
wsrep_node_address="192.168.56.101"
wsrep_node_name="Node1"

Itt a 192.168.56.101 cím az aktuális csomópont címe. Ezután lépjen egy másik szerverre, és ott hozza létre ugyanazt a fájlt:

sudo vi /etc/mysql/conf.d/galera.cnf

binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
kötési cím=0.0.0.0
# Galera szolgáltató konfigurációja
wsrep_on=BE
wsrep_provider=/usr/lib/galera/libgalera_smm.so
# Galera Cluster konfiguráció
wsrep_cluster_name="galera_cluster"
wsrep_cluster_address="gcomm://192.168.56.101,192.168.56.102"
# Galera szinkronizálási konfiguráció
wsrep_sst_method=rsync
# Galera Node konfiguráció
wsrep_node_address="192.168.56.102"
wsrep_node_name="Node2"

Hasonlóképpen, itt a csomópont címe 192.168.0.103. Maradjunk a példánál két szervernél, mivel ez elegendő a rendszer működésének bemutatásához, és a wsrep_cluster_address mezőbe egy további IP-cím beírásával is felvehet egy másik szervert. Most fontolja meg, mit jelentenek a fő paraméterek értékei, és folytassa az indítással:

binlog_format- a napló formátuma, amelyben a kérések mentésre kerülnek, a sorérték azt jelzi, hogy ott bináris adatok kerülnek tárolásra;
alapértelmezett tárolómotor- motor SQL táblák amelyet használni fogunk;
innodb_autoinc_lock_mode- AUTO_INCREMENT értékgenerátor üzemmód;
kötési címet- IP-cím, ahol a program figyelni fogja a kapcsolatokat, esetünkben az összes IP-cím;
wsrep_on- tartalmazza a replikációt;
wsrep_provider- könyvtár, amellyel a replikáció végrehajtásra kerül;
wsrep_cluster_name - a fürt neve, minden csomóponton meg kell egyeznie;
wsrep_cluster_address- azon szerverek címeinek listája, amelyek között a mysql adatbázisok replikálódnak, vesszővel elválasztva;
wsrep_sst_method- az adatátvitelhez használt szállítást;
wsrep_node_address- az aktuális csomópont IP-címe;
wsrep_node_name- az aktuális csomópont neve.

Beállítás MySQL replikáció majdnem elkészült. Az indítás előtti utolsó érintés a tűzfal beállítása. Először engedélyezze az iptables szabálykezelő eszközt az Ubuntuban - UFW:

Ezután nyissa meg ezeket a portokat:

sudo ufw engedélyezi a 3306/tcp-t
sudo ufw 4444/tcp engedélyezése
sudo ufw 4567/tcp engedélyezése
sudo ufw engedélyezi a 4568/tcp-t
sudo ufw engedélyezése 4567/udp

INDÍTSA EL MARIADB GALERÁT

Az összes csomópont sikeres beállítása után már csak el kell indítanunk a Galera klasztert az első csomóponton. A fürt elindítása előtt meg kell győződnie arról, hogy a MariaDB szolgáltatás le van állítva az összes szerveren:

sudo galera_new_cluster

A következő paranccsal ellenőrizheti, hogy fut-e a fürt, és hány gép csatlakozik hozzá:

Most csak egy gép van ott, most menjen egy másik szerverre, és futtassa ott a csomópontot:

sudo systemctl start mysql

Ellenőrizheti, hogy az indítás sikeres volt-e, és hogy történt-e hiba a paranccsal:

sudo systemctl állapot mysql

Ezután ugyanezen parancs futtatásával ellenőrizni fogja, hogy az új csomópont automatikusan hozzáadásra került-e a fürthöz:

mysql -u root -p -e "státusz megjelenítése, például "wsrep_cluster_size""

A replikáció működésének ellenőrzéséhez egyszerűen hozzon létre egy adatbázist az első csomóponton, és ellenőrizze, hogy valóban hozzáadták-e az összes többihez:

mysql -u root -p

MariaDB [(nincs)]> adatbázis létrehozása teszt_db;
MariaDB [(nincs)]> adatbázisok megjelenítése;