Inleiding
Transactielogboekverzending is een zeer bekende technologie die in SQL Server wordt gebruikt om een kopie van de live database op de Disaster Recovery Site bij te houden. De technologie is afhankelijk van drie belangrijke taken:de back-uptaak, de kopieertaak en de hersteltaak. Terwijl de back-uptaak op de primaire server wordt uitgevoerd, worden de kopieer- en hersteltaken op de secundaire server uitgevoerd. In wezen omvat het proces periodieke back-ups van transactielogboeken naar een share van waaruit de kopieertaak naar de secundaire server wordt verplaatst; vervolgens past de hersteltaak de logboekback-ups toe op de secundaire server. Voordat dit allemaal begint, moet de secundaire database worden geïnitialiseerd met een volledige back-up van de primaire server die is hersteld met de NORECOVERY-optie.
Microsoft biedt een reeks opgeslagen procedures die kunnen worden gebruikt om Log Shipping end-to-end te configureren, evenals GUI-equivalenten, te beginnen met het eigenschappenitem van elke database waarvoor u Log Shipping mogelijk wilt configureren. Het is vermeldenswaard dat de secundaire database kan worden geconfigureerd in de NORECOVERY-modus of in de STANDBY-modus. In de NORECOVERY-modus is de database nooit beschikbaar voor query's, maar in de STANDBY-modus kan de secundaire database worden opgevraagd wanneer er geen transactielogboekherstelbewerking aan de gang is.
De omgeving instellen
Om de bal aan het rollen te krijgen, maken we twee SQL Server-instanties op AWS met een identieke Amazon EC2-afbeelding. Deze Amazon EC2-instantie draait SQL Server 2017 RTM-CU5 op Windows Server 2016. Vervolgens herstellen we een kopie van de WideWorldImporters-database met behulp van een back-upset die is verkregen van GitHub naar de eerste instantie, onze primaire instantie. We gebruiken dezelfde back-upset om twee identieke databases te maken met de naam BranchDB en CorporateDB.
Afb. 1 SQL Server-versie
Afb. 2 BranchDB en CorporateDB op primaire instantie (secundaire instantie leeg)
Lijst 1:Herstellen van WideWorldImporters-voorbeelddatabase
filelistonly herstellen van disk='WideWorldImporters-Full.bak'database CorporateDB herstellen van disk='WideWorldImporters-Full.bak' met stats=10,recovery,move 'WWI_Primary' naar 'M:\MSSQL\Data\WWI_Primary. mdf', verplaats 'WWI_UserData' naar 'M:\MSSQL\Data\WWI_UserData.ndf', verplaats 'WWI_Log' naar 'N:\MSSQL\Log\WWI_Log.ldf', verplaats 'WWI_InMemory_Data_1' naar 'M:\MSSQL Data\WWI_InMemory_Data_1.ndf'restore database BranchDB van disk='WideWorldImporters-Full.bak' met stats=10,recovery,move 'WWI_Primary' naar 'M:\MSSQL\Data\WWI_Primary1.mdf', verplaats 'WWI_UserData' M:\MSSQL\Data\WWI_UserData1.ndf', verplaats 'WWI_Log' naar 'N:\MSSQL\Log\WWI_Log1.ldf', verplaats 'WWI_InMemory_Data_1' naar 'M:\MSSQL\Data\WWI_InMemory_Data_11.ndfWe hebben nu twee instanties, de primaire instantie die de twee primaire databases host (BranchDB en CorporateDB en de secundaire instantie zonder gebruikersdatabases. We gaan verder met het configureren van Transactielogboekverzending op beide databases, maar onderscheiden ze door een vertraging toe te passen op de herstelconfiguratie van de eerste database. Bedenk dat de databases eigenlijk identiek zijn wat betreft de gegevens die ze bevatten. De volgende afbeeldingen tonen de belangrijkste opties die zijn geselecteerd in de Logboekverzendingsconfiguratie.
Afb. 3 Back-upinstellingen voor BranchDB
Afb. 4 Kopieer instellingen voor BranchDB
Afb. 5 Herstel instellingen voor BranchDB
Elke Log Shipping-taak is geconfigureerd om elke vijf minuten te worden uitgevoerd. Om "Back-ups uitgesteld terugzetten" te verwerken, moeten we de Standby Recovery-modus gebruiken in de Log Shipping-configuratie. Het is logisch omdat het de secundaire database in de standby-modus heeft en aangeeft dat we de secundaire database kunnen opvragen wanneer een transactielogboekherstel niet aan de gang is. De waarde die we in deze optie specificeren (in dit geval 30 minuten) geeft ons een goed venster waarin we rapporten van de secundaire database kunnen uitvoeren, afgezien van de kernvereiste van dit artikel, namelijk het herstellen van gebruikersfouten.
We moeten ook vermelden dat het herstellen van back-ups van transactielogboeken eigenlijk wordt uitgesteld. De tijdstempel is later dan de vertragingswaarde. Dit betekent dat alle back-ups van transactielogboeken worden gekopieerd naar de secundaire server, die is gebaseerd op het schema en gespecificeerd in de kopieertaak. In feite wordt de hersteltaak nog steeds volgens schema uitgevoerd, maar back-ups van transactielogboeken (die niet maximaal 30 minuten oud zijn) worden niet hersteld. In wezen loopt de BranchDB Standby-database 30 minuten achter op de primaire BranchDB-database. Om deze vertraging aan te tonen, zullen we in de volgende sectie een tabel in beide databases maken en een taak maken die elke minuut een record invoegt. We zullen deze tabel in de secundaire databases onderzoeken.
De instellingen voor de CorporateDB-database zijn hetzelfde als in Fig. 3 tot 5, behalve voor de hersteltaak die NIET is ingesteld om back-ups van transactielogboeken uit te stellen.
Afb. 6 Instellingen herstellen voor CorporateDB
De configuratie verifiëren
Zodra de configuratie is voltooid, kunnen we controleren of de configuratie in orde is en beginnen met het observeren van zijn werk. Het Transactielogboek Shipping Report laat ons zien dat de Branch DB inderdaad achterblijft bij de CorporateDB wat betreft herstel:
Afb. 7a Transactielogboek Verzendrapport op primaire server
Afb. 7b Transactielogboek Verzendrapport op secundaire server
Bovendien ziet u het onderstaande bericht in de Restore Job-geschiedenis voor de BranchDB:
Afb. 8 overgeslagen transactielogboekherstel op secundaire server
We kunnen verder gaan met deze verificatie door een tabel te maken en een taak te gebruiken om deze tabel elke minuut met rijen te vullen. De taak is een eenvoudige manier om te simuleren wat een toepassing zou kunnen doen met een gebruikerstabel. Dit kan ons laten zien dat deze vertraging zeker wordt weergegeven in gebruikersgegevens.
Lijst 2 – Log-trackertabel maken
gebruik BranchDBgocreate tabel log_ship_tracker( ID int identiteit (100,1),Database_Name sysname default db_name(),RecordTime datetime default getdate(),ServerName sysname default @@servername)use CorporateDBgocreate table log_ship_tracker( ID int identiteit (100,1 ),Database_Name sysname default db_name(),RecordTime datetime default getdate(),ServerName sysname default @@servername)Lijst 3 – Taak maken om Log Tracker-tabel te vullen
/* ==Scripting Parameters==Bron Server Versie:SQL Server 2017 (14.0.3023) Bron Database Engine Editie:Microsoft SQL Server Standard Edition Bron Database Engine Type:Standalone SQL ServerDoel Server Versie:SQL Server 2017Target Database Engine Editie:Microsoft SQL Server Standard EditionTarget Database Engine Type:Standalone SQL Server*/USE [msdb]GO/****** Object:Job [InsertRecords] Scriptdatum:2-7-2018 15:32:00 **** **/BEGIN TRANSACTIONDECLARE @ReturnCode INTSELECT @ReturnCode =0/****** Object:JobCategory [[Niet gecategoriseerd (lokaal)]] Scriptdatum:2-7-2018 15:32:00 ****** /IF NOT EXISTS (SELECT name FROM 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 OR @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'Geen beschrijving beschikbaar.',@category_name=N'[Niet gecategoriseerd (lokaal)]', @owner_login_name=N'kairos\kigiri', @job_id =@jobId OUTPUTIF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback/****** Object:Stap [InsertRecords] Scriptdatum: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 BranchDBgoinsert 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 OF @ReturnCode <> 0) GOTO QuitWithRollbackEXEC @ReturnCode =msdb.dbo.sp_update_job @job_id =@jobId, @start_step_id =1 IF (@@ERROR <> 0 OR @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_end_date=99991231,@active_start_end_time,=59 schedule_uid=N'03e5f1b2-2e0b-4b30-8d60-3643c84aa08d' IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollbackEXEC @ReturnCode =msdb.dbo.sp_add_jobserver @job_id =@jobId =', @server (lokaal)'IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollbackCOMMIT TRANSACTIONGOTO EndSaveQuitWithRollback:IF (@@TRANCOUNT> 0) ROLLBACK TRANSACTIONEndSave:GO
Wanneer we respectievelijk de tabel op de primaire databases opvragen, kunnen we bevestigen (met behulp van de RecordTime-kolom) dat de rijen overeenkomen in BranchDB en CorporateDB. Als we de tabel in de secundaire databases op dezelfde manier bekijken, zien we duidelijk dat er een kloof van 30 minuten is tussen BranchDB en CorporateDB.
Lijst 4 – Opvragen van de Log Tracker-tabel
selecteer top 10 @@servername [Current_Server],* van BranchDB.dbo.log_ship_tracker order door RecordTime descselect top 10 @@servername [Current_Server], * from CorporateDB.dbo.log_ship_tracker order by RecordTime desc
Afb. 9 Log Tracker-tabellen komen overeen in primaire databases
Afb. 10 Log Tracker-tabellen hebben een gat van ongeveer 30 minuten in secundaire databases
Herstellen van gebruikersfout
Laten we het nu hebben over het belangrijkste voordeel van deze vertraging. In het scenario waarin een gebruiker per ongeluk een tabel laat vallen, kunnen we de gegevens snel herstellen van de secundaire database zolang de vertragingsperiode niet is verstreken. In dit voorbeeld laten we de tabel Sales.Orderlines op BEIDE databases vallen en controleren we of de tabel niet langer bestaat in BEIDE databases.
Lijst 5 – Tabel met orderregels laten vallen
drop-tabel BranchDB.Sales.Orderlinesdrop-tabel CorporateDB.Sales.OrderlinesGOuse BranchDBgoselect@@servername [Current_Server], db_name() [Database_Name], name, schema_name(schema_id) [schema], type_desc, create_date, modified_datefrom sys.tables waar name='Orderlines'GOuse CorporateDBgoselect@@servername [Current_Server], db_name() [Database_Name], name, schema_name(schema_id) [schema], type_desc, create_date, modified_datefrom sys.tables waar name='Orderlines'GO
Afb. 11 Dropping Table Sales.Orderlines
Wanneer we naar de tabel op de secundaire server zoeken, zien we dat de tabel nog steeds beschikbaar is in BEIDE databases. Voor CorporateDB hebben we dus minder dan vijf minuten om de gegevens te herstellen. (Afb. 12). Maar zodra de volgende herstelcyclus wordt uitgevoerd, verliezen we de tabel in de Corporate DB-database. Om deze tabel te herstellen, moeten we een herstel op een bepaald tijdstip uitvoeren met een volledige back-up in een aparte omgeving en vervolgens deze specifieke tabel uitpakken. U zult het ermee eens zijn dat het enige tijd zal duren. Voor de tabel BranchDB Orderlines hebben we iets meer tijd en kunnen we de tabel herstellen met een enkele SQL-instructie via een gekoppelde server (zie lijst 6).
Afb. 12 Vijf minuten aftellen:tabel bestaat in beide secundaire databases
Afb. 13 Extra 25 minuten om de BranchDB-tabel te herstellen
Lijst 6 – Tabel met orderregels herstellen
GEBRUIK [master]GO/****** Object:LinkedServer [10.2.1.84] Scriptdatum:2-7-2018 16:14:59 ******/EXEC master.dbo.sp_addlinkedserver @server =N'10.2.1.84', @srvproduct=N'SQL Server'/* Om veiligheidsredenen wordt het wachtwoord voor inloggen op afstand van de gekoppelde server gewijzigd met ######## */EXEC master.dbo.sp_addlinkedsrvlogin@rmtsrvname =N'10.2.1.84',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpasswo rd=NULLGOselecteer * in BranchDB.Sales.Orderlines van [10.2.1.84].BranchDB.Sales.Orderlines
Afb. 14 Herstel de tabel BranchDB Sales.Orderlines
Vervolgens verifiëren we de primaire server (BranchDB-database) dat de tabel is hersteld.
Afb. 15 Herstel de tabel BranchDB Sales.Orderlines
Conclusie
SQL Server biedt een aantal manieren om gegevensverlies door verschillende hoofdoorzaken te herstellen - schijfstoringen, corruptie, gebruikersfouten enz. Point-in-time herstel vanaf back-ups is waarschijnlijk de meest bekende van deze methoden. Voor bepaalde eenvoudige gevallen van gebruikersfouten of soortgelijke gevallen, waarbij een of twee objecten verloren gaan, is het gebruik van Transactielogboekverzending met vertraagd herstel een goede benadering om te overwegen. Er moet echter worden opgemerkt dat een secundaire database, die strikt is geconfigureerd voor DR-behoeften, moet worden geselecteerd voor lagere RPO's.
