najlepsze rozwiązania dotyczące linków Managed Instance — Azure SQL Managed Instance

Applies to:Azure SQL Managed Instance

W tym artykule opisano najlepsze rozwiązania dotyczące używania linku Managed Instance do replikowania danych między Azure SQL Managed Instance a wystąpieniami SQL Server hostowanymi w dowolnym miejscu. Link zapewnia replikację danych niemal w czasie rzeczywistym między połączonymi replikami.

Regularne wykonywanie kopii zapasowych dzienników

Jeśli SQL Server jest wstępnym serwerem podstawowym, wykonaj pierwszą kopię zapasową dziennika na SQL Server po zakończeniu wstępnej replikacji, gdy baza danych nie znajduje się już w stanie przywracania... na instancji Azure SQL Managed. Następnie regularnie wykonuj kopie zapasowe dziennika transakcji SQL Server, aby zachować rozmiar pliku dziennika transakcji w dobrej kondycji, podczas gdy SQL Server jest w roli nadrzędnej.

Funkcja linku replikuje dane przy użyciu technologii rozproszonych grup dostępności opartych na zawsze włączonych grupach dostępności. Replikacja danych rozproszonej grupy dostępności jest oparta na replikowaniu rekordów dziennika transakcji. Instancja podstawowa SQL Server nie może obcinać żadnych wpisów dziennika transakcji z bazy danych, dopóki nie zostaną zreplikowane do bazy danych w replice pomocniczej. Jeśli problemy z połączeniem sieciowym powodują spowolnienie lub zablokowanie replikacji rekordów dziennika transakcji, plik dziennika nadal rośnie w wystąpieniu podstawowym. Intensywność obciążenia i szybkość sieci określają szybkość wzrostu. Jeśli awaria połączenia sieciowego jest długotrwała, a obciążenie instancji podstawowej jest duże, plik dziennika może zająć całe dostępne miejsce do magazynowania.

Wykonywanie regularnych kopii zapasowych dziennika transakcji obcina dziennik transakcji i minimalizuje ryzyko wyczerpania miejsca w wystąpieniu podstawowym SQL Server z powodu wzrostu pliku dziennika. Gdy SQL Managed Instance jest podstawową, ponieważ kopie zapasowe dziennika wykonywane są automatycznie. Regularne wykonywanie kopii zapasowych dzienników na głównym serwerze SQL sprawia, że baza danych jest bardziej odporna na nieplanowane zdarzenia wzrostu dziennika. Rozważ zaplanowanie codziennych zadań tworzenia kopii zapasowej dziennika przy użyciu zadania SQL Server Agent.

Aby utworzyć kopię zapasową pliku dziennika, takiego jak przykład podany w tej sekcji, możesz użyć skryptu Transact-SQL (T-SQL). Zastąp symbole zastępcze w przykładowym skrypcie nazwą bazy danych, nazwą i ścieżką pliku kopii zapasowej oraz opisem.

Aby utworzyć kopię zapasową dziennika transakcji, użyj następującego przykładowego skryptu Transact-SQL (T-SQL) w SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Użyj następującego polecenia Transact-SQL (T-SQL), aby sprawdzić obszar dziennika używany przez bazę danych na SQL Server:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE); 

Dane wyjściowe zapytania wyglądają jak w poniższym przykładzie przykładowej bazy danych tpcc:

W tym przykładzie baza danych użyła 76% dostępnego dziennika z bezwzględnym rozmiarem pliku dziennika wynoszącym około 27 GB (27 971 MB). Progi akcji różnią się w zależności od obciążenia. W poprzednim przykładzie rozmiar dziennika transakcji i procent użycia dziennika zwykle wskazuje, że należy wykonać kopię zapasową dziennika transakcji, aby obciąć plik dziennika i zwolnić trochę miejsca lub częściej wykonywać kopie zapasowe dziennika. Może to również wskazywać, że trunkowanie dziennika transakcji jest blokowane przez otwarte transakcje. Aby uzyskać więcej informacji na temat rozwiązywania problemów z dziennikiem transakcji w SQL Server, zobacz Rozwiązywanie problemów z pełnym dziennikiem transakcji (błąd SQL Server 9002). Aby uzyskać więcej informacji na temat rozwiązywania problemów z dziennikiem transakcji w Azure SQL Managed Instance, zobacz Rozwiązywanie błędów dziennika transakcji z Azure SQL Managed Instance.

