Extend an Always On availability group to Azure SQL Managed Instance (preview)

Dotyczy:Azure SQL Managed Instance

Ten artykuł uczy, jak rozszerzyć grupę dostępności Always On o wiele baz danych pomiędzy SQL Server a Azure SQL Managed Instance za pomocą linku Managed Instance, korzystając z SQL Server Management Studio (SSMS), PowerShell lub Azure CLI.

Ten artykuł opisuje tryb łącza z wieloma bazami danych, który replikuje wszystkie bazy danych w grupie dostępności za pomocą jednego linku. Tryb łącza z jedną bazą danych replikuje jedną bazę danych na łącze.

Przegląd

Gdy rozszerzasz grupę dostępności Always On pomiędzy SQL Server a Azure SQL Managed Instance, tworzysz link, który replikuje wiele baz danych w grupie dostępności do docelowej repliki. Link wykorzystuje rozproszoną grupę dostępności do replikacji zmian w czasie niemal rzeczywistym od obecnej repliki pierwotnej do kopii bazy danych tylko do odczytu na replice wtórnej. Zapewnia to, że kopie tylko do odczytu na drugiej stronie pozostają up-todacie głównej.

Możesz użyć istniejącej grupy dostępności lub zacząć od samodzielnych baz danych. Gdy wybierasz samodzielne bazy danych w SSMS, kreator tworzy grupę dostępności pojedynczego węzła na początkowym punkcie podstawowym i replikuje wybrane bazy danych przez jedno łącze.

Podstawowym może być SQL Server lub Azure SQL Managed Instance. Utworzenie linku z SQL Managed Instance wymaga SQL Server 2022 lub SQL Server 2025 z wymaganą skumulowaną aktualizacją oraz odpowiadającą polityką aktualizacji SQL Managed Instance. Przykłady tworzenia w tym artykule zaczynają się od SQL Server. Nie przeprowadzają procesu tworzenia z SQL Managed Instance. Wspierane jest przełączanie awaryjne z odwróceniem ról między SQL Server a Azure SQL Managed Instance dla instancji skonfigurowanych z odpowiadającymi politykami aktualizacji.

Wspieralność

Poniższe wymagania dotyczą rozszerzenia grupy dostępności poprzez połączenie z wieloma bazami danych podczas podglądu. SQL Server jest obsługiwany zarówno na Windows, jak i Linux. Musisz zainstalować wymaganą kumulatywną aktualizację (CU). Wcześniejsze wersje nie wspierały tej funkcji.

Rozważ następujące kwestie:

• Edycja standardowa nie jest obsługiwana, ponieważ podstawowe grupy dostępności obsługują tylko jedną bazę danych.
• SQL Server 2019 i wcześniejsze wersje nie są wspierane w trybie linku z wieloma bazami danych, ponieważ brakuje im wymaganej technologii wprowadzonej w SQL Server 2022.
• Aby utworzyć link z SQL Managed Instance lub odwrócić role z powrotem do SQL Server, Twój SQL managed instance musi korzystać z polityki aktualizacji odpowiadającej wersji SQL Server. Dla jednokierunkowej replikacji i przełączania z SQL Server, polityka aktualizacji docelowych musi odpowiadać lub być wyższa niż wersja SQL Server.
  • SQL Server 2022 obsługuje replikację do instancji skonfigurowanych według polityk SQL Server 2022, SQL Server 2025 oraz Always-up-to-date.
  • SQL Server 2025 obsługuje replikację do instancji skonfigurowanych według polityk SQL Server 2025 i Always-up-to-date, ale nie SQL Server 2022. Nie możesz replikować danych ani wrócić do SQL Server po cutoverze, jeśli polityki się nie zgadzają.

Aby poznać wersje i edycje SQL Server obsługujące linki z jedną bazą danych, zobacz wsparcie wersji Managed Instance link.

Wymagania wstępne

Aby rozszerzyć swoją grupę dostępności między SQL Server a Azure SQL Managed Instance, potrzebujesz następujących warunków wstępnych:

