Implementacja trybu failover w standardzie MS SQL Server 2017

Wprowadzenie

Często musimy zapewnić odporność na błędy MS SQL Server DBMS, zwłaszcza gdy nie ma edycji Enterprise, a tylko Standard.

Zwracamy uwagę, że nie będziemy badać edycji Express, ponieważ istnieją znaczne ograniczenia dotyczące tej instancji. Jasne, niektóre z nich możemy ominąć. Na przykład, aby rozwiązać problem z bazą danych o rozmiarze 10 GB, możemy podzielić dużą bazę danych na mniejsze. W tym celu możemy utworzyć nową bazę danych na podstawie określonej właściwości i połączyć selekcje z tych samych tabel z różnych baz danych w widokach w głównej bazie danych. Jednak odporność na awarie w wersji Express będzie wykonywana przez administratora systemu lub przy użyciu oprogramowania własnego lub innej firmy.

W tym artykule przyjrzymy się wszystkim istniejącym standardowym technologiom odporności na awarie dla MS SQL Server 2017 oraz przykładowi implementacji najbardziej odpowiedniego ujednoliconego standardu odporności na awarie w edycji Standard.

Krótka recenzja

1. Zawsze włączone

   Rozkład obciążenia na wszystkie strony, wszystkie strony powinny być do siebie podobne pod względem charakterystyki. Tryb synchroniczny zapewnia maksymalną niezawodność transmisji danych; jednak wydajność będzie równa szybkości najwolniejszej imprezy. Tryb asynchroniczny zapewnia najwyższą wydajność, ale mogą wystąpić niedopasowanie danych między stronami, co może skutkować bardziej złożoną obsługą i prawdopodobieństwem utraty ostatnich zmian w przypadku awarii strony głównej. Szybkość przełączania w tryb synchroniczny jest prawie natychmiastowy i nie wymaga administratora systemu i DBA, natomiast w trybie asynchronicznym zależy od aktualnego stanu duplikatów DB i zwykle trwa około 5 minut (można również zautomatyzować proces przełączania o jednego DBA bez administratora systemu ).Microsoft zaleca używanie tej technologii dla bazy danych. Jest dostępny w wersji Enterprise, począwszy od wersji 2012 i nowszych oraz z ograniczeniami w wersji Standard (Aby dowiedzieć się więcej, zapoznaj się z 5 najczęściej zadawanymi pytaniami dotyczącymi podstawowych grup dostępności).

2. Klastrowanie

   Mimo prostoty konfiguracji rozwiązanie to jest zawodne ze względu na wąskie gardło w postaci jednej hurtowni danych. W przypadku awarii hurtowni danych jej przywrócenie zajmie ponad 1 godzinę. Ta technologia jest dostępna w wersji Standard w wersji 2008 i nowszych.

3. Replikacja

   Każda replikacja obejmuje tworzenie wyzwalaczy systemowych dla każdej uczestniczącej tabeli, podczas gdy replikacja migawki mocno obciąża główną bazę danych. W związku z tym replikacja migawek może być wykonywana tylko poza godzinami szczytu obciążenia bazy danych (na przykład w nocy), co jest niedopuszczalne, ponieważ konieczny jest tryb gorącej gotowości. Replikacja scalająca jest skomplikowana w obsłudze przez niektóre systemy (na przykład CRM, NAV).
   Replikacja transakcyjna jest możliwa w wersji Enterprise. Dostępne w wersji Standard (scalanie i migawki bazy danych) oraz w wersji Enterprise (transakcje) do wersji 2008 i nowszych.

4. Odbicie lustrzane

   Jest to możliwe w dowolnym trybie. Jednak tryb synchroniczny zapewnia maksymalną niezawodność i szybkie przełączanie, podczas gdy tryb asynchroniczny zapewnia użytkownikom maksymalną szybkość działania głównej bazy danych. Jednak możliwe jest niedopasowanie danych między stronami, a przełączanie może być powolne.

   W tym przypadku serwer-świadek lub DBA zapewnia automatyczne przełączanie na poziomie bazy danych (na przykład, gdy obciążenie procesora przekracza 50% na serwerze głównym). Administrator systemu udziela połączenia z innym serwerem. Kopia zapasowa bazy danych dla dowolnego typu dublowania jest w trybie ciągłego odzyskiwania, więc nie można uzyskać do niej dostępu.

   Tryb odzyskiwania bazy danych jest pełny.

   Microsoft uważa to za przestarzałą technologię bazodanową. Jest dostępny w wersji Standard (w trybie synchronicznym) oraz w wersji Enterprise (w trybie asynchronicznym) do wersji 2008 i nowszych.

