Autor Zpráva
Virtus
Profil
Zdravím,
rád bych se zeptal, zda tu má někdo nějaký zkušenosti s MariaDB Galera Cluster, případně i s jiným databázovým clustrem. Asi začnu tím, na co bych rád cluster nasadil:

Databáze:
Server version: 5.5.39-MariaDB MariaDB Server
V budoucnu určitě přechod na MariaDB 10.x

Zátěž na databázi:
avg. traffic:    20MB / s
avg. read:       4k query / s
avg. write:      1k query / s (poměr insert:update - 3:1)
avg. connection: 1k / s
peak (read/write): 20k(15k/5k), traffic: 40MB

Využíváné možnosti databáze:
nativní funkce
set option
trigger
stored procedure
view
memory table
innodb table
foreign key (on delete/update cascade/set null)
transaction (vyjímečně, asi by se bez nich dalo obejít)
signály (signal sqlstate..., atd.)

Od clusteru potřebuju master - master, do budoucna pravděpodobně přidat i jeden slave (master-master-slave). A teď rovnou k dotazům:
1) Pokud se jeden z masterů odpojí, propíšou se automaticky změny z běžícího masteru na vypadnutý, poté co bude znova spuštěn nebo existuje něco co se nepropíše?
2) Má zátěž vliv na propis dat? Jaká je asi tak prodleva propisu dat mezi mastery při zátěži, kterou jsem popsal výše (stačí i hrubý odhad, pokud má někdo aspoň trochu představu)?
3) Při propisu změn mezi jednotlivými servery, spouští se triggery?
4) Pokud v dotazu vznikne chyba, bude zalogovaná na všech serverech v clusteru?
5) Mám dotazy:
insert into tab(col_id,col_value) values (5,'value1');
insert into tab(col_id,col_value) values (5,'value2');
kde col_id je primární klíč a každý z dotazů provedu téměř zároveň, ale každý na jiném DB serveru, pokud zde existuje prodleva mezi propisem dat v clusteru, jak se cluster zachová?
6) Při výpadku jednoho serveru a opětovném spuštění, naplní se i memory tables?
7) přenáší cluster i set option?
8) Na co si dát s clustrem pozor, případně co ratši vůbec nepoužívat?


Díky za odpovědi.
Karel N.
Profil *
Doporučuji buď si zaplatit admina nebo pročíst odbornou literaturu, v diskuzi nemůžeš moc čekat, že dostaneš potřebné a detailní odpovědi.

U mysql/mariadb je pořád lepší se vyhnout master-master pokud člověk neví co dělá nebo nemá chuť to řešit. Jen krátce ti odpovím, abych tě nasměroval.

1) při pádu z jednoho z nich musíš veškerou obsluhu a aktuálnost dat zajistit sám. Dají se na to samozřejmě napsat skripty, viz ukázkové v pythonu. K pádu je většinou nějaký důvod, kterž je nutné vyřešit. Poté je nutné zkontrolovat v binlogu, co vše se stihlo na něj zkopírovat a co vše je comitnuté v databázi, případně ručně sjednat nápravu. Pokud je mezi servery špatné spojení, je to problém. Mysql umí replikovat přes tcp a udp a dostupnost spojení je samozřejmě kritická, má vliv pouze na zpoždění synchronizace. Zároveň se tady dostáváš do situaci, kdy klienti jsou na tenhle server připojení, musíš je failoverovat na druhý, který musí zátěž unést, pdo v php třeba tohle neumí jednoduše. Používá se na to třeba mysql proxy, která zajišťuje balancing serverů a odstiňuje klienty od konkrétních masterů.

2) samozřejmě, že má. S daty se musí dělat více operací. Jen pro orientaci je běžné, že reálná propustnost dotazů se sníží na 70 % při zapnutí replikace, často to bývá ale i 50 %, vše závisí na správné konfiguraci. Zároveň musíš počítat i s pádem části serverů a nesmí ti to kaskádou spadnou vše.

3) Záleží na typu replikace. Ano i ne, vše se dá nastavit a je nutné tomu nějaký čas věnovat, kvůli replikaci tam jsou jistá omezení. Odkážu tě pouze na dokumentaci

4) podle typu chyby, chyba v syntaxi sql se nedostane dál. Pokud je chyba na úrovni constraint, bude zalogována na každém serveru kde vznikla a podle toho, jestli je synchronní nebo asychnronní replikace se vrátí/nevrátí klientovi. V případě asynchronní je nutné poté chybu vyřešit ručně.

