Zero app downtime - MariaDB Galera Cluster

Još jedno od mojih početničkih pitanja :)

Recimo da imam jedan LB.
Iza njega 2x web server + 2x DB.
Ta dva DB servera su u klasteru.

Kako bi išao update recimo te neke web aplikacije, a da imam 0 downtime?

Kapiram da bih recimo sa LB privremeno slao posetioce na jedan web server, recimo tamo gde je web app povezana sa slave DB node-om?
Nekako isključim sinhronizaciju ta dva DB servera. (ako je to moguće)
Uradim publish aplikacije na onaj "otkačeni" web server, i izmene nad bazom.
Nakon testa usmerim LB onda na taj ažurirani web server.
Odradim publish aplikacije na tom drugom serveru, recimo rsync fajlova sa prvog.
Šta sa bazom onda? Aktiviram sinhronizaciju ponovo? Šta će biti ukoliko je bilo u međuvremenu nekih izmena podataka u nekoj od tabela na tom slave DB nodu? Hoće li biti konflikta ili će samo da se master node dopuni sa tim izmenama?

Jednostavno resenje je da slave DB tokom update-a stavis u read-only mode.
Komplikovanije i bolje je da sve transakcije koje su uradjene nad slave bazom nakon sto glavni sajt opet postane live jednostavno izvrsis nad glavnom bazom.
U principu, treba imati podrsku u samoj aplikaciji za te stvari, bez toga ne znam moze li uopste da ide.

Ne moze Galera na 2 masine ako hoces da radi. Napravi obican master-slave i podesi neki plivajuci IP za auto-fail, da ti, ako master ne radi, taj IP predje na slave. Ako je baza mala, samo GPL Mysql, pa ces menajti kad zatreba. Ako je velika, slobodno Percona, ne cluster vec obican server.


:D

Prvo, ako sve radi normalno, ne znam zasto bi morao da gasis replikaciju da pustis izmene nad bazom.

Ako moras, onda ide tako nekako kako si opisao:

- Ugasis replikaciju.
- Izbacis jedan web server sa LB-a
- Namestis da taj web server gadja slave
- Pustis izmene na njega
- Prebacis saobracaj da gadja taj web server
- Namestis da stari master postane slave od novog
- Uradis update koda na drugi web server

Mada, realno i u produkciji, skoro nikad nemas toliko izmena na bazi da ne mozes da ih pustis na master. Izmene koje traze takve izmene su alter table na tabelama od vise miliona redova, jedino to. Ako ti je izmena dodavanje tabele, ili dodavanje indexa na tabeli od par desetina hiljada redova to ce lockovati na par sekundi, to moze u produkciji - bude server spor 20s nije nista strasno.

Update koda ide kroz verzije i zamene symlinkova da bi bio atomican. Tako radi i jenkins i envoyer i gomila alata imas lepo opisano kad znas sta da trazis :) Obicno se i kod update-uje u produkciji bez izbacivanja servera sa LB-a.

Ovo sto ti opisujes je kad su neke bas bas izmene, cilj treba da bude continuous deployement, tako da izmene idu na produkciji sve vreme :D

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Nije mi jasno šta misliš kad kažeš da ne može Galera na 2 mašine?
Daj pls neki link na šta misliš kad kažeš plivajući IP. Recimo u AWS okruženju da koristim EIP

Verovatno da sam iskomplikovao zamišljanjem kako to u praksi izgleda, ali dobro si pretpostavio da razmišljam o CD.

Nemam iskustva sa app developmentom pa ne znam kakve izmene nad bazom inače mogu da se očekuju.

Ako uzmem na primer neku PHP app poput WordPress, Magento i slično, tu mi je jasno...
Instaliram plugin neki, to će biti izmene nad fajlovima, i dodavanje nekih novih tabela. To bi trebalo da bude banalno, i ne bi trebalo da može da ugrozi bazu.

Kako ja zamišljam CD...

Sa git hooks dočekam merge sa nekim dev branch-om, i jenkinsom okinem git pull na tom nekom dev serveru, skriptu koja će importovati nova tebele.
Istestiram ako radi sve kako treba, uradim onda opet merge sa master branch, i onda to ode i na public server.
A da bi bilo 0 downtime sam mislio da bih trebao pomocu LB da kontrolisem publish na produkciju

Nema čarobnog štapića kojim to možeš da uradiš onako kako zamišljaš. A to nije samo na MySQL bazi. Recimo, pogledaj Oracle Editioning koji postoji na Oracle bazi od verzije 11, pa ćeš videti da i pored ogromne podrške u vezi sa edicijama baze, postoji gomila stvari koja nije jednostavna.

