MCCGE – MySQL Cluster Carrier Grade Edition

MySQL Cluster, šta reći osim da je jedan od manje poznatih dragulja među proizvodima MySQL-a. MySQL Cluster je „moj posao“ već nekoliko godina, donosi mi leba, mesa, goriva …. kriv je što mi je brada posedela, što gubim kosu… ček, nije, debilni korisnici su krivi za ovo drugo, ali, da ne davim … nisam pisao neko vreme pošto je bilo puno posla oko 7.0, imali smo neke zanimljive probleme, radili veliki sistem za Verizon … sve u svemu .. evo jedne male priče o tome čemu MySQL Cluster stvarno služi i šta jeste a šta zapravo nije.

Da krenemo prvo od toga šta MySQL Cluster nije a što mnogi potencijalni korisnici, razni SUN prodavci, mnogi „developeri“ misle da jeste.

MySQL Cluster nije zamena za ORACLE RAC.

Mnogo vreme, para i energije sam/smo utrošili objašnjavajući ovu činjenicu raznim prodavcima, developerima, što van SUN-a, što unutar. MySQL Cluster ima neke mogućnosti o kojima ORACLE RAC može samo da sanja ali u opštem slučaju MySQL Cluster ne može da zameni ORACLE RAC i performanse koje će MySQL Cluster imati u poređenju će biti i do 100 puta lošije.

Šta je onda MySQL Cluster?

MySQL Cluster je „shared nothing“, „no single point of failure“, HA (high availability) RDBMS. Šta to znači i čemu to zluži?

MySQL – ima neke veze sa MySQL-om
Cluster – koristi grupu računara a ne samo jedan
shared nothing – nijedan resurs se ne deli izmedju komponenti (na primer ORACLE RAC  ima shared storage, dakle disk je deljen između nodova)
no single point of failure – nema „problematične tačke“, dakle ako bilo koji deo sistema crkne, sistem će nastaviti da radi (na primer na ORACLE RAC-u ako crkne storage, ceo ORACLE RAC ode u %$?/%$# )
HA – high availabiliti, velika dostupnost, mnogo devetki, MySQL Cluster može da obezbedi 99.999% uptime.

Zvuči dobro? Kako onda nije zamena za RAC? :)

Kako izgleda MySQL Cluster sistem, šta ga čini, kako radi – to će nam verovatno reći i šta su mu mane i zašto ne može da zameni ORACLE RAC kao i gde mu je u primena.

Svaki deo MySQL Cluster-a se zove „nod“ (čvor). Nodovi MySQL Cluster-a se dele u 4 osnovne grupe:

• management nodovi
• data nodovi
• sql nodovi
• api nodovi

Management nodovi (ndb_mgmd) nisu neophodni za rad MySQL Cluster-a. Ne moraju da budu na dedicated mašini, i ne troše nikakve ozbiljne resurse. Management nod (bar jedan) je neophodan pri startovanju klastera, pri rekonekciji ostalih nodova i u slučaju da je potrebna arbitracija mada ovu funkciju u slučaju da nijedan management nod nije dostupan može da preuzme bilo koji api ili sql nod. Management nodovi takođe vode log o svim dešavanjima na klasteru i daju informacije o svim nodovima klastera kroz NDB API ili kroz command line interface applikaciju ndb_mgm. Poželjno je imati 2 management noda na klasteru mada je i jedan dovoljan pošto je ovo nod bez koga klaster može da radi.

Data nodovi (ndbd, ndbmtd) čuvaju vaše podatke. Tu se nalaze tabele, slogovi … MySQL Cluster nudi opciju NoOfReplica koja služi da definiše koliko kopija vaših podataka želite da imate u klaster. Standardna vrednost je 2 ali su moguće i vrednosti 3 i 4 mada nisu preporučene pošto nigde nemamo u production okruženju testiran klaster sa NoOfReplica različit od 2. Data nodova može da bude do 40 i svi vaši podaci se nalaze na ovim datanodovima. Data nod treba da bude na dedicated mašini. Cluster može da „preživi“ da ostane bez 50% data nodova ali ne „bilo kojih“ 50%. Pošto se svaki podatak nalazi na tačno dva data noda (i to uvek na data nodovima sa IDem jedan za drugim, dakle prvi i drugi data nod imaju iste podatke, treci i cetvrti, peti i sesti, sedmi i osmi i tako dalje). Ako iz klastera ispadnu dva data noda koji imaju iste podatke (na primer treci i cetvrti) ceo klaster će da rikne pošto nema sve podatke. Ima tu sada komplikovana priča šta se kada i zašto dešava, net split, detekcija i rezolucija split brain scenarija i slicno … sve u svemu bitno je znati da se svi podaci nalaze na data nodu. Do verzije 7.0 data node je umeo da koristi maksimalno 2 jezgra na serveru što je danas sa novim mnogo jezgarnim procesorima prilična mana tako da je od verzije 7.0 uveden novi binary (ndbmtd) koji je kompatibilan sa starim ndbd (u 7.0 postoje oba, koristite ndbd ako imate do 2 jezgra i ndbmtd ako imate vise) ali ume da koristi do 8 jezgara. I dalje data nod ne može da koristi više od 8 ali za sada to ne bi trebalo da predstavlja problem.

