Další díl seriálu o SQL Serveru a vysoké dostupnosti bude zaměřen na database mirroring, neboli zrcadlení databází.
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žší 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.
| 823 | Nastala chyba CRC součtu na uložených datech |
| 824 | Logická chyba |
| 829 | Stránka s příznakem „čekání na obnovu“ (restore pending) |
Tabulka 1- Automatická obnova stránek
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 tří 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
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.
Autor: Marek Chmel
Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.
