Fokozott rendelkezésre álló MySQL Cluster algoritmus és választott - szóló cikk

MySQL Cluster - a döntés, hogy építsenek hibatűrő rendszerek. A bevezetőben egy rövid leírást az alapfogalmak, a részletes információkat a dokumentációban. Az alábbiakban leírt érvényes változata MySQL Cluster 5.1, található a kiadás időpontjában a cikkeket a kiadásra jelölt szakaszban.

Noda lesz az úgynevezett logikai szerver alkotó klaszter. De egyetlen fizikai szerveren lehet helyezni több csomópontot. A klaszter három fő típusa csomópontok:

  1. Az adatok csomópont (NDB-node) - végrehajtható folyamat ndbd, felelős tárolására fragmens adatokat a fürt. Fontos NoOfReplicas klaszter paraméter (száma replikák) - az adatok száma csomópontok, amelyben minden egyes fragmentum van tárolva. A teljes száma az adatok csomópontok többszörösének kell lennie számának replikák. Csoport csomópontok - csomópont számát (a csomópontok száma a csoportban az a szám, replikák), amely tárolja a ugyanazt az információt. Például NoOfReplicas = 2, a csomópontok száma - 6. Mindegyik táblázat van osztva 6 darab (a hash az elsődleges kulcs), felsorolni azok F1, F2, F3, F4, F5, F6. 6 csomópontok (D1, D2, D3, D4, D5, D6) 3 csoport - minden egyes csoport az első csomópont (D1, D2) tárolja a fragmensek F1, F2; csomópontok a második csoport D3, D4 tárolt töredékek F3, F4; A csomópontok a harmadik csoport D5, D6 tárolt töredékek F5, F6. Elmulasztása minden csomópont egy csoport vezet tény, hogy a klaszter.
  2. SQL-csomópont (vagy API-node) - végrehajtható folyamat mysqld. A SQL-csomópont elfogadja kliens kapcsolatok és hozzáfér az adatokat a csomópontok az adatokat. Ezen túlmenően, minden egyes SQL-csomópont tárolja a saját nem-NDB asztal (MyISAM, InnoDB.), Mintha nem volt része a klaszter.
  3. Management csomópont (menedzsment-node) - végrehajtható folyamat ndbmgmd. Felelős a fürtkonfiguráció, minden csomópont hozzáfér a menedzsment csomópont, amikor a kapcsolat a klaszter. Nem szabályozza tranzakciók és egyéb aktuális ügyek, és koncentrál kizárólag a konfigurációt. Ez fogyaszt kis erőforrás, ezért gyakran az ugyanazon a fizikai szerverről a másikra csomópontjában. Meghibásodása esetén a vezérlő csomópontok, a klaszter továbbra normális működését, de nem lesz képes újraindítani a csomópontot. A konfiguráció tartalmaz egy vagy több vezérlő csomópontok.

Döntőbíró és választottbírósági algortimy

Egy cluster node mindig a döntőbíró. A kijelölt döntőbíró az indulás vagy a klaszter és változtatni lehet a döntőbíró változást eljárást. A választott bíró kijelöléséről, valamint a változás megtalálható a naplókat a klaszter. Az alapértelmezett beállítás szerint a döntőbíró egy menedzsment csomópont, de ez nem feltétlenül van így. Választottbíró lehet bármilyen kezelése vagy az SQL-csomópont. Ezek a csomópontok a konfigurációs megadható paraméter ArbitrationRank (választott bíró helyezés); paraméter értékek: 0 - a csomópont soha nem lesz a döntőbíró, 1 - a csomópont lesz a döntőbíró a kiemelt; 2 - Noda lesz a döntőbíró csak akkor, ha nincs jelölt nagy priritetom. Minden egyes pillanatban a klaszter egyetlen döntőbíró.

Letiltása egy csomópont csoport, agyhasítás