SQL nodovi su MySQL serveri koji su učlanjeni u klaster. Ovim MySQL serverima vi pristupate iz vaše aplikacije kao što bi pristupali običnom MySQL serveru sa razlikom da svi ovi MySQL serveri vide identične podake u ndbcluster tabelama. Sve promene su sinhrone tako da ako na jednom MySQL serveru promenite neki podatak on je odma vidljiv na svim MySQL serverima, tako da na primer možete bez problema da radite insert u istu tabelu iz 20 različitih MySQL servera. Maksimalni broj SQL nodova je limitiran ukupnim brojem nodova koji se iz verzije u verziju menja. do 6.2 je ukupni limit nodova bio 64 za GPL i 128 za CGE verziju MySQL Clustera, od nekog 6.2 i u 6.3 bi trebalo da je limit podignut na 256 za obe verzije (isti je sigurno za obe verzije ali se ne secam više da li je 128 ili 256), sve u svemu, može mnogo da ih bude… SQL nodovi nisu „standardni“ MySQL server, već poseban MySQL server koji dolazi uz MySQL Cluster. Prave se od „najsvežijeg MySQL servera u trenutku izlaženja cluster-a plus ndbcluster patchevi“. Bilo koji MySQL server može da crkne i to ne uslovljava rad klastera. Klaster će raditi sve i ako nijedan MySQL server ne radi.

API nodovi su „specijalni nodovi“ koji su generalno „vaše aplikacije koje koriste ndb API“. NDB API je API koji vam daje mogućnost da se direktno okačite na data nodove i tražite ili šaljete podatke na klaster. Nudi veliku brzinu (do 10 puta brži pristup podacima nego kroz SQL nod) ali je rad mnoooogo komplikovaniji od jednostavnog pisanja SQL upita.

Sve je to naravno spojeno netom, sve to naravno sedi u lan-u, nije moguće razbacati nodove na različite geografske lokacije, saobraćaj koji ide između nodova je velik i ne trpi kašnjenja, loše linkove i slično.

Super, dalkle 30% mašina mi crkne i sve i dalje radi, lepo, ali šta ako hoću da odradim upgrade na novu verziju. MySQL je najzad izbacio 7.0 koji ima mt data node koji ume da iskoristi 8 jezgara na mojim serverima i ja oću da pređem sa 6.3 na 7.0, ali ne smem da imam downtime…

Nije problem :D. MySQL Cluster može da se upgradeuje ONLINE!! Šta to znači – to znači da bez prekida rada, bez da vaši klijenti primete bilo šta, možete da odradite upgrade celog sistema. Isto tako postoji gomila drugih stvari koje klaster ume da odradi ONLINE, na primer, želite da dodate novo polje u neku tabelu. Na normalnom MySQL-u bi taj alter lokovao tabelu i dok se proces ne završi niko ne bi mogao ništa da piše po toj tabeli. U nekom slučaju bi je zalokovao i za read – to nije online … MySQL Cluster vam daje mogućnost da to odradite ONLINE dakle taj alter table će da radi, niko neće da primeti ništa, i onda puf, odjednom evo je nova kolona … BEKAP, koliko problema ste imali da napravite bekap vaše 20G baze na MySQL-u, mysqldump zalokuje samo tabelu koju dampuje pa dobijete bekap koji nije konzistentan ili zalokuje sve tabele pa vam je baza neupotrebljiva minutima (ili satima) dok se bekap ne završi. lvmbackup, hotbackup, innodbhotbackup, svi oni samo ubrzavaju pravljenje bekapa ali nijedno od tih rešenja ne može da napravi konzistentan bekap bez prekida servisa. MySQL Cluster ima ONLINE BACKUP, dakle imate konzistentan point in time backup koji ne lokuje ništa!!

Super, a gde je kvaka, naravno, uvek ima kvaka … podaci na klasteru su distribuirani, dakle vaša tabela se nalazi na nekoliko servera koji su povezani internetom, super, SELECT * FROM t1 WHERE a=b; radi super … ali, pogledajmo ovo, SELECT * FROM t1 JOIN t2 USING x JOIN t3 USING y JOIN t4 using z WHERE …; radimo join iz nekoliko tabela, sve te tabele su razbacane po serverima, podataka ima svuda, spojiti sve to i poslati nazad na mysql košta mnoooooooooooooooooooogo vremena tako da će taj upit biti i do 100 puta sporiji nego na običnom InnoDB-u. To znači da sve to super radi ako nemate kompleksne joine. Idealno radi sa PK ACCESS-om, dakle ako pristupate podacima direktno preko primarnog ključa MySQL Cluster je najbrža i najsigurnija stvar na svetu, ali ako vam treba kompleksni join, zaobiđite MySQL Cluster u širokom luku i odaberite neko drugo MySQL HA rešenje (ili platite ORACLE RAC).

Za početak dovoljno. Videću da ovih dana napravim nekoliko postova sa primerima kako se setuje i koristi MySQL Cluster.