Implementering af failover i MS SQL Server 2017 Standard

Introduktion

Ofte er vi nødt til at sikre fejltolerance for MS SQL Server DBMS, især når der ikke er nogen Enterprise-udgave, men kun Standard.

Vi vil gerne bemærke, at vi ikke vil undersøge Express-udgaven, fordi der er betydelige begrænsninger for dette tilfælde. Selvfølgelig kan vi omgå nogle af dem. For at løse problemet med databasestørrelsen på 10 GB kan vi for eksempel opdele en stor database i mindre. For at gøre dette kan vi oprette en ny database baseret på en bestemt egenskab og kombinere valgene fra de samme tabeller i forskellige databaser i visningerne i hoveddatabasen. Fejltolerance i Express-udgaven udføres dog enten af ​​en systemadministrator eller ved at bruge din egen eller tredjeparts software.

I denne artikel skal vi udforske alle eksisterende standardfejltoleranceteknologier til MS SQL Server 2017 og et eksempel på implementering af den bedst egnede enhedsstandard for fejltolerance i standardudgaven.

Kort anmeldelse

1. AlwaysOn

   Belastningsfordeling mellem alle parter, alle parter bør være ens i deres egenskaber til hinanden. Den synkrone tilstand sikrer den maksimale pålidelighed af datatransmission; præstationen vil dog være lig med hastigheden for den langsomste fest. Den asynkrone tilstand sikrer den højeste ydeevne, men der kan være uoverensstemmelser i data mellem parterne, hvilket kan forårsage en mere kompleks vedligeholdelse og sandsynligheden for at miste de seneste ændringer i tilfælde af hovedpartsfejl. Hastigheden af ​​at skifte til en synkron tilstand er næsten øjeblikkelig og kræver ikke en systemadministrator og DBA, mens den i den asynkrone tilstand afhænger af den aktuelle tilstand af DB-duplikater og tager normalt omkring 5 minutter (du kan også automatisere omskiftningsprocessen med én DBA uden en systemadministrator ).Microsoft anbefaler at bruge denne teknologi til en database. Den er tilgængelig i Enterprise-udgaven fra og med version 2012 og nyere og med begrænsninger i standardudgaven (For at få mere at vide, se venligst Top 5 spørgsmål om grundlæggende tilgængelighedsgrupper).

2. Klynger

   På trods af konfigurationens enkelhed er denne løsning upålidelig på grund af flaskehalsen i form af et enkelt datavarehus. I tilfælde af datavarehusfejl vil det tage over 1 time at gendanne det. Denne teknologi er tilgængelig i standardudgaven af ​​version 2008 og nyere.

3. Replikering

   Enhver replikering involverer oprettelse af systemtriggere for hver deltagende tabel, mens snapshot-replikering vil belaste hoveddatabasen kraftigt. Snapshot-replikering kan derfor kun udføres uden for myldretiden med databasebelastningen (for eksempel om natten), hvilket er uacceptabelt, fordi en varm standby er nødvendig. Fletreplikering er kompliceret at vedligeholde af nogle systemer (f.eks. CRM, NAV).
   Transaktionel replikering er mulig i Enterprise-udgaven. Tilgængelig i Standard-udgaven (sammenlægning og database-øjebliksbilleder) og Enterprise-udgaven (transaktioner) op til version 2008 og nyere.

4. Spejling

   Det er muligt i enhver tilstand. Den synkrone tilstand sikrer dog den maksimale pålidelighed og hurtige skift, mens den asynkrone tilstand giver brugerne den maksimale ydelseshastighed for hoveddatabasen. Det er dog muligt, at data ikke matcher parterne, og skiftet kan være langsomt.

   Her sørger en vidneserver eller DBA for det automatiske skift på databaseniveau (f.eks. når CPU-belastningen er over 50 % på hovedserveren). En systemadministrator giver forbindelsen til den anden server. En backupdatabase for enhver form for spejling er i en kontinuerlig gendannelsestilstand, så den kan ikke tilgås.

   En gendannelsestilstand for databasen er fuld.

   Microsoft betragter det som en forældet databaseteknologi. Den er tilgængelig i standardudgaven (i den synkrone tilstand) og i Enterprise-udgaven (i den asynkrone tilstand) op til version 2008 og nyere.

