Úvod
Transaction Log Shipping je velmi dobře známá technologie používaná v SQL Serveru k udržování kopie živé databáze na webu pro obnovu po havárii. Technologie závisí na třech klíčových úlohách:Backup Job, Copy Job a Restore Job. Zatímco úloha zálohování běží na primárním serveru, úlohy kopírování a obnovy běží na sekundárním serveru. Proces v podstatě zahrnuje pravidelné zálohování protokolu transakcí do sdílené složky, ze které se úloha kopírování přesune na sekundární server; následně úloha Restore Job použije zálohy protokolu na sekundární server. Než to vše začne, musí být sekundární databáze inicializována plnou zálohou z primárního serveru obnovenou s možností NORECOVERY.
Společnost Microsoft poskytuje sadu uložených procedur, které lze použít ke konfiguraci odesílání protokolu end-to-end, stejně jako ekvivalenty GUI počínaje položkou vlastností každé databáze, pro kterou můžete chtít nakonfigurovat odesílání protokolu. Stojí za zmínku, že sekundární databázi lze konfigurovat v režimu NORECOVERY nebo v režimu STANDBY. V režimu NORECOVERY není databáze nikdy k dispozici pro dotazy, ale v režimu STANDBY může být sekundární databáze dotazována, když neprobíhá žádná operace obnovy protokolu transakcí.
Nastavení prostředí
Abychom to dostali do pohybu, vytvoříme dvě instance SQL Serveru na AWS s identickým obrazem Amazon EC2. Tato instance Amazon EC2 používá SQL Server 2017 RTM-CU5 na Windows Server 2016. Poté obnovíme kopii databáze WideWorldImporters pomocí sady záloh získané z GitHubu do první instance, naší primární instance. Stejnou zálohovací sadu používáme k vytvoření dvou identických databází s názvem BranchDB a CorporateDB.
Obr. 1 verze SQL Server
Obr. 2 BranchDB a CorporateDB na primární instanci (sekundární instance)
Výpis 1:Obnovení vzorové databáze WideWorldImporters
restore filelistonly from disk='WideWorldImporters-Full.bak'restore database CorporateDB from disk='WideWorldImporters-Full.bak' se statistikami=10,recovery, move 'WWI_Primary' to 'M:\MSSQL\Data\WWI_Primary. mdf' , přesuňte 'WWI_UserData' do 'M:\MSSQL\Data\WWI_UserData.ndf' , přesuňte 'WWI_Log' do 'N:\MSSQL\Log\WWI_Log.ldf', přesuňte 'WWI_InMemory_Data_1' do \'M:\MSSQL Data \ wwi_inmemory_data_1.ndf'restore databáze Branchdb z disku ='wideWorlDimporters-full.bak' se statistiky =10, zotavení, přesun 'wwi_primary' to 'm:\ mssql \ data \ wwi_primary1.mdf', pohybu M:\MSSQL\Data\WWI_UserData1.ndf' , přesuňte 'WWI_Log' do 'N:\MSSQL\Log\WWI_Log1.ldf', přesuňte 'WWI_InMemory_Data_1' do 'M:\MSSQL\Data\WWI_InMemory_Data_>11.ndfNyní máme dvě instance, primární instanci hostující dvě primární databáze (BranchDB a CorporateDB a sekundární instanci bez uživatelských databází. Pokračujeme v konfiguraci odesílání protokolu transakcí na obou databázích, ale odlišujeme je použitím zpoždění na konfiguraci obnovení první databáze. Připomeňme si, že databáze jsou ve skutečnosti identické, pokud jde o data, která obsahují. Následující grafika ukazuje klíčové možnosti vybrané v konfiguraci Log Shipping.
Obr. 3 Nastavení zálohování pro BranchDB
Obr. 4 Zkopírujte nastavení pro BranchDB
Obr. 5 Obnovte nastavení pro BranchDB
Každá úloha Log Shipping je nakonfigurována tak, aby se spouštěla každých pět minut. Abychom mohli zpracovat „Delay Restoring Backups“, musíme použít režim Standby Recovery v konfiguraci Log Shipping. Je to logické, protože má sekundární databázi v pohotovostním režimu a znamená, že můžeme dotazovat sekundární databázi, kdykoli neprobíhá obnovení protokolu transakcí. Hodnota, kterou uvedeme v této volbě (v tomto případě 30 minut), nám poskytuje dobré okno, během kterého můžeme spouštět sestavy ze sekundární databáze, kromě základního požadavku tohoto článku, kterým je možnost zotavení z chyby uživatele.
Měli bychom také zmínit, že obnova záloh protokolu transakcí je ve skutečnosti zpožděna. Jeho časové razítko je pozdější než hodnota zpoždění. To znamená, že všechny zálohy protokolu transakcí budou zkopírovány na sekundární server, který je založen na plánu a specifikovaný v úloze kopírování. Ve skutečnosti bude úloha obnovení stále probíhat podle plánu, ale zálohy protokolu transakcí (které nejsou staré až 30 minut) nebudou obnoveny. V podstatě je databáze BranchDB Standby 30 minut za primární databází BranchDB. Abychom toto zpoždění demonstrovali, v další části vytvoříme tabulku v obou databázích a vytvoříme úlohu, která každou minutu vkládá záznam. Tuto tabulku prozkoumáme v sekundárních databázích.
Nastavení pro CorporateDB Database jsou stejná jako na Obr. 3 až 5, s výjimkou úlohy obnovení, která NENÍ nastavena na zpoždění zálohování protokolu transakcí.
Obr. 6 Obnovte nastavení pro CorporateDB
Ověření konfigurace
Jakmile je konfigurace hotová, můžeme ověřit, že je konfigurace v pořádku a začít s pozorováním její práce. Zpráva o odeslání protokolu transakcí nám ukazuje, že DB pobočky skutečně zaostává za CorporateDB, pokud jde o obnovení:
Obr. 7a Zpráva o odeslání protokolu transakcí na primárním serveru
Obr. 7b Zpráva o odeslání protokolu transakcí na sekundárním serveru
Kromě toho si všimnete zprávy níže v historii obnovení úlohy pro BranchDB:
Obr. 8 Přeskočené obnovení protokolu transakcí na sekundárním serveru
S tímto ověřením můžeme jít ještě dále tím, že vytvoříme tabulku a pomocí úlohy každou minutu naplníme tuto tabulku řádky. Úloha je jednoduchý způsob simulace toho, co může aplikace dělat s uživatelskou tabulkou. To nám může ukázat, že toto zpoždění se v uživatelských datech rozhodně projevuje.
Výpis 2 – Vytvoření tabulky sledování protokolů
použijte BranchDBgocreate tabulku log_ship_tracker( ID int identita (100,1),Database_Name sysname default db_name(),RecordTime datetime default getdate(),ServerName sysname default @@servername)use CorporateDBgocreate table log_ship_tracker(ID int identity (100,1 ),Database_Name sysname default db_name(),RecordTime datetime default getdate(),ServerName sysname default @@servername)Výpis 3 – Vytvořte úlohu k naplnění tabulky sledování protokolů
/* ==Parametry skriptování==Verze zdrojového serveru:SQL Server 2017 (14.0.3023) Edice zdrojového databázového stroje:Microsoft SQL Server Standard Edition Typ zdrojového databázového stroje:Samostatný SQL ServerVerze cílového serveru:SQL Server 2017 Edice cílového databázového stroje:Microsoft SQL Server Standard Edition Cílový databázový stroj Typ:Samostatný SQL Server*/USE [msdb]GO/****** Objekt:Úloha [InsertRecords] Datum skriptu:2. 7. 2018 15:32:00 **** **/BEGIN TRANSACTIONDECLARE @ReturnCode INTSELECT @ReturnCode =0/****** Objekt:JobCategory [[Uncategorized (Local)]] Datum skriptu:2. 7. 2018 15:32:00 ****** /POKUD NEEXISTUJE (VYBERTE název Z msdb.dbo.syscategories WHERE name=N'[Uncategorized (Local)]' AND category_class=1)BEGINEXEC @ReturnCode =msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Uncategorized (Local)]'IF (@@ERROR <> 0 NEBO @ReturnCode <> 0) GOTO QuitWithRollbackENDDECLARE @jobId BINARY(16)EXEC @ReturnCode =msdb.dbo.sp_add_job @ job_name=N'InsertRecords', @enabled=1 ,@notify_level_eventlog=0,@notify_level_email=0,@notify_level_netsend=0,@notify_level_page=0,@delete_level=0,@description=N'Popis není k dispozici.',@category_name=N'[Uncategorized (Local)]', @owner_login_name=N'kairos\kigiri', @job_id =@jobId OUTPUTIF (@@ERROR <> 0 NEBO @ReturnCode <> 0) GOTO QuitWithRollback/****** Objekt:Krok [InsertRecords] Datum skriptu:7/ 2/2018 15:32:00 ******/EXEC @ReturnCode =msdb.dbo.sp_add_jobstep @[email protected],@step_name=N'InsertRecords',@step_id=1,@cmdexec_success_code=0, @on_success_action=1,@on_success_step_id=0,@on_fail_action=2,@on_fail_step_id=0,@retry_attempts=0,@retry_interval=0,@os_run_priority=0, @subsystem=N'TSQL',@commandD=Bgoinsuse Branch intolog_ship_trackervalues(db_name(),getdate(),@@název_serveru)použít CorporateDBgoinsert intolog_ship_trackervalues(db_name(),getdate(),@@název_serveru)GO',@database_name=N'master',@flags=0IF (@@ERROR <> 0 NEBO @ReturnCode <> 0) GOTO QuitWithRollbackEXEC @ReturnCode =msdb.dbo.sp_update_job @job_id =@jobId, @start_step_id =1 POKUD (@@ERROR <> 0 NEBO @ReturnCode <> 0) GOTO QuitWithRollbackEXEC @ReturnCode =msdb.dbo.sp_add_jobschedule @[email protected], @name=N'Schedule', @enabled=1, freq_type=4,@freq_interval=1,@freq_subday_type=4,@freq_subday_interval=1,@freq_relative_interval=0,@freq_recurrence_factor=0,@active_start_date=20180702,@active_time_end_date,2_9_active@start_time=1_31_99 schedule_uid=N'03e5f1b2-2e0b-4b30-8d60-3643c84aa08d' IF (@@ERROR <> 0 NEBO @ReturnCode <> 0) GOTO QuitWithRollback @EXEC @ReturnCode =msdb.dbo.spId_adjober =msdb.dbo.sp'd_adjobserv_ (local)'IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollbackCOMMIT TRANSACTIONGOTO EndSaveQuitWithRollback:IF (@@TRANCOUNT> 0) ROLLBACK TRANSACTIONEndSave:GO
Když se dotazujeme na tabulku v primárních databázích, můžeme potvrdit (pomocí sloupce RecordTime), že se řádky shodují v BranchDB a CorporateDB. Když stejným způsobem prozkoumáme tabulku v sekundárních databázích, jasně vidíme, že mezi BranchDB a CorporateDB máme 30minutovou mezeru.
Výpis 4 – Dotazování tabulky sledování protokolu
vyberte 10 nejlepších @@název_serveru [Current_Server],* z pořadí BranchDB.dbo.log_ship_tracker podle RecordTime descvyberte 10 nejlepších @@název_serveru [Current_Server], * z CorporateDB.dbo.log_ship_tracker pořadí podle RecordTime desc
Obr. 9 Shodují se tabulky sledovače protokolů v primárních databázích
Obr. 10 tabulek sledování protokolů má v sekundárních databázích ~30minutovou mezeru
Obnova po chybě uživatele
Nyní si promluvme o hlavní výhodě tohoto zpoždění. Ve scénáři, kdy uživatel neúmyslně zahodí tabulku, můžeme data rychle obnovit ze sekundární databáze, dokud neuplynula doba zpoždění. V tomto příkladu zrušíme tabulku Sales.Orderlines v OBOU databázích a ověříme, že tabulka již neexistuje v OBOU databázích.
Výpis 5 – Vypuštění tabulky řádků objednávek
drop table BranchDB.Sales.Orderlinesdrop table CorporateDB.Sales.OrderlinesGOuse BranchDBgoselect@@název_serveru [aktuální_server], db_name() [název_databáze], název, název_schématu(id_schéma) [schéma], typ_desc, datum_upravit, odkud_dat vytvořit. name='Orderlines'GOuse CorporateDBgoselect@@název_serveru [aktuální_server], název_db() [název_databáze], název, název_schématu (id_schéma) [schéma], typ_desc, datum vytvoření, datum úpravy ze sys.tables kde name='Orderlines'GO
Obr. 11 Vypuštění tabulky Sales.Orderlines
Když hledáme tabulku na sekundárním serveru, zjistíme, že tabulka je stále dostupná v OBOU databázích. Pro CorporateDB tedy máme méně než pět minut na obnovu dat. (obr. 12). Jakmile se však provede další cyklus obnovy, ztratíme tabulku v databázi Corporate DB. Abychom tuto tabulku mohli obnovit, musíme provést obnovu v určitém okamžiku pomocí úplné zálohy v samostatném prostředí a poté extrahovat tuto konkrétní tabulku. Souhlasíte s tím, že to bude nějakou dobu trvat. Pro tabulku BranchDB Orderlines máme trochu více času a můžeme tabulku obnovit pomocí jediného SQL příkazu přes Linked Server (viz Výpis 6).
Obr. 12 Pětiminutové odpočítávání:Tabulka existuje v obou sekundárních databázích
Obr. 13 Dalších 25 minut na obnovení tabulky BranchDB
Výpis 6 – Obnovení tabulky řádků objednávek
USE [master]GO/****** Objekt:LinkedServer [10.2.1.84] Datum skriptu:2. 7. 2018 16:14:59 ******/EXEC master.dbo.sp_addlinkedserver @server =N'10.2.1.84', @srvproduct=N'SQL Server'/* Z bezpečnostních důvodů je heslo pro vzdálené přihlášení propojeného serveru změněno na ######## */EXEC master.dbo.sp_addlinkedsrvlogin@rmtsrvname =N'10.2.1.84',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpasswo rd=NULLGOselect * do BranchDB.Sales.Orderlines z [10.2.1.84].BranchDB.Sales.Or
Obr. 14 Obnovte tabulku BranchDB Sales.Orderlines
Poté ověříme primární server (BranchDB Database), zda je tabulka obnovena.
Obr. 15 Obnovte tabulku BranchDB Sales.Orderlines
Závěr
SQL Server poskytuje řadu způsobů obnovy po ztrátě dat z různých základních příčin – selhání disku, poškození, uživatelská chyba atd. Obnova ze zálohy v určitém okamžiku je pravděpodobně nejznámější z těchto metod. Pro určité jednoduché případy chyby uživatele nebo podobný případ, kdy dojde ke ztrátě jednoho nebo dvou objektů, je vhodné zvážit použití Transaction Log Shipping with Delayed Recovery. Je však třeba poznamenat, že pro nižší RPO je třeba vybrat sekundární databázi, která je nakonfigurována striktně pro potřeby DR.
