Replikacja transakcyjna z Azure SQL Managed Instance

Dotyczy: Azure SQL Managed Instance

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

Za pomocą replikacji transakcyjnej można wypychać zmiany wprowadzone w wystąpieniu zarządzanym Azure SQL do:

• Baza danych 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

Kluczowymi składnikami replikacji transakcyjnej są wydawcy, dystrybutora i subskrybenta, jak pokazano na poniższej ilustracji:

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

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

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

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

• SQL Server 2016 i nowsze wersje
• SQL Server 2014 RTM CU10 (12.0.4427.24) lub SP1 CU3 (12.0.2556.4)
• SQL Server 2012 SP2 CU8 (11.0.5634.1) lub SP3 (11.0.6020.0) lub SP4 (11.0.7001.0)

Istnieją różne typy replikacji:

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

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

• Opublikuj zmiany wprowadzone w co najmniej jednej tabeli w bazie danych i rozpowszechnij je do jednej lub wielu baz danych w wystąpieniu SQL Server lub Azure SQL Database, która subskrybuje zmiany.
• Zachowaj kilka rozproszonych baz danych w stanie synchronizacji.
• Migrowanie baz danych z jednego wystąpienia SQL Server lub Azure SQL Managed Instance do innej bazy danych przez ciągłe publikowanie zmian.

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

Wydawca i dystrybutor są konfigurowane w ramach pojedynczego wystąpienia zarządzanego SQL i rozpowszechniają zmiany w innym wystąpieniu zarządzanym SQL, SQL Database lub SQL Server wystąpieniu.

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, Azure SQL Managed Instance lub SQL Server.

Wydawca 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.

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.

• 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ż konieczna zmiana reguły zabezpieczeń ruchu wychodzącego sieciowej grupy zabezpieczeń wystąpienia zarządzanego SQL dla allow_linkedserver_outboundtagu usługi docelowej 1433 z virtualnetwork na internet.
• Umieść zarówno wydawcę, jak 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ą inne.

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

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 SQL Server w środowisku lokalnym 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 na Azure Portal, Eksplorator usługi Microsoft Azure Storage lub za pośrednictwem klientów wiersza polecenia (Azure PowerShell lub interfejsu wiersza polecenia) lub interfejsu API REST usługi Azure Storage Management.

Oto przykład sposobu usuwania pliku i 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 skonfigurowanych do ciągłego uruchamiania jest ograniczona do 30 w 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 to ciągłe, nadal można mieć dystrybutora, który wprowadza opóźnienie tylko kilka sekund. Jeśli wymagana jest duża liczba dystrybutorów, zaleca się używanie zaplanowanej i nie ciągłej konfiguracji.

Używanie 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świetla 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 wystąpienie zarządzane SQL wydawcy lub dystrybutora znajduje się w grupie trybu failover, administrator wystąpienia zarządzanego SQL musi wyczyścić wszystkie publikacje na starym podstawowym serwerze podstawowym i ponownie skonfigurować je w nowym serwerze 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. Porzucanie metadanych subskrypcji od wydawcy przez uruchomienie następującego skryptu w bazie danych wydawcy. Zastąp <name of publication> wartości i <name of subscriber> :

   SQL Kopiuj

   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:

   SQL Kopiuj

   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 od wydawcy, uruchamiając następujący skrypt w opublikowanej bazie danych:

   SQL Kopiuj

   EXEC sp_removedbreplication;
   

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

   SQL Kopiuj

   EXEC sp_dropdistributor 1, 1;
   

Jeśli subskrybent wystąpienia zarządzanego SQL znajduje się w grupie trybu failover, publikacja powinna być skonfigurowana do nawiązywania połączenia 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.

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

• Konfigurowanie replikacji między wydawcą SQL Managed Instance a subskrybentem
• Konfigurowanie replikacji między wydawcą SQL Managed Instance, dystrybutorem SQL Managed Instance i subskrybentem SQL Server
• Utwórz publikację.
• Utwórz subskrypcję wypychania przy użyciu nazwy serwera jako subskrybenta (na przykład N'azuresqldbdns.database.windows.net), a baza danych w Azure SQL Nazwa bazy danych jako docelowa baza danych (na przykład Adventureworks).

• Replikacja z SQL Managed Instance i grupą trybu failover
• Replikacja do bazy danych SQL
• Replikacja do wystąpienia zarządzanego
• Tworzenie publikacji
• Tworzenie subskrypcji wypychania
• Types of Replication (Typy replikacji)
• Monitorowanie (replikacja)
• Inicjowanie subskrypcji