Implementering av failover i MS SQL Server 2017 Standard

Introduktion

Ofta måste vi säkerställa feltolerans för MS SQL Server DBMS, särskilt när det inte finns någon Enterprise-utgåva, utan bara den Standard.

Vi vill notera att vi inte kommer att granska Express-utgåvan eftersom det finns betydande begränsningar för detta fall. Visst, vi kan kringgå några av dem. Till exempel, för att lösa problemet med databasstorleken på 10 GB, kan vi dela upp en stor databas i mindre. För att göra detta kan vi skapa en ny databas baserad på en viss egenskap och kombinera urvalen från samma tabeller i olika databaser i vyerna i huvuddatabasen. Feltolerans i Express-utgåvan kommer dock att utföras antingen av en systemadministratör eller genom att använda din egen eller tredje parts programvara.

I den här artikeln kommer vi att utforska alla befintliga standardtekniker för feltolerans för MS SQL Server 2017 och ett exempel på implementering av den mest lämpliga enhetliga standarden för feltolerans i standardutgåvan.

Kort recension

1. Alltid på

   Belastningsfördelning mellan alla parter, alla parter bör likna varandra i sina egenskaper. Synkronläget säkerställer maximal tillförlitlighet för dataöverföring; prestandan kommer dock att vara lika med hastigheten för den långsammaste festen. Det asynkrona läget säkerställer högsta prestanda, men det kan finnas data som inte matchar parterna, vilket kan orsaka ett mer komplext underhåll och sannolikheten att förlora de senaste ändringarna i fallet med huvudpartsfelet. Hastigheten för att växla till ett synkront läge är nästan omedelbar och kräver inte en systemadministratör och DBA, medan det i asynkront läge beror på det aktuella tillståndet för DB-duplikat och tar vanligtvis cirka 5 minuter (du kan också automatisera växlingsprocessen med en DBA utan en systemadministratör ).Microsoft rekommenderar att du använder denna teknik för en databas. Den är tillgänglig i Enterprise-utgåvan från och med version 2012 och senare och med begränsningar i standardutgåvan (för mer information, se de fem bästa frågorna om grundläggande tillgänglighetsgrupper).

2. Klustring

   Trots enkelheten i konfigurationen är denna lösning opålitlig på grund av flaskhalsen i form av ett enda datalager. I händelse av datalagerfel kommer det att ta över 1 timme att återställa det. Denna teknik är tillgänglig i standardutgåvan av version 2008 och senare.

3. Replikering

   Varje replikering innebär att man skapar systemutlösare för varje deltagande tabell medan replikering av ögonblicksbilder kommer att belasta huvuddatabasen kraftigt. Därför kan ögonblicksbildreplikering endast göras under lågtrafiktid då databasen laddas (till exempel på natten), vilket är oacceptabelt, eftersom ett varmt standbyläge är nödvändigt. Sammanslagningsreplikering är komplicerat att underhålla av vissa system (till exempel CRM, NAV).
   Transaktionsreplikering är möjlig i Enterprise-utgåvan. Tillgänglig i standardutgåvan (sammanslagnings- och ögonblicksbilder av databaser) och Enterprise-utgåvan (transaktioner) upp till version 2008 och senare.

4. Spegling

   Det är möjligt i alla lägen. Det synkrona läget säkerställer dock maximal tillförlitlighet och snabb växling, medan det asynkrona läget ger användarna maximal prestandahastighet för huvuddatabasen. Det är dock möjligt att data inte matchar parterna och bytet kan gå långsamt.

   Här tillhandahåller en vittnesserver eller DBA den automatiska växlingen på databasnivå (till exempel när CPU-belastningen är över 50 % på huvudservern). En systemadministratör beviljar anslutningen till den andra servern. En säkerhetskopieringsdatabas för alla typer av spegling är i ett kontinuerligt återställningsläge, så den kan inte nås.

   Ett återställningsläge för databasen är fullt.

   Microsoft ser det som en föråldrad databasteknik. Den är tillgänglig i standardutgåvan (i synkront läge) och i Enterprise-utgåvan (i asynkront läge) upp till version 2008 och senare.

