SQL Server a vysoká dostupnost – IV.

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.
SQL Server a vysoká dostupnost – IV.

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é.

Klepněte pro větší obrázek

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.

Klepněte pro větší obrázek

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.

Klepněte pro větší obrázek

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-serveruZá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.

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.

Témata článku: SQL, Jednotlivý uživatel, Jednotlivý díl, Logo, Recovery, Cílový server, DOS, Celkové zrychlení, Mirroring, Dostupnost, Ostatní možnosti, Záloha

Určitě si přečtěte

Tesla chce změnit nákladní dopravu. Její elektrický náklaďák má ohromující parametry

Tesla chce změnit nákladní dopravu. Její elektrický náklaďák má ohromující parametry

** Tesla představila elektrický kamion ** Má obdivuhodný výkon i dojezd ** Prodávat by se měl už za dva roky

17.  11.  2017 | Vojtěch Malý | 226

Nejlepší notebooky do 10 tisíc, které si teď můžete koupit

Nejlepší notebooky do 10 tisíc, které si teď můžete koupit

** I pod hranicí desíti tisíc korun existují dobře použitelné notebooky ** Mohou plnit roli pracovního stroje i zařízení pro zábavu ** Nejlevnější použitelný notebook koupíte za pět a půl tisíce

16.  11.  2017 | Stanislav Janů | 53

Do 20 let nebude nikdo vlastnit auta, říká zkušený šéf několika automobilek

Do 20 let nebude nikdo vlastnit auta, říká zkušený šéf několika automobilek

** Bývalý šéf a expert z několika velkých automobilek se vyjádřil k budoucnosti tohoto průmyslu ** Do 20 let „nikdo“ nebude vlastnit auta ** Veškerá doprava bude řešená pomocí velkých logistických platforem

15.  11.  2017 | Karel Javůrek | 74


Aktuální číslo časopisu Computer

Otestovali jsme 5 HDR 4K televizorů

Jak natáčet video zrcadlovkou

Vytvořte si chytrou domácnost

Radíme s koupí počítačového zdroje