MariaDB - Galera - multimaster

vesterna12

  • ***
  • 122
  • byrokracie zabíjí kreativitu
    • Zobrazit profil
    • E-mail
MariaDB - Galera - multimaster
« kdy: 07. 04. 2021, 15:41:09 »
Rad bych databazi v rezimu multimaster. Libi se mi MariaDB - Galera. V pripade 3 nodu je cluster odolny na vypadek jednoho nodu.
Pri teto konfiguraci bych se mel vyhnout i problemum spojenych se "split brain".
V pripade, ze jde o Inno uloziste a vsechny tabulky maji definovane indexy melo by jit o spolehlive reseni z pohlednu datove konzistence.
Za predpokladu, ze v aplikaci prevlada cteni nez zapis tak i vykonne s ohledem na HW. Je neco co jsem zapomenul zohlednit? Kapacitu uloziste neresim...


oss

  • ***
  • 230
    • Zobrazit profil
    • E-mail
Re:MariaDB - Galera - multimaster
« Odpověď #1 kdy: 07. 04. 2021, 16:07:51 »
Rozhodne nie, ked to pouzijes zabudni na miesto na disku. DB subory su vzdy len rastuce, zabudni na transakcie, cudzie kluce, a vlastne vsetky vyhody niecoho viac ako "suboroveho systemu s tcp rozhranim".

Re:MariaDB - Galera - multimaster
« Odpověď #2 kdy: 07. 04. 2021, 16:58:12 »
zabudni na transakcie, cudzie kluce, a vlastne vsetky vyhody niecoho viac ako "suboroveho systemu s tcp rozhranim".

??

Re:MariaDB - Galera - multimaster
« Odpověď #3 kdy: 07. 04. 2021, 17:44:07 »
mysli na to, že odolné to je jen tehdy, když se ti klient umí v případě výpadku připojit na jiný master a tam transakci udělat znovu. Dále nezapomeň, že galera podporuje jen tzv. optimistic locking, kdy nemá globální locky, ale pouze lokální pro danou instanci, je tedy vhodné řešit lokalitu zápisu, kdy nemůže zároveň zapisovat stejná data na více masterů zároveň, ale je to dobré určitý master preferovat k zápisu určitých dat, to si musíš dělat sám.

Asi ti nezbývá než si toho poměrně dost nastudovat a načíst si oficiální dokumentaci, je to tam dobře popsané, měl bys vědět jak to funguje a jak se o to starat.

V praxi používáme multimaster u mariadb, ale chováme se k tomu jako k active-standby, kdy proxy upřednostňuje zápis pouze na první funkční instanci (číst je možné ze všech, teda pokud neděláš něco jako select for update). Dobře funguje proxySQL jako balancer nebo obyčený haproxy s jeho nativními checky. Díky zápisu vždy pouze na jeden master se udrží poměrně vysoká kompatibilita s klienty.

Jako omezení bych vyzdvihnul:
  • nutnost mít všude primary key, bez nich to je tenký led
  • zapomeň na auto increment sloupce, případně se dá řešit varianta s dírami, kdy každý má svoji řadu - sudá/lichá či máš increment 3 u tří masterů atd.
  • triggery na insert hodnot jsou problém, raději se vyhnout úplně použití procedůr a triggerů na databázi
  • podpora je pouze pro row based replication (statement snad umí jen poslední verze, takže bych neriskoval), takže jakýkoliv update celého sloupce může udělat pěknou melu v replikaci
  • bude tě trápit velikost transance, nepočítej s tím, že při importu do eshopu budeš moci tisíce updatů strčit do jediné transakce
  • nepodporuje to myisam, interní tabulka mysql, kde jsou struktury, uživatelé, procedůry, granty je myisam, takže buď jí převedeš na innodb nebo musíš veškeré tyhle změny aplikovat na všechny instanci. Je tady určitá možnost to nechat projít replikačním protokolem, ale není to spolehlivé, raději se při deploymentu připoj na všechny a zajistit změny na všech masterech
  • při alterech tabulek si prostuduj rozdíj mezi RSU a TOI, nauč se používat správnou variantu ve správnou dobu

oss

  • ***
  • 230
    • Zobrazit profil
    • E-mail
