Migrowanie za pomocą linku — Azure SQL Managed Instance

Dotyczy:Azure SQL Managed Instance

W tym artykule przedstawiono migrowanie bazy danych SQL Server do Azure SQL Managed Instance przy użyciu linku Managed Instance.

Aby uzyskać szczegółowy przewodnik dotyczący migracji, zapoznaj się z Migrate to Azure SQL Managed Instance. Aby porównać narzędzia migracji, przejrzyj Compare LRS z linkiem Managed Instance.

Uwaga

Bezpośrednio za pośrednictwem portalu Azure możesz teraz migrować wystąpienie SQL Server obsługiwane przez Azure Arc do Azure SQL Managed Instance. Aby uzyskać więcej informacji, zobacz Migrate to Azure SQL Managed Instance.

Omówienie

Link Managed Instance umożliwia migrację z SQL Server hostowanego w dowolnym miejscu do Azure SQL Managed Instance. Link używa technologii Always On grupy dostępności, aby replikować zmiany niemal w czasie rzeczywistym z podstawowego wystąpienia SQL Server do pomocniczego wystąpienia SQL Managed Instance. Link zapewnia jedyną prawdziwą opcję migracji w trybie online między SQL Server a Azure SQL Managed Instance, ponieważ jedynym przestojem jest przełączenie do docelowego wystąpienia zarządzanego SQL.

Migracja za pomocą linku umożliwia:

  • Możliwość testowania obciążeń tylko do odczytu na SQL Managed Instance przed zakończeniem migracji do Azure.
  • Możliwość utrzymania linku i migracji tak długo, jak potrzebujesz — tygodnie, a nawet miesiące.
  • Replikacja danych niemal w czasie rzeczywistym, która zapewnia najszybszą dostępną replikację danych do Azure.
  • Migracja z minimalnym przestojem w porównaniu do innych dostępnych obecnie rozwiązań.
  • Natychmiastowe przełączenie do docelowej instancji zarządzanej SQL.
  • Możliwość migracji w dowolnym momencie, w którym wszystko będzie gotowe.
  • Możliwość migrowania pojedynczych lub wielu baz danych z jednego lub wielu wystąpień SQL Server do tych samych lub wielu wystąpień zarządzanych SQL w Azure.
  • Jedyna prawdziwa online migracja do poziomu usługi Krytyczny dla biznesu.

Uwaga

Chociaż można migrować tylko jedną bazę danych na połączenie, można ustanowić wiele połączeń z tego samego wystąpienia SQL Server do tej samej instancji zarządzanej SQL.

Zachowanie podczas przełączenia

Sposób przełączenia zależy od wersji programu SQL Server, z której przeprowadzasz migrację, oraz od zasad aktualizacji docelowego wystąpienia zarządzanego SQL:

  • W przypadku wersji od SQL Server 2016 do SQL Server 2019 przełączenie na usługę SQL Managed Instance powoduje usunięcie łącza.
  • W przypadku SQL Server 2022 lub nowszych wersji podczas przejścia do SQL Managed Instance można, w zależności od wyboru dokonanego podczas przełączania awaryjnego, usunąć łącze lub je zachować. Jeśli zdecydujesz się zachować link, a wystąpienie zarządzane programu SQL jest skonfigurowane z odpowiadającymi mu zasadami aktualizacji, możesz w razie potrzeby przeprowadzić migrację zwrotną do SQL Server.

W przypadku migracji usunięcie linku jest zalecaną opcją. Jeśli zdecydujesz się zachować link, ale później zdecydujesz się go usunąć, poczekaj, aż Azure ukończyć pierwszą pełną kopię zapasową bazy danych po przejściu w tryb failover przed usunięciem linku. Ten krok gwarantuje, że baza danych jest w dobrej kondycji i w pełni funkcjonalna w SQL Managed Instance. Pomaga również uniknąć rzadkiego znanego problemu, w którym baza danych może być tymczasowo niedostępna po ponownym uruchomieniu serwera, jeśli link zostanie usunięty zbyt wcześnie. Aby uzyskać więcej informacji, zobacz Baza danych jest niedostępna po ponownym uruchomieniu serwera po przełączeniu awaryjnym łącza MI.

