Rozszerz grupę dostępności Always On o usługę Azure SQL Managed Instance (wersja zapoznawcza)

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. Połączenie wykorzystuje rozproszoną grupę dostępności do replikowania zmian w czasie niemal rzeczywistym z bieżącej repliki podstawowej do kopii bazy danych przeznaczonych tylko do odczytu na replice wtórnej. Zapewnia to, że kopie tylko do odczytu na serwerze pomocniczym pozostają aktualne względem serwera głównego.

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 poziomu usługi SQL Managed Instance wymaga programu SQL Server 2022 lub SQL Server 2025 z wymaganą aktualizacją zbiorczą oraz odpowiedniej zasady aktualizacji usługi SQL Managed Instance. Przykłady tworzenia w tym artykule zaczynają się od SQL Server. Nie przeprowadzają procesu tworzenia z SQL Managed Instance. Przełączanie awaryjne z odwróceniem ról między SQL Server a usługą Azure SQL Managed Instance jest obsługiwane w przypadku instancji skonfigurowanych ze zgodnymi zasadami 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 wystąpienia zarządzanego SQL lub przywrócić role z powrotem do programu SQL Server, wystąpienie zarządzane SQL musi korzystać z zasad aktualizacji odpowiadających wersji programu SQL Server. W przypadku replikacji jednokierunkowej i przełączenia z programu SQL Server docelowa polityka aktualizacji musi być zgodna z wersją programu SQL Server lub nowsza.
  • 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żna replikować danych ani przełączyć się z powrotem na SQL Server po przełączeniu, jeśli zasady nie są zgodne.

Informacje o wersjach i edycjach programu SQL Server obsługujących połączenia z pojedynczą bazą danych można znaleźć w artykule Obsługiwane wersje usługi 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. Zasada zgodności jest wymagana, gdy SQL Managed Instance jest początkową instancją podstawową lub w przypadku odwrócenia ról. 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.
• W przypadku wielowęzłowej grupy dostępności — 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 połączeniu nadal działać po awaryjnym przełączeniu lokalnej grupy dostępności.
• 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 wbudowanej procedury składowanej sys.sp_multidb_milink, aby włączyć tę funkcję na każdej replice SQL Server w grupie dostępności lub na instancji SQL Server, w której planujesz utworzyć grupę jednowęzłową.

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 w każdej replice. Zwraca 1 po włączeniu i 0 po 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 przygotowanie TDE dla łącza pod kątem 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 pojedynczej repliki SQL Server jako punktu końcowego partnera łącza. Bez nasłuchiwacza połączenie przestaje działać po przełączeniu awaryjnym lokalnej grupy dostępności. W przypadku jednowęzłowej grupy dostępności, w tym utworzonej przez kreatora SSMS dla samodzielnych baz danych, użyj punktu końcowego IP tej instancji programu SQL Server.

Kreator SSMS wymienia certyfikaty między usługą Azure SQL Managed Instance i wyłącznie z bieżącą repliką podstawową programu SQL Server. Nie konfiguruje zaufania certyfikatów na pozostałych replikach SQL Server. Musisz ręcznie skopiować i skonfigurować wymagane certyfikaty na wszystkich pozostałych replikach programu SQL Server, aby łącze mogło nadal działać po przełączeniu awaryjnym lokalnej grupy dostępności. Ten krok ręczny dotyczy zarówno konfiguracji SSMS, jak i skryptowej. Zapoznaj się z sekcją Nawiązywanie zaufania między instancjami, aby poznać kroki wymiany certyfikatów.

Przygotuj się na skryptowe tworzenie linków

Aby zapewnić zalecany sposób konfiguracji, użyj SSMS. 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 programu PowerShell i interfejsu wiersza polecenia platformy Azure służące do tworzenia linku nie tworzą automatycznie 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 Zmień istniejący punkt końcowy zamiast tworzyć kolejny. 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 kontynuowaniem tworzenia rozproszonej grupy 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 karty SQL Server initial primary i rozpocznij od instrukcji tworzenia rozproszonej grupy dostępności. 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 rozproszona grupa 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 flaga ta nie jest wymagana, a alternatywne obejścia opisano w Rozwiązywanie problemu z błędem 1412. Po włączeniu flagi tworzenie kopii zapasowych dziennika może być kontynuowane, ale zachowane rekordy dziennika nie stają się ponownie używalne. 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 początkowy 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 przyjmuje wartość SingleDatabase, jeśli parametr -LinkMode zostanie pominięty. Użyj -LinkMode MultiDatabase w PowerShell lub --link-mode MultiDatabase w 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ń węzły Always On — wysoka dostępność i Grupy dostępności, aby wyświetlić rozproszoną grupę dostępności utworzoną dla tego połączenia.

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 kompilacjach, które to obsługują, flaga śledzenia 12381 zapobiega temu obcinaniu. 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 bieżącego serwera podstawowego, niezależnie od tego, czy jest 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ń węzły Wysoka dostępność Always On i Grupy 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. Ukończ Weryfikację i przejrzyj Podsumowanie. 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

Uruchom dodawanie na bieżącym elemencie głównym. 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. Podaj docelowy pełny skład, w tym wszystkie istniejące bazy danych, które chcesz zachować, oraz nowe bazy danych. Dostarczona lista zastępuje obecne składy. Pominięcie bazy danych usuwa ją ze składu połączenia.

Na przykład, aby dodać DB09, gdy link zawiera już DB01, DB03, DB05 i DB07, zachowaj te cztery nazwy na liście i dodaj do niej również DB09. 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 bieżącym serwerze podstawowym, aby zautomatyzować proces usuwania 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

Poniższe kroki dotyczą zarówno przypadku, gdy podstawowy jest SQL Server, jak i przypadku, gdy podstawowe jest wystąpienie zarządzane SQL.

1. Połącz się z aktualnym głównym serwerem w SSMS. W Eksplorator obiektów rozwiń węzły Wysoka dostępność Always On i Grupy 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 strony Introduction i Azure Login, a następnie wybierz link na stronie Select 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. Przed zamknięciem kreatora sprawdź Wyniki, aby upewnić się, że operacja zakończyła się pomyślnie.

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 łącze zawiera DB01, DB03, DB05, DB07 i DB09, poniższe polecenie usuwa DB05 i zachowuje pozostałe cztery. 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, DB07 i DB09, poniższe polecenie usuwa DB05 i zachowuje pozostałe cztery. 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.

Przełącz awaryjnie lub przełącz na platformę Azure

Użyj istniejących procedur przełączania awaryjnego w programie SSMS lub w skryptach, aby odwrócić role między programem SQL Server a usługą 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. Łączniki są dozwolone, ale nazwa nie może zaczynać się ani kończyć łącznikiem.
• Nie obniżaj wersji żadnej repliki SQL Server poniżej SQL Server 2022 CU27 lub SQL Server 2025 CU9, zależnie od przypadku, gdy aktywne jest połączenie w trybie wielu baz danych. 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 bezpośrednio zmienić trybu linku. 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ć. Warstwy General Purpose i Business Critical obsługują 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