A döntőbíró van szükség egy olyan helyzetben, ahol a klaszter megszakad több csomópont. Hagyja, hogy a klaszter fizikailag osztható 2 darab (például hálózat miatt nem marshrutirizatora). Lehetséges, hogy minden egyes darab tárolja az összes a klaszter adatok (azaz, legalább egy csomóponthoz minden csoportban). Minden darab fog működni, mint egy teljes fürt, ami zavar a az adatok sértetlenségét (például, hogy egyes ügyfelek fognak dolgozni egy szelet, és néhány - a másikba). Ez a helyzet veszélyes, és az úgynevezett osztott agy.

választottbírósági algoritmus

választottbírósági algoritmus meglehetősen egyszerű. Kezd el dolgozni azonnal észlelése után töredezettség minden munkanapon adatok node cluster töredékek.

  1. Látok legalább egy adat csomópont minden egyes csoportból (más szavakkal -, hogy a látható része a klaszter összes adat)? Ha nem - kikapcsol. Ha igen, továbbra algoritmus
  2. Vannak olyan lemorzsolódási adatok csomópontok csomópont minden csoportban (más szóval -, hogy a második rész az összes adat)? Ha nem -, majd kikapcsolja a második része az 1. szabály, én továbbra is. Ha igen, folytassa az algoritmust.
  3. Kérdezd döntőbíró. Ha a játékvezető nem tudja - kikapcsol. Ha egy választottbíró áll, hogy kiderítse jelen vagyok a jelenlegi konfiguráció - ha nem áll le, és ha igen -, hogy folytassa a munkát

Változás döntőbíró

Ha ennek eredményeképpen a fragmentáció eltűnt döntőbíró, miután a választottbírósági algoritmus csomópontok válasszon új választottbírót. A kiválasztási algoritmus most egyszerű - a csomópont kiválaszt a legalacsonyabb sorszámú (nodeID), amelynek körében vezető ArbitrationRank.

Miért van a konfiguráció a két személy nem okazoustoychivoy?

Tekintsük az alábbi konfiguráció postoennuyu két fizikai gépek:

  • Az első kiszolgáló - adatok 1 csomópont, az SQL csomópont-1, a vezérlő csomópont 1
  • A második kiszolgáló - adatok 2 csomópont, az SQL csomópont-2 (is lehetséges, hogy ellenőrizzék a 2 csomópont)

Jelentése NoOfReplicas = 2 nyújt adatokat redundanciát; mindkét csomópontja része ugyanabban a csoportban. Első pillantásra úgy tűnik, hogy a konfigurációs otkzoustoychiva, de a gyakorlatban nem. Amikor kiindulási klaszter arbiter fog első vezérlési csomópontot. Tekintsük a helyzetet, amelyben a hibás első szerver (pl leállt, leégett a hálózati kártya vagy hibás port marshrutirizatore). A második adat csomópont választottbírósági algoritmus munkák:

  1. Lásd, ha egy csomópont minden egyes csoportban? Igen, csak egy csoport a csomópont - I.
  2. Ez nem otklyuchivashayasya része egy komplett adatokat? Igen, az adatok 1 csomópont egy másolatát tartalmazza az adatokat.
  3. Kérdezd döntőbíró. A döntőbíró nem elérhető. Leállt.

Látjuk, hogy az egyik meghibásodása szerver letiltja az egész fürt. Ugyanez fordulhat elő konfiguráció három szerverek és NoOfReplicas = 3, ha a szerver ki van kapcsolva, amely a döntőbíró.

Egy egyszerű példa a hibatűrő konfiguráció

Hogy az olvasó arról, hogy a következő konfigurációs stabil kapcsolatban az a tény, valamint a három fizikai szerverek:

  • Az első kiszolgáló - adatok 1 csomópont, SQL-1 csomópont (ArbitrationRank = 0), (NoOfReplicas = 2)
  • A második kiszolgáló - adatok csomópont 2, SQL-2 csomópont (ArbitrationRank = 0), (NoOfReplicas = 2)
  • Harmadik szerver - az irányító csomópontot (ArbitrationRank = 2)

Adatredundanciát nem garancia az átállást. Mindig előteszt konfiguráció segítségével a fent leírt agloritma vagy fizikai disconnect szerverek.