• Aktywna subskrypcja platformy Azure. Jeśli jej nie masz, utwórz bezpłatne konto.
• Obsługiwana wersja i edycja SQL Server z zainstalowaną wymaganą aktualizacją usługi. Możesz użyć istniejącej grupy dostępności Always On lub samodzielnych baz danych, które SSMS umieszcza w nowej grupie dostępności pojedynczego węzła. Grupy dostępności zamkniętej nie są obsługiwane.
• Azure SQL Managed Instance z polityką aktualizacji odpowiednią dla Twojego scenariusza. Polityka dopasowania jest wymagana, gdy SQL Managed Instance jest podstawowym lub przy odwróceniu roli. Zacznij, jeśli nie masz zarządzanej instancji SQL.
• SQL Server Management Studio (SSMS) 22.10.2 lub nowszy.
• Do konfiguracji skryptowej Azure PowerShell z modułem Az w wersji 16.3.0 lub nowszej oraz Az.SQL w wersji 7.1.0 lub nowzej, albo Azure CLI w wersji 2.90.0 lub nowzej. Możesz również użyć usługi Azure Cloud Shell. Sprawdź, czy zainstalowane moduły lub CLI spełniają te wymagania wersji.
• Prawidłowo przygotowane środowisko.
• Dla grupy dostępności z wieloma węzłami skonfigurowany nasłuchiwacz grupy dostępności. Używaj adresu IP słuchacza podczas konfiguracji łącza, a nie adresu IP pojedynczej repliki SQL Server. Użycie nasłuchiwacza pozwala łączu działać dalej po awaryjnym przejściu grupy dostępności lokalnej.
• Brak istniejących linków na żadnej repliki SQL Server, gdy włączysz tryb łącza z wieloma bazami danych. Zanim zaczniesz, usuń wszystkie linki korzystające ze starszego trybu pojedynczej bazy danych.
• Wystarczająca dostępna pojemność bazy danych i miejsce na docelowej instancji zarządzanej dla wszystkich baz danych w Twojej grupie dostępności. Przejrzyj limity zasobów.

Permissions

W przypadku programu SQL Server potrzebne są uprawnienia administratora systemu .

W przypadku usługi Azure SQL Managed Instance musisz być członkiem roli SQL Managed Instance Contributor lub mieć następujące uprawnienia roli niestandardowej:

Włącz tryb łącza z wieloma bazami danych

Obsługa trybu łącza z wieloma bazami danych jest domyślnie wyłączona podczas podglądu. Użyj sys.sp_multidb_milink wbudowanej procedury przechowywanej, aby włączyć ją na każdej repliki SQL Server w grupie dostępności lub na instancji SQL Server, gdzie planujesz utworzyć grupę pojedynczych węzłów.

Uruchom następujące polecenie na każdej repliki SQL Server, aby włączyć tryb łącza z wieloma bazami danych:

EXEC sys.sp_multidb_milink 1;

To ustawienie pozostaje przy wszystkich restartach SQL Server, więc wystarczy je włączyć tylko raz na każdej repliki.

Aby sprawdzić ustawienie, uruchom procedurę przechowywaną bez parametru na każdej repliki. Zwraca się 1 po włączeniu i 0 wyłączeniu:

EXEC sys.sp_multidb_milink;

Jeśli procedura przechowywana nie jest dostępna, sprawdź, czy replika ma obsługiwaną wersję SQL Server oraz zainstalowaną skumulowaną aktualizację.

Aby wyłączyć tryb łącza z wieloma bazami danych, najpierw usuń wszystkie linki, a następnie wykonaj następujące polecenie na każdej repliki SQL Server:

EXEC sys.sp_multidb_milink 0;

Przygotuj bazy danych grup dostępności

Ustaw każdą bazę SQL Server, którą chcesz replikować, na pełny model odzyskiwania, a następnie stwórz pełną kopię zapasową. Zarówno istniejące bazy danych grup dostępności, jak i samodzielne bazy danych wymagają takiego przygotowania. Użyj procedury kopii zapasowej SSMS w przewodniku konfiguracyjnym łącza.

W przypadku baz danych SQL Server należy przenieść certyfikat TDE do SQL Managed Instance. W przypadku szyfrowanych baz danych SQL Managed Instance powiązanych z SQL Server, użyj klucza zarządzanego przez klienta, dostępnego dla docelowego SQL Server. Przejrzyj przygotowania TDE do linku wymagań w każdym kierunku.

