Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Zero app downtime - MariaDB Galera Cluster

[es] :: MySQL :: Zero app downtime - MariaDB Galera Cluster

[ Pregleda: 1913 | Odgovora: 14 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

CoyoteKG

Član broj: 70939
Poruke: 2544



+6745 Profil

icon Zero app downtime - MariaDB Galera Cluster19.04.2019. u 11:45 - pre 2 meseca
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?

 
Odgovor na temu

bojan_bozovic

Član broj: 29028
Poruke: 3068
87.116.182.*

Sajt: iching.ch


+309 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster19.04.2019. u 11:52 - pre 2 meseca
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.
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2315

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+455 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster19.04.2019. u 12:14 - pre 2 meseca
Citat:
CoyoteKG:
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.

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.
Citat:

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)

stop slave;

:D
Citat:

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?

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

Please do not feed the Trolls!

Profesionalni sport je oksimoron. Profesionalni sportista je, najcesce, samo moron.
 
Odgovor na temu

CoyoteKG

Član broj: 70939
Poruke: 2544



+6745 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster19.04.2019. u 12:28 - pre 2 meseca
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
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 2587



+1079 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster19.04.2019. u 13:14 - pre 2 meseca
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).
 
Odgovor na temu

CoyoteKG

Član broj: 70939
Poruke: 2544



+6745 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster19.04.2019. u 14:58 - pre 2 meseca
uh.....

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

[Ovu poruku je menjao CoyoteKG dana 19.04.2019. u 16:11 GMT+1]
 
Odgovor na temu

agvozden
Aleksandar Gvozden
founder
Info-G
Beograd

Član broj: 37813
Poruke: 1099
*.dynamic.sbb.rs.

Sajt: www.gvozden.info


+65 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster20.04.2019. u 10:51 - pre 2 meseca
^
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.


 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2295 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster20.04.2019. u 12:37 - pre 2 meseca
tako je nastao cuveni "devops" - iliti multipraktik, koji zna dovoljno
od svega da bi mogao da napravi tako nesto :)
 
Odgovor na temu

mjanjic
Šikagou

Član broj: 187539
Poruke: 1219



+365 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster20.04.2019. u 13:11 - pre 2 meseca
Možemo to da shvatimo kao sarkazam, jer Devops je nešto drugo ;)
Blessed are those who can laugh at themselves, for they shall never cease to be amused.
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 2512
109.72.51.*



+551 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster20.04.2019. u 13:13 - pre 2 meseca
Citat:
CoyoteKG:
uh.....

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

[Ovu poruku je menjao CoyoteKG dana 19.04.2019. u 16:11 GMT+1]


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
press any key to continue or any other to quit....
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 2512
109.72.51.*



+551 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster20.04.2019. u 13:14 - pre 2 meseca
Citat:
mjanjic:
Možemo to da shvatimo kao sarkazam, jer Devops je nešto drugo ;)


Pa ste je drugo nego deployment and testing?

press any key to continue or any other to quit....
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2295 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster20.04.2019. u 13:50 - pre 2 meseca
kako nisu, nesto ti tu nisi dobro svatio

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

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2315

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+455 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster21.04.2019. u 08:31 - pre 59 dana i 5h
Citat:
bogdan.kecman: kako nisu, nesto ti tu nisi dobro svatio

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

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. :)
Please do not feed the Trolls!

Profesionalni sport je oksimoron. Profesionalni sportista je, najcesce, samo moron.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2295 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster21.04.2019. u 11:36 - pre 59 dana i 2h
Citat:
nkrgovic: Al si ti vickast.... :) Mada, da ne pocinjem ko to radi i kako... :)

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

Citat:
nkrgovic
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. :)


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
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2315

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+455 Profil

icon Re: Zero app downtime - MariaDB Galera Cluster21.04.2019. u 18:26 - pre 58 dana i 19h
To sto ti imas policy podrazumeva da application architect i project manager budu razumne osobe, svesne problema, koje ga em tehnicki stvarno razumeju, em imaju autoritet da to jasno stave do znanja onima iznad.....

A i realno, ako imas potrebu za 7 devetki, imas i DR sajt. :) Lepo prebacis sve na DR, zakazes downtime glavnog, pa radis kao gospodin. :D Ako si besan turbo-mega biznis, kome treba takav availability, onda imas DR i imas pare da ga platis. Ako nemas, onda nisi takav biznis :)
Please do not feed the Trolls!

Profesionalni sport je oksimoron. Profesionalni sportista je, najcesce, samo moron.
 
Odgovor na temu

[es] :: MySQL :: Zero app downtime - MariaDB Galera Cluster

[ Pregleda: 1913 | Odgovora: 14 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.