Replikacja transakcyjna za pomocą usługi Azure SQL Managed Instance

  • Artykuł

Dotyczy:Azure SQL Managed Instance

Replikacja transakcyjna to funkcja usługi Azure SQL Managed Instance i programu SQL Server, która umożliwia replikowanie danych z tabeli w usłudze Azure SQL Managed Instance lub wystąpieniu programu SQL Server do tabel umieszczonych w zdalnych bazach danych. Ta funkcja umożliwia synchronizowanie wielu tabel w różnych bazach danych.

Omówienie

Replikacja transakcyjna umożliwia wypychanie zmian wprowadzonych w wystąpieniu zarządzanym usługi Azure SQL do:

  • Baza danych programu SQL Server (lokalna lub na maszynie wirtualnej platformy Azure)
  • Baza danych w usłudze Azure SQL Database
  • Wystąpienie bazy danych w usłudze Azure SQL Managed Instance

Uwaga

Aby korzystać ze wszystkich funkcji usługi Azure SQL Managed Instance, należy użyć najnowszych wersji programu SQL Server Management Studio (SSMS) i narzędzi SQL Server Data Tools (SSDT).

Elementy

Kluczowymi składnikami replikacji transakcyjnej są Wydawca, Dystrybutor i Subskrybent, jak pokazano na poniższej ilustracji:

Diagram of replication with Azure SQL.

Rola Azure SQL Database Wystąpienie zarządzane Azure SQL
Wydawca Nie Tak
Dystrybutor Nie Tak
Subskrybent ściągania Nie Tak
Subskrybent wypychania Tak Tak

Wydawca publikuje zmiany wprowadzone w niektórych tabelach (artykułach), wysyłając aktualizacje do dystrybutora. Wydawcą może być wystąpienie zarządzane usługi Azure SQL lub wystąpienie programu SQL Server.

Dystrybutor zbiera zmiany w artykułach od wydawcy i dystrybuuje je do subskrybentów. Dystrybutor może być wystąpieniem zarządzanym usługi Azure SQL lub wystąpieniem programu SQL Server (dowolna wersja, o ile jest równa lub wyższa niż wersja programu Publisher).

Subskrybent otrzymuje zmiany wprowadzone w wydawcy. Wystąpienie programu SQL Server i wystąpienie zarządzane usługi Azure SQL mogą być zarówno wypychane, jak i ściągane subskrybentami, chociaż subskrypcja ściągania nie jest obsługiwana, gdy dystrybutor jest wystąpieniem zarządzanym usługi Azure SQL, a subskrybent nie. Baza danych w usłudze Azure SQL Database może być tylko subskrybentem wypychania.

Usługa Azure SQL Managed Instance może obsługiwać bycie subskrybentem z następujących wersji programu SQL Server:

Uwaga

W przypadku innych wersji programu SQL Server, które nie obsługują publikowania obiektów na platformie Azure, możesz użyć metody ponownego publikowania danych , aby przenieść dane do nowszych wersji programu SQL Server.

Próba skonfigurowania replikacji przy użyciu starszej wersji może spowodować błąd MSSQL_REPL20084 (proces nie może nawiązać połączenia z subskrybentem) i MSSQL_REPL40532 (Nie można otworzyć nazwy> serwera <żądanej podczas logowania. Logowanie nie powiodło się).

Typy replikacji

Istnieją różne typy replikacji:

Replikacja Azure SQL Database Wystąpienie zarządzane Azure SQL
Transakcyjna w warstwie Standardowa Tak (tylko jako subskrybent) Tak
Migawka Tak (tylko jako subskrybent) Tak
Scal replikację Nie Nie
Komunikacja równorzędna Nie Nie
Dwukierunkowa Nie Tak
Subskrypcje z możliwością aktualizacji Nie Nie.

Macierz obsługi

Tabela obsługi replikacji transakcyjnej dla usługi Azure SQL Managed Instance jest taka sama jak w przypadku programu SQL Server.

Wydawca Dystrybutor Subskrybenta
SQL Server 2022 SQL Server 2022 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2019 SQL Server 2022
SQL Server 2019		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2017 SQL Server 2022
SQL Server 2019
SQL Server 2017		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2016 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016		 SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2014 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014		 SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2012 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012		 SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008

Kiedy używać