Link replikuje wszystkie bazy danych z wybranej grupy dostępności. Nie możesz wybrać podzbioru, więc sprawdź dostępną pojemność docelowej instancji SQL zarządzanej przed utworzeniem linku. Miejsce docelowe nie może zawierać baz danych o tych samych nazwach, co te, które chcesz replikować. Istniejące bazy danych o różnych nazwach są dozwolone, pod warunkiem ograniczenia pojemności instancji.

Link obsługuje tylko replikowanie baz danych użytkowników. Replikacja systemowych baz danych nie jest obsługiwana. Aby zreplikować obiekty na poziomie wystąpienia przechowywane w master lub msdb, utwórz ich skrypty i uruchom skrypty T-SQL w wystąpieniu docelowym.

Konfiguruj słuchacz i certyfikaty

W przypadku grupy dostępności wielu węzłów używaj adresu IP słuchacza podczas konfiguracji łącza, zarówno w SSMS, jak i w skryptach. Słuchacz kieruje połączeniami do aktualnej repliki podstawowej. Nie używaj adresu IP pojedynczego repliki SQL Server jako punktu końcowego linku. Bez słuchacza połączenie nie działa dalej po awaryjnym przejściu grupy dostępności lokalnej. Dla grupy dostępności pojedynczego węzła, w tym tej stworzonej przez kreator SSMS dla samodzielnych baz danych, użyj punktu końcowego IP tej instancji SQL Server.

Kreator SSMS wymienia certyfikaty pomiędzy Azure SQL Managed Instance a tylko obecną podstawową repliką SQL Server. Nie konfiguruje zaufania certyfikatów na pozostałych replikach SQL Server. Musisz ręcznie skopiować i skonfigurować wymagane certyfikaty na każdej innej repliki SQL Server, aby połączenie mogło działać po awaryjnym przejściu lokalnej grupy dostępności. Ten krok ręczny dotyczy zarówno konfiguracji SSMS, jak i skryptowej. Przegląd Ustalenie zaufania między instancjami w ramach kroków wymiany certyfikatów.

Przygotuj się na skryptowe tworzenie linków

Używaj SSMS do zalecanego doświadczenia z konfiguracją. Kreator automatyzuje wiele kroków konfiguracji. Jeśli nie potrzebujesz automatyzacji skryptowej, pomiń tę sekcję i przejdź do zakładki SSMS w grupie Rozszerzenie dostępności.

Skryptowa konfiguracja to zaawansowana opcja, która wymaga doświadczenia w konfigurowaniu grup dostępności, punktów końcowych i zaufania do certyfikatów. Wykonuj te kroki tylko wtedy, gdy używasz PowerShell lub Azure CLI z SQL Server jako podstawowym narzędziem.

Lista kontrolna obejmuje zarówno istniejące grupy dostępności, jak i samodzielne bazy danych. Po przygotowaniu baz danych, zaufania i punktów końcowych, ponownie wykorzystaj istniejącą grupę dostępności lub utwórz ją w kroku 4. Następnie stwórz grupę dostępności rozproszonej. Polecenia PowerShell i Azure CLI tworzące link nie tworzą dla Ciebie grupy dostępności.

Aby uzyskać skrypt dostosowany do Twojego środowiska, użyj kreatora linków SSMS i wybierz Script na stronie Summary . Przejrzyj wygenerowany skrypt i wykonaj go osobno.

1. Włącz tryb łącza z wieloma bazami danych na każdej repliki SQL Server lub na samodzielnej instancji SQL Server i przygotuj bazy danych.
2. Ustanów zaufanie między instancjami. Wykonaj kroki tworzenia certyfikatów, wymiany klucza publicznego, importu certyfikatów root oraz walidacji łańcucha certyfikatów. Dla grupy wielowęzłowej należy zastosować wymagania certyfikatu do każdej repliki SQL Server, nie tylko do obecnej podstawowej.
3. Zabezpiecz punkt końcowy do mirroringu bazy danych. Jeśli Twoja grupa dostępności ma już punkt końcowy, użyj Alter istniejącego punktu zamiast tworzyć nowy. Zachowaj skonfigurowany port końcowy dla polecenia tworzenia linku.
4. Przygotuj grupę dostępności. Jeśli masz już grupę dostępności zawierającą wszystkie bazy, które chcesz replikować, użyj jej ponownie i pomiń tworzenie nowej grupy. Jeśli zaczynasz od samodzielnych baz danych, najpierw stwórz grupę dostępności na SQL Server. W zakładce podstawowej SQL Server użyj przykładu pojedynczego węzła CREATE AVAILABILITY GROUP z CLUSTER_TYPE = NONE, ale zastąp FOR DATABASE [<DatabaseName>] go pełną listą baz danych, np. FOR DATABASE [DB01], [DB03], [DB05], [DB07]. Ustaw <AGNameOnSQLServer> nazwę, którą chcesz nadać nowej grupie. Uruchom ten skrypt przed kontynuacją tworzenia grup dystrybuowanej dostępności. Nie uruchamiaj tego na istniejącej grupie ani nie zmieniaj konfiguracji klastra w istniejącej grupie.
5. Stwórz grupę dostępności rozproszonej na SQL Server. Użyj podstawowej karty SQL Server i zacznij od instrukcji tworzenia grupy dostępności rozproszonej. Ustaw <AGNameOnSQLServer> grupę dostępności, którą ponownie użyłeś lub stworzyłeś w poprzednim kroku. Dla grupy wielowęzłowej używamy adresu IP słuchacza dla <SQLServerIP>. Dla grupy z jednym węzłem użyj punktu końcowego instancji SQL Server. Zachowaj <DAGName> jako nazwę linku oraz <AGNameOnSQLMI> jako nazwę grupy dostępności zarządzanej instancji dla polecenia tworzenia poniżej.
6. Sprawdź grupy dostępności na SQL Server. Potwierdź, że zarówno grupa dostępności Always On, jak i grupa dystrybucyjnej dostępności są obecne. Następnie wróć do Rozszerzenie grupy dostępności, wybierz PowerShell lub Azure CLI i uruchom polecenie tworzenia wielu baz danych z tego artykułu zamiast polecenia pojedynczej bazy danych z innego przewodnika.

Rozszerzenie grupy dostępności

Aby zachować rekordy logów potrzebne do seedingu, zaleca się włączenie flagi trace 12381 w obsługiwanych wersjach SQL Server przed utworzeniem połączeń, zwłaszcza dla dużych baz danych lub wielu baz danych w trybie linków wielobazowych. Jednak ta flaga nie jest wymagana, a istnieją alternatywne środki łagodzące, wymienione w błędzie Troubleshoot 1412. Po włączeniu flagi kopie zapasowe logów mogą być kontynuowane, ale zapisy logów zachowane nie są wielokrotnie użyteczne. Monitoruj wzrost logów SQL Server i wolną przestrzeń na dysku, a flagę wyłącz zaraz po zakończeniu seedingu dla wszystkich tworzonych linków.

Użyj SSMS do automatyzacji tworzenia łączy lub wybierz PowerShell lub Azure CLI do zaawansowanej konfiguracji skryptowej. Poniższe przykłady wykorzystują SQL Server jako podstawowy serwer podstawowy. Możesz też zacząć od SQL Managed Instance z odpowiednią polityką aktualizacji, ale ten proces tworzenia nie jest tu omówiony.

W przypadku konfiguracji skryptowej wykonaj skryptowane kroki konfiguracyjne, aby ponownie użyć lub utworzyć grupę dostępności zawierającą wszystkie bazy danych, które chcesz replikować, a następnie utwórz grupę dostępności rozproszonej przed uruchomieniem polecenia PowerShell lub Azure CLI creation command. Alternatywnie, jeśli zaczynasz od samodzielnych baz danych, procedura SSMS w tej sekcji automatycznie tworzy grupę dostępności pojedynczego węzła jako część konfiguracji łącza.

W trybie łącza z wieloma bazami danych wyraźnie określ MultiDatabase w skryptach i podaj wszystkie nazwy baz danych w grupie dostępności. PowerShell domyślnie używa funkcji SingleDatabase if -LinkMode jest pomijany. Zastosowanie -LinkMode MultiDatabase w PowerShell lub --link-mode MultiDatabase Azure CLI.

Update-Module -Name Az
Update-Module -Name Az.Sql