5. Wysyłka dziennika transakcji

   Istnieją dwa tryby:ciągłe odzyskiwanie na serwerze w stanie gotowości lub odzyskiwanie z opóźnieniami. Pierwszy tryb przełącza kopię zapasową bazy danych w tryb ciągłego odzyskiwania i w tym przypadku nie możemy uzyskać do niej dostępu.

   Drugi tryb regularnie przełącza kopię zapasową bazy danych w tryb odzyskiwania podczas wdrażania aktualizacji (baza danych kopii zapasowej jest dostępna między wdrożeniami, ale jest to możliwe pod warunkiem, że instancje MS SQL Server mają tę samą wersję).

   Jak to działa:

   1. Okresowo kopia zapasowa dziennika transakcji bazy danych jest przechowywana w folderze publicznym na serwerze źródłowym i rezerwowym (katalog i harmonogram są domyślnie konfigurowane co 15 minut).
   2. Serwer rezerwowy okresowo kopiuje kopię zapasową dziennika transakcji bazy danych do folderu lokalnego (katalog i harmonogram są domyślnie konfigurowane co 15 minut).
   3. Serwer rezerwowy przywraca dziennik transakcji z kopii zapasowej dziennika transakcji (harmonogram jest domyślnie konfigurowany co 15 minut).

   Administratorzy baz danych mogą zautomatyzować proces przełączania na poziomie bazy danych, podczas gdy administrator systemu może to zrobić na poziomie połączenia z serwerem.

   Należy również zauważyć, że ta metoda zawsze działa w trybie asynchronicznym. Możesz skonfigurować wiele baz danych kopii zapasowych.

   Tryb odzyskiwania bazy danych jest pełny lub masowy.

   Jest dostępny w wersji Standard do wersji 2008 i nowszych.

   Istnieją dwa tryby:ciągłe odzyskiwanie na serwerze w stanie gotowości lub odzyskiwanie z opóźnieniami.

Podsumowanie

Najkorzystniejsza jest wysyłka dziennika transakcji w edycji Standard, ponieważ wygodnie jest go wykorzystać do płynnego przejścia z jednego serwera na drugi, np. podczas aktualizacji środowiska. Ponadto wysyłka dziennika transakcji jest prosta i łatwa w użyciu, a także zawsze działa w trybie asynchronicznym, który nie obciąża zbytnio bazy danych, w przeciwieństwie do synchronicznego trybu dublowania. W każdym razie tworzenie kopii lustrzanych jest dopuszczalne, jeśli można skonfigurować własne automatyczne przełączanie; w przeciwnym razie możliwe jest fałszywe przełączanie (na przykład, gdy procesor głównego serwera jest obciążony w ponad 50%).

W przypadku wersji Enterprise użyj technologii AlwaysOn.

Konfigurowanie przełączania awaryjnego po wysłaniu dziennika transakcji

Bardziej szczegółowe informacje na temat konfiguracji wysyłki dziennika transakcji znajdziesz tutaj. Ponadto możliwe jest zautomatyzowanie tego procesu poprzez opracowanie własnego narzędzia do wielokrotnego wielokrotnego użytku, a także do powrotu do głównego serwera po jego naprawie w przypadku awarii.

Przyjrzyjmy się jednej z możliwych opcji debugowania przełączania awaryjnego po wysłaniu dziennika transakcji na poziomie DBMS.

Należy zauważyć, że ta metoda jest odpowiednia dla serwera zarezerwowanego tylko dla jednej instancji instancji MS SQL Server, ponieważ w przypadku kilku instancji występuje problem z określeniem, które zadania należy wykonać, a których nie.

Opiszmy kolejność kroków:

1. Wykonaj wszystkie zadania, aby skopiować najnowsze pliki ze źródła (przy dobrze przemyślanej architekturze katalog musi być dostępny, nawet jeśli główny serwer nie działa)
2. Wyłącz wszystkie zadania kopiowania plików ze źródła
3. Wykonaj wszystkie zadania, aby przywrócić bazę danych przy użyciu najnowszych plików ze źródła
4. Wyłącz wszystkie zadania przywracania bazy danych przy użyciu najnowszych plików ze źródła
5. Spraw, aby baza danych została przywrócona i zleceniodawca wysyłki dziennika, ale bez odbiorcy
6. Twórz pełne kopie zapasowe bazy danych
7. Utwórz zadania do tworzenia kopii zapasowych dzienników transakcji

Poniżej znajduje się przykład implementacji powyższej sekwencji jako procedury składowanej.

Należy zauważyć, że ważne jest skonfigurowanie loginu (najlepiej loginu domeny), w ramach którego będą wykonywane zadania tworzenia kopii zapasowych dzienników transakcji.

Przykład debugowania przełączania awaryjnego wysyłki dziennika transakcji

CREATE PROCEDURE [srv].[RunLogShippingFailover] @isfailover bit=1, @login nvarchar(255)=N'LOGIN', -- login domeny, w ramach którego będą wykonywane zadania w celu utworzenia kopii zapasowych dzienników transakcji. @backup_directory nvarchar(255)=N'DIRECTORY'—publiczny katalog do wysyłania kopii zapasowych dzienników transakcji pomiędzy instancjami MS SQL Server (na przykład 'D:\Shared')AS /* Przeniesienie serwera rezerwowego do trybu głównego, gdy główny serwer nie działa, jeśli @isfailover =1 jest w pełni zautomatyzowany, gdy @isfailover jest równe 0, nic się nie dzieje - tutaj musimy od nowa utworzyć dziennik wysyłki ze stanu gotowości na główny, a następnie przełączyć się na serwer główny, a następnie do ponownie skonfiguruj wysyłkę dziennika transakcji. Uważa się, że ten serwer rezerwowy otrzymuje kopie zapasowe dzienników transakcji z jednego serwera */BEGIN --jeśli istnieje przełącznik przesunięcia na serwer rezerwowy, musisz wykonać wszystkie zadania, aby skopiować najnowsze pliki ze źródła if(@isfailover=1) rozpocznij wybieranie [identyfikator_zadania] w #zadania z [msdb].[dbo].[sysjobs] gdzie [nazwa], np. „LSCopy%”; zadeklaruj unikalny identyfikator @job_id; while(exists(wybierz top(1) 1 z #jobs)) rozpocznij wybierz top(1) @job_id=[job_id] z #jobs; rozpocznij próbę EXEC [msdb].dbo.sp_start_job @[email protected]_id; end try begin catch end catch delete z #jobs gdzie [job_id][email protected]_id; koniec tabeli upuszczania #zadania; end --wyłącz wszystkie zadania kopiowania plików ze źródła podczas przełączania na serwer zapasowy --włącz wszystkie zadania kopiowania plików ze źródła podczas powrotu na serwer produkcyjny update [msdb].[dbo].[sysjobs] set [enabled]=case when (@isfailover=1) następnie 0 else 1 end gdzie [name] jak 'LSCopy%'; --jeśli przechodzimy na serwer rezerwowy, musimy wykonać wszystkie zadania przywracania baz danych przy użyciu najnowszych plików ze źródła if(@isfailover=1) begin select [job_id] do #jobs2 z [msdb].[dbo ].[sysjobs] gdzie [nazwa] jak „LSRestore%”; while(exists(wybierz top(1) 1 z #jobs2)) rozpocznij wybierz top(1) @job_id=[job_id] z #jobs2; rozpocznij próbę EXEC [msdb].dbo.sp_start_job @[email protected]_id; EXEC [msdb].dbo.sp_start_job @[email protected]_id; end spróbuj begin catch end catch delete z #jobs2 gdzie [job_id][email protected]_id; koniec tabeli upuszczania #jobs2; end --wyłącz wszystkie zadania przywracania baz danych przy użyciu najnowszych plików ze źródła podczas przełączania na serwer rezerwowy --włącz wszystkie zadania przywracania baz danych przy użyciu najnowszych plików podczas powrotu na serwer produkcyjny update [msdb].[dbo] .[sysjobs] set [enabled]=case when (@isfailover=1) then 0 else 1 end gdzie [name] jak 'LSRestore%'; --przełączając się na serwer rezerwowy, sprawiamy, że baza danych jest możliwa do przywrócenia i jako główna do wysyłania dzienników bez adresata if(@isfailover=1) zacznij wybrać [secondary_database] jako [name] do #dbs z msdb.dbo.log_shipping_monitor_secondary gdzie [secondary_server ][email protected]@NAZWASERWERA; zadeklaruj @db nvarchar(255); while(exists(select top(1) 1 z #dbs)) begin select top(1) @db=[name] from #dbs; zacznij próbować RESTORE DATABASE @db WITH RECOVERY; koniec spróbuj początek złap koniec złap usuń z #dbs gdzie [nazwa][email protected]; koniec tabeli upuszczania #dbs; wybierz [secondary_database] jako [name] do #dbs2 z msdb.dbo.log_shipping_monitor_secondary gdzie [secondary_server][email protected]@SERVERNAME; zadeklaruj @jobId BINARY(16); zadeklaruj @polecenie nvarchar(max); define @dt nvarchar(255)=cast(YEAR(GetDate()) as nvarchar(255)) +'_'+cast(MIESIĄC(GetDate()) as nvarchar(255)) +'_'+cast(DAY( GetDate()) as nvarchar(255)) +'_'+cast(DatePart(godzina,GetDate()) as nvarchar(255)) +'_'+cast(DatePart(minuta,GetDate()) as nvarchar(255) )) +'.trn'; zadeklaruj @ nazwa_zadania_zapasowego nvarchar(255); zadeklaruj @schedule_name nvarchar(255); zadeklaruj @disk nvarchar(255); zadeklaruj unikalny identyfikator @uid; while(exists(select top(1) 1 from #dbs2)) begin select top(1) @db=[name] from #dbs2; ustaw @[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]+'] TO DISK =@disk WITH NOFORMAT, NOINIT, NAME ='+N''''[email protected]+N''''+N', SKIP, NOREWIND, RZECZOWNIK, STATYSTYKI =10;'; ustaw @uid=newid(); zacznij próbować BACKUP DATABASE @db TO DISK =@disk WITH NOFORMAT, NOINIT, NAME =@db, SKIP, NOREWIND, NOUNLOAD, STATS =10; EXEC msdb.dbo.sp_add_job @[email protected]_nazwa_pracy, @enabled=1, @notify_level_eventlog=0, @notify_level_email=0, @notify_level_netsend=0, @notify_level_page=0, @delete_level=0, @description=N'Brak opisu dostępne.', @category_name=N'[Bez kategorii (lokalne)]', @[email protected], @job_id =@jobId WYJŚCIE; EXEC msdb.dbo.sp_add_jobstep @[email protected], @[email protected]_nazwa_pracy, @step_id=1, @cmdexec_success_code=0, @on_success_action=1, @on_success_step_id=0, @on_fail_fail_step=2 @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=5, @freq_relative_interval=0, @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'(lokalne)'; end try begin catch end catch delete z #dbs2 gdzie [nazwa][email protected]; koniec tabeli upuszczania #dbs2; koniecEND