Pogledaj na guglu "database versioning". Postoji dosta "best practices" stvari, ali to što ti hoćeš nije nešto što DBA može sam da uradi, potrebna je kompletna promena metodologije razvoja softvera, a još ako baza podržava neke napredne tehnike, utoliko bolje.
Samo da se ne razočaraš, sve super radi na stranicama nekog opskurnog IT časopisa kada ti je cela šema ukupno tri tabele i sve je lepo i ružičasto, samo što to nikada nije slučaj u praksi.

Ti nekom objektu u bazi (na primer tabeli) možeš da pristupiš preko njenog imena, možeš preko sinonima, možeš preko pogleda. Na oracle bazi čak i možeš da radiš update ili delete sloga iz pogleda (sa ograničenjima) korišćenjem INSTEAD OF trigera.
Jedna taktika koja radi na SVIM bazama je da svaku novu verziju objekta kreiraš u posebnoj šemi. Recimo imaš tabelu MyTable1 u šemi appv1. Ovoj tabeli pristupaš tako što je zoveš sa appv1.MyTable1 što je jako glupo.
Drugi pristup je da napraviš usera (šemu) appv1user koji će imati u svojoj šemi sinonim na appv1.MyTable1. Onda bazi pristupaš kao appv1user i gađaš tabelu preko SynMyTable1 (ne mora Sym, to sam stavio da se vidi da je to sada privatni sinonim u šemi appv1user, a ne prava tabela).

Napraviš ogromnu izmenu i staviš tabelu u šemu appv2, pa kreiraš usera appv2user koji ima isti sinonim SynMyTable1, ali koji pokazuje na šemu appv2, ne više na appv1.

Onda promeniš aplikaciju da se više ne kači na bazu kao appv1user nego kao appv2user.
Još treba da obezbediš da se izmene nastale od momenta puštanja nove aplikacije, pa sve do momenta kada se završe sve sesije koje koriste appv1user konekciju uradi ažuriranje i nove tabele.

To nije uvek potrebno, recimo ako dodaš kolonu tabeli, sve će raditi kao i pre, osim ako glupavi developeri ne rade glupave stvari (recimo SELECT * ili INSERT bez navođenja liste kolona).

uh.....

vidim da cu morati da naucim i da programiram i administriram db :)

^
Za jednostavnije aplikacije dovoljan ti je onaj članak iz časopisa ;)

Dobro je znati više od toga, ali ako hoćeš više od toga, teško to ide i sa decenijama iskustva. Uvek dobro dođe nečija pomoć.
Ja sam u principu da svako radi svoj posao, ako je veća i zbiljnija baza, onda obavezno db administrator nezavisno od programera / programskog tima.
Možeš da budeš i multipraktik, ali teško je pohvatati sve znanje ovog univerzuma, a uz to još biti produktivan.

Potpis

Moj Veb Sajt HostCentar Blog
Aleksinac Južna Srbija TimeOut

tako je nastao cuveni "devops" - iliti multipraktik, koji zna dovoljno
od svega da bi mogao da napravi tako nesto :)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Možemo to da shvatimo kao sarkazam, jer Devops je nešto drugo ;)

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

Pa sad ako developer nije tako nesto predvideo. U principu, ako se struktura baze ne menja, nema tu nesto posla za zamenu web aplikacije.
A ako se menja, e sad sta ces, onda moras da gurnes bazu off dok se ne izvedu neophodne promene.
Samo ne znam kako ces ti onda izvesti to sto developer nije predvideo ;p

Pa ste je drugo nego deployment and testing?

kako nisu, nesto ti tu nisi dobro svatio

devops == madjionicar, kad nesto zase1234es njega okrivis i magicno
nemas vise problem

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Al si ti vickast.... :) Mada, da ne pocinjem ko to radi i kako... :)

@Coyote:

- Izmene koda idu prilicno fino. CD u praksi, sa PHP aplikacijama ide skroz live :

1) Napravis DocRoot koji je /neki/path/current/public
2) Napravis /neki/path/releases/1 (pri release)
3) Napravis current kao symlink na releases/1

Sledeci put, dignes releases/2, promenis symlink, reloadujes php-fpm/nginx/apache, obavezno reloadujes opcache - i to je to.

Ako napravis dovoljno testova u pipeline-u, nema nikakvog razloga zasto ne bi radio i CD. Ako ima neki monitoring, koji moze da okine rollback, ako aplikacija pocne da vraca greske, sve moze i sme da ide automatski. Mozes sve ovo da resis sa malo vise truda krozcist gitlab-ci.yml (OK, mnogo vise truda), mozes da koristis gotova resenja kao npr. Envoyer. :)