Re:MariaDB - Galera - multimaster
« Odpověď #4 kdy: 08. 04. 2021, 07:17:46 »
zabudni na transakcie, cudzie kluce, a vlastne vsetky vyhody niecoho viac ako "suboroveho systemu s tcp rozhranim".

??

To vsetko clovek strati pouzitim Galery/MariaDB.
Ako je asi mozne, ze ine databazy nezvladaju multimaster?
Sice tomu povies "begin transaction" a ono odpovie "OK", ale nic sa nestane, rovnako s cudzimi klucmi, niektorimi indexami.... Ak chce clovek prist o data nie je lepsia volba.


Re:MariaDB - Galera - multimaster
« Odpověď #5 kdy: 08. 04. 2021, 08:28:44 »
Stejne tak si uzijes s deadlocky. Jakmile delas zapisy na ruzne servery, budes se potkavat a casto na ne narazis. Jo a jeste tu je read gap - ale to se tyka i master-slave pouziti v galere. Galera je near-sync, commitnes data na jednom serveru a existuje (sice kratka, ale je tam) mezera, kdy data jeste nemas na slave. Tedy idealne musis zajistit, ze select after insert jde na stejny server (coz je jeste v pohode), ale napr i GET after POST by ti mel jit na stejny. A to uz muze byt obcas orisek.

vesterna12

  • ***
  • 122
  • byrokracie zabíjí kreativitu
    • Zobrazit profil
    • E-mail
Re:MariaDB - Galera - multimaster
« Odpověď #6 kdy: 08. 04. 2021, 21:59:36 »
Dekuju za odpoved.
Jakou databazi  by bylo tedy vhodne pouzit pro multimaster?
V aplikaci prevazuji pozadavky na cteni, synchronni aktualizace zaznamu v clusteru i za cenu zvysene odezvy a transakce.

Re:MariaDB - Galera - multimaster
« Odpověď #7 kdy: 08. 04. 2021, 23:37:55 »
Sice tomu povies "begin transaction" a ono odpovie "OK", ale nic sa nestane, rovnako s cudzimi klucmi, niektorimi indexami.... Ak chce clovek prist o data nie je lepsia volba.

A co jiného čekáš od begin transaction? Jaké problémy máš s cizími klíčemi v galeře a které nefungují správně? Přijít o data? Mariadb s innodb patří k velice spolehlivé databázi pokud jde o ztrátu dat, těch kritických nasazení v ČR jsem dělal několik.

Stejne tak si uzijes s deadlocky. Jakmile delas zapisy na ruzne servery, budes se potkavat a casto na ne narazis. Jo a jeste tu je read gap - ale to se tyka i master-slave pouziti v galere. Galera je near-sync, commitnes data na jednom serveru a existuje (sice kratka, ale je tam) mezera, kdy data jeste nemas na slave. Tedy idealne musis zajistit, ze select after insert jde na stejny server (coz je jeste v pohode), ale napr i GET after POST by ti mel jit na stejny. A to uz muze byt obcas orisek.

read gap s two phase commit? Mluvíš nejspíš o asynchronní replikaci přes nativní mariadb cluster a nikoliv synchronní v Galeře, tam probíhá two phase commit, server na který zapisuješ potvrze zápis jako poslední, dirty reads se v praxi dějí hodně ojediněle. GET po POSTu v galeře vychází vždy stejný, opravdu nejspíš mluvíš o asynchronní replikaci, takovéhle zpoždění se v galeře nedějí.

od Galera 4.0 existuje funkce wsrep_sync_wait_upto_gtid(), kam můžeš předat gtip transakce a tím zajistit, že tvoje proběhne až po jiné. V distribuovaném módu totiž neexistuje globální lineární serializace, ale každý master má vlastní serializaci a poté se řeší opakování při konfliktech (to lze nastavit na automatické na pozadí).

Ano, Mariadb s Galerou "nepodporují" paralelní zápis stejných dat na více masterů, globální locky mají experimentálně jen v posledních verzích. Mimochodem tohle je obecný problém distribuovaných databází a každá má určitá specifika, kterým se musíš přizpůsobit. I Oracle s RACem má stejné problémy a musí se to také řešit lokalitou zápisu.

