Implementace převzetí služeb při selhání v MS SQL Server 2017 Standard

Úvod

Často potřebujeme zajistit odolnost MS SQL Server DBMS proti chybám, zvláště když neexistuje edice Enterprise, ale pouze standardní.

Rádi bychom poznamenali, že nebudeme zkoumat edici Express, protože pro tuto instanci existují významná omezení. Jistě, některé z nich můžeme obejít. Například pro vyřešení problému s velikostí databáze 10 GB můžeme rozdělit velkou databázi na menší. K tomu můžeme vytvořit novou databázi založenou na určité vlastnosti a kombinovat výběry ze stejných tabulek různých databází v pohledech v hlavní databázi. Odolnost vůči chybám v edici Express však bude provedena buď správcem systému, nebo pomocí vašeho vlastního softwaru nebo softwaru třetích stran.

V tomto článku prozkoumáme všechny stávající standardní technologie odolnosti proti chybám pro MS SQL Server 2017 a příklad implementace nejvhodnějšího jednotného standardu odolnosti proti chybám v edici Standard.

Krátká recenze

1. Vždy zapnuto

   Rozložení zátěže mezi všechny strany, všechny strany by si měly být navzájem podobné svými charakteristikami. Synchronní režim zajišťuje maximální spolehlivost přenosu dat; výkon se však bude rovnat rychlosti nejpomalejší strany. Asynchronní režim zajišťuje nejvyšší výkon, ale mezi stranami může docházet k nesouladu dat, což může způsobit složitější údržbu a pravděpodobnost ztráty posledních změn v případě selhání hlavní strany. Rychlost přechodu do synchronního režimu je téměř okamžitá a nevyžaduje systémového administrátora a DBA, zatímco v asynchronním režimu záleží na aktuálním stavu DB-duplikátů a obvykle trvá cca 5 minut (proces přepínání lze automatizovat i jedním DBA bez administrátora systému ).Microsoft doporučuje používat tuto technologii pro databázi. Je k dispozici ve verzi Enterprise počínaje verzí 2012 a vyšší as omezeními ve verzi Standard (Další informace naleznete v části 5 nejčastějších otázek o skupinách základní dostupnosti).

2. Shlukování

   I přes jednoduchost konfigurace je toto řešení nespolehlivé kvůli úzkému hrdlu v podobě jednoho datového skladu. V případě selhání datového skladu bude jeho obnova trvat déle než 1 hodinu. Tato technologie je dostupná ve standardní edici verze 2008 a vyšší.

3. Replikace

   Jakákoli replikace zahrnuje vytvoření systémových spouštěčů pro každou zúčastněnou tabulku, zatímco replikace snímků silně zatíží hlavní databázi. Proto lze replikaci snímků provádět pouze v době mimo špičku zatížení databáze (například v noci), což je nepřijatelné, protože je nutný pohotovostní režim. U některých systémů je údržba slučovací replikace komplikovaná (například CRM, NAV).
   V edici Enterprise je možná transakční replikace. K dispozici v edici Standard (slučování a databázové snímky) a edici Enterprise (transakce) až do verze 2008 a vyšší.

4. Zrcadlení

   Je to možné v jakémkoli režimu. Synchronní režim však zajišťuje maximální spolehlivost a rychlé přepínání, zatímco asynchronní režim poskytuje uživatelům maximální rychlost výkonu hlavní databáze. Mezi účastníky však může dojít k nesouladu dat a přepínání může být pomalé.

   Zde svědecký server nebo DBA poskytuje automatické přepínání na úrovni databáze (například když je zatížení CPU na hlavním serveru vyšší než 50 %). Správce systému udělí připojení k druhému serveru. Záložní databáze pro jakýkoli typ zrcadlení je v režimu nepřetržitého obnovení, takže k ní nelze přistupovat.

   Režim obnovy databáze je plný.

   Microsoft to považuje za zastaralou databázovou technologii. Je k dispozici v edici Standard (v synchronním režimu) a v edici Enterprise (v asynchronním režimu) až do verze 2008 a vyšší.