Dopasowywanie wydajności między replikami

Gdy używasz funkcji linku, dopasuj wydajność między SQL Server a SQL Managed Instance. To dopasowanie pomaga uniknąć problemów z wydajnością, jeśli replika pomocnicza nie jest w stanie dotrzymać tempa replikacji z repliki podstawowej lub po wystąpieniu przełączenia awaryjnego. Wydajność obejmuje rdzenie procesora CPU (lub rdzenie wirtualne [vCores] w Azure), pamięć i przepływność operacji we/wy.

Wydajność replikacji można monitorować, sprawdzając rozmiar kolejki ponownego odtworzenia w replice pomocniczej. Rozmiar kolejki operacji redo pokazuje liczbę rekordów dziennika, które oczekują na ponowne wdrożenie na replice pomocniczej. Stale duży rozmiar kolejki ponownego uruchamiania pokazuje, że replika pomocnicza nie może nadążyć za repliką podstawową. Rozmiar kolejki ponownej można sprawdzić w następujący sposób:

• Wartość redo_queue_size w widoku dynamicznego zarządzania sys.dm_hadr_database_replica_states na głównej replice.
• InstanceRedoLagReplicationSeconds Wartość polecenia Get-AzSqlInstanceLink w repliki podstawowej.

Jeśli rozmiar kolejki operacji przywracania jest stale wysoki, rozważ zwiększenie zasobów na replice pomocniczej.

Monitorowanie opóźnienia replikacji

Monitorowanie opóźnienia replikacji pomaga określić szybkość synchronizacji repliki pomocniczej z repliką podstawową. Duża rozbieżność wskazuje, że replika pomocnicza ma problemy z nadążaniem za repliką podstawową, co jest zwykle spowodowane niską przepustowością sieci w połączeniu między dwoma wystąpieniami, niespójną alokacją zasobów między dwiema replikami lub zbyt dużym obciążeniem na replikę podstawową.

Monitorowanie opóźnienia replikacji jest szczególnie ważne podczas przeprowadzania planowanego trybu failover, co wymaga, aby replika pomocnicza została w pełni zsynchronizowana z repliką podstawową, zanim będzie można wykonać tryb failover. Jeśli opóźnienie replikacji jest wysokie, przejście w tryb failover może potrwać dłużej, a w niektórych przypadkach może nawet zakończyć się niepowodzeniem.

Użyj następującego zapytania T-SQL w SQL Server i SQL Managed Instance, aby monitorować opóźnienie replikacji między replikami:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Obracanie certyfikatu

Może być konieczne ręczne obracanie certyfikatu używanego do zabezpieczania punktu końcowego dublowania bazy danych na SQL Server. Ponieważ usługa zarządza i automatycznie obraca certyfikat używany do zabezpieczenia punktu końcowego dublowania bazy danych na SQL Managed Instance, nie musisz go ręcznie obracać.

SQL Server

Certyfikat używany do zabezpieczenia punktu końcowego dublowania bazy danych w SQL Server może wygasnąć. Jeśli certyfikat wygaśnie, może prowadzić do obniżenia poziomu połączenia. Aby zapobiec temu problemowi, należy odnowić certyfikat przed jego wygaśnięciem.

Użyj następującego polecenia Transact-SQL (T-SQL), aby sprawdzić datę wygaśnięcia bieżącego certyfikatu:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK' 

Jeśli certyfikat wkrótce wygaśnie lub już wygasł, utwórz nowy certyfikat, a następnie zmień istniejący punkt końcowy, aby zastąpić bieżący certyfikat.

Po skonfigurowaniu punktu końcowego do korzystania z nowego certyfikatu można usunąć wygasły certyfikat.

SQL Managed Instance (Zarządzana instancja SQL)

Certyfikat punktu końcowego dublowania bazy danych na SQL Managed Instance jest okresowo obracany automatycznie. Nie musisz monitorować daty wygaśnięcia certyfikatu punktu końcowego odbicia bazy danych w SQL Managed Instance, jeśli możesz zweryfikować łańcuch certyfikatów w SQL Server pomyślnie.

Weryfikowanie łańcucha certyfikatów w SQL Server

Problemy z łańcuchem certyfikatów mogą obniżyć wydajność łącza. Aby zapobiec temu problemowi, regularnie zweryfikuj łańcuch certyfikatów w SQL Server.

Następujące scenariusze mogą powodować problemy z łańcuchem certyfikatów w SQL Server:

• Zaplanowana rotacja certyfikatów w SQL Managed Instance.
• Niezamierzone lub przypadkowe zmiany certyfikatów w SQL Server, takie jak usuwanie lub zmienianie certyfikatu używanego do zabezpieczenia punktu końcowego dublowania bazy danych.

Najpierw określ certificate_id zaimportowanego certyfikatu punktu końcowego mi, zastępując wartość <ManagedInstanceFQDN>, a następnie uruchamiając następujące zapytanie na SQL Server:

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO 

Następnie zweryfikuj certyfikat, zastępując wartość <certificate_id> z wyniku poprzedniego zapytania, a następnie uruchamiając następujące zapytanie na SQL Server:

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO 

Odpowiedź Commands completed successfully. Completion time: ... wskazuje, że certyfikat punktu końcowego MI został pomyślnie zweryfikowany.

Jeśli wystąpi błąd, najbardziej niezawodnym działaniem zapobiegawczym jest przywrócenie łańcucha certyfikatów poprzez najpierw usunięcie wszystkich certyfikatów utworzonych w sekcjach Pobierz klucz publiczny certyfikatu z SQL Managed Instance i zaimportuj go do SQL Server oraz Zaimportuj klucze głównej instytucji certyfikującej zaufanej przez Azure do SQL Server, a następnie ponowne ich zaimportowanie.

Dodaj flagi śledzenia uruchamiania

W SQL Server istnieją dwie flagi śledzenia (-T1800 i -T9567), które po dodaniu jako parametry uruchamiania mogą zoptymalizować wydajność replikacji danych za pośrednictwem linku. Zobacz Włączanie flag śledzenia rozruchu, aby dowiedzieć się więcej.

Używaj zatwierdzania synchronicznego z ostrożnością

Domyślny tryb zatwierdzania linku jest asynchroniczny. Chociaż można zmienić tryb zatwierdzania na synchroniczny, nie jest zalecane i nie jest konieczne zabezpieczenie przed potencjalną utratą danych.

Podczas planowanego połączonego trybu failover replikacja tymczasowo przełącza się do trybu zatwierdzania synchronicznego do momentu ukończenia trybu failover. Po przejściu w tryb failover tryb zatwierdzania przełącza się z powrotem do trybu asynchronicznego, nawet jeśli jest jawnie ustawiony na tryb synchronicznego zatwierdzania przed przejściem w tryb failover.

Użycie trybu zatwierdzania synchronicznego dla łącza może mieć wpływ na wydajność repliki podstawowej, zwłaszcza jeśli między replikami występuje duże opóźnienie sieci. W trybie zatwierdzania synchronicznego transakcje w repliki podstawowej muszą czekać na potwierdzenie, że rekordy dziennika transakcji są wzmacniane w repliki pomocniczej, zanim transakcja może zostać zatwierdzona na serwerze podstawowym. Ten czas oczekiwania zwiększa się wraz z większym opóźnieniem sieci, co może prowadzić do zwiększenia czasu odpowiedzi transakcji i zmniejszenia przepływności w replice podstawowej.

Powiązana zawartość

Aby użyć linku:

• Przygotuj środowisko dla łącza Managed Instance
• Konfiguruj połączenie między SQL Server i wystąpieniem zarządzanym SQL za pomocą programu SSMS
• Konfiguruj połączenie między SQL Server i wystąpieniem zarządzanym SQL za pomocą skryptów
• Przełącz łącze w tryb failover
• Migrowanie za pomocą linku
• Rozwiązywanie problemów z linkiem

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

• Omówienie linku Managed Instance
• Odzyskiwanie po awarii z linkiem Managed Instance
• Najlepsze rozwiązania dotyczące obsługi linku

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

• Replikacja transakcyjna w ramach SQL Managed Instance
• Usługa ponownego odtwarzania dziennika (LRS)