Mariadb s Galerou v ČR provozuje na řadě kritických projektů a je to poměrně solidní databáze, má sice spousty bolístek, ale patří mezi těm jednodušším na správu. Další varianta je použití Postgresql, ale master-master replikace tam není sranda, BDR extenze podporuje pouze async, Bucardo je jen pro Pg 12 a běží jako další služba, PostgreSQL-XC či přímo EnterpriseDB mají vlastní forknutou verzi PostgresSQL. Je s tím obecně daleko více práce. V open source SQL databázích s tímhle končíme, více toho není nebo to je příliš zabugované.

oss

  • ***
  • 230
    • Zobrazit profil
    • E-mail
Re:MariaDB - Galera - multimaster
« Odpověď #8 kdy: 09. 04. 2021, 08:05:34 »
To je vtip?

Vykon - oproti osttanym databazam rozhodne nie.
Transakcie - su feikove.
Cudzie kluce - pozri na akom engine musis vyuzivat galeru.
Strata dat - s tym mam bohate skunosti.

Ja viem, ze dnes je v mode tvorit aplikacie co funguju, len pokial fuka spravny vietor, ale preco sa taym este chvalit a vychvalovat to ako spravne riesnie?

Re:MariaDB - Galera - multimaster
« Odpověď #9 kdy: 09. 04. 2021, 08:28:02 »
V čem jsou transakce na innodb fejkové, jaké mají cizí klíče na innodb problémy? InnodB je defaultní formát mariadb již pár let a i před tím byl nesmysl používat myisam.

Mám úplně stejné zkušenosti jako AoK, pouze ne na clusteru, ale jen jednotlivé instance + několikanásobná master-slave replikace. Mysql->mariaDB používáme od cca 2002 na stejné DB, samozřejmě od začátku na innodb (myisam by byl holý nesmysl). DB nikdy (ťuk ťuk) žádná data neztratila, pouze jednou při smrti zdroje na MB serveru se poškodil FS na HW raidu (s baterkou) - vyřešilo se přehozením na druhý server. Velikost za ty roky narostla na cca 150GB, největší tabulky mají na disku desítky GB (data + indexy).

Napiš konkrétní zkušenosti pro porovnání.

Re:MariaDB - Galera - multimaster
« Odpověď #10 kdy: 09. 04. 2021, 10:54:56 »
To je vtip?

Vykon - oproti osttanym databazam rozhodne nie.
Transakcie - su feikove.
Cudzie kluce - pozri na akom engine musis vyuzivat galeru.
Strata dat - s tym mam bohate skunosti.

Ja viem, ze dnes je v mode tvorit aplikacie co funguju, len pokial fuka spravny vietor, ale preco sa taym este chvalit a vychvalovat to ako spravne riesnie?

Můžeš být konkrétní? Srovnávat výkon je vždy diskutabilní, ale innodb poskytuje poměrně solidní rovnováhu, ve srovnání s Oracle DB nebo SQL Serverem na stejném HW poskytuje často lehce vyšší výkon pro operace, které podporuje, určitě není pozadu, u většiny nasazení ale člověk nejde na dřeň a každá databáze má konstrukce, které jí sednou a které jí nesednou. Podpora sql funkcí, procedur a divné chování jsou jiné úvahy.

Co znamená, že transakce jsou fejkové? Můžeš být konkrétní? Mariadb s Galerou deklaruje repeatable read, což dovoluje hodně ojedinělý výskyt Phantom chyb, viz specifikace ANSI SQL-92. Myisam engine nemá transakce a tam jsou opravdu fejkové, ale to není varianta, o které se bavíme, galera podporuje pouze innodb.

Opět, co znamená ztráta dat? Při jaké nastavení? Mariadb a innodb používá double write buffer ve výchozím nastavení, to dovoluje se dostat z nesprávně zapsaný page do datového souboru i v případě okamžitého pádu serveru. Zároveň veškeré transakce jsou v binlogu, pokud se poškodí datový soubor, je možné ho rekonstruovat, v případě použití galera clusteru (o tom je tohle vlákno), dochází k synchronní replikaci na jiný stroj. Poškození datových souborů kvůli chybě HW či OS se může vyskytovat, za to ale nemůže databáze samotná a od toho jsou zálohy případně právě použití clusteru. Ano, již několikrát jsem musel obnovovat datové soubory z odvařených serverů, díky kontrolním součtům u binlogu není ztráta většinou tak velká.