5. Transaktionslogforsendelse

   Der er to tilstande:kontinuerlig gendannelse på en standby-server eller gendannelse med forsinkelser. Den første tilstand skifter en backupdatabase til en kontinuerlig gendannelsestilstand, og i dette tilfælde kan vi ikke få adgang til den.

   Den anden tilstand skifter backupdatabasen til en gendannelsestilstand regelmæssigt under implementering af opdateringer (sikkerhedskopidatabasen er tilgængelig mellem implementeringer, men dette er muligt, forudsat at MS SQL Server-instanser er af samme version).

   Sådan fungerer det:

   1. Periodisk gemmes en sikkerhedskopi af databasetransaktionsloggen i en offentlig mappe på kilde- og standbyserveren (mappen og tidsplanen konfigureres som standard hvert 15. minut).
   2. Standby-serveren kopierer med jævne mellemrum transaktionsloggens backup af databasen til en lokal mappe (mappen og tidsplanen konfigureres som standard hvert 15. minut).
   3. Standby-serveren gendanner transaktionsloggen fra backup af transaktionsloggen (tidsplanen konfigureres som standard hvert 15. minut).

   Databaseadministratorer kan automatisere omskiftningsprocessen på databaseniveau, mens en systemadministrator kan gøre dette på niveau med forbindelse til serveren.

   Det skal også bemærkes, at denne metode altid fungerer i asynkron tilstand. Du kan konfigurere flere backup-databaser.

   Databasegendannelsestilstanden er fuld eller bulk-logget.

   Den er tilgængelig i standardudgaven op til version 2008 og nyere.

   Der er to tilstande:kontinuerlig gendannelse på en standby-server eller gendannelse med forsinkelser.

Oversigt

