Dostupnost online aplikace s databází

kvas

  • ***
  • 124
    • Zobrazit profil
    • E-mail
Dostupnost online aplikace s databází
« kdy: 13. 09. 2024, 11:41:16 »
Ahoj,

rozmyslam, ako najjednoduchsie zabezpecit co najvacsiu dostupnost online sluzby. Ide o java aplikaciu (Spring) s MySQL databazou. Aktualne to bezi na jednom serveri v hostingu. A rad by som tejto sluzbe zabezpecil co najvacsiu dostupnost. Kratky vypadok (desiatky minut nie je problem), ale napr. viac ako 4 hodiny uz je vela.

V skratke riesim scenar:
v hostingu vypadne server s aplikaciou na niekolko hodin, ale ja potrebujem aby ta aplikacia bola povedzme do 1-2 hodin opat dostupna.


Zatial mam tuto variantu:

na druhom zeleze/serveri/hostingu rozbehnut kopiu aplikacie spolu s kopiou DB a v pripade vypadku sluzby prehodit DNS na druhe zelezo. Problem je s migraciou dat z DB. Mohol by som si napisat cron job, ktory v pravidelnych intervaloch prekopiruje data z prvej DB do druhej DB, ale nerad by som vymyslal koleso - urcite toto uz niekto riesil predomnou a to je presne dovod preco pisem tento post.

1) Nakopli by ste ma prosim, co presne mam hladat, resp. ako co najjednoduchsie drzat 2 rozne instancie DB 100% synchronizovane bez nutnosti rucneho kopirovania dat z jednej DB do druhej. Ak by to pomohlo, som ochotny vymenit MySQL za MariadDB, prip. PostreSQL.

2) Ak by existovalo este elegantnejsie riesenie ako manualna/rucna zmena DNS na iny server tak budem rad za tip/napovedu.

3) Nehladam kanon na vrabce vo forme "super-mega high availability cluster", ale nieco, co sa da rozumne udrziavat, nejaky jednoduchy KISS princip.

Dakujem za kazdy tip.




Re:Dostupnost online aplikace s databází
« Odpověď #1 kdy: 13. 09. 2024, 12:20:09 »
Nezminujete jaky je rozpocet. Narocnost te applikace.
Kazdopadne pro nejlepsi dostupnost applikace je nejlepsi pouzit kubernetes.
DB uz v dnesni dobe pomoci operatoru bezi velmi stabilne. A vase applikace v pripade padu je automaticky restartovana. Pripadne pokud je spravne naprogramovana muze bezet ve vice instancich a tudiz pad jedne instance znamena minimalni vypadek pro uzivatele.

alfi

  • ****
  • 335
    • Zobrazit profil
    • E-mail
Re:Dostupnost online aplikace s databází
« Odpověď #2 kdy: 13. 09. 2024, 12:27:23 »
Mysql/Mariadb umí replikaci master2master, tj. v každou chvíli existujou dvě stejné kopie. Pak stačí přidat odpovídající počet frontendů v různých serverovnách, příp. nějaký load balancer. Jednoduché je taky mít v DNS záznamy s krátkou TTL - a monitoringem přes API nastavit správnou verzi. Podle typu obsahu, pokud nevadí mírně neaktuální, taky může stačit jen lokální cache výsledného html :)

Re:Dostupnost online aplikace s databází
« Odpověď #3 kdy: 13. 09. 2024, 13:08:42 »
Mysql/Mariadb umí replikaci master2master, tj. v každou chvíli existujou dvě stejné kopie. Pak stačí přidat odpovídající počet frontendů v různých serverovnách, příp. nějaký load balancer. Jednoduché je taky mít v DNS záznamy s krátkou TTL - a monitoringem přes API nastavit správnou verzi. Podle typu obsahu, pokud nevadí mírně neaktuální, taky může stačit jen lokální cache výsledného html :)

Umí je tam plugin GalleraCluster wsrep jen se povolí a nakonfiguruje a ten normálně běží multimaster HA. Nemá tedy nad sebou load balancer, ale to je detail dořešit.
„Řemeslo se naučí každý. Umění nikdo.“
„Jednoduchost je nejvyšší úroveň sofistikovanosti.“
- Leonardo Da Vinci

Re:Dostupnost online aplikace s databází
« Odpověď #4 kdy: 13. 09. 2024, 13:21:24 »
Pro tento účel používáme standardní mysql/mariadb replikaci master/slave (+ třetí/čtvrtou instanci do firmy pro zálohování/development), pro non-db filesystém drbd. Ale servery jsou v jednom DC, takže mají natažený dedikovaný gigabit pro drbd. Provoz master/master neděláme (obě mariadb mají po startu zapnutý read-only a do zápisu se přepíná až při přehození uzlu na master), aby se to nedopatřením nekouslo na splitbrain. To raději o chvilku delší failover.

Pro něco vzdálenějšího a menší změny dat bych se nebál např. pravidelný zfs send/receive či obyč. rsync každých pár minut, pokud by zvládlo počty souborů a objemy změn.

Samozřejmě existují daleko vychytanější řešení, ale také obvykle podstatně složitější a dražší.


Re:Dostupnost online aplikace s databází
« Odpověď #5 kdy: 13. 09. 2024, 13:26:04 »
Ještě existuje MySQL NDB Cluster který je řešený jinak než GalleraCluster, ale jelikož to vyvíjí Oracle tak je otázka v jakém stavu to dneska je.
Asi je dobrý zmínit, že tyhle multimaster řešení mají obvykle různá omezení oproti standalone DB. Typicky třeba CitusData (shardovaný postgres je dost specifický).
„Řemeslo se naučí každý. Umění nikdo.“
„Jednoduchost je nejvyšší úroveň sofistikovanosti.“
- Leonardo Da Vinci

Re:Dostupnost online aplikace s databází
« Odpověď #6 kdy: 13. 09. 2024, 13:28:36 »
Kopírování dat mezi více instancemi databáze se říká replikace, to je ten pojem, který hledáte. Měla by vám stačit master/slave replikace – máte primární instanci (master), na kterou jdou zápisy, data se replikují na slave, který se nepoužívá buď vůbec (jednodušší řešení), nebo se z něj může číst (složitější, ale zlepší to výkon, protože se rozloží zátěž). Když přestane být master dostupný, udělá se ze slave master a jede se dál.

Pozor na to přepnutí, kritické je to, aby byl vždy opravdu jen jeden master. Aby se nestalo, že část systému vyhodnotí, že master přestal být dostupný a přepne slave→master, ale jiná část pořád uvidí původní master – a některé zápisy půjdou na původní master a některé na původní slave povýšený na master. Ten samý problém pak nastává, když je master opravdu nedostupný, a pak najednou ožije (třeba se znovu připojí datacentrum, které mělo nějaký výpadek).

Tj. na první pohled to vypadá, že by bylo dobré mít přepínání masteru na jinou instanci automatizované. Ale pokud si můžete dovolit výpadek 1–2 hodiny, bude jednodušší přepínat to ručně – prostě někdo ověří, že žádná instance aplikací nekomunikuje s masterem, vypne je, přepne původní slave na master, všechny aplikace přesměruje na nový master a aplikace zapne.

Jiný případ je master/master nebo multi-master replikace, která znamená, že můžete zapisovat na obou stranách. MySQL to podporuje už dlouho (na rozdíl od PostgreSQL, které myslím, stále má multi-master replikaci jen v rámci komerčních řešení). Ale slyšel jsem už spoustu strašidelných historek o tom, jak se master/master replikace v MySQL rozpadla – takže vzhledem k tomu, že to nepotřebujete, bych nepokoušel osud.

Co se týče aplikace, tam je to vlastně velmi jednoduché. Můžete mít aplikace ve více instancích v různých datacentrech, v DNS bude mít IP adresy všech instancí, klient si vždycky nějakou vybere a s tou bude komunikovat. Zároveň to bude fungovat jako rozvažování zátěže. Když dojde k výpadku jedné lokality, chytřejší klienti po neúspěšném spojení na jednu IP adresu zkusí jinou IP adresu z odpovědi; pro hloupější klienty je dobré tu nefunkční IP adresu z DNS dočasně vyřadit, ať se vůbec nenabízí.

Pokud byste nechtěl trvale platit provoz dvou instancí aplikace, můžete ji samozřejmě provozovat jen v jedné lokalitě a počítat s tím, že v případě výpadku koupíte nějaký VPS někde jinde a tam aplikaci rozběhnete. V takovém případě je ale dobré mít zautomatizovanou tu instalaci aplikace, protože jestli začnete ručně na VPS instalovat distribuci, do ní Javu a pak vaši aplikaci, budete mít dost perné ty dvě hodiny povoleného výpadku. V takovém případě by v DNS samozřejmě byla jen IP adresa základní lokality a při výpadku a instalaci v jiné lokalitě by se ta IP adresa změnila.

Každopádně je potřeba mít v DNS nastavenou krátkou dobu platnosti záznamů. Doporučuju 5 minut, protože níž se stejně reálně nedostanete – mnozí klienti kratší dobu než 5 minut ignorují. Takže je potřeba počítat s tím, že klienti reálně pocítí výpadek v řádu pár minut až dejme tomu deset či patnáct minut. Pokud byste měl požadavek na zkrácení doby nedostupnosti pro klienty (podle dotazu to nepředpokládám), už je potřeba to řešit jinak než přes DNS.

Existují služby, které umí to přepnutí DNS zařídit automaticky – monitorují cílové servery, a pokud přestanou být dostupné, přehodí DNS záznamy jinam. Jako službu DNS-failover to nabízí třeba ClouDNS.net, ale určitě to umí i jiní. (Nebo si to samozřejmě můžete sám naskriptovat.) Ale jak jsem psal – přepnutí aplikace je jednoduchá disciplína, klíčové je to přepnutí databáze.

Samozřejmě existují už hotová řešení, třeba cloudové databáze (kompatibilní s MySQL), ale předpokládám, že vám jde o co nejlevnější řešení na bázi nějakých dvou VPS.

