Článek přečtěte do 5 min.

Při práci s databázemi SQL Server se často setkáte se scénáři, kdy potřebujete záložní kopii databáze pouze pro čtení, musíte přesunout nebo migrovat databázi z jednoho serveru na druhý se zkrácením prostojů nebo potřebujete nakonfigurovat řešení pro obnovu po havárii. Microsoft SQL Server vám poskytuje funkce pro tyto požadavky, jako jsou skupiny dostupnosti SQL Server AlwaysOn, zrcadlení databáze, zálohování a obnova a dodání protokolu.

V tomto příspěvku popisujeme jednu z nejjednodušších funkcí, odesílání protokolů, kterou můžete použít nejen pro řešení obnovy po havárii pro databázi SQL Server, ale také pro migraci databází SQL Server se zkrácením prostojů. V našich předchozích blozích jsme psali o nasazení Microsoft SQL Server na Oracle Cloud Infrastructure (OCI) a konfiguraci skupin dostupnosti SQL Server Always On na Oracle Cloud Infrastructure. Provedeme Vás konfigurací odesílání protokolů mezi dvěma servery SQL ve dvou různých tenancích OCI.

Co je to doprava protokolu?

Každá databáze SQL Server má transakční protokol, který zaznamenává všechny transakce a úpravy databáze provedené každou transakcí. Záloha tohoto protokolu transakcí se nazývá záloha protokolu transakcí. Odeslání protokolu používá proces pravidelného automatického zálohování protokolu transakcí na primárním databázovém serveru a obnovení na jeden nebo více sekundárních databázových serverů pomocí úloh SQL Server Agent.

Podle společnosti Microsoft vám dodání protokolu poskytuje následující výhody:

  • Poskytuje řešení zotavení po havárii pro jednu primární databázi a jednu nebo více sekundárních databází, každou na samostatné instanci SQL Server.
  • Podporuje omezený přístup pouze pro čtení k sekundárním databázím během intervalu mezi úlohami obnovy.
  • Umožňuje uživatelem zadanou prodlevu mezi okamžikem, kdy primární server zálohuje protokol primární databáze, a okamžikem, kdy musí sekundární servery obnovit (aplikovat) zálohu protokolu. Delší prodleva může být užitečná například při náhodné změně dat v primární databázi. Pokud je náhodná změna zaznamenána rychle, může vám zpoždění umožnit načíst stále nezměněná data ze sekundární databáze, než se tam změna projeví.

Architektura

Než půjdeme dále, vysvětlíme si nějakou terminologii.

Nájemní smlouva je zabezpečený a izolovaný oddíl OCI k vytváření, organizaci a správě vašich cloudových zdrojů. Tyto zdroje zahrnují Compute instance, sítě, úložiště, databáze, identity, analýzy a další. Nájem může být také nazýván účtem.

Virtuální cloudová síť (VCN) je virtuální privátní síť, kterou nastavíte v oblasti OCI. Velmi připomíná tradiční síť s pravidly firewallu a komunikačními bránami. VCN pokrývá jeden nebo více bloků CIDR (IPv4 a IPv6, pokud je povoleno). Můžete to porovnat s virtuální privátním cloudem (VPC) Azure Virtual Network (VNet) nebo Amazon Web Service (AWS).

Dynamická směrovací brána (DRG) je volitelný virtuální směrovač, který můžete přidat do své VCN. Poskytuje cestu pro privátní síťový provoz mezi vaší VCN a místní sítí. Můžete jej použít s dalšími síťovými komponentami a směrovačem ve vaší místní síti k navázání spojení prostřednictvím site-to-site VPN nebo OCI FastConnect. Může také poskytnout cestu pro privátní síťový provoz mezi vaší VCN a jinou VCN v jiné oblasti.

Vzdálené peeringové připojení (RPC) je komponenta, kterou můžete přidat do DRG. Umožňuje vám propojit jednu VCN s jinou VCN v jiné oblasti.

V tomto scénáři pracujeme se dvěma nájemci OCI a VCN. Potřebujeme tedy nakonfigurovat peering VCN tak, aby spolu mohly mluvit dva SQL servery ve dvou různých tenancích OCI. Konfigurace odesílání protokolů mezi servery SQL ve stejném pronájmu OCI a VCN je jednodušší a nevyžaduje partnerský vztah VCN.

Naše architektura používá následující komponenty:

OCI nájem A:

  • VCN-A
  • DRG-A
  • SQLServer-A

OCI nájem B:

  • VCN-B
  • DRG-B
  • SQLServer-B

Grafika znázorňující architekturu pro protokol Microsoft SQL Server odeslání mezi dvěma nájemci na OCI.

Začínáme

Postupujeme podle kroků uvedených v části Použití SQL Server Management Studio pro konfiguraci odesílání protokolu. Než začneme, musíme nakonfigurovat peering VCN mezi dvěma nájemci OCI.