Det mest foretrukne er transaktionslogforsendelse i Standard-udgaven, fordi det er praktisk at bruge det til en glidende overgang fra en server til en anden, for eksempel ved opdatering af miljøet. Derudover er transaktionslogforsendelsen enkel og nem at bruge, ligesom den altid fungerer i den asynkrone tilstand, hvilket ikke belaster databasen meget, i modsætning til den synkrone spejlingstilstand. Under alle omstændigheder er spejling acceptabel, hvis det er muligt at konfigurere sin egen automatiske omskiftning; ellers er falsk skift mulig (f.eks. når CPU'en på hovedserveren er belastet med mere end 50%).

Til Enterprise-udgaven skal du bruge AlwaysOn-teknologien.

Konfiguration af failover ved forsendelse af transaktionslog

Du kan finde mere detaljerede oplysninger om konfiguration af transaktionslogforsendelsen her. Derudover er det muligt at automatisere denne proces ved at udvikle dit eget hjælpeprogram til en gentagen multipel brug, samt til at vende tilbage til hovedserveren, efter at den er blevet repareret i tilfælde af failover.

Lad os undersøge en af ​​de mulige muligheder for fejlretning af failover ved forsendelse af transaktionslog på DBMS-niveau.

Det skal bemærkes, at denne metode er egnet til en server, der kun er reserveret til én forekomst af MS SQL Server-forekomster, da der i flere tilfælde er et problem med at bestemme, hvilke opgaver der skal udføres, og hvilke vi ikke gør.

Lad os beskrive rækkefølgen af ​​trin:

1. Udfør alle opgaver for at kopiere de seneste filer fra kilden (Med en gennemtænkt arkitektur skal biblioteket være tilgængeligt, selvom hovedserveren er nede)
2. Deaktiver alle opgaver for at kopiere filer fra kilden
3. Udfør alle opgaver for at gendanne en database ved hjælp af de nyeste filer fra kilden
4. Deaktiver alle databasegendannelsesopgaver ved hjælp af de seneste filer fra kilden
5. Gør databasen gendannet og principal for logforsendelsen, men uden en modtager
6. Opret fuldstændige sikkerhedskopier af databasen
7. Opret opgaver til at sikkerhedskopiere transaktionslogfiler

Nedenfor er der et eksempel på implementering af ovennævnte sekvens som en lagret procedure.

Det skal bemærkes, at det er vigtigt at konfigurere et login (helst et domæne-login), hvorunder opgaverne udføres for at lave sikkerhedskopier af transaktionslogfiler.

Et eksempel på fejlretning af failover for forsendelse af transaktionsloggen

OPRET PROCEDURE [srv].[RunLogShippingFailover] @isfailover bit=1, @login nvarchar(255)=N'LOGIN', -- et domæne-login, hvorunder opgaverne udføres for at lave sikkerhedskopier af transaktionslogfiler. @backup_directory nvarchar(255)=N'DIRECTORY'—offentlig mappe til at sende sikkerhedskopier af transaktionslogfiler mellem MS SQL Server-instanser (f.eks. 'D:\Shared')AS /* Flytning af standby-serveren til hovedtilstanden, når den primære serveren er nede, hvis @ isfailover =1 er fuldautomatisk, når @isfailover er lig med 0, sker der ikke noget - her skal vi oprette en ny forsendelseslog fra standby til den primære, og så skal vi skifte til hovedserveren og derefter til konfigurer transaktionslogforsendelsen igen. denne standby-server menes at modtage sikkerhedskopier af transaktionslogfiler fra én server */BEGIN --hvis der er et skifte skifte til en standby-server, skal du udføre alle opgaver for at kopiere de seneste filer fra kilden if(@isfailover=1) start vælg [job_id] til #jobs fra [msdb].[dbo].[sysjobs] hvor [navn] som 'LSCopy%'; erklær @job_id entydig identifikator; while(eksisterer(vælg top(1) 1 fra #jobs)) start vælg top(1) @job_id=[job_id] fra #jobs; start prøv EXEC [msdb].dbo.sp_start_job @[email protected]_id; slut prøv start catch end catch slet fra #jobs hvor [job_id][email protected]_id; slut drop tabel #jobs; end --deaktiver alle opgaver til kopiering af filer fra kilden, når du skifter til backupserveren --aktiver alle opgaver for kopiering af filer fra kilden, når du vender tilbage til produktionsserveropdateringen [msdb].[dbo].[sysjobs] set [enabled]=case when (@isfailover=1) then 0 else 1 end where [name] like 'LSCopy%'; --hvis vi skifter til en standby-server, skal vi udføre alle opgaverne for at gendanne databaser ved at bruge de seneste filer fra kilden if(@isfailover=1) start vælg [job_id] til #jobs2 fra [msdb].[dbo ].[sysjobs] hvor [navn] som 'LSRestore%'; while(eksisterer(vælg top(1) 1 fra #jobs2)) start vælg top(1) @job_id=[job_id] fra #jobs2; start prøv EXEC [msdb].dbo.sp_start_job @[email protected]_id; EXEC [msdb].dbo.sp_start_job @[email protected]_id; slut prøv start catch end catch slet fra #jobs2 hvor [job_id][email protected]_id; slut drop tabel #jobs2; end --deaktiver alle opgaverne for at gendanne databaser ved hjælp af de seneste filer fra kilden, når der skiftes til en standby-server --aktiver alle opgaverne for at gendanne databaser ved hjælp af de seneste filer, når du vender tilbage til produktionsserveropdateringen [msdb].[dbo] .[sysjobs] sæt [enabled]=case when (@isfailover=1) then 0 else 1 end where [name] like 'LSRestore%'; --når vi skifter til en standby-server, gør vi databasen gendannbar og principal for logforsendelse uden en modtager, hvis (@isfailover=1) begynder at vælge [secondary_database] som [navn] i #dbs fra msdb.dbo.log_shipping_monitor_secondary hvor [secondary_server ][email protected]@SERVERNAVN; erklære @db nvarchar(255); while(eksisterer(vælg top(1) 1 fra #dbs)) start vælg top(1) @db=[navn] fra #dbs; start prøv GENDAN DATABASE @db MED GENDANNELSE; slut prøv start catch end catch slet fra #dbs hvor [navn][email protected]; slut drop tabel #dbs; vælg [sekundær_database] som [navn] i #dbs2 fra msdb.dbo.log_shipping_monitor_secondary hvor [sekundær_server][email protected]@SERVERNAVN; erklær @jobId BINÆR(16); erklær @kommando nvarchar(max); erklær @dt nvarchar(255)=cast(YEAR(GetDate()) som nvarchar(255)) +'_'+cast(MONTH(GetDate()) som nvarchar(255)) +'_'+cast(DAY( GetDate()) som nvarchar(255)) +'_'+cast(DatePart(time,GetDate()) som nvarchar(255)) +'_'+cast(DatePart(minut,GetDate()) som nvarchar(255) )) +'.trn'; erklær @backup_job_name nvarchar(255); erklær @skemanavn nvarchar(255); erklær @disk nvarchar(255); erklær @uid entydig identifikator; while(eksisterer(vælg top(1) 1 fra #dbs2)) start vælg top(1) @db=[navn] fra #dbs2; sæt @[email protected]_directory+N'\'[email protected]+N'.bak'; sæt @backup_job_name=N'LSBackup_'[email protected]; sæt @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 LOG ['[email protected]+'] TIL DISK =@disk MED NOFORMAT, NOINIT, NAME ='+N''''[email protected]+N''''+N', SKIP, NOREWIND, NOUNLOAD, STATISTIK =10;'; sæt @uid=nyvid(); start prøv BACKUP DATABASE @db TIL DISK =@disk MED NOFORMAT, NOINIT, NAME =@db, SKIP, NOREWIND, NOUNLOAD, STATISTIK =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 tilgængelig.', @category_name=N'[Ukategoriseret (Lokal)]', @[email protected], @job_id =@jobId OUTPUT; 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=1_step_id=0, @fa_id=0, @fa_success_ @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_0=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 prøv start catch end catch slet fra #dbs2 hvor [navn][email protected]; slut drop tabel #dbs2; endEND

For at vende tilbage til hovedserveren er det nødvendigt at konfigurere transaktionslogforsendelsen fra standbyserveren til den primære server og derefter udføre fejlretningen af ​​en failover. Derefter bliver hovedserveren produktionsserveren. Derefter skal du konfigurere transaktionslogforsendelsen fra produktionsserveren til standbyserveren.

Konfiguration af automatisk justering til overvågning af transaktionslogforsendelsen

For at overvåge forsendelsen af ​​transaktionsloggen skal du bruge opgaven LSAlert_ og en rapport på overvågningsserveren. For at gøre dette skal du højreklikke på forekomsten på overvågningsserveren og derefter vælge Rapporter/Standardrapport/Transaktionslogforsendelsesstatus.

Ganske ofte, over tid, tager overvågningsserveren (i tilfælde af, at den ikke er en produktions-) forkert den seneste tid til at oprette en backup af databasetransaktionsloggen på produktionsserveren. Som følge heraf står vi over for falske advarsler.

Det er muligt at løse problemet ved at bruge følgende script:

Et eksempel på konfiguration af justeringen til overvågning af transaktionslogforsendelse

OPRET PROCEDURE [srv].[AutoCorrectMonitorLogShipping] ASBEGIN /* Justering af overvågning af transaktionsloggen forsendelse */ SET NOCOUNT ON; update t2 set t2.[last_backup_date]=t1.[BackupFinishDate] ,t2.[last_backup_date_utc]=DateAdd(time,-DateDiff(time,GetUTCDate(),GetDate()),t1.[BackupFinishDate]) ,t2 ]=RIGHT(t1.[PhysicalDeviceName], CHARINDEX('\',REVERSE(t1.[PhysicalDeviceName]),1)-1) fra [PRODUCTION_INSTANCE_NAME].[SRV].[inf].[vServerLastBackupDB] som t1 indre joinforbindelse [msdb].[dbo].[log_shipping_monitor_primary] som t2 på t1.[DBName] collate SQL_Latin1_General_CP1_CI_AS=t2.[primary_database] collate SQL_Latin1_General_CP1_CI_AS hvor t1.[BackupType'] 

 Vi kan automatisere et opkald til en lagret procedure efter tid. For eksempel kan vi oprette en passende opgave i agenten og planlægge den for hvert 5. minut. Naturligvis skal produktionsserveren være knyttet til backupserveren (Serverobjekter\Linkede servere).
 

 Her bruger vi visningen [inf].[vServerLastBackupDB] i SRV-databasen, der definerer de seneste database-backups:
 

 Et eksempel på implementering af vServerLastBackupDB-visningen: 
 
OPRET VISNING [inf].[vServerLastBackupDB] aswith backup_cte as( vælg bs.[databasenavn], backup_type =case bs.[type] når 'D' derefter 'database' når 'L' derefter 'log' når 'I' ' derefter 'differential' ellers 'other' end, bs.[first_lsn], bs.[sidste_lsn], bs.[backup_start_date], bs.[backup_finish_date], cast(bs.[backup_size] som decimal(18,3)) /1024/1024 som BackupSizeMb, rownum =row_number() over (partition efter bs.[databasenavn], skriv rækkefølge efter bs.[backup_finish_date] desc ), LogicalDeviceName =bmf.[logical_device_name], PhysicalDeviceName =bmf.[physical_device_name] .[server_name], bs.[brugernavn] FRA msdb.dbo.backupset bs INNER JOIN msdb.dbo.backupmediafamily bmf ON [bs].[media_set_id] =[bmf].[media_set_id])vælg [server_name] som [ServerName] , [databasenavn] som [DBnavn], [brugernavn] som [ USerName], [backup_type] som [BackupType], [backup_start_date] som [BackupStartDate], [backup_finish_date] som [BackupFinishDate], [BackupSizeMb], -- ukomprimeret størrelse [LogicalDeviceName], [PhysicalDeviceName], [First_lsnst] [first_lsnst] , [last_lsn] som [LastLSN]fra backup_ctewhere rownum =1;
 
Resultat
 

 I denne artikel har vi kort gennemgået alle mulige fejltolerance- og hurtige tilgængelighedsmuligheder i MS SQL Server 2017, samt eksempler på implementering af fejlfinding af failover og automatisk justering af overvågning af transaktionslogforsendelsen.
 
Referencer:
 
 
msdb
 
Tilgængelige SQL Server 2017-udgaver
 
Altid tændt
 
SQL Server Failover Cluster Installation
 
Replikering
 
Spejling
 
Logforsendelse
 
Konfigurer logforsendelse