V dnešním díle seriálu o vysoké dostupnosti se zaměříme na log shipping. Jedná se o funkci dostupnou v běžných edicích tj. Standard, Enterprise, Business Intelligence a Web. Log shipping automaticky zasílá zálohu transakčního logu z primárního serveru na několik sekundárních serverů. Na těchto sekundárních serverech je následně záloha transakčního logu obnovena.
Log Shipping nabízí několik zajímavých funkcí, mezi které patří Disaster Recovery pro jednotlivé databáze. Bohužel toto DR řešení nenabízí vysokou dostupnost, protože log shipping neumožňuje konfiguraci pro failover jako např. mirroring nebo AlwaysOn, které byly představeny v minulých dílech.
Konfigurace
Konfigurace log shipping je dostupná ve vlastnostech jednotlivých databází, stejně jako database mirroring. Při zapnutí je nejprve nutné nastavit zálohování transakčního logu databáze na dostupné úložiště pro ostatní log shipping partnery a intervaly pro jednotlivé zálohy. Čím kratší bude zvolený interval (výchozí hodnota je 15 minut) tím více budou databáze mezi servery synchronizované.
Po nastavení zálohování je možné určit partnerské servery, na které budou tyto zálohy přenášeny. U log shippingu máme možnost volby pro obnovu dat. Cílový server může mít databázi ve stavu restoring nebo standby. V případě standby je možné tuto databázi použít pro readonly přístup např. pro reporting. Zároveň je zde možné nastavit, zda-li má dojít k upozornění, pokud nebyla obnovena záloha po určitou dobu.
V případě standby konfigurace jsou k dispozici 2 možnosti jak pracovat s obnovou transakčních logů. Zvolíme-li v nastavení odpojit uživatele během obnovy, pak budou uživatelé vždy během obnovy transakčních logů od databáze odpojeni. Pokud tuto volbu nezvolíme, tak bude systém čekat, až k databázi nebude připojen žádný uživatel. Do té doby, dokud budou uživatelé připojeni, nebudou transakční logy obnoveny.
Velkou výhodou log shippingu je možnost nastavení vícero serverů, na které má být přenášena záloha transakčního logu. U každého serveru může být navíc odlišně nastavené zpoždění mezi obnovou záloh.
Při konfiguraci log shipping jsou vytvořeny v SQL agentovi plánované úlohy, kterými je prováděna záloha, obnova a kopírování zálohy na cílové servery. Protože se neustále bavíme o transakčním logu, je nutné doplnit, že jedním z požadavků na log shipping konfiguraci je nastavení recovery režimu u databáze na full nebo bulk-logged. Více zde http://www.prosql.cz/prce-s-recovery-modely-na-sql-serveru Zálohy transakčních logů mohou být navíc komprimovány pro optimalizaci síťové komunikace mezi jednotlivými servery a hlavně pro zrychlení daných operací. Příjemnou vlastností SQL Server 2012 je dostupnost komprimovaných záloh už ve standard edici.
Failover
V případě výpadku je možné pomocí několika kroků převést standby databázi na databázi primární.
· Nejprve je nutné překopírovat všechny transakční logy z primárního serveru na server sekundární, v případě aktivní primární databáze provedeme tail log backup
· Provedeme obnovu databáze na sekundárním serveru
· Doplníme konfiguraci log shipping pro opětovné zajištění Disaster Recovery
Pro správnou funkci sekundárního serveru je však nutné dořešit také otázku zabezpečení SQL serveru. V každé databázi jsou definovaní databázoví uživatelé, ale pouze v databázi master jsou založené SQL server loginy. Tyto loginy je nutné přenést i na sekundární server, aby veškeré databázové přístupy nadále fungovaly. Samozřejmě je nutné provést i změny v DNS nebo nastavení klientů pro připojení k sekundárnímu serveru.
Závěrem
V dnešním díle seriálu o vysoké dostupnosti jsme si představili log shipping, který přenáší zálohy mezi primárním serverem a replikami. Na těchto sekundárních serverech jsou zálohy pravidelně obnovovány a databáze jsou takto udržovány v synchronizovaném stavu s primární replikou (s mírným zpožděním). Mezi hlavní nevýhody log shipping patří pouze manuální failover a nepodporovaný filestream. Díky synchronizovaným replikám je možné převést log shipping konfiguraci na AlwaysOn v případě, že máme k dispozici enterprise edici SQL Server 2012. V porovnání s ostatními možnostmi pro vysokou dostupnost nenabízí log shipping tolik možností jako Mirroring nebo AlwaysOn, ale i tak má v celkovém řešení Disaster Recovery své místo, i díky podpoře v rámci nižších edicí SQL Serveru.