5. Doprava protokolu transakce

   Existují dva režimy:nepřetržité obnovení na pohotovostním serveru nebo obnovení se zpožděním. První režim přepne záložní databázi do režimu nepřetržité obnovy a v tomto případě k ní nemáme přístup.

   Druhý režim pravidelně přepíná záložní databázi do režimu obnovy během nasazování aktualizací (záložní databáze je k dispozici mezi jednotlivými nasazeními, ale je to možné za předpokladu, že instance MS SQL Server jsou stejné verze).

   Jak to funguje:

   1. Pravidelně se do veřejné složky na zdrojovém a pohotovostním serveru ukládá záložní kopie databázového transakčního protokolu (ve výchozím nastavení se adresář a plán konfigurují každých 15 minut).
   2. Pohotovostní server pravidelně kopíruje zálohu protokolu transakcí databáze do místní složky (adresář a plán se ve výchozím nastavení konfigurují každých 15 minut).
   3. Pohotovostní server obnoví protokol transakcí ze zálohy protokolu transakcí (plán je ve výchozím nastavení konfigurován každých 15 minut).

   Správci databáze mohou automatizovat proces přepínání na úrovni databáze, zatímco správce systému to může udělat na úrovni připojení k serveru.

   Také je třeba poznamenat, že tato metoda vždy funguje v asynchronním režimu. Můžete nakonfigurovat více záložních databází.

   Režim obnovy databáze je plný nebo je protokolován hromadně.

   Je k dispozici v edici Standard až do verze 2008 a vyšší.

   Existují dva režimy:nepřetržité obnovení na pohotovostním serveru nebo obnovení se zpožděním.

Shrnutí

Nejvýhodnější je odesílání protokolu transakcí ve edici Standard, protože je vhodné jej používat pro hladký přechod z jednoho serveru na druhý, například při aktualizaci prostředí. Expedice protokolu transakcí je navíc jednoduchá a snadno použitelná, stejně jako vždy funguje v asynchronním režimu, který na rozdíl od režimu synchronního zrcadlení příliš nezatěžuje databázi. V každém případě je zrcadlení přijatelné, pokud je možné nakonfigurovat vlastní automatické přepínání; jinak je možné falešné přepínání (například když je CPU hlavního serveru zatíženo z více než 50 %).

Pro edici Enterprise použijte technologii AlwaysOn.

Konfigurace převzetí služeb při selhání při odeslání protokolu transakce

Podrobnější informace o konfiguraci dopravy protokolu transakcí naleznete zde. Kromě toho je možné tento proces automatizovat vývojem vlastního nástroje pro opakované vícenásobné použití, stejně jako pro návrat na hlavní server poté, co byl opraven v případě selhání.

Pojďme prozkoumat jednu z možných možností pro ladění převzetí služeb při selhání při odeslání protokolu transakcí na úrovni DBMS.

Je třeba poznamenat, že tato metoda je vhodná pro server vyhrazený pouze pro jednu instanci instance MS SQL Server, protože u několika instancí nastává problém s určením, které úlohy provést a které ne.

Pojďme si popsat sekvenci kroků:

1. Proveďte všechny úkoly pro zkopírování nejnovějších souborů ze zdroje (s dobře promyšlenou architekturou musí být adresář přístupný, i když je hlavní server mimo provoz)
2. Zakažte všechny úlohy kopírování souborů ze zdroje
3. Proveďte všechny úkoly k obnovení databáze pomocí nejnovějších souborů ze zdroje
4. Zakažte všechny úlohy obnovení databáze pomocí nejnovějších souborů ze zdroje
5. Proveďte obnovení databáze a příkazce pro odeslání protokolu, ale bez příjemce
6. Vytvářejte úplné zálohy databáze
7. Vytvářejte úlohy pro zálohování protokolů transakcí

Níže je uveden příklad implementace výše uvedené sekvence jako uložené procedury.

Je třeba poznamenat, že je důležité nakonfigurovat přihlašovací jméno (nejlépe doménové), pod kterým budou prováděny úlohy pro vytváření záloh transakčních protokolů.

Příklad ladění převzetí služeb při selhání odeslání protokolu transakcí

