Omezení galera clusteru
Kolizní zápisové operace¶
Je potřeba se vyvarovat kolizním zápisům. Prakticky to znamená, že pro zápisové operace je vytvořeno samostatné spojení (konektor), které zajistí, že zápisové operace budou realizovány pouze na jednom z nodů. Druhé spojení se balancuje na všechny nody a je mozné ho použít jenom pro čtecí operace. Není technicky možné zabránit tomu, aby tímto spojením nešla poslat i operace zápisová - je nutné toto omezení řešit aplikačně. Pokud by toto nebylo dodrženo, nastanou v clusteru kolizní zápisové operace, které databáze vyřeší deadlockem. Pokud aplikace takové rozdělení nemá a implementace by byla komplikovaná, je možné nainstalovat na loadbalancer MaxScale, který query optimálně rozdělí. Toto řešení je ale pochopitelně procesorově náročnější než jednoduché balancování tcp provozu.
Množství zápisových operací¶
Zápisové operace se realizují na všech nodech. Z tohoto důvodu výkon pro zápisové operace neškáluje s počtem serverů v clusteru. Naopak, kvůli nutnosti data replikovat na zbylé nody, je výkon takových operací spíš nižší než v případě jednoserverové instalace.
Velikost writesetu¶
V jedné zápisové operaci by nemělo dojít ke změnám více jak maximálně několik stovek MB dat, nebo řádově desítek tisíc řádek. Takové query jsou extrémně náročné na zreplikování na ostatní nody. V případě že jsou tyto doporučené hodnoty překročeny, může v ojedinělých situacích dojít i k rozpadnutí celého clusteru. To obvykle vede k výpadku služby. Tyto situace je třeba rozdělit na více menších writesetů.
ALTER TABLE¶
Je třeba se vyvarovat změn struktury tabulek a to především u velkých tabulek. Takové operace je třeba vždy otestovat v labu a poté zrealizovat na produkci v nočních hodinách. U změn, které se ukáží jako nespustitelné na produkci bude třeba použít jiný způsob jak situaci vyřešit – například provést změnu jinde a celou tabulku naimportovat zpět.
InnoDB tabulky¶
V Galera clustru je aktuálně podporována výhradně replikace InnoDB tabulek. Všechny MyISAM tabulky je nutné převést do InnoDB.
Uzamykací mechanizmy¶
Uzamykací mechanizmy jako LOCK TABLES, FLUSH TABLES {explicit table list} WITH READ LOCK, (GET_LOCK(), RELEASE_LOCK().. nejsou podporovány. Podporovány jsou globální uzamykací mechanizmy jako je například FLUSH TABLES WITH READ LOCK.
Primární klíč¶
Všechny tabulky by měly mít primární klíč. Vícesloupcové primární klíče jsou podporovány. DELETE operace nejsou podporovány u tabulek bez primárniho klíče. Řádky v tabulkách bez primárního klíče mohou mít jiné pořadí v jednotlivých nodech.
AUTOINCREMENT¶
Každý nod v Galera clustru může zapisovat do tabulky. Pokud by došlo k simultánnímu zápisu vícero, nebo všech nodů do tabulky, výsledkem by mohli být duplicitní hodnoty ve sloupcích, které AUTOINCREMENT používají.
Aby k takovýmto konfliktům nedocházelo, je potřebné ze strany Galera clustru zabezpečit, aby měl každý záznam unikátní hodnotu. To je zabezpečeno nastavením proměnné auto_increment_increment a auto_increment_offset, kde auto_increment_increment má hodnotu počtu nodů v clustru a auto_increment_offset má na každém nodu jinou hodnotu v rozmezí od 1 do n, kde n je počet nodů v clustru.
Je potřebné si uvědomit, že toto není bug, ale vlastnost a Vaše aplikace s tímto musí počítat. Problematika je detailněji popsána například tady.
Výkon¶
Výkon celého Galera clustru je omezen výkonem nejslabšího nodu v clustru.
Query cache¶
Query cache musí být deaktivováno.
wsrep_sync_wait¶
Nastavení této proměnné zabezpečí, aby data byla vrácena ze synchronizovaného nodu. To se zajistí tak, že před provedením typu operace určené hodnotou wresp_sync_wait proběhne kontrola jestli je node synchronizován. Během kontroly jsou na nodu blokovány nové dotazy, čímž je umožněno dohnat synchronizaci dat provedenou v clusteru do bodu kdy byla kontrola zahájena. Po dosažení synchronizace se provede původní dotaz. To může mít za následek vyšší odezvy. Bez nastavení wresp_sync_wait může nod vracet STALE data.