Tapasztalat a percona xtradb klaszterbe való migrációhoz
Ezért kezdtem el implementálni a Percona XtraDB Cluster-et a szervezetemben - a rendszeres MySQL-kiszolgáló adatbázisainak egy fürtözött architektúrába történő fordítását.
Röviden a feladatról és a bemeneti adatokról
A klaszterben meg kell tartanunk:
- DB több weboldalt a felhasználókkal
- DB a felhasználók statisztikai adataival
- DB a jegyrendszerekhez, a projektmenedzsment rendszerekhez és egyéb apróságokhoz
Más szóval, szinte minden projektünk adatbázisát, azoktól, amelyekre a MySQL-t futtatjuk, most klaszterben kell élniük.
A legtöbb projekt, amelyet távolról tartunk DC-ben, így a klaszter ott lesz.
A fürt földrajzi kiterjesztése a különböző adatközpontok között nem érdemes.
Hogy hozzanak létre egy cluster segítségével 3 azonos szerver konfiguráció: HP DL160 G6, 2X Xeon E5620, 24 GB RAM, 4x SAS 300GB RAID 10. A jó hardver alatt márka vas, amit használni hosszú ideig, és hogy nem sikerül.
Miért Percona?
- Szinkron igaz többmester replikáció (Galera)
- A Percona kereskedelmi támogatásának lehetősége
- MySQL fork az impozáns optimalizálási listával
A klaszter rendszere
A fürtben 3 csomópont, mindegyik fenti fizikai szerverhez (OS Ubuntu 12.04).
Az A csomópont referencia (biztonsági másolat) csomópontként működik, amelyet alkalmazásaink nem töltenek be kérésekkel. Ezzel egyidejűleg a klaszter teljes jogú tagja lesz, és részt vesz a replikációban. Ez úgy történik, annak a ténynek köszönhető, hogy meghibásodás esetén a klaszter, vagy adat a korrupció, akkor van egy node, amely szinte biztosan tartalmazza a legtöbb zsírok adatokat, hogy az alkalmazás egyszerűen nem lerombolja hiánya miatt hozzáféréssel. Talán úgy néz ki, pazarló kiadások források, de nekünk a 99% az adatok megbízhatósága még fontosabb, mint a rendelkezésre álló 24/7. Ez a csomópont fogunk felhasználni SST - Állami Snapshot Transfer - automata leeresztő kiírási csatlakozik a klaszter egy új csomópont, vagy mászni egy hiba után. Ezenkívül az A csomópont kitűnő jelölt a szerver számára, ahonnan normál rendszeres biztonsági másolatokat készítünk.
Szekvenciálisan mindezek így képviselhetők:
A B csomópont és a C csomópont olyan állományok, amelyek terhelést tartanak, de csak az egyikük gondoskodik az írás műveleteiről. Ez sok szakember ajánlása, és az alábbiakban részletesen foglalkozom ezzel a kérdéssel.
Kiegyenlítő részletek
A 3306-os kikötőbe érkező kérelmek. A HAProxy a Round Robint a B és C csomópontok között szállítja.
A 3307-es változat csak a B csomóponton található proxy. Ha a B csomópont hirtelen esik, akkor a kérések a megadott C csomóponthoz jutnak.
A megvalósításhoz eszméink (írni csak az egyik csomópont) alkalmazások kell írni az olvasási kérés megy keresztül a kapcsolatot 10.0.0.70:3306 (10.0.0.70 - mi a VIP), írási irányítani 10.0.0.70: 3307.
A mi esetünkben ez szükségessé tehet egy új kapcsolatot a PHP konfigurációs fájlban, és a DBHandler változó nevét más értékkel kell helyettesíteni. Általában ez nem olyan nehéz azoknak az alkalmazásoknak, amelyeket írtunk. A harmadik féltől származó projektek esetében, amelyek adatbázisai a fürtben lesznek, egyszerűen csak a 3307-es portot definiáljuk. A projektek terhelése kicsi, és a megosztott olvasás lehetőségének elvesztése nem olyan kritikus.
HAProxy konfiguráció (/etc/haproxy/haproxy.cfg):
Annak érdekében, hogy a HAProxy meg tudja határozni, hogy egy fürtcsomópont él-e, a clustercheck segédprogramot használják. (tartalmazza a percona-xtradb-klasztert), amely HTTP válaszként megjeleníti a csomópont állapotinformációkat (szinkronizált / nem szinkronizált). Minden egyes csomóponton xinetd szolgáltatást kell konfigurálni:
Csomópontok konfigurálása
Először is, ne felejtsd el szinkronizálni az időt minden csomóponton. Hiányoztam ezt a pillanatot, és sokáig nem tudtam megérteni, hogy az én SST szorosan feszes-e - elindult, lógott a folyamatokban, de valójában nem történt semmi.
my.cnf az A csomóponton (konfigurációmban node105):
Továbbá csak a különböző paraméterek:
Az elmúlt két configs mi egyértelműen megmondja a szervernek, hogy hol keresse az első csomópont a klaszter (aki tudja, hol a csoport tagjai élő), és hogy ez volt vele, nem pedig más rendelkezésre álló, meg kell gyűjteni az adatokat szinkronizálni kell.
Ezzel a konfigurációval most már leálltam, és a projekteket fokozatosan egy klaszterbe fordítom. Folytatom a tapasztalataim további írásáról.
Problémás kérdések
Jelezni fogom itt a kérdéseket, hogy nem találtam azonnal a választ, de a válasz különösen fontos a technológia megértéséhez és a klaszterhez való helyes munkához.
Miért ajánlott írni egy csomóponton a fürt összes elérhetőségén? Végtére is úgy tűnik, hogy ez ellentmond a multi-master replikációnak.
Saját vizsgálatok azt mutatták, hogy az agresszív belépési minden csomóponton ment az egyik a másik után, így csak a munka referencia csomópont, azaz Valójában azt mondhatjuk, hogy a klaszter megállt. Ez határozottan egy hátránya ebben a konfigurációban, mert a harmadik csomópont is, ebben az esetben, hogy a terhet a saját, de biztosak vagyunk abban, hogy az adatok nem ép, és a legrosszabb eset, akkor manuálisan futtatni egy mű egyetlen szerver módban.
Ennek két irányelve van:
Ezeknek az irányelveknek a jelentése kezdetben különleges zavart okozott nekem.
Az a tény, hogy sok füzet arra figyelmeztette a fürt első csomópontját, hogy hagyja el a gcomm: // üres értékét a wsrep_urls-ban.
Kiderült, hogy ez rossz. A gcomm: // jelenléte új klaszter inicializálását jelenti. Ezért közvetlenül a konfiguráció első csomópontjának kezdete után törölnie kell ezt az értéket. Ellenkező esetben a csomópont újraindítása után két különböző klaszter kapható, amelyek közül az egyik csak az első csomópontból áll.
Saját magam számára megmutattam a konfiguráció sorrendjét, amikor a fürt elkezdődött és újraindult (már részletesebben leírtuk)
1. A csomópont: kezdődik a gcomm: // B, gcomm: // C, gcomm: //
2. A csomópont: a gcomm: // eltávolítása a vonal végén
3. B, C csomópontok: kezdődik a gcomm: // A
Megjegyzés: meg kell adnia a portszámot a csoportos kommunikációs kérelmekhez, az alapértelmezett érték a 4567. Ez a helyes bejegyzés: gcomm: // A: 4567
Lehetséges, hogy nem blokkoló xtrabackup-ot használunk SST-módszerként egy adományozó csomóponton?
SST során clustercheck a donor megjeleníti HTTP 503, illetve az HAProxy vagy más LB, amely felhasználja ezt az eszközt, hogy meghatározza a helyzetét a donor csomópont elérhetetlennek minősül, valamint a csomópont, amelybe az átcsoportosítás történik. De ez a viselkedés megváltoztatható a clustercheck szerkesztésével. amely lényegében egy normál bash script.
Ez a következő szerkesztéssel történik:
Megjegyzés: ezt csak akkor teheti meg, ha biztos benne, hogy a xtrabackup SST-ként van használva. és nem valamilyen más módszert. Abban az esetben, ha egy csomópontot donorként adományozunk, ez a korrekció egyáltalán nem értelmezhető.