Udostępnij za pośrednictwem


Link do trybu failover — Azure SQL Managed Instance

Dotyczy: Azure SQL Managed Instance

W tym artykule przedstawiono sposób przełączania bazy danych w tryb failover połączonej między programem SQL Server i usługą Azure SQL Managed Instance przy użyciu programu SQL Server Management Studio (SSMS) lub programu PowerShell na potrzeby odzyskiwania po awarii lub migracji.

Wymagania wstępne

Aby przeprowadzić bazy danych w tryb failover do repliki pomocniczej za pośrednictwem linku, potrzebne są następujące wymagania wstępne:

Zatrzymywanie obciążenia

Jeśli chcesz przełączyć bazę danych w tryb failover do repliki pomocniczej, najpierw zatrzymaj wszystkie obciążenia aplikacji w replice podstawowej w godzinach konserwacji. Dzięki temu replikacja bazy danych może nadrobić zaległości w pomocniczej wersji, dzięki czemu można przejść w tryb failover do pomocniczej bez utraty danych. Przed przełączeniem w tryb failover upewnij się, że aplikacje nie zatwierdzają transakcji w podstawowej wersji.

Przełączanie bazy danych w tryb failover

Połączoną bazę danych można przejąć w tryb failover przy użyciu języka Transact-SQL (T-SQL), programu SQL Server Management Studio lub programu PowerShell.

Link można przeprowadzić w tryb failover przy użyciu języka Transact-SQL, począwszy od programu SQL Server 2022 CU13 (KB5036432).

Aby wykonać planowane przejście w tryb failover dla linku, użyj następującego polecenia języka T-SQL w repliki podstawowej:

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

Aby przeprowadzić wymuszone przejście w tryb failover, użyj następującego polecenia T-SQL w repliki pomocniczej:

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

Wyświetlanie bazy danych po przejściu w tryb failover

W przypadku programu SQL Server 2022, jeśli wybrano obsługę linku, możesz sprawdzić, czy rozproszona grupa dostępności istnieje w obszarze Grupy dostępności w Eksplorator obiektów w programie SQL Server Management Studio.

Jeśli link został usunięty podczas pracy w trybie failover, możesz użyć Eksplorator obiektów, aby potwierdzić, że rozproszona grupa dostępności już nie istnieje. Jeśli zdecydujesz się zachować grupę dostępności, baza danych będzie nadal synchronizowana.

Czyszczenie po przejściu w tryb failover

Jeśli nie wybrano opcji Usuń łącze po pomyślnym przejściu w tryb failover, przełączenie w tryb failover z programem SQL Server 2022 nie spowoduje przerwania łącza. Możesz zachować link po przejściu w tryb failover, który pozostawia grupę dostępności i aktywną rozproszoną grupę dostępności. Nie trzeba wykonywać dalszych akcji.

Usunięcie linku porzuca tylko rozproszoną grupę dostępności i pozostawia aktywną grupę dostępności. Możesz zdecydować się na utrzymanie grupy dostępności lub jej usunięcie.

Jeśli zdecydujesz się usunąć grupę dostępności, zastąp następującą wartość, a następnie uruchom przykładowy kod T-SQL:

  • <AGName> z nazwą grupy dostępności w programie SQL Server (używanym do utworzenia linku).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Niespójny stan po wymuszonym przejściu w tryb failover

Po wymuszonym przejściu w tryb failover może wystąpić scenariusz podziału mózgu, w którym obie repliki znajdują się w roli głównej, pozostawiając link w stanie niespójnym. Może się tak zdarzyć, jeśli nastąpi przełączenie w tryb failover do repliki pomocniczej podczas awarii, a następnie replika podstawowa wróci do trybu online.

Najpierw upewnij się, że jesteś w scenariuszu podzielonym mózgiem. Można to zrobić przy użyciu programu SQL Server Management Studio (SSMS) lub języka Transact-SQL (T-SQL).

Połącz się zarówno z programem SQL Server, jak i wystąpieniem zarządzanym SQL w programie SSMS, a następnie w Eksplorator obiektów rozwiń węzeł Repliki dostępności w węźle Zawsze włączona wysoka dostępność. Jeśli dwie różne repliki są wyświetlane jako (Podstawowa), jesteś w scenariuszu podzielonym mózgiem.

Alternatywnie można uruchomić następujący skrypt języka T-SQL w programie SQL Server i usłudze SQL Managed Instance, aby sprawdzić rolę replik:

-- Execute on SQL Server and SQL Managed Instance 

declare @link_name varchar(max) = '<DAGName>' 
USE MASTER 
GO

SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 and ag.name = @link_name 
GO

Jeśli oba wystąpienia zawierają inną pozycję Podstawowa w kolumnie Rola linku, jesteś w scenariuszu podzielonym mózgiem.

Aby rozwiązać problem ze podzielonym stanem mózgu, najpierw wykonaj kopię zapasową niezależnie od tego, która replika była oryginalną podstawową repliką. Jeśli oryginalny podstawowy był programem SQL Server, utwórz kopię zapasową dziennika końcowego. Jeśli oryginalny element podstawowy to SQL Managed Instance, utwórz pełną kopię zapasową tylko do kopiowania. Po zakończeniu tworzenia kopii zapasowej ustaw rozproszoną grupę dostępności na rolę pomocniczą repliki, która była oryginalną podstawową, ale teraz będzie nową pomocniczą.

Na przykład w przypadku rzeczywistej awarii przy założeniu, że wymusisz przejście w tryb failover obciążenia programu SQL Server do usługi Azure SQL Managed Instance i zamierzasz kontynuować uruchamianie obciążenia w usłudze SQL Managed Instance, wykonaj kopię zapasową dziennika końcowego w programie SQL Server, a następnie ustaw rozproszoną grupę dostępności na rolę pomocniczą w programie SQL Server, taką jak w poniższym przykładzie:

--Execute on SQL Server 
USE MASTER

ALTER availability group [<DAGName>] 
SET (role = secondary) 
GO 

Następnie wykonaj planowane ręczne przejście w tryb failover z usługi SQL Managed Instance do programu SQL Server przy użyciu linku, takiego jak poniższy przykład:

--Execute on SQL Managed Instance 
USE MASTER

ALTER availability group [<DAGName>] FAILOVER 
GO 

Aby użyć linku:

Aby dowiedzieć się więcej na temat linku:

W przypadku innych scenariuszy replikacji i migracji należy wziąć pod uwagę następujące kwestie: