Внедряване на отказ в MS SQL Server 2017 Standard

Въведение

Често се налага да осигурим отказоустойчивост на СУБД на MS SQL Server, особено когато няма Enterprise издание, а само стандартното.

Бихме искали да отбележим, че няма да разглеждаме изданието Express, тъй като има значителни ограничения за този екземпляр. Разбира се, можем да заобиколим някои от тях. Например, за да разрешим проблема с размера на базата данни от 10 GB, можем да разделим голяма база данни на по-малки. За да направим това, можем да създадем нова база данни въз основа на определено свойство и да комбинираме селекциите от едни и същи таблици на различни бази данни в изгледите в основната база данни. Въпреки това толерантността на грешки в изданието Express ще се извършва или от системен администратор, или чрез използване на собствен софтуер или софтуер на трета страна.

В тази статия ще разгледаме всички съществуващи стандартни технологии за отказоустойчивост за MS SQL Server 2017 и пример за внедряване на най-подходящия унифициран стандарт за отказоустойчивост в стандартното издание.

Кратък преглед

1. Винаги включен

   Разпределението на натоварването между всички страни, всички страни трябва да са сходни по своите характеристики една с друга. Синхронният режим осигурява максимална надеждност на предаването на данни; обаче производителността ще бъде равна на скоростта на най-бавната партия. Асинхронният режим осигурява най-висока производителност, но може да има несъответстващи данни между страните, което може да доведе до по-сложна поддръжка и вероятност от загуба на последните промени в случай на повреда на основната страна. Скоростта на превключване в синхронен режим е почти мигновено и не изисква системен администратор и DBA, докато в асинхронен режим зависи от текущото състояние на DB-дубликатите и обикновено отнема около 5 минути (можете също така да автоматизирате процеса на превключване от един DBA без системен администратор ).Microsoft препоръчва използването на тази технология за база данни. Предлага се в изданието Enterprise, започващо от версия 2012 и по-нова и с ограничения в стандартното издание (За да научите повече, моля, вижте 5-те най-важни въпроса относно основните групи за наличност).

2. Групиране

   Въпреки простотата на конфигурацията, това решение е ненадеждно поради тесното място под формата на единно хранилище за данни. В случай на повреда на хранилището за данни, възстановяването му ще отнеме повече от 1 час. Тази технология е налична в стандартното издание на версия 2008 и по-нова.

3. Репликация

   Всяка репликация включва създаване на системни тригери за всяка участваща таблица, докато репликацията на моментна снимка ще натовари силно основната база данни. Следователно репликацията на моментна снимка може да се извършва само в непиковите часове на натоварване на базата данни (например през нощта), което е неприемливо, тъй като е необходим горещ режим на готовност. Репликацията при сливане е сложна за поддържане от някои системи (например CRM, NAV).
   Транзакционната репликация е възможна в изданието Enterprise. Предлага се в стандартното издание (сливане и моментни снимки на база данни) и изданието Enterprise (транзакции) до версия 2008 и по-нова.

4. Отразяване

   Възможно е във всеки режим. Въпреки това, синхронният режим осигурява максимална надеждност и бързо превключване, докато асинхронният режим осигурява на потребителите максимална скорост на производителност на основната база данни. Въпреки това е възможно несъответствие на данни между страните и превключването може да е бавно.

   Тук сървърът-свидетел или DBA осигурява автоматичното превключване на ниво база данни (например, когато натоварването на процесора е над 50% на главния сървър). Системен администратор предоставя връзката с другия сървър. Резервната база данни за всякакъв тип огледално отразяване е в режим на непрекъснато възстановяване, така че не може да бъде достъпна.

   Режимът за възстановяване на базата данни е пълен.

   Microsoft го смята за остаряла технология за бази данни. Предлага се в стандартното издание (в синхронен режим) и в изданието Enterprise (в асинхронен режим) до версия 2008 и по-нова.

