Dotaz: Vyber DB s failover

[Dave]

Ahoj, muzete mi prosim doporucit nejakou opensource SQL DB s rozumnym (softwarovym) resenim failoveru? Nasel jsem jen MySQL(cluster), u PostgreSQL neni zrejme standardni reseni. Je MySQL v clusteru pouzitelna a bezpecna volba? Diky

Odpovědi

[l0gik]

PostgreSQL od devítky má zabudouvanou podporu replikace. Sice co vím neumí zdaleka vše, ale jako hot standby s failoverem by snad fungovat měla.

MySQL s replikací použielná je dobře, pokud Ti nevadí limitace MySQL (nepoužitelné triggery spolu s FK, Fulltext pouze na netransakčních tabulkách - mixovat příkazy nad různejma enginama se při replikaci nedoporučuje - atd.).

Výhledově je teď vývoj postgresu na replikaci dost zaměřenej, takže bych se ho nebál nasadit, to, co neumí teďka, za chvíli umět bude. Ale pokud chceš jen "hloupou" SQL databázi a nehodláš dělat programování na databázový vrstvě, stačí i MySQL.

[Dave]

Hot standby bohuzel neni pro me ucely dostatecny, takze asi zvolim MySQL. Doufam, ze PostgreSQL bude mit brzy pozadovane vlastnosti take, jelikoz bych ji pouzil radsi. Nicmene v roadmape jsem nic takoveho nenasel.

[l0gik]

No oni na to dělají co vím v databázi pouze potřebné api a nechávaj to na externích nástrojích. Zkus se podívat na pg_pool II, jestli by Ti nestačil. zajímavě taky vypadá http://www.postgres-r.org/documentation/references ale bohužel je to furt ve vývoji, byť funkční. Do produkce to asi není.

[okbob]

failover ma na starosti pgpool

[Ondra]

MySQL cluster jsme chtěli používat, ale nakonec od toho ustoupili a přešli na replikaci (master-master + 2x master - slave). Ze svého testování jsem dospěl přibližně k těmto závěrům. Začnu klady

• stabilní a nenáročný provoz
• velmi krátká doba reakce (vychází z principu in-memory storage enginu - bohužel jediného možného)
• velice rychlá komunikace: vydumpovat databázi (16 MB) trvá 3 sekundy (struktura + data).
• výpadek stroje, který je v redundanci ne prakticky nepostřehnutelný.
• pomocí vyvažování a použití mysql clienta, lze udržet session i při výpadku komunikujícího stroje

a zápory

• aby byla zajištěna kvalita služeb, je potřeba všechny stroje minimálně duplikovat, což znamená provoz alespoň 6 VM.
• Selecty a dumpy jsou rychlé, to nelze ale říct o insertech. Na našem testovacím clusteru cca 3 min (16 MB, data + struktura) a předpokládám, že s vyšším počtem datových nodů by ještě rostla.
• proces obstarávající datová úložiště na storage nodech i v případě, že nic nedělá spotřebovává cca 1,5% systémových zdrojů - předpokládám, že s větším objemem dat by rostla
• přesto, že testovaná velikost databází může být v řádech několika desítek MB, zabírá storage proces 68% RAM paměti (instalován 1 GB), celkově stroj bere 1 GB RAM a další skoro 2 GB na SWAPu
• pokud se změní konfigurační parametr je potřeba restartovat všechny stroje. V dokumentaci sice toto psáno není (je možnost bez restartu jako celku), ale mě se jinak změny neprojevily
• in-memory storage engine. Výše popsaná velká rychlost, ale jinak z mého pohledu spíše negativa. Data jsou v RAM a ne na disku. V případě vypnutí PC a nezálohování storage nodu se o data přichází. Zůstávají pouze metadata na API nódech.
• tomu lze předcházet, pokud použijeme vnitřní příkaz BACKUP. Mě bohužel nefungoval.
• řešení byly v tomto případě dumpy všechn tabulek a po obnovení clusteru import tohoto dumpu (včetně systémových tabulek).
• v případě redundance storage nodů a uchovávání dat roste paměťová náročnost přímo úměrně s rostoucím počtem redundantních nódů
• není možnost jiného storage enginu - nepodporuje fulltext a cizí klíče
• v případě použití nodegroup musí vždy zůstat alespoň jeden stroj z dané nodegrupy běžet (záleží na konfiguraci)

Všechny tyto poznatky mě vedou k tomu, že MySQL Cluster by se hodil do míst, kde můžeme poskytnout mnoho RAM a zajistit faul tolerance provozovaných strojů. V takovém případě se nám odmění špičkovou odezvou a rychlostí s jakou dokáže data poskytovat během selectů.

Přirovnal bych to k domečku z karet, který sice není bez pojivého materiálu, ale ten materiál není lepidlo, nýbrž med.

Osobně jsou pro nás důležitější data která máme než rychlost přístupu k nim. Proto jsme přistoupili k řešení s 2 aktivními servery v master-master replikaci. Pro naše potřeby splňuje redundanci i latenci.

S PostgreSQL nemám zkušenosti.