SQL Server a vysoká dostupnost – III.

V dnešním díle seriálu o vysoké dostupnosti se zaměříme na database mirroring. Mirroring u databází pracuje na principu synchronizace dvou kopií databáze (principal a mirror databáze). V případě výpadku prvního serveru tedy můžeme použít server druhý. Database mirroring byl představen v rámci SQL Server 2005 a dodnes je v serveru k dispozici ve dvou různých režimech.

Mirroring mode

Mirroring může být nakonfigurován ve dvou režimech – high-performance a high-safety (u tohoto rozlišujeme zda-li je k dispozici i automatický failover). Režim high-performance je dostupný pouze u enterprise edice a dovoluje, aby databáze byly replikovány asynchronně. V tomto režimu potvrzuje principal (aktivní) server transakci směrem ke klientovi, aniž by čekal na potvrzení transakce z mirror serveru. Tím je dosaženo minimální latence. Tento režim ale nedovoluje použít automatický failover. Proč tedy tento režim používat? Nejčastěji pokud je mirroring nastaven mezi servery v různých lokalitách. V těchto případech je ale možné využít i log-shipping nebo asynchronní AlwaysOn, o kterém jsme psali v minulém díle.

Druhým režimem je high-safety, který pracuje se synchronní replikací. V tomto případě je transakce potvrzována na mirror i principal serveru, což může způsobovat drobná zpoždění v závislosti na konektivitě mezi těmito servery. U režimu high-safety může být použit i třetí server tzv. witness. Pokud je použit witness server, můžeme v tomto režimu využít automatický failover mezi principal a mirror serverem. Jako witness server je možné použít i nižní edice typu Express. Databáze je dostupná pouze u serverů mirror a principal, na witness serveru nikoli.

Page Repair

Database mirroring a stejně tak i Availability groups, o kterých jsme psali v druhém díle tohoto článku, mohou využívat automatického opravení datových stránek v případě několika definovaných chyb.

V případě database mirroringu může dojít k těmto chybám jak na serveru principal tak na serveru mirror. V případě, že dojde k jedné z těchto 3 chyb na serveru principal, je vložen záznam do tabulky suspect_pages, následně si principal server vyžádá tuto stránku z mirror serveru. Pokud je tato stránka dostupná (čeká se na LSN) na mirror serveru, je odeslána zpět na principal, kde je obnovena. Následně je v tabulce suspect_pages označená jako obnovená. V případě availability groups se rozešle zpráva všem replikám, na kterých je databáze uložená se žádostí o obnovu stránky. Je zde několik výjimek, kdy automatické obnovení stránky není možné a to zejména

· Stránka s ID 0 (hlavička souboru, file header page)

· Stránka s ID 9 (root page)

· GAM stránky (mapa alokovaných extentů)

· SGAM stránky (mapa mixed extentů s volnými stránkami)

· A stránky Page Free Space

Konfigurace

Mirroring je možné konfigurovat přímo z management studia při splnění několika podmínek

· Mirroring nelze použít na systémové databáze (master, model, msdb, temp)

· Databáze musí využívat režim Full Recovery (více zde http://www.prosql.cz/prce-s-recovery-modely-na-sql-serveru/)

· Databáze nevyužívá filestream

· Nejsou využívány distribuované transakce

V konfiguračním dialogu pro mirroring je nutné zvolit jednotlivé partnery (servery principal, mirror a witness) a zkonfigurovat jejich endpointy, což jsou SQL objekty, které dovolují jednotlivým serverům mezi sebou komunikovat. Uvedeme-li správné účty služeb, bude zkonfigurováno i zabezpečení endpointů pro připojení mezi servery. Velkou výhodou mirroringu je také automatické šifrování komunikace. Jakmile jsou endpointy zkonfigurovány a požadovaná databáze je obnovena na mirror server (nutné provést zálohu a obnovu před spuštěním mirroringu) je možné mirroring zapnout v nastavení samotné databáze. Databáze na mirror serveru bude po úspěšném spuštění ve stavu Mirror, Synchronized /Restoring což nedovoluje klientům přistupovat k této databázi, dokud nebude proveden failover. Je však možné využít databázových snapshotů, které mohou být na mirror serveru vytvořeny z této databáze a do nich přistupovat například z reportů. Zde je však nutné uvědomit si, že snapshot je statický a neobjevují se v něm nová data, která byla přidána do principal databáze po vytvoření snapshotu.

Failover

V případě výpadku principal serveru existuje několik variant jak provést failover. Předpokládejme, že máme k dispozici witness server, poté v takovém případě dojde k automatickému failover na server mirror. Má-li klient v connectionString konfigurována jména obou serverů, dojde v klientské aplikaci k automatickému přepojení na mirror server, který přejímá roli primárního serveru. V případě, kdy není použit witness server je nutné provést failover ručně pomocí příkazu ALTER DATABASE.

V případě výpadku mirror serveru funguje primární server i nadále, pouze u mirror serveru může dojít k výpadku reportingu, který využívá snapshoty. Po obnovení mirror serveru bude databáze opět synchronizována s principal serverem. U principal serveru bude v době výpadku stav disconnected, a databáze je v tuto chvíli nechráněna proti výpadku.

Na serveru witness nejsou uložena žádná data, proto jeho výpadek ovlivňuje pouze možnosti automatického failover scénáře pro mirroring.

Závěr

V dnešním díle jsme si představili database mirroring, který je možné nakonfigurovat v několika režimech. Mezi zajímavé vlastnosti mirroringu patří automatický failover v případě witness serveru, automatická oprava datových stránek a komprese synchronizovaných informací. V rámci SQL Server 2012 se jedná o discontinued feature, která nebude dostupná v dalších verzích SQL Serveru a je nahrazena technologií AlwaysOn.