5. Изпращане на дневника на транзакциите

   Има два режима:непрекъснато възстановяване на сървър в режим на готовност или възстановяване със закъснения. Първият режим превключва резервната база данни в режим на непрекъснато възстановяване и в този случай нямаме достъп до нея.

   Вторият режим превключва редовно архивната база данни в режим на възстановяване, докато внедрява актуализации (базата за архивиране е налична между внедряванията, но това е възможно при условие, че екземплярите на MS SQL Server са с една и съща версия).

   Как работи:

   1. Периодично резервно копие на дневника на транзакциите на базата данни се съхранява в публична папка на изходния и резервния сървър (директорията и графикът се конфигурират на всеки 15 минути по подразбиране).
   2. Сървърът в режим на готовност периодично копира архива на регистрационния файл на транзакциите на базата данни в локална папка (директорията и графикът се конфигурират на всеки 15 минути по подразбиране).
   3. Сървърът в режим на готовност възстановява дневника на транзакциите от резервното копие на дневника на транзакциите (графикът се конфигурира на всеки 15 минути по подразбиране).

   Администраторите на бази данни могат да автоматизират процеса на превключване на ниво база данни, докато системният администратор може да направи това на нивото на свързване със сървъра.

   Също така трябва да се отбележи, че този метод винаги работи в асинхронен режим. Можете да конфигурирате множество резервни бази данни.

   Режимът за възстановяване на базата данни е пълен или групово регистриран.

   Предлага се в стандартното издание до версия 2008 и по-нова.

   Има два режима:непрекъснато възстановяване на сървър в режим на готовност или възстановяване със закъснения.

Резюме

Най-предпочитаната е доставката на регистрационни файлове на транзакции в стандартното издание, защото е удобно да се използва за плавен преход от един сървър към друг, например при актуализиране на средата. Освен това доставката на дневника на транзакциите е проста и лесна за използване, както и винаги работи в асинхронен режим, който не натоварва много базата данни, за разлика от режима на синхронно огледално отразяване. Във всеки случай, огледалното отразяване е приемливо, ако е възможно да се конфигурира собствено автоматично превключване; в противен случай е възможно фалшиво превключване (например, когато процесорът на главния сървър е натоварен с повече от 50%).

За изданието Enterprise използвайте технологията AlwaysOn.

Конфигуриране на отказ при изпращане на регистъра на транзакциите

Можете да намерите по-подробна информация за конфигурирането на доставката на дневника на транзакциите тук. Освен това е възможно да се автоматизира този процес, като се разработи своя собствена помощна програма за повтаряща се многократна употреба, както и за връщане към основния сървър, след като е поправен в случай на отказ.

Нека разгледаме една от възможните опции за отстраняване на грешки при отказ при доставка на регистрационни файлове на транзакции на ниво СУБД.

Трябва да се отбележи, че този метод е подходящ за сървър, запазен само за един екземпляр на MS SQL Server, тъй като за няколко случая има проблем при определянето кои задачи да изпълняваме и кои не.

Нека опишем последователността от стъпки:

1. Изпълнете всички задачи, за да копирате най-новите файлове от източника (С добре обмислена архитектура директорията трябва да бъде достъпна, дори ако основният сървър не работи)
2. Деактивирайте всички задачи за копиране на файлове от източника
3. Изпълнете всички задачи за възстановяване на база данни, като използвате най-новите файлове от източника
4. Деактивирайте всички задачи за възстановяване на базата данни, като използвате най-новите файлове от източника
5. Направете базата данни възстановена и основна за доставката на регистрационните файлове, но без получател
6. Създайте пълни резервни копия на базата данни
7. Създайте задачи за архивиране на регистрационни файлове на транзакциите

По-долу има пример за прилагане на гореспоменатата последователност като съхранена процедура.

Трябва да се отбележи, че е важно да конфигурирате потребителско име (за предпочитане вход в домейн), под което ще се изпълняват задачите за създаване на резервни копия на регистрационните файлове на транзакциите.

Пример за отстраняване на грешки при отказ при доставката на регистрационния файл на транзакциите

СЪЗДАВАНЕ НА ПРОЦЕДУРА [srv].[RunLogShippingFailover] @isfailover bit=1, @login nvarchar(255)=N'LOGIN', -- вход в домейн, под който ще се изпълняват задачите, изпълнявани за създаване на резервни копия на регистрационни файлове на транзакции. @backup_directory nvarchar(255)=N'DIRECTORY'—публична директория за изпращане на резервни копия на регистрационни файлове на транзакции между екземпляри на MS SQL Server (например, 'D:\Shared')AS /* Преместване на сървъра в режим на готовност в основния режим, когато принципалът сървърът не работи, ако @ isfailover =1 е напълно автоматизиран, когато @isfailover е равно на 0, нищо не се случва - тук трябва да създадем наново дневника за доставка от режим на готовност към основния и след това трябва да преминем към основния сървър и след това към конфигурирайте отново доставката на дневника на транзакциите. Смята се, че този сървър в режим на готовност получава резервни копия на регистрационни файлове на транзакциите от един сървър */BEGIN -- ако има превключване към резервен сървър, трябва да изпълните всички задачи, за да копирате най-новите файлове от източника if(@isfailover=1) започнете да изберете [job_id] в #jobs от [msdb].[dbo].[sysjobs], където [име] като 'LSCopy%'; декларира @job_id уникален идентификатор; while(exists(select top(1) 1 from #jobs)) start select top(1) @job_id=[job_id] от #jobs; започнете да опитате EXEC [msdb].dbo.sp_start_job @[email protected]_id; край опит начало хващане край хващане изтриване от #jobs където [job_id][email protected]_id; end drop table #jobs; край --забранете всички задачи за копиране на файлове от източника при превключване към резервния сървър --активирайте всички задачи за копиране на файлове от източника при връщане към актуализацията на производствения сървър [msdb].[dbo].[sysjobs] set. [enabled]=case when (@isfailover=1) then 0 else 1 end where [name] like 'LSCopy%'; --ако преминем към сървър в режим на готовност, трябва да изпълним всички задачи за възстановяване на бази данни, като използваме най-новите файлове от източника if(@isfailover=1) започне избор на [job_id] в #jobs2 от [msdb].[dbo] ].[sysjobs] където [име] като 'LSRestore%'; while(exists(select top(1) 1 from #jobs2)) start select top(1) @job_id=[job_id] от #jobs2; започнете да опитате EXEC [msdb].dbo.sp_start_job @[email protected]_id; EXEC [msdb].dbo.sp_start_job @[email protected]_id; край опит начало хващане край хващане изтриване от #jobs2 където [job_id][email protected]_id; крайна таблица за изтриване #jobs2; край -- деактивиране на всички задачи за възстановяване на бази данни с помощта на най-новите файлове от източника при превключване към сървър в режим на готовност -- разрешаване на всички задачи за възстановяване на бази данни с помощта на най-новите файлове при връщане към актуализацията на производствения сървър [msdb].[dbo] .[sysjobs] set [enabled]=case when (@isfailover=1) then 0 else 1 end where [name] като 'LSRestore%'; --при превключване към сървър в режим на готовност, ние правим базата данни възстановяема и принципна за доставка на регистрационни файлове без получател if(@isfailover=1) започне да изберете [secondary_database] като [име] в #dbs от msdb.dbo.log_shipping_monitor_secondary, където [secondary_server ][email protected]@SERVERNAME; декларира @db nvarchar(255); while(exists(select top(1) 1 from #dbs)) start select top(1) @db=[name] from #dbs; започнете опитайте ВЪЗСТАНОВЯВАНЕ НА БАЗА ДАННИ @db С ВЪЗСТАНОВЯВАНЕ; край опит начало хващане край хващане изтриване от #dbs където [име][email protected]; крайна изпускаща таблица #dbs; изберете [secondary_database] като [name] в #dbs2 от msdb.dbo.log_shipping_monitor_secondary, където [secondary_server][email protected]@SERVERNAME; декларира @jobId BINARY(16); декларира @command nvarchar(max); декларира @dt nvarchar(255)=cast(YEAR(GetDate()) като nvarchar(255)) +'_'+cast(MONTH(GetDate()) като nvarchar(255)) +'_'+cast(DAY( GetDate()) като nvarchar(255)) +'_'+cast(DatePart(hour,GetDate()) като nvarchar(255)) +'_'+cast(DatePart(minute,GetDate()) като nvarchar(255 )) +'.trn'; декларира @backup_job_name nvarchar(255); декларира @schedule_name nvarchar(255); декларира @disk nvarchar(255); декларира @uid уникален идентификатор; while(exists(select top(1) 1 from #dbs2)) start 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]+'] НА ДИСК =@disk WITH NOFORMAT, NOINIT, NAME ='+N''''[email protected]+N''''+N', SKIP, NOREWIND, NOUNLOAD, STATS =10;'; задайте @uid=newid(); започнете да опитате BACKUP DATABASE @db НА ДИСК =@disk С 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_netsend=0, @notify_level_page_level=0, @notify_level_page_level=0, @notify_level_page_level=0, @notify_level_pagelevel=0, наличен.', @category_name=N'[Uncategorized (Local)]', @[email protected], @job_id =@jobId ИЗХОД; 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_fa, @on_success_step_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_type=0, @freq_subday_interval=5,_interval_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, @server_name =N'(local)'; край опит начало хващане край хващане изтриване от #dbs2 където [име][email protected]; крайна изпускаща таблица #dbs2; крайEND

За да се върнете към главния сървър, е необходимо да конфигурирате доставката на регистрационния файл на транзакциите от резервния сървър към главния и след това да извършите отстраняване на грешки при отказ. След това основният сървър ще стане производствен сървър. След това трябва да конфигурирате доставката на дневника на транзакциите от производствения сървър към резервния.

