AlwaysOn

V tomto druhém díle seriálu o vysoké dostupnosti SQL Serveru od Marka Chmela se podíváme detailněji na zcela novou funkci AlwaysOn. AlwaysOn je dostupná od verze SQL Server 2012. Pomocí AlwaysOn jsme schopni zajistit vysokou dostupnost databází mezi několika servery. AlwaysOn dovoluje konfigurovat dostupnost nad skupinou vybraných databází, což je pro dnešní systémy velká výhoda. Dnešní SW zdaleka nespoléhá pouze na jednu databází, a díky AlwaysOn nemusíme konfigurovat dostupnost pro každou databází jednotlivě.

Pro konfiguraci AlwaysOn musí databáze splňovat několik podmínek, mezi které patří např.

• Full Recovery režim (více http://www.prosql.cz/prce-s-recovery-modely-na-sql-serveru).
• Provedená záloha
• Nenastavené AUTO_CLOSE
• MultiUser režim
• Uživatelská databáze (nelze např pro master, model, temp)

Availability Groups

V rámci AlwaysOn je nutné konfigurovat Availability Groups (obdoba Exchange DAG), které v sobě obsahují databáze u nichž je vyžadována vysoká dostupnost. V rámci konfigurace AG je nutné zvolit nejen jednotlivé databáze, ale také jednotlivé servery, na které budou databáze replikovány (AG Replicas). U těchto serverů si můžeme vybrat, zda-li budou využívat synchronní (max 3 repliky v tomto režimu) nebo asynchronní replikace dat a také zda-li chceme využít automatický failover mezi servery (max 2 repliky).

Asynchronní režim je vhodný pro repliky mezi datovými centry. V této konfiguraci je sekundární replika mírně zpožděná proti primární replice (je tedy možná drobná ztráta dat při výpadku) díky tomu, že primární server při potvrzení transakce nečeká na potvrzení transakce i ze sekundární repliky. Naproti tomu v synchronním režimu čeká primární replika na potvrzení transakce i ze sekundárních replik. Za cenu určité latence transakcí je ale zajištěno, že pokud je transakce dokončena a potvrzena na primární replice, je uložena také na sekundárních replikách.

Dále je možné u každé repliky nastavit, zda-li budeme chtít využít read-only intent. Jedná se o novou možnost, kdy aplikace v rámci svého connectionString může uvádět, zda-li potřebuje do databáze ReadWrite přístup nebo pouze ReadOnly přístup. Pokud je pro aplikaci dostačující ReadOnly přístup, je možné aby tato aplikace přistupovala k sekundární replice, na které je tento ReadOnly režim povolen. Toho je možné velmi dobře využít např. u reporting aplikací, které data pouze prezentují uživatelům. Taková aplikace nemusí být připojena na primární repliku a může být směrována vůči sekundárním serverům. O samotné směrování se stará komponenta Availability Group Listener, jehož jméno volíme při konfiguraci a je nutné jej nastavit v DNS serveru. Aplikace se následně připojují k tomuto AG Listeneru, který se stará o správné směrování proti jednotlivým replikám.

ReadOnly Routing

AG Listener nám dovoluje nastavit, zda-li replika bude přijímat pouze read-only připojení. Toto nastavení však lze rozšířit o read only routing, kdy jsme schopni nastavovat pořadí jednotlivých ReadOnly replik dle aktivní primární repliky. Nejprve je nutné pro každou repliku nastavit tzv. ReadOnlyURL adresu pomocí powershell (nebo T-SQL) příkazu

Set-SqlAvailabilityReplica -ReadOnlyRoutingConnectionUrl „TCP://sql01.learning.local:1433“

A následně pro každou repliku nastavit routing list. Tedy je-li aktivní replika1, poté routing list sekundárních replik může být např replika2 a replika3. A obdobné nastavení bychom museli konfigurovat I na dalších 2 replikách.

Set-SqlAvailabilityReplica -ReadOnlyRoutingList "SecondaryServer","PrimaryServer"

Active Secondaries

Velkou výhodou sekundárních replik je nejen ReadOnly routing, ale take možnost zálohovat databáze v Availability Group na sekundárních replikách. Tato možnost je opět konfigurovatelná při vytváření listeneru, kde obdobně jako u ReadOnly routing určujeme preference pro backup servery, na kterých bude vytvořená záloha. Pořadí mezi replikami je určeno prioritou, s hodnotou od 1 do 100 (100 je nejvyšší priorita). V případě priority 0 nebude takto označená replika nikdy využita pro zálohu databází.

Monitoring

Pro přehled stavu AvailabilityGroups a replik máme k dispozici dashboard, který je mj. postaven nad ExtendedEvents. Těm se dostalo v SQL Serveru 2012 grafického rozhraní pro jejich jednodušší konfiguraci. V rámci dashboardu je mimo přehledu možné i inicializovat failover (včetně odhadu ztráty dat při forced-failover).

Závěr

V tomto díle jsme si představili AlwaysOn, nejnovější možnost pro vysokou dostupnost v rámci SQL Server 2012. AlwaysOn by se dala charakterizovat jako kombinace mirroring a logshipping technologie. Pro svoji správnou funkci vyžaduje Windows FailOver Cluster a SQL Server Enterprise Edition. Mezi hlavní výhody AlwaysOn patří jednoduchá konfigurace pomocí wizardu a powershellu, možnost více replik mezi servery v různých režimech a také podpora pro filestream a filetable. Zajímavou možností je také backup na sekundárních replikách a readonly routing.