Odwrócenie migracji

Migracja odwrotna do SQL Server z Azure SQL Managed Instance może być obsługiwana w zależności od zasad aktualizacji wystąpienia zarządzanego SQL. Przykład:

  • zasady aktualizacji SQL Server 2022: Bazy danych z wystąpień skonfigurowanych zgodnie z zasadami aktualizacji SQL Server 2022 można przywrócić do wystąpień SQL Server 2022.
  • Zasady aktualizacji SQL Server 2025: Bazy danych z wystąpień skonfigurowanych zgodnie z zasadami aktualizacji SQL Server 2025 można przywracać do wystąpień SQL Server 2025.
  • Polityka aktualizacji Always-up-to-date: Bazy danych z wystąpień skonfigurowanych przy użyciu zasady aktualizacji Always-up-to-date nie mogą być przywrócone do serwera SQL.

Jeśli źródłowa wersja SQL Server jest starsza niż SQL Server 2022 r., migracja odwrotna nie jest możliwa. Podczas migracji bazy danych do SQL Managed Instance następuje uaktualnienie wewnętrzne do nowszej wersji bazy danych, która nie jest zgodna z wcześniejszymi wersjami SQL Server. Zgodność bazy danych z migracją odwrotną jest dostępna tylko wtedy, gdy usługa SQL Managed Instance jest skonfigurowana zgodnie z odpowiednimi zasadami aktualizacji.

Wymagania wstępne

Aby użyć linku z Azure SQL Managed Instance do migracji, potrzebne są następujące wymagania wstępne:

Ocena i odnajdywanie

Po sprawdzeniu, czy środowisko źródłowe jest obsługiwane, zacznij od etapu przed migracją. Odkryj wszystkie istniejące źródła danych, oceń możliwości migracji i zidentyfikuj wszelkie problemy blokujące, które mogą uniemożliwić migrację. Przeskanuj sieć w fazie odkrywania, aby zidentyfikować wszystkie instancje i funkcje SQL Server używane przez organizację.

Aby odnaleźć źródła SQL w swoim środowisku, możesz użyć następujących narzędzi:

  • SQL Server włączone przez Azure Arc automatycznie generuje ocenę do migracji do Azure, upraszczając proces odkrywania i ocenę gotowości do migracji.
  • Azure Migrate w celu oceny przydatności migracji serwerów lokalnych, ustalania rozmiaru opartego na wydajności i określania szacowania kosztów na potrzeby uruchamiania ich w Azure.
  • Microsoft Assessment and Planning Toolkit (zestaw narzędzi MAP Toolkit) w celu oceny bieżącej infrastruktury IT. Zestaw narzędzi udostępnia zaawansowane narzędzie do tworzenia spisu, oceny i raportowania w celu uproszczenia procesu planowania migracji.

Po odnalezieniu źródeł danych należy ocenić wszystkie lokalne wystąpienia SQL Server, które można migrować do Azure SQL Managed Instance, w celu zidentyfikowania barier migracji lub problemów ze zgodnością.

Aby ocenić wystąpienie źródłowe SQL Server, możesz użyć oceny gotowości do migracji .

Aby uzyskać szczegółowe wskazówki, zapoznaj się z artykułem Przed migracją.

Utwórz wystąpienie docelowe

Po dokonaniu oceny istniejącego środowiska i ustaleniu odpowiedniej warstwy usługi i konfiguracji sprzętu dla docelowego wystąpienia zarządzanego SQL wdróż wystąpienie docelowe przy użyciu portalu Azure portalPowerShell lub Azure CLI.

