MariaDB Galera Cluster zkušenosti / doporučení?

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á.

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.