Repliki pomocnicze hiperskala

DOTYCZY: Azure SQL Database

Zgodnie z opisem w temacie Architektura funkcji rozproszonych Azure SQL Database Hiperskala ma dwa różne typy węzłów obliczeniowych, nazywane również replikami:

Repliki pomocnicze są zawsze tylko do odczytu i mogą mieć trzy różne typy:

Każdy typ ma inną architekturę, zestaw funkcji, cel i koszt. Na podstawie potrzebnych funkcji możesz użyć tylko jednego lub nawet wszystkich trzech razem.

Replika o wysokiej dostępności

Replika wysokiej dostępności (HA) używa tych samych serwerów stron co replika podstawowa, więc do dodania repliki wysokiej dostępności nie jest wymagana kopia danych. Repliki wysokiej dostępności są używane głównie do zwiększania dostępności bazy danych; działają jako gorące rezerwy na potrzeby trybu failover. Jeśli replika podstawowa stanie się niedostępna, przejście w tryb failover do jednej z istniejących replik wysokiej dostępności jest automatyczne i szybkie. Parametry połączenia nie muszą ulec zmianie; podczas pracy w trybie failover aplikacje mogą mieć minimalny czas przestoju z powodu porzucania aktywnych połączeń. Jak zwykle w tym scenariuszu zalecana jest właściwa logika ponawiania prób. Kilka sterowników zapewnia już pewien stopień automatycznej logiki ponawiania prób. Jeśli używasz platformy .NET, najnowsza biblioteka Microsoft.Data.SqlClient zapewnia natywną pełną obsługę konfigurowalnej logiki automatycznego ponawiania.

Repliki wysokiej dostępności używają tej samej nazwy serwera i bazy danych co replika podstawowa. Ich cel poziomu usług jest również zawsze taki sam jak w przypadku repliki podstawowej. Repliki wysokiej dostępności nie są widoczne lub można nimi zarządzać jako zasób autonomiczny z portalu lub z dowolnego interfejsu API.

Może istnieć zero do czterech replik wysokiej dostępności. Ich liczbę można zmienić podczas tworzenia bazy danych lub po utworzeniu bazy danych za pośrednictwem typowych punktów końcowych i narzędzi do zarządzania (na przykład programu PowerShell, interfejsu wiersza polecenia az, portalu, interfejsu API REST). Tworzenie lub usuwanie replik wysokiej dostępności nie ma wpływu na aktywne połączenia w repliki podstawowej.

Nawiązywanie połączenia z repliką wysokiej dostępności

W bazach danych hiperskala argument w parametrach połączenia używanych przez klienta określa, ApplicationIntent czy połączenie jest kierowane do repliki podstawowej odczytu i zapisu, czy do repliki ha tylko do odczytu. Jeśli ApplicationIntent jest ustawiona na ReadOnly wartość , a baza danych nie ma repliki pomocniczej, połączenie zostanie przekierowane do repliki podstawowej i domyślnie ReadWrite do zachowania.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Wszystkie repliki wysokiej dostępności są identyczne w ich pojemności zasobów. Jeśli istnieje więcej niż jedna replika wysokiej dostępności, obciążenie intencji odczytu jest dystrybuowane dowolnie we wszystkich dostępnych replikach wysokiej dostępności. Jeśli istnieje wiele replik wysokiej dostępności, należy pamiętać, że każde z nich może mieć różne opóźnienie danych w odniesieniu do zmian danych wprowadzonych w podstawowej lokalizacji. Każda replika wysokiej dostępności używa tych samych danych co podstawowe w tym samym zestawie serwerów stron. Jednak lokalne pamięci podręczne danych na każdej replice wysokiej dostępności odzwierciedlają zmiany wprowadzone w podstawowej usłudze dziennika transakcji, która przekazuje rekordy dziennika z replik podstawowej do replik wysokiej dostępności. W związku z tym w zależności od obciążenia przetwarzanego przez replikę wysokiej dostępności zastosowanie rekordów dziennika może wystąpić z różnymi szybkościami, a zatem różne repliki mogą mieć różne opóźnienia danych względem repliki podstawowej.

Nazwana replika (w wersji zapoznawczej)

Nazwana replika, podobnie jak replika wysokiej dostępności, używa tych samych serwerów stron co replika podstawowa. Podobnie jak w przypadku replik wysokiej dostępności, do dodania nazwanej repliki nie jest wymagana kopia danych.