Po utworzeniu docelowego zarządzanego wystąpienia SQL skonfiguruj połączenie między bazą danych na serwerze SQL Server a w zarządzanym wystąpieniu Azure SQL. Najpierw przygotuj środowisko, a następnie skonfiguruj link przy użyciu SQL Server Management Studio (SSMS) lub skryptów.

Sprawdzanie opóźnienia replikacji

Ważne jest, aby replika pomocnicza nadążyła za repliką podstawową przed przeprowadzeniem planowanego failoveru migracji. Planowane przejście w tryb failover może zakończyć się niepowodzeniem, jeżeli limit czasu zostanie przekroczony, a replika pomocnicza znacząco pozostaje w tyle za repliką podstawową.

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

Jeśli opóźnienie replikacji jest wysokie, poczekaj, aż replika pomocnicza dogoni replikę podstawową. Może być konieczne wykonanie dodatkowych kroków rozwiązywania problemów, jeśli opóźnienie będzie się powtarzać, takie jak wstrzymanie obciążeń w repliki podstawowej, zwiększenie przepływności sieci połączenia między dwoma wystąpieniami lub zwiększenie pojemności zasobów w repliki pomocniczej. Najprostszym sposobem na zatrzymanie obciążeń na głównej replikę SQL Server jest odcinanie połączeń aplikacyjnych do instancji.

Migrowanie wielu baz danych

Jeśli planujesz migrację wielu baz danych z wystąpień na tym samym serwerze, aby zapewnić optymalną wydajność i przewidywalność, zmigruj 8 baz danych na wystąpienie naraz. Jeśli na przykład masz 10 wystąpień z 32 połączonymi bazami danych, migruj 8 baz danych na raz z każdego wystąpienia, korzystając z planowanego przełączenia awaryjnego, i powtarzaj ten proces do czasu migracji wszystkich baz danych.

Synchronizacja danych i przełączenie systemu

Po ustanowieniu linku i gdy jesteś gotowy do migracji, wykonaj następujące kroki (zazwyczaj podczas okna serwisowego):

  1. Zatrzymaj obciążenie w podstawowej bazie danych SQL Server, aby pomocnicza baza danych SQL Managed Instance nadrobiła zaległości. Najprostszym sposobem na zatrzymanie obciążeń na głównej replikę SQL Server jest odcinanie połączeń aplikacyjnych do instancji.
  2. Sprawdź, czy wszystkie dane zostały przekazane do pomocniczej bazy danych w SQL Managed Instance. Sprawdź opóźnienie replikacji , aby upewnić się, że replika pomocnicza jest dogoniona z repliką podstawową.
  3. Wykonaj przełączanie awaryjne połączenia do pomocniczego wystąpienia zarządzanego SQL, wybierając Planowane przełączanie awaryjne.
  4. (Opcjonalnie) Zaznacz pole wyboru Usuń łącze po pomyślnym przejściu w tryb failover , aby upewnić się, że tryb failover jest jednym ze sposobów, a link zostanie usunięty.
  5. (Opcjonalnie) Jeśli korzystasz z obsługiwanej wersji SQL Server z odpowiadającą polityką aktualizacji SQL Managed Instance , możesz zachować link po przełączeniu w tryb failover, aby móc w razie potrzeby cofnąć migrację. Sprawdź sekcję cofnięcia migracji w celu uzyskania szczegółowych informacji o wersji.
  6. Przełączenie aplikacji w celu połączenia z punktem końcowym zarządzanego wystąpienia SQL.
  7. (Opcjonalnie) Jeśli nie zdecydujesz się usunąć łącza podczas przełączenia awaryjnego, możesz je usunąć po przełączeniu, gdy nie będzie już potrzebne.

Weryfikowanie migracji

Po przeniesieniu się do docelowego wystąpienia zarządzanego SQL monitoruj aplikację, przetestuj wydajność i rozwiąż wszelkie problemy.

Aby uzyskać szczegółowe informacje, zapoznaj się z tematem po migracji.