VYTVOŘENÍ PROCEDURY [srv].[RunLogShippingFailover] @isfailover bit=1, @login nvarchar(255)=N'LOGIN', -- přihlášení k doméně, pod kterým se budou spouštět úlohy pro vytváření záloh transakčních protokolů. @backup_directory nvarchar(255)=N'DIRECTORY'—veřejný adresář pro odesílání záloh transakčních protokolů mezi instancemi MS SQL Server (například 'D:\Shared')AS /* Přesunutí pohotovostního serveru do hlavního režimu, když je hlavní server je mimo provoz, pokud @ isfailover =1 je plně automatizovaný, když se @isfailover rovná 0, nic se neděje – zde musíme znovu vytvořit protokol přepravy z pohotovostního režimu na hlavní server a potom se musíme přepnout na hlavní server a poté na znovu nakonfigurujte odeslání protokolu transakcí. předpokládá se, že tento pohotovostní server přijímá zálohy transakčních protokolů z jednoho serveru */BEGIN -- pokud je přepínač shift na pohotovostní server, musíte provést všechny úkoly, abyste zkopírovali nejnovější soubory ze zdroje if(@isfailover=1) začněte vybrat [job_id] do #jobs z [msdb].[dbo].[sysjobs], kde [název] jako 'LSCopy%'; deklarovat jedinečný identifikátor @job_id; while(exists(select top(1) 1 from #jobs)) begin select top(1) @job_id=[job_id] from #jobs; začít zkuste EXEC [msdb].dbo.sp_start_job @[email protected]_id; end try begin catch end catch delete from #jobs where [job_id][email protected]_id; end drop table #jobs; end --zakáže všechny úlohy pro kopírování souborů ze zdroje při přepnutí na záložní server --povolí všechny úlohy pro kopírování souborů ze zdroje při návratu na produkční server aktualizace [msdb].[dbo][sysjobs] set [povoleno]=případ, když (@isfailover=1) then 0 jinak 1 konec kde [jméno] jako 'LSCopy%'; --pokud přejdeme na záložní server, musíme provést všechny úkoly k obnovení databází pomocí nejnovějších souborů ze zdroje if(@isfailover=1) začít vybrat [job_id] do #jobs2 z [msdb].[dbo ].[sysjobs] kde [jméno] jako 'LSRestore%'; while(exists(select top(1) 1 from #jobs2)) begin select top(1) @job_id=[job_id] from #jobs2; začít zkuste EXEC [msdb].dbo.sp_start_job @[email protected]_id; EXEC [msdb].dbo.sp_start_job @[email protected]_id; end try begin catch end catch delete from #jobs2 where [job_id][email protected]_id; end drop table #jobs2; end --zakáže všechny úlohy pro obnovu databází pomocí nejnovějších souborů ze zdroje při přepnutí na záložní server --povolí všechny úlohy pro obnovu databází pomocí nejnovějších souborů při návratu k aktualizaci produkčního serveru [msdb].[dbo] .[sysjobs] set [enabled]=case when (@isfailover=1) then 0 else 1 end where [name] like 'LSRestore%'; --při přepnutí na pohotovostní server zajistíme obnovení databáze a zajistíme, aby byla databáze obnovitelná a hlavní pro odeslání protokolu bez příjemce if(@isfailover=1) begin vyberte [sekundární_databáze] jako [jméno] do #dbs z msdb.dbo.log_shipping_monitor_secondary kde [sekundární_server ][email protected]@SERVERNAME; deklarovat @db nvarchar(255); while(exists(select top(1) 1 from #dbs)) begin select top(1) @db=[name] from #dbs; začít zkusit OBNOVIT DATABÁZI @db S OBNOVOU; end try begin catch end catch delete from #dbs where [name][email protected]; end drop table #dbs; vyberte [sekundární_databáze] jako [jméno] do #dbs2 z msdb.dbo.log_shipping_monitor_secondary kde [sekundární_server][email protected]@NÁZEV SERVERU; deklarovat @jobId BINARY(16); deklarovat @příkaz nvarchar(max); deklarovat @dt nvarchar(255)=cast(YEAR(GetDate()) jako nvarchar(255)) +'_'+cast(MONTH(GetDate()) jako nvarchar(255)) +'_'+cast(DAY( GetDate()) jako nvarchar(255)) +'_'+cast(DatePart(hodina,GetDate()) jako nvarchar(255)) +'_'+cast(DatePart(minute,GetDate()) jako nvarchar(255 )) +'.trn'; deklarovat @backup_job_name nvarchar(255); deklarovat @jméno_plánu nvarchar(255); deklarovat @disk nvarchar(255); deklarovat @uid jedinečný identifikátor; while(exists(select top(1) 1 from #dbs2)) begin select top(1) @db=[name] from #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 LOG ['[email protected]+'] NA DISK =@disk S NOFORMATEM, NOINIT, JMÉNO ='+N''''[email protected]+N''''+N', PŘESKOČIT, NOREWIND, NOUNLOAD, STATS =10;'; set @uid=newid(); začít zkusit ZÁLOHU DATABÁZE @db NA DISK =@disk S NOFORMATEM, 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, @delete_level=0, @description=N', @description=dostupný.', @category_name=N'[Uncategorized (Local)]', @[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_step_id=0, @on_success_step_id_il_action, @id=0_fa @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_interval=5, rel_interval_subday_interval @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, @název_serveru =N'(místní)'; end try begin catch end catch delete from #dbs2 where [name][email protected]; end drop table #dbs2; endEND

Chcete-li se vrátit na hlavní server, je nutné nakonfigurovat odeslání protokolu transakcí z pohotovostního serveru na hlavní server a poté provést ladění převzetí služeb při selhání. Poté se hlavní server stane produkčním serverem. Poté musíte nakonfigurovat odesílání protokolu transakcí z produkčního serveru na záložní.