Get-InstalledModule -Name Az | Select-Object Name, Version
Get-InstalledModule -Name Az.Sql | Select-Object Name, Version

# Run in Azure Cloud Shell and select PowerShell.
$ManagedInstanceName = "<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
$DAGName = "<DAGName>"

# Enter the availability group names from the setup steps.
$AGNameOnSQLServer = "<AGNameOnSQLServer>"
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Include every database in the availability group.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07")

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
$SQLEndpointIP = "<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
$EndpointPort = "<EndpointPort>"

$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
$SQLPartnerEndpoint = "TCP://" + $SQLEndpointIP + ":" + $EndpointPort

# Create the multi-database link with SQL Managed Instance as the secondary.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI -Database $DatabaseNames -PartnerEndpoint $SQLPartnerEndpoint -InstanceLinkRole "Secondary" -FailoverMode "Manual" -SeedingMode "Automatic" -LinkMode "MultiDatabase"

# Run in Azure Cloud Shell and select Bash.
ResourceGroupName="<ResourceGroupName>"
ManagedInstanceName="<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
DAGName="<DAGName>"

# Enter the availability group names from the setup steps.
AGNameOnSQLServer="<AGNameOnSQLServer>"
AGNameOnSQLMI="<AGNameOnSQLMI>"

# Include every database in the availability group.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07}]"

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
SQLEndpointIP="<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
EndpointPort="<EndpointPort>"

SQLPartnerEndpoint="TCP://${SQLEndpointIP}:${EndpointPort}"

# Create the multi-database link with SQL Managed Instance as the secondary.
az sql mi link create --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --partner-availability-group-name "$AGNameOnSQLServer" --instance-availability-group-name "$AGNameOnSQLMI" --databases "$DatabaseNames" --partner-endpoint "$SQLPartnerEndpoint" --instance-link-role Secondary --failover-mode Manual --seeding-mode Automatic --link-mode MultiDatabase

Weryfikuj replikację

Po utworzeniu linku lub dodaniu baz danych, dane replikują się z obecnej podstawowej do obecnej wtórnej repliki. Podstawowym może być SQL Server lub Azure SQL Managed Instance. Po odwróceniu ról dane replikują się w przeciwnym kierunku. W zależności od wielkości bazy danych i prędkości sieci, każda baza może początkowo znajdować się w stanie Przywracania na wtórnej replice. Po zakończeniu początkowego rozmieszczania baza danych zostanie przywrócona do repliki pomocniczej i gotowa do obsługi obciążeń tylko do odczytu.

Na obu replikach użyj Eksplorator obiektów w SSMS, aby zobaczyć stan Synchronizowany każdej replikowanej bazy danych. Rozwiń Always OnHigh Availability i Available Groups , aby zobaczyć rozproszoną grupę dostępności utworzoną dla linku.

Gdy SQL Server jest podstawowy, możesz kontynuować kopie zapasowe logów transakcyjnych podczas seedingu, jeśli flaga trace 12381 jest włączona w obsługiwanej kompilacji. Jeśli wstrzymasz kopie zapasowe logów, aby zapobiec przedwczesnemu obcięciu, wznow je po zakończeniu początkowego seedingu. Dla każdej bazy danych bez harmonogramu kopii zapasowej logów wykonaj pierwszą kopię zapasową dziennika transakcyjnego dopiero po zakończeniu początkowego seedingu, a nie podczas seedingu. Po zakończeniu seedingu wszystkich tworzonych linków wyłącz flagę, jeśli ją włączyłeś, i regularnie wykonuj kopie zapasowe logów transakcyjnych SQL Server, podczas gdy SQL Server pozostaje podstawowy. Gdy Azure SQL Managed Instance jest podstawowym, automatycznie wykonuje kopie zapasowe dzienników transakcyjnych. Nie musisz robić ręcznych kopii zapasowych logów SQL Server dla tych baz danych, podczas gdy SQL Server jest drugorzędny.