Replikacja transakcyjna jest przydatna w następujących scenariuszach:

  • Publikowanie zmian wprowadzonych w co najmniej jednej tabeli w bazie danych i dystrybuowanie ich do jednej lub wielu baz danych w wystąpieniu programu SQL Server lub usłudze Azure SQL Database, które subskrybują zmiany.
  • Zachowaj kilka rozproszonych baz danych w stanie synchronizacji.
  • Migrowanie baz danych z jednego wystąpienia programu SQL Server lub usługi Azure SQL Managed Instance do innej bazy danych przez ciągłe publikowanie zmian.

Porównanie synchronizacji danych z replikacją transakcyjną

Kategoria Synchronizacja danych Replikacja transakcyjna
Zalety - Obsługa aktywne-aktywne
- Dwukierunkowe między środowiskiem lokalnym i usługą Azure SQL Database		 - Mniejsze opóźnienie
- Spójność transakcyjna
— Ponowne używanie istniejącej topologii po migracji
Wady - Brak spójności transakcyjnej
- Większy wpływ na wydajność		 — Nie można opublikować z usługi Azure SQL Database
- Wysoki koszt konserwacji

Typowe konfiguracje

Ogólnie rzecz biorąc, wydawca i dystrybutor muszą znajdować się w chmurze lub lokalnie. Obsługiwane są następujące konfiguracje:

Wydawca z lokalnym dystrybutorem w usłudze SQL Managed Instance

Single instance as Publisher and Distributor.

Program Publisher i dystrybutor są konfigurowane w ramach jednego wystąpienia zarządzanego SQL i dystrybucji zmian w innym wystąpieniu zarządzanym SQL, usłudze SQL Database lub wystąpieniu programu SQL Server.

Wydawca ze zdalnym dystrybutorem w usłudze SQL Managed Instance

W tej konfiguracji jedno wystąpienie zarządzane SQL publikuje zmiany w dystrybutorze umieszczonym w innym wystąpieniu zarządzanym SQL, które może obsługiwać wiele źródłowych wystąpień zarządzanych SQL i rozpowszechniać zmiany w co najmniej jednym miejscu docelowym w usłudze Azure SQL Database, usłudze Azure SQL Managed Instance lub programie SQL Server.

Separate instances for Publisher and Distributor.

Program Publisher i dystrybutor są konfigurowane w dwóch wystąpieniach zarządzanych. Ta konfiguracja ma pewne ograniczenia:

  • Oba wystąpienia zarządzane znajdują się w tej samej sieci wirtualnej.
  • Oba wystąpienia zarządzane znajdują się w tej samej lokalizacji.

Lokalny wydawca/dystrybutor z zdalnym subskrybentem

Azure SQL Database as subscriber.

W tej konfiguracji baza danych w usłudze Azure SQL Database lub Azure SQL Managed Instance jest subskrybentem. Ta konfiguracja obsługuje migrację ze środowiska lokalnego na platformę Azure. Jeśli subskrybent jest bazą danych w usłudze Azure SQL Database, musi być w trybie wypychania.

Wymagania

  • Użyj uwierzytelniania SQL na potrzeby łączności między uczestnikami replikacji.
  • Użyj udziału konta usługi Azure Storage dla katalogu roboczego używanego przez replikację.
  • Otwórz port wychodzący TCP 445 w regułach zabezpieczeń podsieci, aby uzyskać dostęp do udziału plików platformy Azure.
  • Otwórz port wychodzący TCP 1433, gdy wystąpienie zarządzane SQL jest wydawcą/dystrybutorem, a subskrybent nie. Może być również konieczne zmianę reguły zabezpieczeń ruchu wychodzącego sieciowej grupy zabezpieczeń wystąpienia zarządzanego SQL dla allow_linkedserver_outbound tagu usługi docelowej portu 1433 z virtualnetwork na internet.
  • Umieść wydawcę i dystrybutora w chmurze lub w obu środowiskach lokalnych.
  • Skonfiguruj komunikację równorzędną sieci VPN między sieciami wirtualnymi uczestników replikacji, jeśli sieci wirtualne są różne.

Uwaga

Błąd 53 może wystąpić podczas nawiązywania połączenia z plikiem usługi Azure Storage, jeśli port 445 sieciowej grupy zabezpieczeń (NSG) ruchu wychodzącego jest blokowany, gdy dystrybutor jest bazą danych usługi Azure SQL Managed Instance, a subskrybent jest lokalnie. Zaktualizuj sieciową grupę zabezpieczeń sieci wirtualnej, aby rozwiązać ten problem.

Ograniczenia

Replikacja transakcyjna ma pewne ograniczenia specyficzne dla usługi Azure SQL Managed Instance. Dowiedz się więcej o tych ograniczeniach w tej sekcji.

Pliki migawek nie są usuwane z konta usługi Azure Storage