Różnica między replikami wysokiej dostępności polega na nazwach replik:

  • są wyświetlane jako zwykłe (tylko do odczytu) Azure SQL baz danych w portalu i w interfejsie API (INTERFEJS WIERSZA POLECENIA AZ, PowerShell, T-SQL) wywołania;
  • może mieć nazwę bazy danych inną niż replika podstawowa i opcjonalnie znajdować się na innym serwerze logicznym (o ile znajduje się w tym samym regionie co replika podstawowa);
  • mają własny cel poziomu usług, który można ustawić i zmienić niezależnie od repliki podstawowej;
  • obsługa maksymalnie 30 nazwanych replik (dla każdej repliki podstawowej);
  • obsługa różnych uwierzytelniania dla każdej nazwanej repliki przez utworzenie różnych identyfikatorów logowania na serwerach logicznych hostowania nazwanych replik.

W związku z tym nazwane repliki oferują kilka korzyści związanych z replikami wysokiej dostępności dla obciążeń tylko do odczytu:

  • użytkownicy połączeni z nazwaną repliką nie będą mieć rozłączenia, jeśli replika podstawowa jest skalowana w górę lub w dół; w tym samym czasie użytkownicy połączeni z repliką podstawową nie będą mieć wpływu na nazwane repliki skalowania w górę lub w dół
  • obciążenia uruchomione na dowolnej repliki, podstawowej lub nazwanej nie będą miały wpływu na długotrwałe zapytania uruchomione w innych replikach

Głównym celem nazwanych replik jest włączenie masowego scenariusza skalowania w poziomie odczytu OLTP oraz ulepszenia obciążeń hybrydowego przetwarzania transakcyjnego i analitycznego (HTAP). Przykłady sposobu tworzenia takich rozwiązań są dostępne tutaj:

Oprócz głównych scenariuszy wymienionych powyżej, nazwane repliki oferują elastyczność i elastyczność, aby zaspokoić wiele innych przypadków użycia:

  • Izolacja dostępu: można udzielić dostępu do określonej nazwanej repliki, ale nie repliki podstawowej ani innych nazwanych replik.
  • Cel poziomu usług zależny od obciążenia: jako nazwana replika może mieć własny cel poziomu usług, można używać różnych nazwanych replik dla różnych obciążeń i przypadków użycia. Na przykład jedna nazwana replika może służyć do obsługi żądań Power BI, a druga może służyć do obsługi danych na platformie Apache Spark na potrzeby zadań nauki o danych. Każdy z nich może mieć niezależny cel poziomu usług i skalować niezależnie.
  • Routing zależny od obciążenia: z maksymalnie 30 nazwanymi replikami można używać nazwanych replik w grupach, aby aplikacja mogła być odizolowana od innego. Na przykład grupa czterech nazwanych replik może służyć do obsługi żądań pochodzących z aplikacji mobilnych, podczas gdy inna grupa dwóch nazwanych replik może służyć do obsługi żądań pochodzących z aplikacji internetowej. Takie podejście pozwoliłoby na precyzyjne dostrajanie wydajności i kosztów dla każdej grupy.

W poniższym przykładzie zostanie utworzona nazwana replika WideWorldImporters_NR bazy danych WideWorldImporters. Replika podstawowa używa HS_Gen5_4 celu poziomu usługi, podczas gdy nazwana replika używa HS_Gen5_2. Oba używają tego samego serwera MyServerlogicznego . Jeśli wolisz używać interfejsu API REST bezpośrednio, ta opcja jest również możliwa: Bazy danych — tworzenie bazy danych jako pomocniczej repliki nazwanej.

ALTER DATABASE [WideWorldImporters]
ADD SECONDARY ON SERVER [MyServer] 
WITH (SERVICE_OBJECTIVE = 'HS_Gen5_2', SECONDARY_TYPE = Named, DATABASE_NAME = [WideWorldImporters_NR]);

Ponieważ nie ma udziału w przenoszenia danych, w większości przypadków nazwana replika zostanie utworzona w ciągu około minuty. Gdy nazwana replika będzie dostępna, będzie ona widoczna w portalu lub dowolnym narzędziu wiersza polecenia, takiego jak interfejs wiersza polecenia az lub program PowerShell. Nazwana replika jest użyteczna jako zwykła baza danych tylko do odczytu.

Uwaga

Aby uzyskać często zadawane pytania dotyczące replik nazwanych w warstwie Hiperskala, zobacz Azure SQL Database Hiperskala nazwane repliki — często zadawane pytania.

Nawiązywanie połączenia z nazwaną repliką

Aby nawiązać połączenie z nazwaną repliką, należy użyć parametrów połączenia dla tej nazwanej repliki, odwołując się do jej serwerów i nazw baz danych. Nie ma potrzeby określania opcji "ApplicationIntent=ReadOnly", ponieważ nazwane repliki są zawsze tylko do odczytu.