5. Transaktionsloggsändning

   Det finns två lägen:kontinuerlig återställning på en standby-server eller återställning med förseningar. Det första läget växlar en backupdatabas till ett kontinuerligt återställningsläge och i det här fallet kan vi inte komma åt den.

   Det andra läget växlar backupdatabasen till ett återställningsläge regelbundet när uppdateringar distribueras (säkerhetskopidatabasen är tillgänglig mellan distributioner, men detta är möjligt förutsatt att MS SQL Server-instanser är av samma version).

   Hur det fungerar:

   1. Med jämna mellanrum lagras en säkerhetskopia av databastransaktionsloggen i en offentlig mapp på käll- och standbyservern (katalogen och schemat konfigureras som standard var 15:e minut).
   2. Vänteservern kopierar med jämna mellanrum transaktionsloggens säkerhetskopia av databasen till en lokal mapp (katalogen och schemat konfigureras som standard var 15:e minut).
   3. Vänteservern återställer transaktionsloggen från backupen av transaktionsloggen (schemat konfigureras var 15:e minut som standard).

   Databasadministratörer kan automatisera växlingsprocessen på databasnivå, medan en systemadministratör kan göra detta på nivån för anslutning till servern.

   Det bör också noteras att denna metod alltid fungerar i asynkront läge. Du kan konfigurera flera backupdatabaser.

   Databasåterställningsläget är fullt eller bulkloggat.

   Den finns tillgänglig i standardutgåvan upp till version 2008 och senare.

   Det finns två lägen:kontinuerlig återställning på en standby-server eller återställning med förseningar.

Sammanfattning

Det mest föredragna är transaktionsloggsändning i standardutgåvan eftersom det är bekvämt att använda den för en smidig övergång från en server till en annan, till exempel vid uppdatering av miljön. Dessutom är transaktionsloggfrakten enkel och lätt att använda, samt fungerar alltid i det asynkrona läget, vilket inte laddar databasen särskilt mycket, till skillnad från synkronspeglingsläget. I alla fall är spegling acceptabel, om det är möjligt att konfigurera sin egen automatiska omkoppling; annars är falsk växling möjlig (till exempel när processorn på huvudservern är laddad med mer än 50%).

För Enterprise-utgåvan, använd AlwaysOn-tekniken.

Konfigurera failover vid leverans av transaktionslogg

Du kan hitta mer detaljerad information om hur du konfigurerar transaktionsloggfrakten här. Dessutom är det möjligt att automatisera denna process genom att utveckla ditt eget verktyg för upprepad multipel användning, samt för att återvända till huvudservern efter att den har reparerats i fallet med failover.

Låt oss utforska ett av de möjliga alternativen för att felsöka failover vid leverans av transaktionsloggar på DBMS-nivå.

Det bör noteras att den här metoden är lämplig för en server som endast är reserverad för en instans av MS SQL Server-instansen, eftersom det för flera instanser finns problem med att avgöra vilka uppgifter som ska utföras och vilka vi inte gör.

Låt oss beskriva sekvensen av steg:

1. Utför alla uppgifter för att kopiera de senaste filerna från källan (Med en genomtänkt arkitektur måste katalogen vara tillgänglig även om huvudservern är nere)
2. Inaktivera alla uppgifter för att kopiera filer från källan
3. Utför alla uppgifter för att återställa en databas med de senaste filerna från källan
4. Inaktivera alla databasåterställningsuppgifter med de senaste filerna från källan
5. Gör databasen återställd och principiell för loggsändningen, men utan en mottagare
6. Skapa fullständiga säkerhetskopior av databasen
7. Skapa uppgifter för att säkerhetskopiera transaktionsloggar

