Introduktion
Transaktionsloggfrakt är en mycket välkänd teknik som används i SQL Server för att upprätthålla en kopia av den levande databasen på Disaster Recovery Site. Tekniken beror på tre nyckeljobb:säkerhetskopieringsjobbet, kopieringsjobbet och återställningsjobbet. Medan säkerhetskopieringsjobbet körs på den primära servern körs kopierings- och återställningsjobben på den sekundära servern. Processen involverar i huvudsak periodiska säkerhetskopieringar av transaktionsloggar till en resurs från vilken kopieringsjobbet flyttas till den sekundära servern; därefter tillämpar återställningsjobbet loggsäkerhetskopiorna på den sekundära servern. Innan allt detta startar måste den sekundära databasen initieras med en fullständig säkerhetskopia från den primära servern som återställs med alternativet NORECOVERY.
Microsoft tillhandahåller en uppsättning lagrade procedurer som kan användas för att konfigurera loggsändning från början till slut samt GUI-ekvivalenter med början från egenskapsobjektet för varje databas som du kanske vill konfigurera loggsändning för. Det är värt att notera att den sekundära databasen kan konfigureras i NORECOVERY-läge eller i STANDBY-läge. I NORECOVERY-läge är databasen aldrig tillgänglig för frågor, men i STANDBY-läge kan den sekundära databasen frågas när ingen transaktionsloggåterställning pågår.
Konfigurera miljön
För att få bollen i rullning skapar vi två SQL Server-instanser på AWS med en identisk Amazon EC2-bild. Den här Amazon EC2-instansen kör SQL Server 2017 RTM-CU5 på Windows Server 2016. Sedan återställer vi en kopia av WideWorldImporters-databasen med hjälp av en säkerhetskopia som förvärvats från GitHub till den första instansen, vår primära instans. Vi använder samma säkerhetskopieringsuppsättning för att skapa två identiska databaser med namnet BranchDB och CorporateDB.
Fig. 1 SQL Server-version
Fig. 2 BranchDB och CorporateDB på primär instans (sekundär instans tom)
Anteckning 1:Återställer WideWorldImporters exempeldatabas
återställ filelistonly från disk='WideWorldImporters-Full.bak'restore databas CorporateDB från disk='WideWorldImporters-Full.bak' med stats=10,återställning,flytta 'WWI_Primary' till 'M:\MSSQL\Data\WWI_Primary. mdf' , flytta 'WWI_UserData' till 'M:\MSSQL\Data\WWI_UserData.ndf' , flytta 'WWI_Log' till 'N:\MSSQL\Log\WWI_Log.ldf', flytta 'WWI_InMemory_Data_1' till 'M:\MSSQ Data\WWI_InMemory_Data_1.ndf'restore database BranchDB from disk='WideWorldImporters-Full.bak' with stats=10,recovery,move 'WWI_Primary' to 'M:\MSSQL\Data\WWI_Primary1.mdf' , move 'WWI_UserData' M:\MSSQL\Data\WWI_UserData1.ndf' , flytta 'WWI_Log' till 'N:\MSSQL\Log\WWI_Log1.ldf', flytta 'WWI_InMemory_Data_1' till 'M:\MSSQL\Data\WWI_Inpre>1_DataVi har nu två instanser, den primära instansen som är värd för de två primära databaserna (BranchDB och CorporateDB och den sekundära instansen utan användardatabaser. Vi fortsätter med att konfigurera Transaction Log Shipping på båda databaserna men skiljer dem åt genom att tillämpa en fördröjning på återställningskonfigurationen av första databasen. Kom ihåg att databaserna faktiskt är identiska när det gäller data de innehåller. Följande grafik visar de viktigaste alternativen som valts i konfigurationen av logfrakt.
Fig. 3 Säkerhetskopieringsinställningar för BranchDB
Fig. 4 Kopiera inställningar för BranchDB
Fig. 5 Återställ inställningar för BranchDB
Varje loggsändningsjobb är konfigurerat att köras var femte minut. För att bearbeta "Delay Restoring Backups" måste vi använda standby-återställningsläget i Log Shipping-konfigurationen. Det är logiskt eftersom den har den sekundära databasen i standby-läge och indikerar att vi kan fråga efter den sekundära databasen när en transaktionsloggåterställning inte pågår. Värdet vi anger i det här alternativet (30 minuter i det här fallet) ger oss ett bra fönster där vi kan köra rapporter från den sekundära databasen förutom kärnkravet i den här artikeln som är att kunna återställa från användarfel.
Vi bör också nämna att återställningen av säkerhetskopior av transaktionsloggar faktiskt försenas. Dess tidsstämpel är senare än fördröjningsvärdet. Detta innebär att alla säkerhetskopior av transaktionsloggar kommer att kopieras till den sekundära servern, som baseras på schemat och specificeras i kopieringsjobbet. Faktum är att återställningsjobbet fortfarande körs enligt schemat men säkerhetskopior av transaktionsloggar (som inte är upp till 30 minuter gamla) kommer inte att återställas. I huvudsak ligger BranchDB Standby-databasen 30 minuter efter den primära BranchDB-databasen. För att demonstrera denna fördröjning ska vi i nästa avsnitt skapa en tabell i båda databaserna och skapa ett jobb som infogar en post varje minut. Vi kommer att undersöka den här tabellen i de sekundära databaserna.
Inställningarna för CorporateDB-databasen är desamma som i Fig. 3 till 5, förutom återställningsjobbet som INTE är inställt på att fördröja säkerhetskopiering av transaktionsloggar.
Fig. 6 Återställ inställningar för CorporateDB
Verifiera konfigurationen
När konfigurationen är klar kan vi verifiera att konfigurationen är OK och börja med att observera dess arbete. Transaktionsloggförsändningsrapporten visar oss att Branch DB verkligen släpar efter CorporateDB när det gäller återställningar:
Fig. 7a Transaktionsloggfraktrapport på primär server
Fig. 7b Transaktionsloggfraktrapport på sekundär server
Dessutom kommer du att märka meddelandet nedan i Återställ jobbhistorik för BranchDB:
Fig. 8 överhoppad transaktionslogg återställs på sekundär server
Vi kan gå längre med denna verifiering genom att skapa en tabell och använda ett jobb för att fylla den här tabellen med rader varje minut. Jobbet är ett enkelt sätt att simulera vad en applikation kan göra med en användartabell. Detta kan visa oss att denna fördröjning definitivt visas i användardata.
Lista 2 – Skapa loggspårningstabell
använd BranchDBgocreate tabell log_ship_tracker( ID int identitet (100,1),Databas_Name sysname default db_name(),RecordTime datetime default getdate(),ServerName sysname default @@servername)use CorporateDBgocreate table log_ship_tracker(ID int identitet (100,1) ),Databas_Name sysname default db_name(),RecordTime datetime default getdate(),ServerName sysname default @@servername)Lista 3 – Skapa jobb för att fylla i loggspårningstabell
/* ==Skriptparametrar==Källserverversion:SQL Server 2017 (14.0.3023)Source Database Engine Edition:Microsoft SQL Server Standard EditionKälldatabasmotortyp:Fristående SQL ServerTarget Serverversion:SQL Server 2017Target Database Engine Edition:Microsoft SQL Server Standard Edition Target Database Engine Type :Fristående SQL Server*/USE [msdb]GO/******** Objekt:Job [InsertRecords] Skriptdatum:2018-07-02 15:32:00 **** **/BEGIN TRANSACTIONDECLARE @ReturnCode INTSELECT @ReturnCode =0/****** Objekt:JobCategory [[Okategoriserad (Lokal)]] Skriptdatum:2018-07-02 15:32:00 ****** /OM INTE FINNS (VÄLJ namn FRÅN msdb.dbo.syscategories WHERE name=N'[Okategoriserad (Lokal)]' OCH category_class=1)BEGINEXEC @ReturnCode =msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Okategoriserad (Lokal)]'IF (@@ERROR <> 0 OR @ReturnCode <> 0) GÅ TILL QuitWithRollbackENDDECLARE @jobId BINARY(16)EXEC @ReturnCode =msdb.djo.b_add_ 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'Ingen beskrivning tillgänglig.',@category_name=N'[Uncategorized (Local)]', @owner_login_name=N'kairos\kigiri', @job_id =@jobId OUTPUTIF (@@ERROR <> 0 ELLER @ReturnCode <> 0) GOTO QuitWithRollback/****** Objekt:Steg [InsertRecords] Skriptdatum: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',@command=N'use Bra intolog_ship_trackervalues(db_name(),getdate(),@@servername)use CorporateDBgoinsert intolog_ship_trackervalues(db_name(),getdate(),@@servername)GO',@database_name=N'master',@flags=0IF (@@ERROR <> 0 ELLER @ReturnCode <> 0) GÅ TILL QuitWithRollbackEXEC @ReturnCode =msdb.dbo.sp_update_job @job_id =@jobId, @start_step_id =1 OM (@@ERROR <> 0 ELLER @ReturnCode <> 0) GOTO QuitWithRollbackEXEC @ReturnCode =msdb.dbo.sp_add_jobschedule @[email protected], @name=N'Schedule=1, @enable 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_end_date=9990_123_time=9990_1231,=end@active@start5_time,=schema_uid=N'03e5f1b2-2e0b-4b30-8d60-3643c84aa08d' IF (@@ERROR <> 0 ELLER @ReturnCode <> 0) GÅ TILL AvslutaWithRollbackEXEC @ReturnCode =msdb_job_server =msdb.d_job =msdb.d_job =msdb.d_job. (local)'IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollbackCOMMIT TRANSACTIONGOTO EndSaveQuitWithRollback:IF (@@TRANCOUNT> 0) ROLLBACK TRANSACTIONEndSave:GO
När vi frågar tabellen på de primära databaserna respektive kan vi bekräfta (genom att använda kolumnen RecordTime) att raderna matchar i BranchDB och CorporateDB. När vi granskar tabellen i de sekundära databaserna, på samma sätt, ser vi tydligt att vi har ett 30-minutersavstånd mellan BranchDB och CorporateDB.
Lista 4 – Fråga efter loggspårningstabellen
välj topp 10 @@servernamn [Current_Server],* från BranchDB.dbo.log_ship_tracker order by RecordTime descselect top 10 @@servername [Current_Server], * från CorporateDB.dbo.log_ship_tracker order by RecordTime desc
Fig. 9 Log Tracker-tabeller matchar i primära databaser
Fig. 10 loggspårningstabeller har ett gap på ~30 minuter i sekundära databaser
Återställer från användarfel
Låt oss nu prata om den viktigaste fördelen med denna fördröjning. I scenariot, där en användare av misstag tappar en tabell, kan vi snabbt återställa data från den sekundära databasen så länge som fördröjningsperioden inte har förflutit. I det här exemplet släpper vi tabellen Sales.Orderlines på BÅDA databaserna och verifierar att tabellen inte längre finns i BÅDA databaserna.
Lista 5 – Tabell för släppande orderlinjer
släpptabell BranchDB.Sales.Orderlinesdrop-tabell CorporateDB.Sales.OrderlinesGOuse BranchDBgoselect@@servernamn [Current_Server], db_name() [Databas_Name], namn, schema_namn(schema_id) [schema], typ_desc, create_date, modify_dates from where sys.tablesfrom name='Orderlines'GOuse CorporateDBgoselect@@servername [Current_Server], db_name() [Databas_Name], name, schema_name(schema_id) [schema], type_desc, create_date, modify_datefrom sys.tables där name='Orderlines'GO
Fig. 11 Släppbordsförsäljning.Orderlinjer
När vi letar efter tabellen på den sekundära servern finner vi att tabellen fortfarande är tillgänglig i BÅDA databaserna. För CorporateDB har vi alltså mindre än fem minuter på oss att återställa data. (Fig. 12). Men när nästa återställning Cycle körs förlorar vi tabellen i Corporate DB-databasen. För att återställa den här tabellen måste vi göra punkt-i-tidsåterställning med en fullständig säkerhetskopia i en separat miljö och sedan extrahera denna specifika tabell. Du kommer att hålla med om att det kommer att ta lite tid. För tabellen BranchDB Orderlines har vi lite mer tid och vi kan återställa tabellen med en enda SQL-sats över en länkad server (se lista 6).
Fig. 12 Fem minuters nedräkning:Tabell finns i båda sekundära databaserna
Fig. 13 Ytterligare 25 minuter för att återställa BranchDB-tabellen
Lista 6 – Tabell för återställning av orderlinjer
ANVÄND [master]GO/****** Objekt:LinkedServer [10.2.1.84] Skriptdatum:7/2/2018 16:14:59 ******/EXEC master.dbo.sp_addlinkedserver @server =N'10.2.1.84', @srvproduct=N'SQL Server'/* Av säkerhetsskäl ändras lösenordet för den länkade serverns fjärrinloggning med ######## */EXEC master.dbo.sp_addlinkedsrvlogin@rmtsrvname =N'10.2.1.84',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpasswo rd=NULLGOselect * i BranchDB.Sales.Orderlines från [10.2.1.84].BranchDB.Sales.Orderlines
Fig. 14 Återställ tabell för BranchDB Sales.Orderlines
Sedan verifierar vi den primära servern (BranchDB Database) att tabellen är återställd.
Fig. 15 Återställ tabell för BranchDB Sales.Orderlines
Slutsats
SQL Server erbjuder ett antal sätt att återställa från dataförlust från en mängd olika grundorsaker – diskfel, korruption, användarfel etc. Punkt-in-time återställning från säkerhetskopior är förmodligen den mest kända av dessa metoder. För vissa enkla fall av användarfel eller liknande fall, där ett eller två objekt går förlorade, är användningen av transaktionsloggfrakt med fördröjd återställning ett bra sätt att överväga. Det bör dock noteras att en sekundär databas, som är strikt konfigurerad för DR-behov, måste väljas för lägre RPO.