Usługa Azure SQL Managed Instance używa skonfigurowanego przez użytkownika konta usługi Azure Storage dla plików migawek używanych do replikacji transakcyjnej. W przeciwieństwie do programu SQL Server w środowisku lokalnym usługa Azure SQL Managed Instance nie usuwa plików migawek z konta usługi Azure Storage. Gdy pliki nie będą już potrzebne, należy je usunąć. Można to zrobić za pośrednictwem interfejsu usługi Azure Storage w witrynie Azure Portal, Eksplorator usługi Microsoft Azure Storage lub za pośrednictwem klientów wiersza polecenia (programu Azure PowerShell lub interfejsu wiersza polecenia) lub interfejsu API REST usługi Azure Storage Management.

Oto przykład sposobu usuwania pliku i sposobu usuwania pustego folderu.

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

Liczba agentów dystrybucji uruchomionych w sposób ciągły

Liczba agentów dystrybucji skonfigurowanych do ciągłego uruchamiania jest ograniczona do 30 w usłudze Azure SQL Managed Instance. Aby mieć więcej agentów dystrybucji, muszą być uruchomione na żądanie lub ze zdefiniowanym harmonogramem. Harmonogram można zdefiniować z częstotliwością dzienną i wystąpieniem co 10 sekund (lub więcej), więc mimo że nie jest ona ciągła, nadal można mieć dystrybutora, który wprowadza opóźnienie tylko kilka sekund. Gdy wymagana jest duża liczba dystrybutorów, zaleca się używanie zaplanowanej i nie ciągłej konfiguracji.

Z grupami trybu failover

Korzystanie z replikacji transakcyjnej z wystąpieniami w grupie trybu failover jest obsługiwane. Jeśli jednak skonfigurujesz replikację przed dodaniem wystąpienia zarządzanego SQL do grupy trybu failover, replikacja zostanie wstrzymana po rozpoczęciu tworzenia grupy trybu failover, a monitor replikacji wyświetli stan Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replikacja zostanie wznowiona po pomyślnym utworzeniu grupy trybu failover.

Jeśli wydawcalub dystrybutor wystąpienie zarządzane SQL znajduje się w grupie trybu failover, administrator wystąpienia zarządzanego SQL musi wyczyścić wszystkie publikacje w starym podstawowym i ponownie skonfigurować je w nowym podstawowym po przejściu w tryb failover. W tym scenariuszu potrzebne są następujące działania:

  1. Zatrzymaj wszystkie zadania replikacji uruchomione w bazie danych, jeśli istnieją.

  2. Upuść metadane subskrypcji od wydawcy, uruchamiając następujący skrypt w bazie danych wydawcy. Zastąp <name of publication> wartości i <name of subscriber> :

    EXEC sp_dropsubscription @publication = '<name of publication>',
    @article = 'all',
    @subscriber = '<name of subscriber>'

  3. Usuwanie metadanych subskrypcji z subskrybenta. Uruchom następujący skrypt w bazie danych subskrypcji w wystąpieniu zarządzanym SQL subskrybenta. Zastąp <full DNS of publisher> wartość . Na przykład : example.ac2d23028af5.database.windows.net

    EXEC sp_subscription_cleanup
   @publisher = N'<full DNS of publisher>',
   @publisher_db = N'<publisher database>',
   @publication = N'<name of publication>';

  4. Wymuś usunięcie wszystkich obiektów replikacji z wydawcy przez uruchomienie następującego skryptu w opublikowanej bazie danych:

    EXEC sp_removedbreplication;

  5. Wymuszone usunięcie starego dystrybutora z oryginalnego podstawowego wystąpienia zarządzanego SQL (w przypadku powrotu po awarii do starego podstawowego elementu, który był używany do dystrybutora). Uruchom następujący skrypt w master bazie danych w starym dystrybutorze wystąpienia zarządzanego SQL:

    EXEC sp_dropdistributor 1, 1;

Jeśli subskrybent wystąpienia zarządzanego SQL znajduje się w grupie trybu failover, publikacja powinna zostać skonfigurowana do łączenia się z punktem końcowym odbiornika grupy trybu failover dla wystąpienia zarządzanego SQL subskrybenta. W przypadku przejścia w tryb failover kolejna akcja administratora wystąpienia zarządzanego SQL zależy od typu trybu failover, który wystąpił:

  • W przypadku przejścia w tryb failover bez utraty danych replikacja będzie kontynuowana po przejściu w tryb failover.
  • W przypadku przejścia w tryb failover z utratą danych replikacja również działa. Ponownie replikuje utracone zmiany.
  • W przypadku przejścia w tryb failover z utratą danych, ale utrata danych wykracza poza okres przechowywania bazy danych dystrybucji, administrator wystąpienia zarządzanego SQL musi ponownie zainicjować bazę danych subskrypcji.