O kterých verzích Mariadb a galery mluvíš? Netvrdím, že Mariadb a galera je bezchybná a nejlepší cesta. Provozuji různorodé databáze od devadesátých let, nevím, co je dneska moderní, už jedu ve svých kolejích a snažím se doporučovat variantu, která je pro dané použití vhodná. Ztráty dat jsem řešil snad na všech velkých databázích (pamatuješ předloni dvoudenní výpadek Alzy?), zpravidla to je souhra spousty různých vnějších okolností a nikoliv pouze chyba databáze. Innodb je v tomhle poměrně spolehlivé a bouřlivé chyby s neplatnými checksumy, které se občas objevily v počátku již dvacet nepotkávám. Stejně tak je innodb relativně odolné proti chybám operační paměti (bez použití ECC), ale doporučené použití je s ECC, stejně to platí u ostatních. Nebavím se tady o malých projektech, na mariadb běží slevomat, rohlik.cz, kosik.cz, pilulka, používá jí v kritické části Equa Bank, KB, Česká spořitelna a nespočet dalších projektů.

vesterna12

  • ***
  • 122
  • byrokracie zabíjí kreativitu
    • Zobrazit profil
    • E-mail
Re:MariaDB - Galera - multimaster
« Odpověď #11 kdy: 09. 04. 2021, 22:24:40 »
To je vtip?

Vykon - oproti osttanym databazam rozhodne nie.
Transakcie - su feikove.
Cudzie kluce - pozri na akom engine musis vyuzivat galeru.
Strata dat - s tym mam bohate skunosti.

Ja viem, ze dnes je v mode tvorit aplikacie co funguju, len pokial fuka spravny vietor, ale preco sa taym este chvalit a vychvalovat to ako spravne riesnie?

Můžeš být konkrétní? Srovnávat výkon je vždy diskutabilní, ale innodb poskytuje poměrně solidní rovnováhu, ve srovnání s Oracle DB nebo SQL Serverem na stejném HW poskytuje často lehce vyšší výkon pro operace, které podporuje, určitě není pozadu, u většiny nasazení ale člověk nejde na dřeň a každá databáze má konstrukce, které jí sednou a které jí nesednou. Podpora sql funkcí, procedur a divné chování jsou jiné úvahy.

Co znamená, že transakce jsou fejkové? Můžeš být konkrétní? Mariadb s Galerou deklaruje repeatable read, což dovoluje hodně ojedinělý výskyt Phantom chyb, viz specifikace ANSI SQL-92. Myisam engine nemá transakce a tam jsou opravdu fejkové, ale to není varianta, o které se bavíme, galera podporuje pouze innodb.

Opět, co znamená ztráta dat? Při jaké nastavení? Mariadb a innodb používá double write buffer ve výchozím nastavení, to dovoluje se dostat z nesprávně zapsaný page do datového souboru i v případě okamžitého pádu serveru. Zároveň veškeré transakce jsou v binlogu, pokud se poškodí datový soubor, je možné ho rekonstruovat, v případě použití galera clusteru (o tom je tohle vlákno), dochází k synchronní replikaci na jiný stroj. Poškození datových souborů kvůli chybě HW či OS se může vyskytovat, za to ale nemůže databáze samotná a od toho jsou zálohy případně právě použití clusteru. Ano, již několikrát jsem musel obnovovat datové soubory z odvařených serverů, díky kontrolním součtům u binlogu není ztráta většinou tak velká.