Nedan finns ett exempel på implementering av ovan nämnda sekvens som en lagrad procedur.

Det bör noteras att det är viktigt att konfigurera en inloggning (helst en domäninloggning) under vilken uppgifterna kommer att utföras för att skapa säkerhetskopior av transaktionsloggar.

Ett exempel på felsökning av failover för transaktionsloggens frakt

SKAPA PROCEDUR [srv].[RunLogShippingFailover] @isfailover bit=1, @login nvarchar(255)=N'LOGGA IN', -- en domäninloggning under vilken uppgifterna kommer att utföras för att skapa säkerhetskopior av transaktionsloggar. @backup_directory nvarchar(255)=N'DIRECTORY'—offentlig katalog för att skicka säkerhetskopior av transaktionsloggar mellan MS SQL Server-instanser (till exempel 'D:\Shared')AS /* Flytta standby-servern till huvudläget när huvudfunktionen servern är nere om @ isfailover =1 är helt automatiserad när @isfailover är lika med 0, händer ingenting - här måste vi skapa en ny leveranslogg från standby till huvudservern, och sedan måste vi byta till huvudservern och sedan till konfigurera transaktionsloggens frakt igen. denna standby-server tros ta emot säkerhetskopior av transaktionsloggar från en server */BEGIN --om det finns en växling till en standby-server måste du utföra alla uppgifter för att kopiera de senaste filerna från källan if(@isfailover=1) börja välja [job_id] till #jobs från [msdb].[dbo].[syjobs] där [namn] som 'LSCopy%'; deklarera @job_id unik identifierare; while(exists(select top(1) 1 from #jobs)) begin select top(1) @job_id=[jobb_id] från #jobb; börja prova EXEC [msdb].dbo.sp_start_job @[email protected]_id; slut försök börja fånga slut fånga radera från #jobs där [job_id][email protected]_id; slut släpptabell #jobb; end --inaktivera alla uppgifter för att kopiera filer från källan när du byter till backupservern --aktivera alla uppgifter för att kopiera filer från källan när du återgår till produktionsserveruppdateringen [msdb].[dbo].[sysjobs] set [enabled]=fall när (@isfailover=1) sedan 0 else 1 slut där [namn] som 'LSCopy%'; --om vi byter till en standby-server måste vi utföra alla uppgifter för att återställa databaser genom att använda de senaste filerna från källan if(@isfailover=1) start välj [job_id] till #jobs2 från [msdb].[dbo ].[sysjobs] där [namn] som 'LSRestore%'; while(exists(select top(1) 1 from #jobs2)) begin select top(1) @job_id=[jobb_id] från #jobb2; börja prova EXEC [msdb].dbo.sp_start_job @[email protected]_id; EXEC [msdb].dbo.sp_start_job @[email protected]_id; slut försök börja fånga slut fånga radera från #jobs2 där [job_id][email protected]_id; slut släpptabell #jobs2; end --inaktivera alla uppgifter för att återställa databaser med de senaste filerna från källan när du byter till en standby-server --aktivera alla uppgifter för att återställa databaser med de senaste filerna när du återgår till produktionsserveruppdateringen [msdb].[dbo] .[sysjobs] ställ in [enabled]=fall när (@isfailover=1) sedan 0 else 1 slut där [name] som 'LSRestore%'; --när vi byter till en standby-server gör vi databasen återställbar och principiell för loggsändning utan en mottagare om (@isfailover=1) börjar välj [secondary_database] som [namn] till #dbs från msdb.dbo.log_shipping_monitor_secondary där [secondary_server ][email protected]@SERVERNAME; deklarera @db nvarchar(255); while(exists(välj topp(1) 1 från #dbs)) start välj topp(1) @db=[namn] från #dbs; börja försök ÅTERSTÄLL DATABAS @db MED ÅTERSTÄLLNING; slut försök börja fånga slut fånga radera från #dbs där [namn][email protected]; slutsläpptabell #dbs; välj [secondary_databas] som [namn] till #dbs2 från msdb.dbo.log_shipping_monitor_secondary där [secondary_server][email protected]@SERVERNAME; förklara @jobId BINÄR(16); deklarera @kommando nvarchar(max); deklarera @dt nvarchar(255)=cast(YEAR(GetDate()) som nvarchar(255)) +'_'+cast(MONTH(GetDate()) som nvarchar(255)) +'_'+cast(DAY( GetDate()) som nvarchar(255)) +'_'+cast(DatePart(hour,GetDate()) som nvarchar(255)) +'_'+cast(DatePart(minute,GetDate()) som nvarchar(255) )) +'.trn'; deklarera @backup_job_name nvarchar(255); deklarera @schemanamn nvarchar(255); deklarera @disk nvarchar(255); deklarera @uid unikidentifierare; while(exists(välj topp(1) 1 från #dbs2)) start välj topp(1) @db=[namn] från #dbs2; set @[email protected]_directory+N'\'[email protected]+N'.bak'; set @backup_job_name=N'LSBackup_'[email protected]; set @schedule_name=N'LSBackupSchedule_'[email protected]@SERVERNAME+N'_'[email protected]; set @command=N'declare @disk nvarchar(max)='+N''''[email protected]_directory+N'\'[email protected]+'_'[email protected]+N'''' +N'BACKUP LOGG ['[email protected]+'] TO DISK =@disk MED NOFORMAT, NOINIT, NAME ='+N''''[email protected]+N''''+N', SKIP, NOREWIND, NOUNLOAD, STATS =10;'; set @uid=newid(); börja prova BACKUP DATABAS @db TO DISK =@disk MED NOFORMAT, NOINIT, NAME =@db, SKIP, NOREWIND, NOUNLOAD, STATS =10; EXEC msdb.dbo.sp_add_job @[email protected]_job_name, @enabled=1, @notify_level_eventlog=0, @notify_level_email=0, @notify_level_netsend=0, @notify_level_page=0,=0,@delete_levelion tillgänglig.', @category_name=N'[Okategoriserad (Lokal)]', @[email protected], @job_id =@jobId UTGÅNG; EXEC msdb.dbo.sp_add_jobstep @[email protected], @[email protected]_job_name, @step_id=1, @cmdexec_success_code=0, @on_success_action=1, @on_success_action=n_fa_id=0, @fa_success_action=0, @fa_id=0, @fa_id=0 @retry_attempts=0, @retry_interval=0, @os_run_priority=0, @subsystem=N'TSQL', @[email protected], @database_name=N'master', @flags=0; EXEC msdb.dbo.sp_update_job @job_id =@jobId, @start_step_id =1; EXEC msdb.dbo.sp_add_jobschedule @[email protected], @[email protected]_job_name, @enabled=1, @freq_type=4, @freq_interval=1, @freq_subday_type=4, @freq_subday_interval_rel=5,=@freq_recurrence_factor=0, @active_start_date=20171009, @active_end_date=99991231, @active_start_time=0, @active_end_time=235959, @[email protected]; EXEC msdb.dbo.sp_add_jobserver @job_id =@jobId, @server_name =N'(lokal)'; slut försök börja fånga slut fånga radera från #dbs2 där [namn][email protected]; slutsläpptabell #dbs2; endEND