Konfigurace automatické úpravy pro sledování dopravy protokolu transakcí

Chcete-li sledovat odeslání protokolu transakcí, použijte úlohu LSAlert_ a sestavu na monitorovacím serveru. Chcete-li to provést, klikněte pravým tlačítkem na instanci na monitorovacím serveru a poté vyberte možnost Zprávy/Standardní zpráva/ Stav dopravy protokolu transakcí.

Poměrně často časem monitorovací server (v případě, že se nejedná o produkční) nesprávně zabere poslední čas vytvoření zálohy databázového transakčního protokolu na produkčním serveru. V důsledku toho čelíme falešným varováním.

Problém je možné vyřešit pomocí následujícího skriptu:

Příklad konfigurace úpravy pro sledování dopravy protokolu transakcí

CREATE PROCEDURE [srv].[AutoCorrectMonitorLogShipping] ASBEGIN /* Úprava sledování dopravy protokolu transakcí */ SET NOCOUNT ON; update t2 set t2.[last_backup_date]=t1.[BackupFinishDate] ,t2.[last_backup_date_utc]=DateAdd(hodina,-DateDiff(hodina,GetUTCDate(),GetDate()),t1.[BackupFinishDate]) _backup_file[last] ]=RIGHT(t1.[PhysicalDeviceName], CHARINDEX('\',REVERSE(t1.[PhysicalDeviceName]),1)-1) z [PRODUCTION_INSTANCE_NAME].[SRV].[inf].[vServerLastBackupDB] jako vnitřní spojení t1 [msdb].[dbo].[log_shipping_monitor_primary] jako t2 na t1.[DBName] porovnat SQL_Latin1_General_CP1_CI_AS=t2.[primary_database] porovnat SQL_Latin1_General_CP1_CI_AS kde t1.[BackupType]=N'prelog'; 

 Volání uložené procedury můžeme automatizovat podle času. Můžeme například vytvořit vhodnou úlohu v Agentovi a naplánovat ji na každých 5 minut. Produkční server musí být samozřejmě propojen se záložním serverem (Serverové objekty\Propojené servery).
 

 Zde používáme pohled [inf].[vServerLastBackupDB] v databázi SRV, který definuje nejnovější zálohy databáze:
 

 Příklad implementace zobrazení vServerLastBackupDB: 
 
VYTVOŘIT ZOBRAZENÍ [inf].[vServerLastBackupDB] aswith backup_cte as( vyberte bs.[název_databáze], typ_zálohy =případ bs.[typ] když 'D', pak 'databáze' když 'L', pak 'log' když 'I ' potom 'rozdíl' jinak 'jiný' konec, bs.[první_lsn], bs.[poslední_lsn], bs.[datum_startu_zalohy], bs.[datum_konecni_zalohy], cast(bs.[velikost_zalohy] jako decimal(18,3)) /1024/1024 jako BackupSizeMb, rownum =row_number() over (oddíl podle bs.[název_databáze], pořadí typů podle bs.[datum_dokončení_zálohy] desc ), název logického zařízení =bmf.[název_logického_zařízení], název fyzického zařízení =bmf.[název_fyzického_zařízení], b .[název_serveru], bs.[uživatelské_jméno] OD msdb.dbo.backupset bs VNITŘNÍ PŘIPOJENÍ k msdb.dbo.backupmediafamily bmf ON [bs].[media_set_id] =[bmf].[media_set_id])vyberte [název_serveru] jako [Název_serveru] , [název_databáze] jako [název_DB], [uživatelské_jméno] jako [ USerName], [backup_type] jako [BackupType], [backup_start_date] jako [BackupStartDate], [backup_finish_date] jako [BackupFinishDate], [BackupSizeMb], -- nekomprimovaná velikost [LogicalDeviceName], [Physical], [LSNfirstName] jako [Physical], [LSNfirstName] , [last_lsn] jako [LastLSN]z backup_ctewhere rownum =1;
 
Výsledek
 

 V tomto článku jsme stručně zkontrolovali všechny možné možnosti odolnosti proti chybám a rychlé dostupnosti v MS SQL Server 2017 a také příklady implementace ladění převzetí služeb při selhání a automatické úpravy sledování odesílání protokolu transakcí.
 
Odkazy:
 
 
msdb
 
Dostupné edice SQL Server 2017
 
Vždy zapnuto
 
Instalace SQL Server Failover Cluster
 
Replikace
 
Zrcadlení
 
Zapsat zásilku
 
Konfigurovat odesílání protokolu