Przedwczesne obcięcie logów podczas seedingu może powodować błędy 1408 i 1412 w logu błędów SQL Managed Instance. W buildach, które to obsługują, flaga 12381 trace zapobiega temu obcięciu. Wyłącz go po zakończeniu seedingu dla wszystkich tworzonych linków i monitoruj wykorzystanie dziennika transakcji, tempo wzrostu oraz wolne miejsce na dysku, gdy jest włączony. Kopie zapasowe logów mogą być kontynuowane, dopóki wymagane zapisy pozostają przechowywane. To retencja nie zastępuje regularnych kopii zapasowych logów po seedingu. Zobacz Zapobiegaj przedwczesnemu obcinaniu logarytmu.

Dodawanie baz danych

Użyj kreatora SSMS, aby dodać bazy danych z obecnej podstawowej bazy, czy to SQL Server, czy SQL Managed Instance. Czarodziej automatyzuje wymagane zmiany. Dla zaawansowanej automatyzacji użyj PowerShell lub Azure CLI. Dodanie bazy danych to pojedyncza operacja po stronie głównej.

Przed dodaniem baz danych sprawdź, czy istniejące łącze korzysta z trybu połączenia z wieloma bazami danych oraz że cel ma wystarczającą dostępną pojemność i miejsce przechowywania, bez istniejących nazw baz danych kolidujących z nowymi bazami. Gdy SQL Server jest podstawowy, ustaw każdą nową bazę danych, która nie znajduje się jeszcze w grupie dostępności, na pełny model odzyskiwania i stwórz pełną kopię zapasową, korzystając z procedury backupu SSMS.

Dodaj bazy danych za pomocą SSMS

Użyj kreatora Add Database to Azure SQL Managed Instance Link, aby dodać bazy danych do istniejącego linku z wieloma bazami danych:

1. Połącz się z aktualnym głównym serwerem w SSMS. W Eksplorator obiektów rozwiń Always On Grupy Wysokiej Dostępności i Dostępności.

2. Kliknij prawym przyciskiem myszy na grupę dostępności rozproszonej dla swojego linku, najedź kursorem na link Azure SQL Managed Instance i wybierz Dodaj bazę danych....

   

3. Przejdź przez Wprowadzenie i logowanie do Azure, a następnie wybierz link do wielu baz danych na stronie Wybierz link.

4. Na stronie Wybierz bazy danych wybierz bazy danych, które chcesz dodać. Możesz dodawać tylko bazy danych w stanie Gotowy . Bazy danych już znajdujące się w linku są oznaczone jako Już część wybranego linku. Rozwiąż wszelkie kwestie kwalifikacyjne przed kontynuowaniem.

   

5. Pełna weryfikacja i podsumowanie recenzji. Wybierz Zakończ, aby wykonać zmianę, lub wybierz Skrypt , aby wygenerować skrypt bez jego uruchomienia, aby móc go osobno przejrzeć, dostosować i uruchomić. Jeśli wykonasz zmianę w kreatorze, przejrzyj wyniki przed zamknięciem.

Dodaj bazy danych za pomocą skryptów

Dodaj na obecnym wyborze podstawowym. Stosuj się do instrukcji na ten przypadek.

Gdy SQL Server jest podstawowym

Użyj T-SQL, aby dodać każdą bazę danych do grupy dostępności. Link propaguje dodatek do SQL Managed Instance. Nie są potrzebne dalsze działania dotyczące SQL Managed Instance. Nie uruchamiaj aktualizacji PowerShell ani Azure CLI dla tego dodatku.

Gdy SQL Managed Instance jest podstawowym

Użyj PowerShell lub Azure CLI, aby zaktualizować link w SQL Managed Instance. Link automatycznie propaguje dodane bazy danych do grupy dostępności. Nie jest wymagany żaden osobny krok w SQL Server. Dostarcz pełny zamierzony skład, w tym wszystkie istniejące, które chcesz zachować, oraz nowe bazy. Dostarczona lista zastępuje obecne składy. Pominięcie bazy danych usuwa ją z członkostwa linku.

Na przykład, gdy DB09 link już zawiera DB01, DB03, DB05, i DB07, zachowuje te cztery nazwy z listy oraz dodaje DB09 je do listy. Zastąp nazwy zasobów i baz danych swoimi wartościami.

# Include every existing database to retain and each new database to add.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include every existing database to retain and each new database to add.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Powtórz kroki weryfikacji replikacji dla każdej nowo dodanej bazy danych. Wykonuj ręczne kroki kopii zapasowej logów tylko wtedy, gdy SQL Server jest podstawowy.