Конфигуриране на автоматична настройка за наблюдение на доставката на дневника на транзакциите

За да наблюдавате доставката на дневника на транзакциите, използвайте задачата LSAlert_ и отчет на сървъра за наблюдение. За да направите това, щракнете с десния бутон върху екземпляра на сървъра за наблюдение и след това изберете Отчети/Стандартен отчет/ Състояние на доставка на дневника на транзакциите.

Доста често с течение на времето сървърът за наблюдение (в случай че не е производствен) неправилно взема последното време на създаване на резервно копие на дневника на транзакциите на базата данни на производствения сървър. В резултат на това се сблъскваме с фалшиви предупреждения.

Възможно е да разрешите проблема с помощта на следния скрипт:

Пример за конфигуриране на корекцията за наблюдение на доставката на дневника на транзакциите

СЪЗДАВАНЕ НА ПРОЦЕДУРА [srv].[AutoCorrectMonitorLogShipping] ASBEGIN /* Корекция на наблюдението на доставката на дневника на транзакциите */ SET NOCOUNT ON; update t2 set t2.[last_backup_date]=t1.[BackupFinishDate] ,t2.[last_backup_date_utc]=DateAdd(hour,-DateDiff(hour,GetUTCDate(),GetDate()),t1.[BackupFinishDate]) ,t_backup_date]) ,t_backup_date_. ]=RIGHT(t1.[PhysicalDeviceName], CHARINDEX('\',REVERSE(t1.[PhysicalDeviceName]),1)-1) от [PRODUCTION_INSTANCE_NAME].[SRV].[inf].[vServerLastBackupDB] като t1 вътрешно присъединяване. [msdb].[dbo].[log_shipping_monitor_primary] като t2 на t1.[DBName] съпоставяне SQL_Latin1_General_CP1_CI_AS=t2.[primary_database] съпоставяне SQL_Latin1_General_CP1_CI_AS където t1.[Backup>
prelogType';END=N=N'prelogType';END=N 

 Можем да автоматизираме повикване за съхранена процедура по време. Например, можем да създадем подходяща задача в агента и да я планираме на всеки 5 минути. Разбира се, производственият сървър трябва да бъде свързан с резервния сървър (обекти на сървъра\свързани сървъри).
 

 Тук използваме изгледа [inf].[vServerLastBackupDB] в базата данни SRV, който дефинира най-новите архивни копия на база данни:
 

 Пример за внедряване на изгледа vServerLastBackupDB: 
 
СЪЗДАВАНЕ НА ИЗГЛЕД [inf].[vServerLastBackupDB] като с backup_cte as( изберете bs.[име_на_базата], backup_type =case bs.[type], когато 'D', след това 'database', когато 'L', след това 'log', когато 'I' ' след това 'диференциално' друго 'друго' край, bs.[first_lsn], bs.[last_lsn], bs.[backup_start_date], bs.[backup_finish_date], cast(bs.[backup_size] като десетичен(18,3))) /1024/1024 като BackupSizeMb, rownum =row_number() над ( дял по bs.[име_на_база_данни], тип ред по bs.[backup_finish_date] desc), LogicalDeviceName =bmf.[logical_device_name], PhysicalDeviceFime_sical,_def.[име на физическо устройство], bm_def. .[име_на_сървър], bs.[име_на_потребител] ОТ msdb.dbo.backupset bs ВЪТРЕШНО ПРИСЪЕДИНЯВАНЕ msdb.dbo.backupmediafamily bmf ON [bs].[media_set_id] =[bmf].[media_set_id])изберете [име_на_сървър] като [ServerName] , [име на база данни] като [DBName], [user_name] като [ Потребителско име], [backup_type] като [BackupType], [backup_start_date] като [BackupStartDate], [backup_finish_date] като [BackupFinishDate], [BackupSizeMb], -- некомпресиран размер [LogicalDeviceName], [PhysicalDeviceName], [PhysicalDeviceName], [PhysicalDeviceName], [PhysicalDeviceName], [PhysslFini_fir] , [last_lsn] като [LastLSN]от backup_cte, където rownum =1;
 
Резултат
 

 В тази статия разгледахме накратко всички възможни опции за толерантност към грешки и бърза наличност в MS SQL Server 2017, както и примери за внедряване на отстраняване на грешки при отказ и автоматично регулиране на наблюдението на доставката на регистрационния файл на транзакциите.
 
Препратки:
 
 
msdb
 
Налични издания на SQL Server 2017
 
Винаги включено
 
Инсталиране на клъстер за отказване на SQL сървър
 
Репликация
 
Отразяване
 
Изпращане на дневници
 
Конфигуриране на доставка на дневници