För att återgå till huvudservern är det nödvändigt att konfigurera transaktionsloggens leverans från standbyservern till huvudservern och sedan utföra felsökningen av en failover. Sedan kommer huvudservern att bli produktionsserver. Efter det måste du konfigurera transaktionsloggens frakt från produktionsservern till standbyservern.

Konfigurera automatisk justering för övervakning av transaktionsloggens leverans

För att övervaka transaktionsloggens leverans, använd uppgiften LSAlert_ och en rapport på övervakningsservern. För att göra detta, högerklicka på instansen på övervakningsservern och välj sedan Rapporter/Standardrapport/Transaktionslogg leveransstatus.

Ganska ofta, med tiden, tar övervakningsservern (om det inte är en produktionsserver) felaktigt den senaste tiden för att skapa en säkerhetskopia av databastransaktionsloggen på produktionsservern. Som ett resultat möter vi falska varningar.

Det är möjligt att lösa problemet med följande skript:

Ett exempel på konfiguration av justeringen för övervakning av transaktionsloggsändning

SKAPA PROCEDUR [srv].[AutoCorrectMonitorLogShipping] ASBEGIN /* Justering av övervakning av transaktionsloggens leverans */ SET NOCOUNT ON; update t2 set t2.[last_backup_date]=t1.[BackupFinishDate] ,t2.[last_backup_date_utc]=DateAdd(timme,-DateDiff(timme,GetUTCDate(),GetDate()),t1.[BackupFinishDate]) ,t2 ]=RIGHT(t1.[PhysicalDeviceName], CHARINDEX('\',REVERSE(t1.[PhysicalDeviceName]),1)-1) från [PRODUCTION_INSTANCE_NAME].[SRV].[inf].[vServerLastBackupDB] som t1 inre koppling [msdb].[dbo].[log_shipping_monitor_primary] som t2 på t1.[DBName] sortera SQL_Latin1_General_CP1_CI_AS=t2.[primary_database] sortera SQL_Latin1_General_CP1_CI_AS där t1.[BackupType'] 

 Vi kan automatisera ett samtal för en lagrad procedur efter tid. Vi kan till exempel skapa en lämplig uppgift i agenten och schemalägga den var 5:e minut. Naturligtvis måste produktionsservern vara länkad till backupservern (Serverobjekt\Länkade servrar).
 

 Här använder vi vyn [inf].[vServerLastBackupDB] i SRV-databasen som definierar de senaste säkerhetskopiorna av databasen:
 

 Ett exempel på implementering av vServerLastBackupDB-vyn: 
 
SKAPA VY [inf].[vServerLastBackupDB] aswith backup_cte as( välj bs.[databasnamn], backup_type =case bs.[typ] när 'D' sedan 'databas' när 'L' sedan 'logg' när 'I ' sedan 'differential' annars 'other' end, bs.[first_lsn], bs.[last_lsn], bs.[backup_start_date], bs.[backup_finish_date], cast(bs.[backup_size] som decimal(18,3)) /1024/1024 som BackupSizeMb, rownum =row_number() över (partition av bs.[databasnamn], skriv ordning efter bs.[backup_finish_date] desc ), LogicalDeviceName =bmf.[logical_device_name], PhysicalDeviceName =bmf.[physical_device] .[server_name], bs.[användarnamn] FRÅN msdb.dbo.backupset bs INNER JOIN msdb.dbo.backupmediafamily bmf PÅ [bs].[media_set_id] =[bmf].[media_set_id]) välj [server_name] som [ServerName] , [databasnamn] som [DBnamn], [användarnamn] som [ USerName], [backup_type] som [BackupType], [backup_start_date] som [BackupStartDate], [backup_finish_date] som [BackupFinishDate], [BackupSizeMb], -- okomprimerad storlek [LogicalDeviceName], [PhysicalDeviceLS], [First_lsnst] [first_lsnst] , [last_lsn] som [LastLSN]från backup_ctewhere rownum =1;
 
Resultat
 

 I den här artikeln har vi kortfattat granskat alla möjliga feltolerans- och snabbtillgänglighetsalternativ i MS SQL Server 2017, samt exempel på implementering av felsökning av failover och automatisk justering av övervakning av transaktionsloggsändningen.
 
Referenser:
 
 
msdb
 
Tillgängliga SQL Server 2017-utgåvor
 
Alltid på
 
SQL Server Failover Cluster Installation
 
Replikering
 
Spegling
 
Loggfrakt
 
Konfigurera loggfrakt