Usuwanie baz danych

Użyj kreatora SSMS na obecnym głównym, aby zautomatyzować usuwanie po obu stronach. Usunięcie bazy danych wymaga jej usunięcia z linku w SQL Managed Instance oraz z grupy dostępności. Usunięcie go tylko z jednej strony nie kończy operacji.

Usuń bazy danych za pomocą SSMS

Następujące kroki mają zastosowanie zarówno w SQL Server, jak i SQL Managed Instance:

1. Połącz się z aktualnym głównym serwerem w SSMS. W Eksplorator obiektów rozwiń Always On Grupy Wysokiej Dostępności i Dostępności.

2. Kliknij prawym przyciskiem myszy na grupę dostępności rozproszonej, aby uzyskać link, najedź kursorem na link Azure SQL Managed Instance i wybierz Usuń bazę danych....

   

3. W kreatorze Remove Database from Azure SQL Managed Instance Link przejdź przez Introduction i Azure Login, a następnie wybierz link w Wybierz Link.

4. W Wybierz bazy danych wybierz bazy danych do usunięcia. Na przykład wybierz DB05 , aby usunąć go z linku, a następnie wybierz Następny.

   

5. Zakończ weryfikację, przejrzyj podsumowanie i wybierz Zakończ, aby wykonać usuwanie lub Skrypt , aby najpierw przejrzeć wygenerowane polecenia. Sprawdź wyniki po pomyślnym ukończeniu przed zamknięciem czarodzieja.

Usuń bazy danych ze skryptami

Usuń bazy danych w obu instancjach. Obecny główny system decyduje, którą instancję zaktualizować jako pierwszą.

Przykłady PowerShell i Azure CLI wykorzystują następujące zmienne:

Gdy SQL Server jest podstawowym

1. Użyj T-SQL, aby usunąć bazy danych z grupy dostępności.
2. Użyj PowerShell lub Azure CLI, aby usunąć bazy danych z linku w SQL Managed Instance, jak pokazano w tej sekcji.

W kroku SQL Managed Instance dostarcz pełną listę baz danych do zachowania, pomijając tylko te, które chcesz usunąć. Na przykład, jeśli link zawiera DB01, DB03, DB05, DB07i , , DB09, ,DB05 Zastąp nazwy zasobów i baz danych swoimi wartościami.

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Gdy SQL Managed Instance jest podstawowym

1. Użyj PowerShell lub Azure CLI, aby usunąć bazy danych z linku w SQL Managed Instance, jak pokazano w tej sekcji.
2. Użyj T-SQL na SQL Server, aby usunąć bazy danych z grupy dostępności. Usunięcie nie jest zakończone, dopóki nie ukończysz tego etapu.

W kroku SQL Managed Instance dostarcz pełną listę baz danych do zachowania, pomijając tylko te, które chcesz usunąć. Na przykład, jeśli link zawiera DB01, DB03, DB05, DB07i , , DB09, ,DB05 Zastąp nazwy zasobów i baz danych swoimi wartościami.

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Potwierdź, że usunięte bazy danych nie należą już do linku ani do grupy dostępności. Usunięcie bazy danych z replikacji to nie to samo, co usunięcie jej zachowanej kopii. Przejrzyj bazy danych w obu przypadkach, zanim zdecydujesz, czy usunąć kopię, której już nie potrzebujesz.

Failover lub cut over do Azure

Wykorzystaj istniejące procedury awaryjne w SSMS lub skryptach, aby odwrócić role między SQL Server a Azure SQL Managed Instance. Odwrócenie ról wymaga, aby zarządzana instancja SQL korzystała z polityki aktualizacji odpowiadającej wersji SQL Server. Aby replikować w jedną stronę i przełączyć się na Azure SQL Managed Instance, polityka aktualizacji musi odpowiadać lub być wyższa niż wersja SQL Server. Nie możesz replikować danych ani wrócić do SQL Server, jeśli polityki się nie zgadzają. Przejrzyj wspierane kombinacje. Aby uzyskać wskazówki dotyczące migracji i przełączania się, zobacz Migruj z linkem.