Při konfiguraci dopravy protokolu musíte vytvořit sdílený adresář, aby byly zálohy protokolu transakcí dostupné sekundárnímu serveru. V tomto sdíleném adresáři se generují zálohy protokolu transakcí. Pokud například zálohujete své transakční protokoly do adresáře c:\data\tlogs\, můžete vytvořit sdílenou složku \\primaryserver\tlogs tohoto adresáře.

Také se ujistěte, že verze SQL Server sekundární databáze je stejná nebo vyšší než primární databáze. Primární databáze musí používat úplný nebo hromadně protokolovaný model obnovy. Přepnutí databáze na jednoduchou obnovu způsobí, že doprava protokolu přestane fungovat.

Konfigurace zabezpečení

Účty služeb SQL Server a účty služeb SQL Server Agent obou serverů SQL potřebují oprávnění ke čtení a zápisu do sdíleného adresáře. Protokol expedice uložených procedur vyžaduje členství v pevné roli serveru sysadmin.

VCN peering mezi nájemci

Při konfiguraci partnerského vztahu VCN mezi dvěma nájemci musíme zajistit, aby byla na sítě VCN v různých nájemcích použita příslušná oprávnění správy identit a přístupu (IAM) . Musíme také nakonfigurovat DRG v obou nájemních smlouvách a připojit VCN k těmto DRG. Když jste vytvořili DRG pomocí kroků uvedených v článku, postupujte podle kroků v Peering VCN v různých regionech prostřednictvím DRG .

Snímek obrazovky s úkoly, které je třeba provést při konfiguraci DRG v nájemních smlouvách a připojení VCN.

Před úkolem C musíme nakonfigurovat zásady IAM. V pronájmu A potřebujete skupinu (skupinu žadatelů), která má oprávnění ke správě DRG a VCN v pronájmu. Nájemce A vystupuje jako žadatel a nájemce B jako příjemce. Spusťte následující zásady IAM prostřednictvím žadatele:

  • Definujte tenancy Acceptor jako <acceptor-tenancy-ocid>
  • Povolit skupině <název-skupiny-žádajícího> spravovat vzdálený peering-od v oddílu <<název-oddělení žadatele>>
  • Podporujte skupinu <název-skupiny žadatelů> pro správu vzdáleného peeringu v aplikaci Tenancy Acceptor

Spusťte následující zásady IAM příjemcem:

  • Definujte žadatele o pronájem jako <requestor-tenancy-ocid>
  • Definujte skupinu <název-skupiny-žádajícího> jako <skupina-žádajícího-ocid>
  • Přijmout skupinu <název-skupiny-žádajícího> žadatele o pronájem pro správu vzdáleného peeringu v oddílu <název-přijímacího-oddělení>

Konfigurace odesílání protokolu mezi dvěma nájemci

Použijte kroky v části Použití SQL Server Management Studio .

V kroku 5 zadejte cestu UNC sdíleného adresáře, který jste vytvořili. Účty SQL Server a SQL Agent Service z obou nájemců potřebují oprávnění ke čtení/zápisu v tomto adresáři.

Snímek obrazovky okna Nastavení zálohování protokolu transakcí zobrazující síťovou cestu k záložní složce.

Snímek obrazovky okna Nastavení zálohování protokolu transakcí zobrazující alternativní síťovou cestu k záložní složce.

Pokud používáte síťovou cestu k záložní složce, nemusíte postupovat podle kroku 6. Pokud chcete pro zálohování použít místní cestu, zadejte místní cestu k záložní složce.

Snímek obrazovky okna Nastavení zálohování protokolu transakcí zobrazující místní cestu k záložní složce.

V kroku 9 můžete povolit kompresi zálohy, aby byl soubor zálohy komprimován. Povolení komprese záloh vám může pomoci ušetřit místo na disku.

V kroku 17 můžete vybrat režim No Recovery nebo Standby. Pohotovostní režim podporuje omezené operace pouze pro čtení na sekundárním serveru. Pokud zvolíte režim Standby, ujistěte se, že jste postupovali podle kroku 18. Pokud zvolíte režim Standby, operace čtení nebude fungovat, když probíhá obnova.

Monitorování serveru je volitelné, takže tento krok můžete přeskočit.

Po dokončení konfigurace dojde k úplnému zálohování databáze, které se vytvoří a obnoví na sekundárním serveru a poté každých 15 minut.

Nyní jste úspěšně nakonfigurovali odesílání protokolu mezi dvěma servery SQL. Odesílání protokolů můžete použít jako řešení obnovy po havárii, abyste měli záložní kopii pouze pro čtení k přenesení požadavku na čtení do pohotovostní databáze nebo k migraci databází z jednoho serveru na druhý se zkrácením prostojů.

Pokud chcete převzít převzetí služeb při selhání na váš server pro obnovu po havárii nebo dokončit migraci, můžete během období přerušení zastavit připojení aplikace a postupovat podle kroků v části Fail Over to a Log Shipping Secondary (SQL Server) pro převzetí služeb při selhání primárního databázového serveru do vašeho sekundární databázový server. Po dokončení převzetí služeb při selhání musíte přesměrovat své aplikace, aby se připojily k novému primárnímu serveru SQL.

Zdroj: Oracle