- Izmene baze razni "DevOps Engineers" ovog "modernog tipa" misle da se rade iz koda kroz migracije. Kad imas bazu od preko 100GB i tabele preko 1GB, pa ti pametni pusti migraciju.... pa imas na drugoj temi Bogijev savet za kristalnu kuglu :D

Realno, schema-less strukture su popularne zbog ovoga... moz' da radis sta 'oces. Naravno, puno srece kad nesto ne radi. :D U praksi, sve ima svoj merrit, ako zelis DevOps kao kulturu, nista te ne sprecava da imas sve elemente te kulture i da radis planirane izmene nad bazom. Ako hoces da imas "devops guy" koji je realno release engineer koji misli da sve zna, onda puno srece :). Again, vidi onu kuglu. :)

Izmene na bazi koje su velike su malo obimna prica za forum. Svode se na to da imas asinhronu replikaciju, pa da se potrudis da izmene budu ili :

1) Dodavanje index-a
2) Dodavanje kolone na kraj (OBAVEZNO NA KRAJ)
3) Kreiranje novih tablea (ovo moze kad god hoces ;) )

Onda 1) i 2) mozes da uradis prvo na slave-ovima, pa proglasis neki slave za master, a onda uradis izmene na masteru i vratis ga u upotrebu. Pri tom ti treba alat kojim menjas kako se klijenti kace na bazu... Mislim da je zvanicno MySQL resenje MySQL Router, onda imas MySQL orchestrator, verovatno ima jos nesto. Moze da se, recimo resi tako sto imas ProxySQL na svakom klijentu, plus Orchestrator, pa onda kad prebacis da neki drugi host bude master, proxysql prebaci klijente da se kace na njega... Ima malo posla :)

Pri tom, celo ovo resenje JESTE infrastructure as code, jeste skroz u skladu sa DevOps principima, ima gotove module za puppet recimo... i sto je najvaznije odlicno radi. :) Samo sto nije za ove .... "znam ja sve, to cu ja kroz kod" tipove. Baze podataka obicno drze bitne stvari (citaj novac / finansijske podatke) i nisu za taj nacin rada.

Da se vratimo na Galera replikaciju: Ovo sve NE MOZE sa Galera replikacijom. Galera je sinhrona, ne mozes da pustis upit prvo na slave, jer je u pitanju multi-master sistem. Kad imas Galera-u, onda alter lockuje sve tri baze i dok ne zavrsi ceo sistem ti je lockovan (moras da imas 3 da bi imao pouzdan quorum ako jedna masina ispadne). Zato kazem da Galera nije resenje za sve, stavise nije za dosta toga. Odlicna je za neke use-cases, ali samo za neke. :)

Note: Ako ti je baza do 2-3GB, za neki WordPress, lepo sve to ignorisi, digni RDS i pucaj ALTER TABLE na produkciju. :) Prodje to dovoljno brzo. :)

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

vidis da funkcionise :D ... u ima svih nas kojima je trazena ta staklena kugla, zakon po kom nas nece teretiti ako im je turimo de treba potreban je sad :D



a uglavnom jeste :D

a kada nije, i kada je u pitanju ozbiljna promena na aplikaciji, za svaku tu promenu se pravi plan, promena testira etc etc... na primer u telco svetu, ako sw promena zahteva bilo kakav zahtev u db-u testiranje implementacije te promene na produkciju se testira 6-12 meseci!!!! normalan ciklus za major release upgrade je 2 godine testiranja posle "Feature freeze" trenutka!!! i min 6 meseci posle bilo kog fix-a!! tako da "release now" i "release often" filozofija kod velikih sistema gde je downtime "skup" ne postoji, tj, postoji, 24/6 meseci polisa u telko svetu se racuna kao "often" obzirom da je to ogromno "ubrzanje" u odnosu na to kako se to radilo pre 20+ godina

ja licno imam policy, ne postoji upgrade bez downtime-a!!!. da li ce downtime biti 1sec ili 1dan zavisi od sistema koji se menja i tipa promene i kolicine novca ulozenog u infrastrukturu, ali downtime ce biti! i to mora svim "zahtevacima staklenih kugli" biti predoceno odma u startu. availability u nivou n devetki se podrazumeva za "non planned outage", ali ti mozes da imas 99.9999999999999999999% uptime i sa 5 dana down ako si za tih 5 dana imao pravilno i na vreme najavljen maintenance window

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/