Monitorowanie replikacji i rozwiązywanie problemów z jej replikacją

Użyj następujących dynamicznych widoków zarządzania (DMV) oraz widoku katalogu w SQL Server, aby sprawdzić główną grupę dostępności, łączność replik oraz stan replikacji każdej bazy danych:

SELECT * FROM sys.availability_groups;
SELECT * FROM sys.dm_hadr_availability_replica_states;
SELECT * FROM sys.dm_hadr_database_replica_states;
SELECT * FROM sys.dm_hadr_internal_availability_groups;
SELECT * FROM sys.dm_hadr_internal_availability_replicas;

Jeśli wewnętrzne DMV replikacyjne nie są dostępne lub wykonywanie sys.sp_multidb_milink procedur przechowywanych zgłasza, że nie są dostępne, zweryfikowaj zainstalowaną wersję SQL Server i skumulowaną aktualizację tej repliki. Aby uzyskać ogólne rozwiązania problemów z łącznością i replikacją, zobacz link Troubleshoot the Managed Instance.

Ograniczenia

Rozważ następujące ograniczenia przy rozszerzaniu grupy dostępności za pomocą linku z wieloma bazami danych:

• Nazwy linków muszą być używane małymi literami. Dozwolone są myślniki, ale imię nie może się zaczynać ani kończyć na łączniku.
• Nie cofaj żadnej repliki SQL Server poniżej SQL Server 2022 CU27 lub SQL Server 2025 CU9, w zależności od tego, gdy link w trybie wielu baz danych jest aktywny. Obniżenie poziomu poniżej wymaganego CU może powodować nieprzewidywalne problemy nawet bez awaryjnego przełączania.
• Grupy dostępności zamkniętej nie są obsługiwane.
• Linki pojedynczej bazy danych i łącza wielobazowe nie mogą współistnieć na tej samej instancji SQL Server.
• Nie możesz zmienić trybu linku na miejscu. Aby przełączać się między trybami łącza z jedną bazą danych a wieloma bazami danych, usuń wszystkie istniejące łącza, zmień tryb na każdej repliki SQL Server, a następnie odtworz linki w nowym trybie.
• Gdy tworzysz link do istniejącej grupy dostępności, wszystkie bazy danych w tej grupie muszą zostać zreplikowane. Nie możesz wybrać tylko podzbioru baz danych z tej grupy.
• Pozostała pojemność bazy danych na docelowej instancji SQL zarządzanej ogranicza liczbę baz danych, które możesz replikować. Uniwersalne i biznesowe wsparcie do 100 baz danych na instancję, a Next-gen General Purpose obsługuje do 500. Istniejące bazy danych wliczają się do tych limitów. Na przykład instancja z limitem 100 baz danych i 10 istniejącymi bazami danych ma pojemność na 90 dodatkowych baz danych. Więcej informacji można znaleźć w artykule o ograniczeniach zasobów.
• Dodanie baz danych do grupy dostępności poza dostępną pojemnością docelowej SQL managed instance może się powiodować na SQL Server, ale replikacja do SQL Managed Instance nie powiodła się. Ten warunek może pozostawić link w stanie niespójnym, co wymaga ręcznego usunięcia niereplikowanych baz danych z grupy dostępności.
• Dodawanie baz danych jest propagowane przez ten link, ale usunięcie bazy danych po jednej stronie nie usuwa automatycznie jej z drugiej. Jeśli usuniesz bazę danych z grupy dostępności, jej kopia pozostaje w SQL Managed Instance. Jeśli usuniesz bazę danych z linku w SQL Managed Instance, baza danych pozostaje w grupie dostępności bez replikacji przez link i wymaga ręcznego czyszczenia.
• Dodając bazy danych do istniejącego łącza przez SSMS, można dodawać tylko bazy danych w stanie Gotowości . Nie możesz dodawać baz danych należących do innej grupy dostępności lub mających nazwę, która już istnieje na miejscu docelowym.

Treści powiązane

• Omówienie linku Managed Instance
• Przygotowywanie środowiska na potrzeby funkcji łącza
• Konfigurowanie linku za pomocą programu SSMS
• Najlepsze rozwiązania dotyczące obsługi linku
• Rozwiązywanie problemów z linkiem