5) Zase záleží na typu a nastavení replikace. V případě synchronní (čeká se na commit na všech serverech) se dotazy v pořádku vykonají. V případě asynchronní není zaručeno, s kterým výsledkem který server skončí.

6) ne.

7) krátká odpověď je ne. Set option je pro konkrétní spojení nebo konkrétní instanci, není možné ho jednoduše replikovat. Však při replikaci se aktuální session proměnné ukládají s sql do bin2logu. Je ale stejně nutné znát jak to funguje a co se uvnitř děje jinak se ti to rozbije jako domeček z karet.

8) pokud tomu nerozumíš, nepoužívej to. Mysql cluster je na konfiguraci, údržbu a obsluhu složitější. Musíš nastudovat mnoho a mnoho materiálů. Pokud můžeš, zvedej výkon serveru, bude to jednodušší, spolehlivější a rychlejší. Používat master-slave replikaci pro zálohy je ok, master-slave-slave pro škálování čtení je trochu složitější, ale pořád to jde, od master-master dej raději ruce pryč.

Databázím a škálování se věnuji profesně 10 let. Zatížení, které chceš generovat nemá smysl škálovat na více mašin, pouze zajistit max. master-slave replikaci pro zálohy, zároveň si tím může postupně ošahat jak se to vše chová.
Virtus
Profil
Velice děkuji za odpovědi, hodně mi pomohli, jen bych se chtěl zeptat ještě na jednu věc. Při konfiguraci master-slave, je standartní postup v případě delšího výpadku masteru, udělat ze slavu master a při opětovném spuštění bývalého masteru z něj udělat slave a mergnout do něj data z aktuálního masteru, jak je to popsaný v dokumentaci nebo se takováto situace řeší standartně jinak?

Jinak s výkonem serveru problém zatím není (HW jede na 16%), jen se snažím, snad dostatečně v čas, případným budoucím problémům vyhnout a právě kvůli tomu, budem přidávat druhý databázový server a řešit replikaci databáze na aplikační úrovni programu mi přišlo "hloupé", když databáze k tomu nabýzí nastroje ;)
Karel N.
Profil *
nemáš vůbec za co, jsem rád, že aspoň trochu to pomohlo. Není snadné rozsáhlou problematiku nějak popsat v pár větách.

Ano, je možné v případě neočekávaného výpadku nahodit slave jako master a zajistit dostupnost služby. V praxi jsem ale k tomu neměl nikdy příležitost, slave jsme měli vždy jinak nakonfigurovaný (HW) než aby mohl být masterem a u menších clusterů nám master nikdy takhle nehavaroval. Setkal jsem se ale s řešením, kdy zůstal slave pouze pro čtení a zápis změn byl dočasně pozastaven než se problém s master vyřešil, to ale záleží jak je možné tohle zajistit na úrovni aplikace.

My používáme řešení se síťovým raid řadičem, kdy běží dva mastery, oba mají přístup na stejný mirrorovaný disk a v případě havárie jednoho hned jeho úlohu přebírá ten druhý. Proxy v mezičase drží dotazy ve frontě, při spadnutí master serveru je reakční doba asi 1s, což je pro nás akceptovatelné.

Řešit tohle na aplikační úrovni je také možné, ale v praxi u rozsáhlejších řešení to přináší velké komplikace pro údržbu, přeci jen zásah do aplikace řeší jiní lidé než údržbu serverů, proto je vhodné to oddělit.

Držte se schématu master-slave, odzkoušejte si všechny možné scénáře (výpadky, nedostupnost sítě, vypnutí serveru atd.), na vše si připravte skripty, pokud to jde a hlavně vše někam popiště/zdokumentujte. V případě výpadku musíte okamžitě vědět co dělat a ne jít teprve na google. Pokud neděláte službu se SLA 99,99+, není velký problém prohození udělat ručně, pokud máte nonstop podporu. Důležité v případě mysql je zkontrolovat co je v binlogu ještě necommitnutý.

Nastavte si monitoring pro master i slave (SHOW SLAVE STATUS, SHOW MASTER STATUS) a kontrolujte jak moc je slave pozadu oproti masteru a v případě vysokého zpoždění (10s) vyhazujte warningy třeba na email. Je důležité, abyste kdylikov věděli v jakém stavu celý cluster je.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0