Rozwiązywanie typowych problemów

Dziennik transakcji i replikacja transakcyjna

W zwykłych okolicznościach dziennik transkacji służy do rejestrowania zmian danych w bazie danych. Zmiany są rejestrowane w dzienniku transakcji i sprawiają, że użycie magazynu dzienników rośnie. Istnieje również proces automatyczny, który umożliwia bezpieczne obcięcie dziennika transakcji, a ten proces zmniejsza ilość używanego miejsca do magazynowania dziennika. Podczas publikowania na potrzeby replikacji transakcyjnej zostanie skonfigurowane obcinanie dziennika transakcji, dopóki zmiany w dzienniku nie zostaną przetworzone przez zadanie czytnika dzienników. W niektórych okolicznościach przetwarzanie dziennika transakcji jest skutecznie blokowane, a ten stan może prowadzić do wypełnienia całego magazynu zarezerwowanego dla dziennika transakcji. Jeśli nie ma wolnego miejsca dla dziennika transakcji i nie ma więcej miejsca na zwiększenie dziennika transakcji, mamy pełny dziennik transakcji. W tym stanie baza danych nie może już przetwarzać żadnego obciążenia zapisu i skutecznie staje się bazą danych tylko do odczytu.

Wyłączony agent czytnika dzienników

Czasami publikacja replikacji transakcyjnej jest skonfigurowana dla bazy danych, ale agent czytnika dzienników nie jest skonfigurowany do uruchamiania. W takim przypadku zmiany gromadzą się w dzienniku transakcji i nie są przetwarzane. Prowadzi to do ciągłego wzrostu dziennika transakcyjnego i ostatecznie do pełnego dziennika transkacji. Użytkownik powinien upewnić się, że zadanie czytnika dzienników istnieje i jest aktywne. Alternatywą byłoby wyłączenie replikacji transakcyjnej, jeśli nie jest to konieczne.

Limity czasu zapytań agenta czytnika dzienników

Czasami zadanie czytnika dzienników nie może wykonać skutecznego postępu z powodu powtarzających się limitów czasu zapytania. Aby naprawić limity czasu zapytania, należy zwiększyć ustawienie limitu czasu zapytania dla zadania agenta czytnika dzienników.

Zwiększenie limitu czasu zapytania dla zadania czytnika dzienników można wykonać za pomocą programu SSMS. W Eksploratorze obiektów w obszarze SQL Server Agent znajdź zadanie, które chcesz zmodyfikować. Najpierw zatrzymaj go, a następnie otwórz jego właściwości. Znajdź step 2 i zmodyfikuj go. Dołącz wartość polecenia za pomocą -QueryTimeout <timeout_in_seconds>polecenia . Dla wartości limitu czasu zapytania spróbuj 21600 lub wyższą. Na koniec ponownie uruchom zadanie.

Rozmiar magazynu dziennika osiągnął maksymalny limit 2 TB

Gdy rozmiar magazynu dziennika transakcji osiągnie maksymalny limit, czyli 2 TB, dziennik fizycznie nie może wzrosnąć więcej niż. W tym przypadku jedynym dostępnym ograniczeniem ryzyka jest oznaczenie wszystkich transakcji, które mają być replikowane jako przetworzone, aby umożliwić obcinanie dziennika transakcji. Oznacza to, że pozostałe transakcje w dzienniku nie zostaną zreplikowane i należy ponownie zainicjować replikację.

Uwaga

Po wykonaniu środków zaradczych należy ponownie zainicjować replikację, co oznacza ponowne replikowanie całego zestawu danych. Jest to rozmiar operacji danych i może być długotrwały, w zależności od ilości danych, które powinny być replikowane.

Aby przeprowadzić ograniczenie ryzyka, najpierw należy zatrzymać agenta czytnika dzienników w dystrybutorze. Następnie należy uruchomić procedurę sp_repldone składowaną z flagą ustawioną reset na 1 w bazie danych wydawcy, aby umożliwić obcinanie dziennika transakcji. To polecenie powinno wyglądać następująco EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1: . Następnie należy ponownie zainicjować replikację.

Następne kroki

Aby uzyskać więcej informacji na temat konfigurowania replikacji transakcyjnej, zobacz następujące samouczki:

Zobacz też