O kterých verzích Mariadb a galery mluvíš? Netvrdím, že Mariadb a galera je bezchybná a nejlepší cesta. Provozuji různorodé databáze od devadesátých let, nevím, co je dneska moderní, už jedu ve svých kolejích a snažím se doporučovat variantu, která je pro dané použití vhodná. Ztráty dat jsem řešil snad na všech velkých databázích (pamatuješ předloni dvoudenní výpadek Alzy?), zpravidla to je souhra spousty různých vnějších okolností a nikoliv pouze chyba databáze. Innodb je v tomhle poměrně spolehlivé a bouřlivé chyby s neplatnými checksumy, které se občas objevily v počátku již dvacet nepotkávám. Stejně tak je innodb relativně odolné proti chybám operační paměti (bez použití ECC), ale doporučené použití je s ECC, stejně to platí u ostatních. Nebavím se tady o malých projektech, na mariadb běží slevomat, rohlik.cz, kosik.cz, pilulka, používá jí v kritické části Equa Bank, KB, Česká spořitelna a nespočet dalších projektů.

Priklanite se tedy k reseni dedikovaneho nodu pro zapis (za predpokladu, ze to zohlednuje aplikace)? Rozhodl se tak treba Kosik nebo Equa? Prakticka zkusenost je rozhodne zajimava...

Re:MariaDB - Galera - multimaster
« Odpověď #12 kdy: 10. 04. 2021, 01:47:03 »

Stejne tak si uzijes s deadlocky. Jakmile delas zapisy na ruzne servery, budes se potkavat a casto na ne narazis. Jo a jeste tu je read gap - ale to se tyka i master-slave pouziti v galere. Galera je near-sync, commitnes data na jednom serveru a existuje (sice kratka, ale je tam) mezera, kdy data jeste nemas na slave. Tedy idealne musis zajistit, ze select after insert jde na stejny server (coz je jeste v pohode), ale napr i GET after POST by ti mel jit na stejny. A to uz muze byt obcas orisek.

read gap s two phase commit? Mluvíš nejspíš o asynchronní replikaci přes nativní mariadb cluster a nikoliv synchronní v Galeře, tam probíhá two phase commit, server na který zapisuješ potvrze zápis jako poslední, dirty reads se v praxi dějí hodně ojediněle. GET po POSTu v galeře vychází vždy stejný, opravdu nejspíš mluvíš o asynchronní replikaci, takovéhle zpoždění se v galeře nedějí.


Moje praxe mluví jinak. Dějí. Aspoň si prosím přečti dokumentaci: https://mariadb.com/kb/en/about-galera-replication/

Kód: [Vybrat]
Galera's replication is not completely synchronous. It is sometimes called virtually synchronous replication.

Kód: [Vybrat]
However, in practice, synchronous database replication has traditionally been implemented via the so-called "2-phase commit" or distributed locking which proved to be very slow.
Takže ne, žádný two-phase commit a žádná synchronní replika :)

Re:MariaDB - Galera - multimaster
« Odpověď #13 kdy: 10. 04. 2021, 01:56:48 »
A ještě doplním

Citace
This approach is also called virtually synchronous replication, given that while it is logically synchronous, the actual writing and committing to the tablespace happens independently, and thus asynchronously on each node.

Takže ano, update nebo insert se ti nepotkal, ale po commitu můžeš readem z jiného serveru opravdu přečíst stará data.

Re:MariaDB - Galera - multimaster
« Odpověď #14 kdy: 10. 04. 2021, 11:21:31 »
Mě ta diskuze příjde dost extrémní, pokud chci používat jakýkoliv cluster v režimu master-master tak v něm existují různá ale, která je třeba prostě akceptovat.
Vzhledem k tomu, že lepší variantu jak galera-cluster (u RDBMS) budete těžko shánět je třeba se prostě přizpůsobit.
Varianta teoreticky ještě může být CITUS a to jsem zatím nezkoušel, předpokládám, že to má také spousty ale ale ale.

Snad každého napadne, proč to nedělá ORACLE s DB protože to prostě nelze složit tak, aby to fungovalo. Nejde o to, že jsou tak hloupí a neumí to, ale prostě to nejde jinak.

Já bych osobně zvážil datově malou SQL (konzistence) a k ní nějakou větší noSQL (nekonečný storage - nativní cluster) to mě příjde jako ultimátní řešení na všechno.

Nicméně vytýkat clusteru, že se nechová jako standalone databáze je jak brečet, že na tříkolce si můžu zajet do obchodu, ale dopravní letadlo tam nemůže přistát.
„Řemeslo se naučí každý. Umění nikdo.“
„Jednoduchost je nejvyšší úroveň sofistikovanosti.“
- Leonardo Da Vinci