Znane problemy z migracją

Zapoznaj się z następującymi znanymi problemami związanymi z migracją za pomocą linku.

W rzadkich przypadkach baza danych może być tymczasowo niedostępna w usłudze SQL Managed Instance po ponownym uruchomieniu serwera po przełączeniu awaryjnym łącza. Ten znany problem występuje, gdy usuniesz połączenie, zanim platforma Azure ukończy tworzenie pełnej kopii zapasowej bazy danych po początkowym awaryjnym przełączeniu do usługi SQL Managed Instance.

Baza danych jest automatycznie odzyskiwane po interwencji Microsoft, ale odzyskiwanie może zająć trochę czasu.

Aby uniknąć tego problemu, nie usuwaj linku, dopóki pierwsza pełna kopia zapasowa nie zakończy się po przejściu w tryb failover z SQL Server do SQL Managed Instance. Aby uzyskać więcej informacji, zobacz Baza danych niedostępna po ponownym uruchomieniu serwera.

Niepowodzenia operacji przywracania po migracji do usługi SQL Managed Instance

W przypadku migracji bazy danych do Azure SQL Managed Instance z SQL Server 2019 i nowszych wersji z włączonym przyspieszonym odzyskiwaniem bazy danych, ale skonfigurowanej przy użyciu magazynu wersji trwałej (PVS) ustawionego na inną niż grupa plików PRIMARY, można doświadczyć błędów podczas operacji przywracania na docelowym wystąpieniu zarządzanym SQL.

Aby obejść ten problem, przed przeprowadzeniem migracji do usługi SQL Managed Instance upewnij się, że magazyn wersji trwałej (PVS) ma wartość PRIMARY w źródłowej bazie danych programu SQL Server. Jeśli baza danych została już zmigrowana bez ustawienia PVS na PRIMARY, możesz ustawić ją w źródłowej bazie danych programu SQL Server, a następnie ponownie przeprowadzić migrację bazy danych do usługi SQL Managed Instance.

Nie można użyć przyspieszonego odzyskiwania bazy danych po przeprowadzeniu migracji do SQL Managed Instance

Począwszy od programu SQL Server 2019, jeśli migrujesz bazę danych do usługi Azure SQL Managed Instance, a źródłowa baza danych ma wyłączone przyspieszone odzyskiwanie bazy danych, nie można użyć przyspieszonego odzyskiwania bazy danych w docelowym wystąpieniu zarządzanym SQL.

Aby obejść ten problem, przed przeprowadzeniem migracji do usługi SQL Managed Instance upewnij się, że włączono przyspieszone odzyskiwanie bazy danych w źródłowej bazie danych programu SQL Server. Jeśli baza danych została już zmigrowana bez włączania przyspieszonego odzyskiwania bazy danych, możesz ją włączyć w źródłowej bazie danych programu SQL Server, a następnie ponownie zmigrować bazę danych do wystąpienia zarządzanego SQL.

Program SQL Server 2017 i starsze wersje nie obsługują przyspieszonego odzyskiwania bazy danych, więc ten problem nie dotyczy baz danych migrowanych z tych wersji programu SQL Server.

Nie można użyć usługi Service Broker po przeprowadzeniu migracji do SQL Managed Instance

W przypadku migracji bazy danych do Azure SQL Managed Instance, i Service Broker jest wyłączony w źródłowej bazie danych, nie można użyć usługi Service Broker w docelowej zarządzanej instancji SQL.

Aby obejść ten problem, upewnij się, że usługa Service Broker jest włączona w źródłowej bazie danych SQL Server przed przeprowadzeniem migracji do SQL Managed Instance. Jeśli baza danych została już zmigrowana bez włączania usługi Service Broker, możesz ją włączyć w źródłowej bazie danych programu SQL Server, a następnie ponownie zmigrować bazę danych do usługi SQL Managed Instance.

Powiązana zawartość

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:

  • Last updated on