kvas

  • ***
  • 124
    • Zobrazit profil
    • E-mail
Re:Dostupnost online aplikace s databází
« Odpověď #7 kdy: 13. 09. 2024, 14:05:57 »
Kopírování dat mezi více instancemi databáze se říká replikace, to je ten pojem, který hledáte. Měla by vám stačit master/slave replikace – máte primární instanci (master), na kterou jdou zápisy, data se replikují na slave, který se nepoužívá buď vůbec (jednodušší řešení), nebo se z něj může číst (složitější, ale zlepší to výkon, protože se rozloží zátěž). Když přestane být master dostupný, udělá se ze slave master a jede se dál.

toto by sa mi pacilo, jednoduche a funkcne. nastudujem tu replikaciu. Este jeden dotaz: ked prepnem (z dovodu vypadku) slave na master a master na slave, preklopia sa automaticky bez rucneho zasahu nove data z novej master instancie na povodnu  master instanciu (aktualny slave)? ak ano, tak to by mi uplne postacovalo.

nie je problem tu slave instanciu (app + db) drzat/platit v inom regione datacentra ako server, ktory sa tam flaka. to by som ho mohol vyuzit na roztiahnutie zataze a odbremenit trochu master server - len musim este nastudovat ako drzat klientske sessions stale na jednom serveri - ale aj to uz urcite niekto riesil.

co sa tyka DNS, tam mam TTL nastavene uz teraz na 10 minut.

dakujem za rady.
« Poslední změna: 13. 09. 2024, 14:09:12 od kvas »

Re:Dostupnost online aplikace s databází
« Odpověď #8 kdy: 13. 09. 2024, 14:33:29 »
toto by sa mi pacilo, jednoduche a funkcne. nastudujem tu replikaciu. Este jeden dotaz: ked prepnem (z dovodu vypadku) slave na master a master na slave, preklopia sa automaticky bez rucneho zasahu nove data z novej master instancie na povodnu  master instanciu (aktualny slave)? ak ano, tak to by mi uplne postacovalo.
Ze slave se dělá master v okamžiku, kdy původní master není dostupný. Tj. slave se povýší na master (aby povolil zápisy), pokud bylo salve víc, pak se začnou data z nového masteru replikovat na ostatní slave. Když pak znovu ožije původní master, nesmí se hned znovu zapojit do clusteru. Ten původní master, který znova ožil, musí být považován za pokažený, má zastaralá data. Tj. může se případně znovu sesynchronizovat s masterem a nastartuje se na něm replikace, takže bude slave. Teprve v tomto okamžiku se případně může udělat opačné přepnutí, že se z toho dočasného masteru udělá zase zpět slave a původní master, který je teď slave, se zase povýší na master.

len musim este nastudovat ako drzat klientske sessions stale na jednom serveri - ale aj to uz urcite niekto riesil.
Tomu se říká sticky session – pak ale nemůžete používat to balancování přes DNS. A fallback na jiný server znamená ztrátu session. Ideální je session vůbec nepoužívat – údaje o přihlášeném uživateli můžete mít v JWT, odkud si to vyzvedne každý server bez nutnosti nějakých session. Pokud session nutně potřebujete, pak je asi lepší mít sdílené úložiště session, aby při přepnutí klienta na jiný server nedošlo ke ztrátě session. Sticky session bych bral až jako poslední možnost – to se používá v případě, kdy se veškerý provoz směřuje na revezní proxy, která dělá rozvažování zátěže a podle session směřuje klienta na backend server, kde se drží ta session. Pak ale ta reverzní proxy je single point of failure.

Re:Dostupnost online aplikace s databází
« Odpověď #9 kdy: 15. 09. 2024, 21:04:29 »
Pre vysoku dostupnost (HA) DB postave jednoducho
3 nodovy Gallera cluster ( napriklad Mariadb + Gallera, alebo Pecona XtraDB). V pripade vypadku nodu sa sam po pripojeni dosynchonizuje pripadne ak je toho moc nacita vsetky data s funkcneho nodu.

Na aplikacnom node nainstalujete proxy MaxScale (jednoduchsia konfiguracia) alebo ProxySQL (vykonejsie a viacej moznosti routovania + Query cache) .. tento proxy bude vidiet vsetky nody DB a smerovat automaticky trafik na funkcny nod. Cize APP sa proji na localhost Proxy.

Osobne odporucam kombinaciu Percona XtraDB + ProxySQL
s ProxySQL nastavit zapisy na jeden nod (sam failoverne na dalsi ak bude treba a vrati s5 ked bude povodny ok/syncnuty)
 citanie (SELECTy) vie distribuovat na vsetky nody.

Gallera cluster je dobry pre HA ma vsak svoje obmedzenia, napr nesmiete zapisovat do rovnakych tabuliek na roznych nodoch lebo dojde k Lockom.
Preto zapisy smerovat len na jeden nod. Na ine nody je moznete ties zapisovat ale do inych tabuliek.