Aby powrócić do serwera głównego, należy skonfigurować wysyłanie dziennika transakcji z serwera rezerwowego do głównego, a następnie wykonać debugowanie pracy awaryjnej. Następnie serwer główny stanie się serwerem produkcyjnym. Następnie musisz skonfigurować wysyłanie dziennika transakcji z serwera produkcyjnego na serwer rezerwowy.

Konfigurowanie automatycznego dostosowania monitorowania wysyłki dziennika transakcji

Aby monitorować wysyłanie dziennika transakcji, użyj zadania LSAlert_ i raportu na serwerze monitorowania. Aby to zrobić, kliknij prawym przyciskiem myszy instancję na serwerze monitorowania, a następnie wybierz Raporty/Raport standardowy/Status wysyłki dziennika transakcji.

Dość często z biegiem czasu serwer monitorujący (w przypadku, gdy nie jest to serwer produkcyjny) błędnie przyjmuje ostatni czas tworzenia kopii zapasowej logu transakcyjnego bazy danych na serwerze produkcyjnym. W rezultacie otrzymujemy fałszywe ostrzeżenia.

Problem można rozwiązać za pomocą następującego skryptu:

Przykład konfiguracji dostosowania monitorowania wysyłki dziennika transakcji

CREATE PROCEDURE [srv].[AutoCorrectMonitorLogShipping] ASBEGIN /* Dostosowanie monitorowania wysyłki dziennika transakcji */ SET NOCOUNT ON; aktualizuj t2 ustaw t2.[last_backup_date]=t1.[DataZakończeniaZapasu] ,t2.[last_backup_date_utc]=DateAdd(godzina,-DateDiff(godzina,GetUTCDate(),GetDate()),t1.[DataZakończeniaZapasu]) ,t2.[plik_last_kopii zapasowej ]=RIGHT(t1.[NazwaUrządzeniaFizycznego], CHARINDEX('\',REVERSE(t1.[NazwaUrządzeniaFizycznego]),1)-1) z [NAZWA_INSTANCJI_PRODUKCYJNEJ].[SRV].[inf].[vServerLastBackupDB] jako sprzężenie wewnętrzne t1 [msdb].[dbo].[log_shipping_monitor_primary] jako t2 na t1.[DBName] zestawia SQL_Latin1_General_CP1_CI_AS=t2.[primary_database] zestawia SQL_Latin1_General_CP1_CI_AS gdzie t1.[BackupType]=N'pre>'; 

 Możemy zautomatyzować wywołanie procedury składowanej według czasu. Na przykład, możemy stworzyć odpowiednie zadanie w Agencie i zaplanować je co 5 minut. Oczywiście serwer produkcyjny musi być połączony z serwerem zapasowym (obiekty serwera\serwery połączone).
 

 Tutaj używamy widoku [inf].[vServerLastBackupDB] w bazie danych SRV, który definiuje najnowsze kopie zapasowe bazy danych:
 

 Przykład implementacji widoku vServerLastBackupDB: 
 
CREATE VIEW [inf].[vServerLastBackupDB] aswith backup_cte as(wybierz bs.[nazwa_bazy_danych], backup_type =case bs.[typ], gdy 'D', a następnie 'baza danych', gdy 'L', a następnie 'log', gdy 'I ' then 'differential' else 'other' end, bs.[first_lsn], bs.[last_lsn], bs.[backup_start_date], bs.[backup_finish_date], cast(bs.[backup_size] as decimal(18,3)) /1024/1024 jako BackupSizeMb, rownum =row_number() over (partycja według bs.[nazwa_bazy_danych], wpisz kolejność według bs.[backup_finish_date] desc), LogicalDeviceName =bmf.[logiczna_nazwa_urządzenia], PhysicalDeviceName =bmf.[fizyczna_nazwa_urządzenia], bs .[nazwa_serwera], bs.[nazwa_użytkownika] Z msdb.dbo.backupset bs WEWNĘTRZNE POŁĄCZENIE msdb.dbo.backupmediafamily bmf ON [bs].[identyfikator_zestawu_mediów] =[bmf].[identyfikator_zestawu_mediów])wybierz [nazwa_serwera] jako [Nazwa_serwera] , [nazwa_bazy_danych] jako [nazwa_bazy_danych], [nazwa_użytkownika] jako [ UserName], [backup_type] as [BackupType], [backup_start_date] as [BackupStartDate], [backup_finish_date] as [BackupFinishDate], [BackupSizeMb], -- rozmiar nieskompresowany [LogicalDeviceName], [PhysicalDeviceName], [first_lsn] as [FirstLSN] , [last_lsn] jako [LastLSN]z backup_ctewhere rownum =1;
 
Wynik
 

 W tym artykule omówiliśmy pokrótce wszystkie możliwe opcje odporności na błędy i szybkiej dostępności w MS SQL Server 2017, a także przykłady implementacji debugowania przełączania awaryjnego i automatycznego dostosowania monitorowania wysyłki dziennika transakcji.
 
Referencje:
 
 
msdb
 
Dostępne wersje SQL Server 2017
 
Zawsze włączone
 
Instalacja klastra pracy awaryjnej serwera SQL
 
Replikacja
 
Odbicie lustrzane
 
Wysyłka dziennika
 
Konfiguruj wysyłkę dziennika