Kopírování dat mezi více instancemi databáze se říká
replikace, to je ten pojem, který hledáte. Měla by vám stačit master/slave replikace – máte primární instanci (master), na kterou jdou zápisy, data se replikují na slave, který se nepoužívá buď vůbec (jednodušší řešení), nebo se z něj může číst (složitější, ale zlepší to výkon, protože se rozloží zátěž). Když přestane být master dostupný, udělá se ze slave master a jede se dál.
Pozor na to přepnutí, kritické je to, aby byl vždy opravdu jen jeden master. Aby se nestalo, že část systému vyhodnotí, že master přestal být dostupný a přepne slave→master, ale jiná část pořád uvidí původní master – a některé zápisy půjdou na původní master a některé na původní slave povýšený na master. Ten samý problém pak nastává, když je master opravdu nedostupný, a pak najednou ožije (třeba se znovu připojí datacentrum, které mělo nějaký výpadek).
Tj. na první pohled to vypadá, že by bylo dobré mít přepínání masteru na jinou instanci automatizované. Ale pokud si můžete dovolit výpadek 1–2 hodiny, bude jednodušší přepínat to ručně – prostě někdo ověří, že žádná instance aplikací nekomunikuje s masterem, vypne je, přepne původní slave na master, všechny aplikace přesměruje na nový master a aplikace zapne.
Jiný případ je master/master nebo multi-master replikace, která znamená, že můžete zapisovat na obou stranách. MySQL to podporuje už dlouho (na rozdíl od PostgreSQL, které myslím, stále má multi-master replikaci jen v rámci komerčních řešení). Ale slyšel jsem už spoustu strašidelných historek o tom, jak se master/master replikace v MySQL rozpadla – takže vzhledem k tomu, že to nepotřebujete, bych nepokoušel osud.
Co se týče aplikace, tam je to vlastně velmi jednoduché. Můžete mít aplikace ve více instancích v různých datacentrech, v DNS bude mít IP adresy všech instancí, klient si vždycky nějakou vybere a s tou bude komunikovat. Zároveň to bude fungovat jako rozvažování zátěže. Když dojde k výpadku jedné lokality, chytřejší klienti po neúspěšném spojení na jednu IP adresu zkusí jinou IP adresu z odpovědi; pro hloupější klienty je dobré tu nefunkční IP adresu z DNS dočasně vyřadit, ať se vůbec nenabízí.
Pokud byste nechtěl trvale platit provoz dvou instancí aplikace, můžete ji samozřejmě provozovat jen v jedné lokalitě a počítat s tím, že v případě výpadku koupíte nějaký VPS někde jinde a tam aplikaci rozběhnete. V takovém případě je ale dobré mít zautomatizovanou tu instalaci aplikace, protože jestli začnete ručně na VPS instalovat distribuci, do ní Javu a pak vaši aplikaci, budete mít dost perné ty dvě hodiny povoleného výpadku. V takovém případě by v DNS samozřejmě byla jen IP adresa základní lokality a při výpadku a instalaci v jiné lokalitě by se ta IP adresa změnila.
Každopádně je potřeba mít v DNS nastavenou krátkou dobu platnosti záznamů. Doporučuju 5 minut, protože níž se stejně reálně nedostanete – mnozí klienti kratší dobu než 5 minut ignorují. Takže je potřeba počítat s tím, že klienti reálně pocítí výpadek v řádu pár minut až dejme tomu deset či patnáct minut. Pokud byste měl požadavek na zkrácení doby nedostupnosti pro klienty (podle dotazu to nepředpokládám), už je potřeba to řešit jinak než přes DNS.
Existují služby, které umí to přepnutí DNS zařídit automaticky – monitorují cílové servery, a pokud přestanou být dostupné, přehodí DNS záznamy jinam. Jako službu
DNS-failover to nabízí třeba ClouDNS.net, ale určitě to umí i jiní. (Nebo si to samozřejmě můžete sám naskriptovat.) Ale jak jsem psal – přepnutí aplikace je jednoduchá disciplína, klíčové je to přepnutí databáze.
Samozřejmě existují už hotová řešení, třeba cloudové databáze (kompatibilní s MySQL), ale předpokládám, že vám jde o co nejlevnější řešení na bázi nějakých dvou VPS.
9 Odpovědí
5145 Zhlédnutí