Podobnie jak w przypadku replik wysokiej dostępności, mimo że repliki podstawowe, wysokiej dostępności i nazwane współużytkują te same dane na tym samym zestawie serwerów stron, pamięci podręczne danych na każdej nazwanej replice są synchronizowane z podstawowym za pośrednictwem usługi dziennika transakcji, która przekazuje rekordy dziennika z podstawowej do nazwanych replik. W związku z tym w zależności od obciążenia przetwarzanego przez nazwaną replikę zastosowanie rekordów dziennika może wystąpić z różnymi szybkościami, a zatem różne repliki mogą mieć różne opóźnienia danych względem repliki podstawowej.

Modyfikowanie nazwanej repliki

Można zdefiniować cel poziomu usługi nazwanej repliki podczas jej tworzenia za pomocą ALTER DATABASE polecenia lub w inny obsługiwany sposób (interfejs wiersza polecenia AZ, program PowerShell, interfejs API REST). Jeśli musisz zmienić cel poziomu usługi po utworzeniu nazwanej repliki, możesz to zrobić za pomocą ALTER DATABASE ... MODIFY polecenia w samej nazwie repliki. Jeśli na przykład WideWorldImporters_NR jest to nazwana replika WideWorldImporters bazy danych, możesz to zrobić, jak pokazano poniżej.

ALTER DATABASE [WideWorldImporters_NR] MODIFY (SERVICE_OBJECTIVE = 'HS_Gen5_4')

Usuwanie nazwanej repliki

Aby usunąć nazwaną replikę, upuść ją tak samo jak zwykła baza danych. Upewnij się, że masz połączenie z master bazą danych serwera z nazwaną repliką, którą chcesz usunąć, a następnie użyj następującego polecenia:

DROP DATABASE [WideWorldImporters_NR];

Ważne

Nazwane repliki zostaną automatycznie usunięte po usunięciu repliki podstawowej, z której zostały utworzone.

Znane problemy

Częściowo nieprawidłowe dane zwrócone z sys.databases

W publicznej wersji zapoznawczej wartości wierszy zwracane z sys.databaseselementu , dla nazwanych replik, w kolumnach innych niż name i , mogą być niespójne i database_idnieprawidłowe. Na przykład kolumna compatibility_level nazwanej repliki może być zgłaszana jako 140, nawet jeśli podstawowa baza danych, z której utworzono nazwaną replikę, jest ustawiona na 150. Obejściem, jeśli to możliwe, jest pobranie tych samych danych przy użyciu DATABASEPROPERTYEX() funkcji, która zwróci poprawne dane.

Replika geograficzna (w wersji zapoznawczej)

Dzięki aktywnej replikacji geograficznej można utworzyć replikę pomocniczą do odczytu podstawowej bazy danych hiperskala w tym samym lub w innym regionie świadczenia usługi Azure. Repliki geograficzne muszą być tworzone na innym serwerze logicznym. Nazwa bazy danych repliki geograficznej zawsze odpowiada nazwie bazy danych podstawowej.

Podczas tworzenia repliki geograficznej wszystkie dane są kopiowane z podstawowego do innego zestawu serwerów stron. Replika geograficzna nie współużytkuje serwerów stron z serwerami podstawowymi, nawet jeśli znajdują się w tym samym regionie. Ta architektura zapewnia niezbędną nadmiarowość dla trybu failover geograficznie.

Repliki geograficzne są używane do obsługi transakcyjnie spójnej kopii bazy danych za pośrednictwem replikacji asynchronicznej. Jeśli replika geograficzna znajduje się w innym regionie świadczenia usługi Azure, może być używana do odzyskiwania po awarii w przypadku awarii lub awarii w regionie podstawowym. Repliki geograficzne mogą być również używane w scenariuszach geograficznych skalowania odczytu w poziomie.

W warstwie Hiperskala należy ręcznie zainicjować tryb geo-failover. Po przejściu w tryb failover nowy podstawowy będzie miał inny punkt końcowy połączenia, odwołując się do nazwy serwera logicznego obsługującego nową replikę podstawową. Aby uzyskać więcej informacji, zobacz aktywna replikacja geograficzna.

Replikacja geograficzna baz danych w warstwie Hiperskala jest obecnie dostępna w wersji zapoznawczej z następującymi ograniczeniami:

  • Można utworzyć tylko jedną replikę geograficzną (w tym samym lub innym regionie).
  • Grupy trybu failover nie są obsługiwane.
  • Planowana praca w trybie failover nie jest obsługiwana.
  • Przywracanie repliki geograficznej w czasie nie jest obsługiwane.
  • Tworzenie kopii bazy danych repliki geograficznej nie jest obsługiwane.
  • Pomocnicza pomocnicza (nazywana również "łańcuchem replik geograficznych") nie jest obsługiwana.

Następne kroki