Replikáció- a terhelés alatt működő rendszerek architektúrájában használt technika, amelynek eredménye a terhelés eloszlása egy adatbázissal több szerver között. 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 másolását egy szolga MySQL szerverre, az ilyen sokszorosítást leginkább a megbízhatóság biztosítása érdekében végzik. Ha a Master szerver meghibásodik, 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 működik, a leggyakoribb műveletek a következők KIVÁLASZTÁS- adatolvasá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 az 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 és megbízhatóságot érhet el.
A megoldás népszerű, de nem mindig alkalmazható, mivel előfordulhatnak késések a replikáció során – ha ez megtörténik, az információkat a Master szerverről is ki kell olvasni.
Egy bizonyos típusú kérések egy adott adatbázis-kiszolgálóhoz irányítása mindenesetre az alkalmazás szintjén valósul meg.
Ha program szinten különválasztja a SELECT lekérdezéseket és az összes többit úgy, hogy elküldi őket a címre szükséges szerver Ha valamelyik meghibásodik, az infrastruktúra által kiszolgált alkalmazás működésképtelenné válik. Ahhoz, hogy ez működjön, többet kell nyújtania összetett áramkörés lefoglalja az egyes szervereket.
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
Cseréljük le az /etc/hostname fájlban lévő meglévő értékeket master és slave értékre, hogy a változtatások érvénybe lépjenek, és újraindítsák a szervert.
1. A főszerveren végezzük el a beállításokat.
root@master:/#
A fő szerkesztése konfigurációs fájl adatbázis szerver
mcedit /etc/mysql/my.cnf
Válassza ki a szerver azonosítóját - tetszőleges 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 - szintén alapértelmezés szerint, törölje a megjegyzéseket
Állítsa be 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ó szükséges jogait
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ÁRVAL;
A Master szerver állapotának ellenőrzése:
+——————+———-+—————+——————+
| Fájl | Pozíció | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+—————+——————+
| mysql-bin.000001 | 327 | db1 | |
+——————+———-+—————+——————+
1 sor a készletben (0,00 mp)
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
root@slave:/#
5. Adatbázis létrehozása
A szeméttelep betöltése:
mysql -u root -p db1< db1.sql
6. Módosítsa a my.cnf fájlt
mcedit /etc/mysql/my.cnf
Az azonosítót a Master szerveren beállított érték növelésével rendeljük hozzá
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ő tárnapló 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. Hozzon létre 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ő kéré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 méretezés, de a fő hátrány az adatmásolás deszinkronizálása és a késleltetés, ami kritikus lehet.
Egy korszerűbb megoldás használata lehetővé teszi ezek teljes elkerülését. Könnyen beállítható, megbízható, és szükségtelenné teszi az adatbázis-kiíratások kézi másolását.
Itt található egy rövid leírás a MySQL-kiszolgáló teljes replikációjának beállításáról. Feltételezzük, hogy az összes adatbázis replikálva lesz, és a replikációt korábban nem konfigurálták. Az itt leírt lépések végrehajtásához rövid időre le kell állítania a fejkiszolgálót.
Ez a legegyszerűbb módja a slave szerver telepítésének, de nem ez az egyetlen módja. Például, ha már van kép a főkiszolgálóról, a főkiszolgálón már van beállított kiszolgálóazonosító és naplózás, a szolgakiszolgáló telepíthető anélkül, hogy leállítaná a főkiszolgálót, vagy akár frissítési zárakat is beállítana (további információkért lásd: 4.10. .7 Gyakran ismétlődő GYIK.
Ahhoz, hogy valódi MySQL-replikációs guru legyen, azt javasoljuk, hogy először tanulja meg, értse meg és próbálja ki a Lásd: 4.10.6. A replikációval kapcsolatos SQL-parancsok című szakaszban említett összes parancsot. A `my.cnf' fájlból való replikáció indításának beállításait is át kell tekintenie: Lásd a 4.10.5. fejezet Replikációs beállítások a `my.cnf' fájlból című részben.
- Győződjön meg arról, hogy a MySQL legújabb verziója telepítve van a fő- és szolgakiszolgáló(k)on. 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 a hiba megtalálható-e a legújabb kiadásban.
- Állítson be egy külön replikációs felhasználót a fejkiszolgálón FÁJL jogosultsággal (a MySQL 4.0.2-nél régebbi verzióiban) vagy REPLICATION SLAVE jogosultsággal az újabb MySQL verziókban. Ennek a felhasználónak engedéllyel kell rendelkeznie az összes szolgakiszolgálóró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 adni neki. 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 fejkiszolgálón. mysqladmin -u root -p leállítás
- Hozzon létre egy képet a fejkiszolgálón lévő összes adatról. Ennek legegyszerűbb módja (Unixon) a létrehozás kátrány a teljes adatkönyvtár 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 más hasonló program segítségével adatkönyvtár-archívumot hozhatnak létre.
- A főkiszolgálón lévő my.cnf fájlban adjon hozzá bejegyzéseket a log-bin bejegyzési szakaszhoz, a szerverazonosító=unique számot pedig a szakaszhoz, majd indítsa újra a kiszolgálót. Nagyon fontos, hogy a slave szerver azonosítója eltérjen a főkiszolgáló azonosítójától. Tekinthetjük, hogy a szerver-id egy IP-cím szerepét tölti be - ez egyedileg azonosítja a szervert a replikációs résztvevők között. log-bin szerver-id=1
- Indítsa újra a MySQL-t a fejkiszolgálón.
- Adja hozzá a következőt a my.cnf fájlhoz a szolga 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-id érték nincs megadva, akkor 1-re lesz állítva, ha a master-host értéke szintén nincs megadva, akkor 2-re lesz állítva. Vegye figyelembe, hogy ha a szerver-id értéket kihagyjuk, akkor a főszerver megtagadja a kapcsolatokat az összes szolga szerverrel, és a slave szerver megtagadja a csatlakozást a főszerverhez. 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ép adatokat a szolga szerver(ek) adatkönyvtárába. Győződjön meg arról, hogy a fájl- és könyvtárjogosultságok helyesek. A MySQL-t futtató felhasználónak ugyanúgy tudnia kell adatokat olvasni és írni rájuk, mint a fejkiszolgálón.
- Indítsa újra a slave szerver(eke)t.
A lépések végrehajtása után a szolgakiszolgáló(k)nak csatlakozniuk kell a főkiszolgálóhoz, és hozzá kell igazítaniuk adatait a főkiszolgálón a lemezkép elfogadása után bekövetkezett változásokhoz.
Ha a szolga kiszolgáló -azonosítója nincs beállítva, a következő hiba kerül naplózásra:
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 meg van adva, a server_id értéket nullától eltérő értékre kell beállítani. A kiszolgáló nem működik szolgakiszolgálóként.)
Ha a fejkiszolgáló azonosítója nincs beállítva, a slave szerverek nem tudnak csatlakozni a fejkiszolgálóhoz.
Ha egy szolgakiszolgáló bármilyen okból nem képes replikálni, a hibaüzenetek a szolgakiszolgáló hibanaplójában találhatók.
Amint a szolgaszerver elkezdi a replikációt, egy `master.info' fájl jelenik meg 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 történtek. feldolgozott. Ne törölje vagy szerkessze ezt a fájlt, hacsak nem biztos benne, hogy szükséges. Még ha ennyire magabiztos is, akkor is jobb a CHANGE MASTER TO parancs használata.
Nem sokkal ezelőtt 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 erről fogok beszélni mit jelent a replikáció a MySQL-ben, mikor van rá szükség és hogyan kell konfigurálni.
A replikáció fő feladata az egyesítsék több szerver erejét. Tegyük fel, hogy webhelyének van dedikált szervere, de idővel nagyon látogatott lesz, és már nem bírja a terhelést. Ennek eredményeként a szerver lelassul és rendszeresen összeomlik. 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 idő, 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 az adatbázis egyszerre két szerveren lesz. Ha az egyik főszerver (más néven a főszerver) már nem tud megbirkózni, akkor átvált egy tartalék szerverre.
Minden az adatbázis-frissítési kérések mindig a fejkiszolgálóhoz mennek. A fejkiszolgáló frissítése után elhelyezi az erről szóló információkat külön fájl, ahonnan a slave szerverek minden információt megkapnak. De a mintavételezési műveletek, amelyek általában többségben vannak, és ezek a leglassabbak, már átvihetők a slave szerverekre, mivel az adatok mindkettőben ugyanazok.
Most találjuk ki hogyan kell konfigurálni a replikációt a MySQL-ben:
- Telepítse a legtöbbet a MySQL legújabb verziói minden szerverre.
- Hozzon létre egy felhasználót a jogosultságokkal a fő kiszolgálón A SLAVE CSERÉJE. A címhez, ahonnan csatlakozhat, adja meg a " Minden".
- Á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=a létrehozott_felhasználó bejelentkezése
master-password=a Created_user jelszava
master-port=port_for_connecting_to_the_master_server
szerver-azonosító=ez_szolga_kiszolgáló_azonosítója - Mozgassa meg az összes alapot a főszervertől a rabszolgákig.
- Fuss a főszerver, majd az összes rabszolga.
A replikáció sikeres használatához a MySQL-ben a következőket kell tennie:
- Győződjön meg arról, hogy a MySQL verzió >= a Master-re telepített verzió telepítve van a Slave-ként működő kiszolgálón. A replikáció fordított sorrendben is lehetséges, a mesternek több is van új verzió a Slave-en egy régebbivel, de ennek az opciónak a működése nem garantált.
- Ellenőrizze a MySQL Slave kiszolgáló és a Master közötti kapcsolatot (# mysql -hMASTERHOST -uroot -p), mert előfordulhat, hogy a tűzfal le van zárva.
Egy MySQL adatbázis mester-szolga replikációja
Ez egy egyszerű példa az egyik mester-szolga replikációja MySQL adatbázisok . Azok, akik először csinálják ezt, ezzel a példával kezdjék, és pontosan kövessenek az utasításokat.
Először is különböző azonosítókat kell regisztrálnia a mester és a slave szerverekhez. A Mester szerveren engedélyeznie kell a bináris naplózást (log-bin), meg kell adnia a replikációhoz szükséges adatbázist, és létre kell hoznia egy szolga szerver felhasználót, amelyen keresztül a slave szerver adatokat kap a mastertől. Tovább slave szerver a továbbítási napló be van kapcsolva, meg van adva a replikáció adatbázisa, és elindul a szolga replikáció.
MASTER: A MySQL Master szerveren végrehajtott műveletek.
My.cnf szerkesztése – MySQL konfigurációs fájl. Elhelyezkedése attól függ operációs rendszerés magának a MySQL-nek a beállításait. A my.cnf fájlban a következő paraméterek adódnak hozzá a szakaszokhoz:
szerver azonosító = 1
# Útvonal a bináris naplóhoz.
# A fájlnév kiterjesztés nélkül van írva, mivel a kiterjesztés úgyis telepítve lesz
# MySQL szerver által automatikusan (.000001, .000002 stb.)
# Célszerű a mysql-bint annak a könyvtárnak a gyökerében keresni, ahol az összes adatbázis tárolva van,
# az engedélyekkel kapcsolatos problémák elkerülése érdekében.
log-bin =/ var/ lib/ mysql/ mysql- bin
# A replikálandó MySQL adatbázis neve
A my.cnf módosítása után újra kell indítania a MySQL-t. Egy vagy több mysql-bin.000001, mysql-bin.000002, ... fájlnak meg kell jelennie a bináris napló tárolására szolgáló könyvtárban (log-bin).
Most maximális jogokkal rendelkező felhasználóként kell csatlakoznia a MySQL-hez, és létre kell hoznia egy felhasználót (rpluser_s500) jelszóval (cserélje ki a PASSW-t), amelyen keresztül a Slave szerver adatokat kap az adatbázis frissítéseiről:
mysql> A replikációs szolga engedélyezése BE * .* TO "rpluser _s500"@"%
"
A "PASSW" AZONOSÍTÁSA ;
mysql> FLUSH JOGOSULTSÁGOK ;
$ mysqldump -- törzsadatok - hHOST - uUSER - p dbreplica > dbreplica.sql
Betöltés alatt kiírható az adatbázisból, de meg kell jegyezni, hogy ha az adatbázis nagy, akkor a kiírás írása közben az adatbázis nem lesz írható.
SALVE: A MySQL Slave szerveren végrehajtott műveletek.
Először is szerkesztenie kell a my.cnf fájlt a következő részben:
# Főkiszolgáló azonosítója (1 és 4294967295 közötti szám)
szerver azonosító = 500
# A közvetítőnapló elérési útja, amely a főkiszolgálótól kapott adatokat tárolja
# A követelmények ugyanazok, mint a bináris napló esetében.
relay- log =/ var/ lib/ mysql/ mysql- relay- bin
relay- log- index =/ var/ lib/ mysql/ mysql- relay- bin .index
# Annak az adatbázisnak a neve, amelybe az összes módosítást be kell írni,
# előfordulhat az adatbázisban ugyanazzal a névvel a főkiszolgálón
replikáció-do- db= "dbreplica"
A my.cnf módosítása után indítsa újra a MySQL-t.
mysql> ADATBÁZIS LÉTREHOZÁSA dbreplica
Most fel kell töltenie egy dumpot:
$ mysql - uROOT - p dbreplica< dbreplica.sql
Ezután beállítunk egy kapcsolatot a főkiszolgálóval, ahol a MASTER_HOSTNAME_OR_IP helyére a MySQL főkiszolgáló címe vagy IP-címe kerül, a MASTER_USER és a PASSWORD pedig a felhasználó hitelesítő adatai, amelyet a Master szerveren hoztak létre, hogy csatlakozzon a slavehez:
mysql> CHANGE MASTER TO MASTER_HOST = "MASTER _HOSTNAME_OR_IP", MASTER_USER = "rpluser _s500", PASSWORD = "JELSZÓ" ;
A kérés lefuttatása után az adatbázis tárolási könyvtárában létrejön egy master.info fájl, amelybe a Mesterrel való kapcsolat adatai kerülnek.
A replikáció elindításához már csak egy kérést kell küldenie a MySQL-nek:
mysql> START SLAVE;
Ezek után, ha minden jól ment, láthatja, hogy a Master szerveren lévő adatbázisban minden változás hogyan jelenik meg a Slave adatbázisában.
MySQL replikációs beállítások
Bináris naplófájl beállításai (log-bin)
MySQL bináris napló a szerver adatbázisokban bekövetkező változások naplózására szolgál. A replikációhoz engedélyezni kell a főkiszolgálón a slave szervereken, csak akkor szabad használni, ha a slave egy másik MySQL-szolga mestere is. A naplózás engedélyezése egy paraméter hozzáadásával a mysql.cnf szakaszhoz:
log-bin = mysql-bin
A példabeállításokban: „Egy MySQL-adatbázis mester-szolga replikációja” a bináris naplózás engedélyezve volt az összes MySQL-adatbázishoz. Ha csak bizonyos adatbázisokhoz kell bejelentkeznie, például a DB_NAME1 és a DB_NAME2, akkor a varázsló my.cnf fájljához beállításokat kell adnia. binlog-do-db:
binlog-do- db= "DB _NAME1"
binlog-do- db= "DB _NAME2"
Azaz fel kell sorolni az adatbázis összes nevét, ahol minden adatbázisnak megvan a saját sora a binlog-do-db paraméterrel. Ennek az operátornak az antonimája binlog-ignore-db="DB_NAME", amely arra utasítja a MySQL-t, hogy naplózza az összes adatbázist, kivéve a binlog-ignore-db paraméterekben megadottakat.
Ha adatbázisokat ad meg, vesszővel elválasztva, például így:
A binlog-ignore-db paraméter helytelen használata!
binlog- ignore- db= "DB _ NAME3, DB_ NAME4"
akkor első pillantásra minden úgy fog működni, ahogy kell – nincs hiba, de valójában a DB_NAME3 és DB_NAME4 adatbázisok nem lesznek kizárva a bináris naplóból: a MySQL úgy fogja tekinteni, hogy a "DB_NAME3, DB_NAME4" egy "" nevű adatbázis DB_NAME3, DB_NAME4" " (azaz vessző és szóköz van az adatbázis nevében)!
Mielőtt egy adatbázist hozzáadna vagy kizárna a bináris naplóból, meg kell értenie, hogyan és milyen módokban működik a MySQL bináris naplója. Ez határozza meg a replikáció megbízható működését, az adatok konzisztenciáját és a megvalósítás során fellépő hibák számát (a teljes kiküszöbölésig).
A bináris napló adattárolási formátumáért felelős paraméter - binlog_format, amely a MySQL 5.1-től kezdve 3 értéket vehet fel: STATEMENT (alapértelmezés szerint a MySQL = 5.7.7-ben használatos) és MIXED.
NYILATKOZAT – MySQL bináris naplózási mód
NYILATKOZAT- ebben a módban a szokásos SQL lekérdezések információ hozzáadására, frissítésére és törlésére további szolgáltatási adatokkal íródnak a bináris naplóba. Ilyen bejelentkezés megnyitásával szöveg szerkesztő, megtalálhatja benne az adatbázisban lévő adatok módosítására vonatkozó kérelmeket szöveges formátum. A binlog_format=STATEMENT használatának előnyei: viszonylag kis fájlméret, a napló megtekintésének lehetősége a mysqlbinlogban vagy a PHPMyAdminban. A hátrányok az SQL lekérdezések használatában rejlenek, erről alább.
Tételezzük fel, hogy a bináris naplóhoz csak egy adatbázishoz adnak hozzá adatokat (binlog - do- db= "felhasználók"). A következő lekérdezés, amely közvetlenül érinti a "felhasználók" adatbázist, nem kerül naplózásra a bináris naplóban:
1. példa
USE kliensek;
Felhasználók FRISSÍTÉSE.számlák BEÁLLÍTOTT összeg= összeg+ 5 ;
Ezt a viselkedést az okozza, hogy az alapértelmezett "kliensek" adatbázist használják, amely nem kerül naplózásra a bináris naplóban Kimutatás módban.
Egy másik példa, amikor a binlog-do-db-ben nem megadott adatbázishoz intézett kérés a bináris naplóba kerül:
2. példa
USE felhasználók;
UPDATE ügyfelek.kedvezmények SET százalék= százalék+ 5 ;
Ez továbbra is ugyanúgy történik, az alapértelmezett adatbázis használata miatt, de ebben az esetben „rossz”, „extra” lekérdezések kerülnek a bináris naplóba.
Mind az első, mind a második kérés váratlan következményekkel járhat, ha replikációt használ a slave kiszolgálón. Az első példából származó kérés esetén a Master és a Slave szerveren eltérőek lesznek az adatok: a mesteren az összeg=összeg+5 végrehajtásra kerül, a slave-en nem. A második kérés használatakor egy kérés érkezik a Slave-hez, hogy módosítsa az adatokat egy olyan adatbázisban, amely nincs regisztrálva a slave-ek listájában, és a Master-Slave replikáció meghiúsul, ha a kliensek adatbázisa nem létezik a slave-en vagy.. módosításokat hajt végre az adatbázistáblán, ha van ilyen. Így a Master-Slave replikáció során bináris log Statement módban módosíthatja a slave szerver adatbázisát, amelyet nem replikációra szántak! Csak találgatni lehet, hogy az ilyen változtatások milyen következményekkel járhatnak, ezért nagyon óvatosnak kell lennie a Statement bináris naplózási mód használatakor.
Egy másik probléma bináris naplózás Kimutatás módban történő használatakor jelentkezhet, ha a Slave szerver úgy van beállítva, hogy az eredetitől eltérő nevű adatbázisokba írjon. Például egy adatbázist replikálnak egy mester db_countries kiszolgálóra, ahol ugyanazt az adatbázist db_countries_slave-nek nevezik (az új adatbázis nevét a slave szerveren a replicate-rewrite-db="db_countries->db_countries_slave" paraméter határozza meg, és egy új adatbázisnév már hozzá van rendelve a replikációhoz: replicate-do-db="db_countries_slave"). Amíg a mester az adatbázisban lévő adatokat frissíti a USE db_countries és UPDATE nevek SET ... használatával, minden rendben van, de amint egy olyan kérés érkezik, amely megadja az adatbázis nevét, például: UPDATE db_countries.names SET ... replikáció a Slave hibával leáll: A "db_countries.names" tábla nem létezik a lekérdezésben. Alapértelmezett adatbázis: "db_countries_slave". Lekérdezés: UPDATE db_countries.names SET .... ROW módban nincs ilyen probléma.
ROW – bináris naplózási mód
SOR- ha ezt a bináris naplótárolási módot választja, csak a kiválasztott adatbázisok módosításai kerülnek a fájlba bináris formátumban. Az adatok sokkal több helyet foglalhatnak, mint a nyilatkozat módban. Ennek a replikációs típusnak azonban van egy fő előnye – ebben a módban a replikáció sokkal biztonságosabb, mint a Statement esetében.
Csak a binlog-do-db vagy binlog-ignore-db paraméterekkel definiált adatbázisok megváltozott adatai kerülnek a bináris naplóba. Az alapértelmezett adatbázis nem befolyásolja ezt a viselkedést. Ennek köszönhetően az 1. példa lekérdezései után a frissítési adatok a bináris naplóba kerülnek, de a második példa sql-je már nem kerül kiírásra.
Több Részletes leírás Az Utasítás és a Sor mód előnyei és hátrányai a hivatalos angol nyelvű dokumentációból kiolvashatóak: 17.1.2.1 Az utasításalapú és soralapú replikáció előnyei és hátrányai.
VEGYES - bináris naplózási mód
VEGYES- olyan mód, amelyben a bináris napló egyidejűleg 2 replikációs módot használ: az utasítást és a sort a különböző kérések adatainak tárolására. A vegyes bináris naplózási mód működéséről többet megtudhat a hivatalos angol nyelvű dokumentációból: 5.4.4.3 Vegyes bináris naplózási formátum. Ez nem jelenti azt, hogy ez egy ideális lehetőség, de ha megérti a Mixed működését, akkor a gyakorlatban is használható.
Automatikus bináris napló törlése - expire_logs_days
Alapértelmezés szerint a bináris naplók soha nem törlődnek automatikusan. A naplótároló automatikus törléséhez használja az expire_logs_days paramétert, amely megadja, hogy a MySQL hány napig tárolja a bináris naplót.
Példa egy bináris napló automatikus törlésére, több mint 10 nap telt el a létrehozása óta
expire_logs_days= 10
Egyéb hasznos bináris naplóbeállítások
Felhasználó a Slave és a Master összekapcsolásához
Master-Slave replikáció esetén legalább egy felhasználói fiók szükséges a főkiszolgálón, amelyet a slave használ a csatlakozáshoz. Az ilyen fiókok hozzáférési jogainak követelményei: az egyetlen REPLICATION SLAVE jogosultság az adatbázisokhoz, táblákhoz való hozzáférés megnyitása vagy bármilyen más jogosultság hozzáadása - nem szükséges. Egy REPLIKÁCIÓS SLAVE-vel rendelkező felhasználót különböző slave szerverek használhatnak arra, hogy egyidejűleg fogadják az adatokat a főszervertől, vagy minden slave számára külön felhasználó hozható létre.
Nem szabad replikációhoz használni fiókot bármilyen kiterjesztett hozzáférési joggal felruházva. A főszerverhez való csatlakozáshoz szükséges bejelentkezési név és jelszó tiszta szövegben tárolódik a slave-en (master.info fájl az adatbázist tartalmazó könyvtárban).
mysql> FELHASZNÁLÓ LÉTREHOZÁSA "replicat" @"10.0.0.1" A "pass" AZONOSÍTÁSA ;
mysql> REPLIKÁCIÓS SLAVE MEGHATÁROZÁSA * .* A "replikációhoz" @"10.0.0.1" ;
A 10.0.0.1-es IP-cím a Slave szerver IP-címe, le kell cserélni egy valódira. Az sql lekérdezéseknél az IP-címet lecserélhetjük a speciális % szimbólumra, majd bármelyik gépről kapcsolódhatunk a masterhez, de biztonsági okokból érdemes a slave szerver valós címére korlátozni magunkat.
További beállítások
Az InnoDB típusú táblákat és tranzakciókat használó adatbázisok legmegfelelőbb replikációja érdekében a következő sorokat kell hozzáadnia a főkiszolgáló konfigurációjához (my.cnf szakasz):
innodb_flush_log_at_trx_commit= 1
sync_binlog= 1
Viszonylag nemrégiben ismerkedtem meg a MySQL szerverek replikációjával, és miközben különféle kísérleteket végeztem a konfigurációval, leírtam, hogy nekem mi vált be. Amikor elég sok anyagot gyűjtöttem össze, jött az ötlet, hogy megírjam ezt a cikket. Megpróbáltam tippeket és megoldásokat gyűjteni 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 tudom úgy tenni, mintha teljesen leírnám, de remélem, hasznos lesz a cikk.
Rövid bemutatkozás
A replikáció (a latin replikó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. Hívjuk a fő szervert 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 hajtódnak végre, míg az adatok olvasására irányuló lekérdezések (más szóval: SELECT) végrehajthatók mind a replikákon, mind a mesteren. Az egyik replikán végzett replikációs folyamat nincs hatással a többi replika működésére, és gyakorlatilag nincs hatással a mester munkájára.
A replikáció a mesteren karbantartott bináris naplók használatával történik. Minden olyan lekérdezést tárolnak, amely változásokhoz vezet (vagy potenciálisan vezethet) az adatbázisban (a lekérdezések nincsenek kifejezetten mentve, így ha meg akarja nézni őket, akkor a mysqlbinlog segédprogramot kell használnia). A binlogok átkerülnek replikákba (a mesterről letöltött binlogot "továbbító binlognak" 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ó során nem maguk a megváltozott adatok kerülnek átvitelre, hanem csak a kérések okozzák a változásokat.
A replikáció során az adatbázis tartalma több szerveren duplikálódik. Miért szükséges a sokszorosításhoz folyamodni? Ennek több oka is van:
- teljesítmény és skálázhatóság. Előfordulhat, hogy egy szerver nem tudja kezelni az adatbázis egyidejű olvasási és írási műveletei által okozott terhelést. A replikák létrehozásának előnyei annál nagyobbak, minél több írási olvasás van a rendszeren.
- 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 replika „lelassítható” egy ideig a mysqldump végrehajtásához, de a master nem.
- halasztott számítások. A nehéz és lassú SQL-lekérdezések külön replikán is végrehajthatók, anélkül, hogy félnünk kellene az interferenciától normál működés az egész rendszert.
A replikáció beállítása
Tegyük fel, hogy van egy működő MySQL adatbázisunk, amely már tele van adatokkal és be van kapcsolva. A fent leírt okok egyike miatt engedélyezni fogjuk a szerverünk replikációját. Kiinduló adataink:- A fő IP-cím 192.168.1.101, a replikák 192.168.1.102.
- MySQL telepítve és konfigurálva
- be kell állítania a testdb adatbázis-replikációt
- szüneteltethetjük a varázslót egy időre
- természetesen mindkét gépen van root
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 szakaszban:szerverazonosító = 1
log-bin = /var/lib/mysql/mysql-bin
replikáció-do-db = tesztdb
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 alatt a replikáció végrehajtásra kerül. A "replikációs slave" jogosultság elegendő:
mysql@master> GRANT replikációs slave ON "testdb".* TO "replication"@"192.168.1.102" A "jelszó" AZONOSÍTJA;
Indítsa újra a MySQL-t, hogy a konfigurációban végrehajtott módosítások életbe lépjenek:
root@master# szolgáltatás mysqld újraindítás
Ha minden jól ment, a "show master status" parancsnak valami ilyesmit kell mutatnia:
mysql@master> 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 az adatbázis módosításával a mesteren.
Replika beállítások
Adjuk 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 töltsük be ú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
replikáció-do-db = tesztdb
Root@replica# service mysqld újraindítás
Adatátvitel
Itt zárolnunk kell az adatbázist az íráshoz. Ehhez leállíthatja az alkalmazásokat, vagy használhatja a csak olvasható jelzőt a mesteren (figyelem: ez a jelző nincs hatással a SUPER jogosultsággal rendelkező felhasználókra). Ha vannak MyISAM tábláink, akkor "kimossuk a táblákat" is:mysql@master> A TÁBLÁZATOK ÖBLÍTÉSE AZ OLVASÁSZÁROLÁSSAL;
mysql@master> SET GLOBAL read_only = 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ékekre (a mester sikeres blokkolása után ezek nem változhatnak):
Fájl: mysql-bin.000003
Pozíció: 98
Kiírjuk az adatbázist, és a művelet befejezése után eltávolítjuk a mester zárolását:
mysql@master> 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” parancsokkal, és megnézzük, hogy minden rendben ment-e:
mysql@replica> 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
mysql@replica> szolga indítása;
A MASTER_LOG_FILE és MASTER_LOG_POS értékeit a mestertől vesszük.
Nézzük meg, hogyan megy a replikáció a "show slave status" paranccsal:
mysql@replica> 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. Ha a replikáció sikeresen elindul, értéküknek megközelítőleg meg kell egyeznie 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 bármilyen egész szám lehet.
Ha a replikáció normális, a replika követni fogja a mestert (a Master_Log_File naplószáma és az Exec_Master_Log_Pos pozíciója nő). A mester másolatának késleltetési idejét (Seconds_Behind_Master) ideális esetben nullával kell egyenlőnek 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 bekövetkező változásokat.
Ha a Slave_IO_State üres, és a Seconds_Behind_Master értéke NULL, akkor a replikáció nem indult el. Tekintse meg a MySQL naplót, hogy megtudja az okot, szüntesse meg és indítsa újra a replikációt:
mysql@replica> szolga indítása;
Ezekkel az egyszerű lépésekkel olyan replikát kapunk, amelynek adatai megegyeznek a mester adataival.
Mellesleg, amikor a master blokkolva van, akkor jön létre a dump. Ha elfogadhatatlanul sokáig tart 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 engedélyezze a mestert.
- indítsa el a replikációt a szokásos módon.
Replikák hozzáadása
Tegyük fel, hogy már van egy működő mesterünk és egy replikánk, és hozzá kell adnunk még egyet. Ezt még egyszerűbb megtenni, mintha az első replikát hozzáadnánk a mesterhez. És ami sokkal szebb, hogy ehhez nem kell megállítani a mestert.Először is állítsuk be a MySQL-t a második replikán, és győződjön meg arról, hogy beléptünk szükséges paramétereket a konfigurációban:
szerverazonosító = 3
replikáció-do-db = tesztdb
Most állítsuk le a replikációt az első replikán:
mysql@replica-1> Szolga leállítása;
A replika továbbra is normálisan fog működni, de a rajta lévő adatok már nem aktuálisak. Nézzük meg az állapotot, és emlékezzünk arra a fő pozícióra, amelyet a replika elért a replikáció leállítása előtt:
mysql@replica-1> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G
A szükséges értékek Master_Log_File és Exec_Master_Log_Pos:
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:
mysql@replica-1> 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:
mysql@replica-2> MASTER MÓDOSÍTÁSA MASTER_HOSTRA = "192.168.1.101", MASTER_USER = "replikáció", MASTER_PASSWORD = "jelszó", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_5P OSTER_15_5P;
mysql@replica-2> 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ő replika „show slave status” parancsának 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 dump jön létre). Így két másolatunk lesz azonos adatokkal.
Replikák egyesítése
Néha a következő helyzet adódik: két adatbázis van a mesteren, amelyek közül az egyik az egyik replikán, a másik 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á azokat a mesterre vagy leállítaná? Egészen egyszerűen 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 replika-2 replikákon. Állítsuk be mindkét adatbázis replikációját a replika-1-re 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:
mysql@replica-2> STOP SLAVE;
mysql@replica-2> 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 (ez befejezi a replika-2-vel végzett manipulációkat). A kiíratást visszaállítjuk a replika-1-re.
A replika-1 helyzete a következő: a testdb1 adatbázis egy fő pozícióban van, és folytatja a replikációt, a testdb2 adatbázist egy másik pozícióból visszaállították egy kiíratból. Szinkronizáljuk őket.
Állítsuk le a replikációt, és emlékezzünk a mester pozíciójára:
mysql@replica-1> STOP SLAVE;
mysql@replica-1> 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 második adatbázis neve szerepel a szakaszban:
replikáció-do-db = tesztdb2
Indítsuk újra a MySQL-t, hogy a konfiguráció módosításai érvénybe lépjenek. A MySQL-t egyébként egyszerűen újra lehetett indítani a replikáció leállítása nélkül – a naplóból megtudhatnánk, hogy a masterben melyik pozícióban állt le a replikáció.
Most replikáljunk abból a pozícióból, ahol a replika-2 szüneteltetve volt arra a helyre, ahol éppen szüneteltettük a replikációt:
mysql@replica-1> MASTER MÓDOSÍTÁSA MASTER_HOSTRA = "192.168.1.101", MASTER_USER = "replikáció", MASTER_PASSWORD = "jelszó", MASTER_LOG_FILE = "mysql-bin.000015", MASTER_LOG_1P OSTER_231;
mysql@replica-1> a slave indítása, 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, ezután 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:
mysql@replica-1> SLAVE ÁLLAPOT MEGJELENÍTÉSE\G
mysql@replica-1> START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501
Adjuk hozzá mindkét adatbázis nevét a replika-1 konfigurációjához a következő szakaszban:
replikáció-do-db = tesztdb1
replikáció-do-db = tesztdb2
Fontos: minden adatbázist külön sorban kell felsorolni.
Indítsa újra a MySQL-t, és folytassa a replikációt:
mysql@replica-1> MASTER MÓDOSÍTÁSA MASTER_HOST-RA = "192.168.1.101", MASTER_USER = "replikáció", MASTER_PASSWORD = "jelszó", MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_1POSTER_50_1;
Miután a replika-1 utoléri a mestert, az adatbázisuk tartalma azonos lesz. Az adatbázist a replika-2-be egyesítheti hasonló módon, vagy a replika-1 teljes kiíratásával.
Castling mester és replika
Szükség lehet a replikát fő módba kapcsolni, például fő hiba esetén vagy egy műszaki munka. Egy ilyen váltás lehetővé tételéhez a replikát úgy kell konfigurálnia, mint a mestert, vagy el kell készítenie azt passzív mester.Engedélyezzük a bináris naplózást (a binlogok továbbítása mellett) a konfigurációs szakaszban:
log-bin = /var/lib/mysql/mysql-bin
És adjon hozzá egy felhasználót a replikációhoz:
mysql@master> A replikációs szolga MEGHATÁROZÁSA 'testdb'-n.* A 'replication'@'192.168.1.101'-HOZ A "jelszó" AZONOSÍTJA;
A passzív mester úgy hajtja végre a replikációt, mint egy rendes replika, de emellett bináris logikákat hoz létre - vagyis elindíthatjuk belőle a replikációt. Ellenőrizzük ezt a "show master status" paranccsal:
mysql@replica> MESTER ÁLLAPOT MUTATÁSA\G
Fájl: mysql-bin.000001
Pozíció: 61
Binlog_Do_DB:
Binlog_Ignore_DB:
Most, hogy a passzív mestert aktív módba kapcsolja, 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.
mysql@master> A TÁBLÁZATOK KIÖBLÍTÉSE AZ OLVASÁS ZÁROLÁSSAL
mysql@master> SET GLOBAL read_only = BE;
mysql@replica> STOP SLAVE;
mysql@replica> MESTER ÁLLAPOT MUTATÁSA;
Fájl: mysql-bin.000001
Pozíció: 61
mysql@master> 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;
mysql@master> szolga indítása;
Ez az, ezért lecseréltük az aktív mestert. Eltávolíthatja a blokkot a korábbi mesterről.
Következtetés
Megtanultunk egy kicsit a replikáció beállításáról a MySQL-ben és néhány alapvető művelet végrehajtásáról. Sajnos a következő fontos kérdések nem tartoznak a cikk keretei közé:
- 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ál, bármelyikük meghibásodása rendszerhibát eredményez, hacsak nem gondoskodunk erről. Gondoskodnunk kell a helyzet kezeléséről a master és a replika hibája esetén. Az egyik létező eszköz az MMM, azonban ezt fájllal módosítani kell.
- terhelés elosztás. Több replika használata esetén átlátszó kiegyenlítő mechanizmust szeretnénk alkalmazni, különösen akkor, ha a replikák teljesítménye egyenetlen. Linux alatt lehetőség van egy szabványos 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, az adatok megváltoztatására vonatkozó kéréseket pedig a masternek kell elküldeni. A replikák lehetséges késése miatt azonban egy ilyen séma gyakran hatástalan, és azonosítani kell azokat az olvasási kéréseket, amelyeket még végre kell hajtani a masteren.
Köszönöm a figyelmet!
Betöltés...