A to už se v podstatě neliší od toho, když programátor explicitně vybere datový zdroj.
Rozdíl je v tom, že na datový zdroj mohou být navázané další věci, třeba cache. Takže použití jiného datové zdroje může mít další konsekvence.
A co se týče rychlého failoveru, tak ten se přeci nemusí dělat "rekonfigurací aplikace", ale např. za pomocí IP směrování nebo.....
Nemusí se dělat jen rekonfigurací aplikace, ale zrovna začít posílat IP pakety v průběhu navázaného spojení někam jinam podle mne není nejlepší způsob, protože to bude chvíli trvat, než se zjistí, že to spojení je nakopnuté a má se ukončit a navázat nové.
Podstatné je říct si, k čemu vlastně má ten cluster sloužit. Pokud jde hlavně o bezpečné uložení dat, jako bonus zrychlení přístupu, ale pokud vypadne master, můžu si dovolit odstavit aplikaci třeb ai na několik hodin a během odstávky v klidu podle předem daného postupu přepnout provoz na jiný primární server, je to jiná situace, než když si od clusteru slibuju minimalizaci doby, kdy aplikace nemůže provádět zápis. V tom druhém případě je potřeba na to mít nastavené automaty. A osobně bych to nedělal tak, že někomu něco utrhnu pod nohama. Buď se víc datových zdrojů řeší na úrovni aplikace, pak by měla aplikace vědět, který je její aktuální datový zdroj. Nebo je tam nějaká proxy, takže z pohledu aplikace je to transparentní, a to, kam jde reálný provoz, zase ví proxy.
Nejhorší, co se vám s clusterem může stát, že budete mít dva (nebo více) primárů. K čemuž dojde snáz, když nevidíte, s čím se reálně komunikuje. Pak můžete mít dva aplikační servery, oba se připojují k databázi na stejné IP adrese, ale každý bude ve skutečnosti mít pod tou IP adresou jiný primár…
Zobrazit příspěvky
