BonzBlog Michaela Juřka

Jednou z nejzajímavějších novinek v SQL 2005 je možnost zrcadlení databáze. A tak mi nedalo si ji nevyzkoušet. Protože jsem neměl tři servery, použil jsem tři instance uvnitř jednoho Virtual PC na svém notebooku, a fungovalo to přesto výborně. Hlavně jsem ocenil jednoduchost, zvládl jsem to nastavit i bez předchozího přečtení dokumentace :-)

Princip není složitý - klient nebo střední vrstva přistupuje k primárnímu serveru (Principal), přičemž data (resp. transakční log) jsou paralelně zapisována na záložní server (Mirror), a to v několika možných režimech (viz dále). Komunikace probíhá proprietárním binárním protokolem přes jeden zvolený TCP port bez použití distribuovaných transakcí. Na zrcadle jsou data ve stavu permanentní průběžné obnovy - inicializace zrcadla se provádí zálohou principal databáze a její obnovou na mirror serveru s možností NO RECOVERY, obě databáze musejí mít zapnuté plné používání transakčního logu. Administrátor může provést s databází dvě akce:

• Pozastavení/obnovení mirroringu (Pause/Resume), čímž se na principalu změny jakoby hromadí ve frontě a jsou pak maximální možnou rychlostí přenášena na mirror (stav zvaný synchronizing)
• Failover - tj. záměna rolí obou serverů. V podstatě dochází k odrolování probíhajících transakcí, kontrole synchronizace a přepnutí rolí. Klienti jsou převedeni automaticky - nová vlastnost SNAC (SQL Native Access Client). A teď pozor, na mém notebooku trvá failover cca 1s !!!

Nejdůležitější je volba správného režimu:

• Synchronní režim (maximize protection) - data se zapisují synchronně do transakčních logů obou serverů. Selhání libovolného serveru znamená nedostupnost celého systému (musí přijít administrátor a rozhodnout co dál). Pokud chcete např. aplikovat service pack, uděláte to takto: Pause, Instalace na mirror, Resume, počkat na stav Synchronized, Failover, Pause, instalace na principal, Resume, počkat na stav Synchronized, Failover zpět na Principal.
• Asynchronní režim (maximize performance) - data jsou na mirror přenášena maximální možnou rychlostí, nicméně asynchronně. Režie takového přenosu je nejmenší, existuje ovšem riziko ztráty malého množství dat v případě havárie principalu. Pokud vypadne mirror, systém je dále dostupný. Vypadne-li principal, musí přijít administrátor a rozhodnout co dál - přechod na mirror nemůže být automatický právě z důvodu rizika ztráty malého množství dat, někdo zodpovědný musí rozhodnout, jak je to s Principal serverem vážné a co teď
• Synchronní režim s automatickým failoverem (maximum availability) - uspořádání pro synchronní režim je doplněno třetím serverem, tzv. svědkem (witness). Přesnější označení by asi bylo arbitr. Tento svědek umožňuje automatický failover v případě selhání Principal serveru, selhání mirror serveru nemá žádné důsledky pro dostupnost. K čemu je potřeba? Brání scénáři zvanému "split brain", kdy dojde k výpadku komunikace mezi principalem a mirrorem, přičemž tito si "myslí", že druhý server selhal. Oba se tedy považují za principal servery a umožňují klientům aktualizaci dat - se všemi důsledky na jejich konzistenci, či spíše nekonzistenci. Svědek tedy musí serveru, který se chce prohlásit za Principal "odsvědčit", že toto smí udělat, zároveň je zodpovědný za to, že se to dozví klienti. Provedl jsem malý test - nechal jsem Principal server selhat tím, že jsem pomocí Kill zrušil jeho proces. Failover nastal s výchozím nastavením za 10-15s (měřeno z klienta). Asi by to šlo vyladit i na kratší dobu, ale pak by mohlo docházet k failoveru "při každém dupnutí do země", takže bych timeouty raději nezkracoval.

Pokud si s tím budete hrát, možná se vám stane, že po několika failoverch mirroring nepůjde nastavit v Management Studiu. To je zřejmě chyba. Proveďte 1 (až 2) failovery pomocí T-SQL příkazu ALTER DATABASE a bude zase vše OK. Při nastavování mirroringu vyplňte jména účtů na jednotlivých serverech, přestože jsou stejná. Pokud to neuděláte, průvodce sice skončí úspěšně, ale mirroring nepoběží.