Repliki pomocnicze w warstwie Hiperskala

  • Artykuł

Dotyczy:Azure SQL Database

Jak opisano w artykule Architektura funkcji rozproszonych, hiperskala usługi Azure SQL Database 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:

  • Replika wysokiej dostępności
  • Replika geograficzna
  • Nazwana replika

Każdy typ ma inną architekturę, zestaw funkcji, cel i koszt. Na podstawie potrzebnych funkcji można użyć tylko jednego lub nawet wszystkich tych trzech razem. Repliki pomocnicze są obsługiwane zarówno przez warstwy obliczeniowe bezserwerowe, jak i aprowizowane.

Aby uzyskać samouczki dotyczące konfigurowania replik nazwanych w warstwie Hiperskala i zarządzania nimi, zobacz:

Replika 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 żadna kopia danych. Repliki wysokiej dostępności są używane głównie w celu zwiększenia dostępności bazy danych; działają jako repliki rezerwowe w trybie 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 musi się zmieniać. Podczas pracy w trybie failover aplikacje mogą powodować minimalny przestój z powodu porzuconych 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. Jeśli używasz platformy .NET, najnowsza biblioteka Microsoft.Data.SqlClient zapewnia natywną pełną obsługę konfigurowalnej logiki automatycznego ponawiania prób.

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 ani zarządzane 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 zarządzania i narzędzi (na przykład: powerShell, interfejs wiersza polecenia AZ, portal, interfejs API REST). Tworzenie lub usuwanie replik wysokiej dostępności nie ma wpływu na aktywne połączenia w repliki podstawowej.

Połączenie do repliki wysokiej dostępności

W bazach danych hiperskala argument w parametry połączenia używany przez klienta określa, ApplicationIntent czy połączenie jest kierowane do repliki podstawowej odczytu i zapisu, czy do repliki wysokiej dostępności tylko do odczytu. Jeśli ApplicationIntent jest ustawiona ReadOnly na 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ć inne opóźnienie danych w odniesieniu do zmian danych wprowadzonych w podstawowej wersji. 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 w każdej replice wysokiej dostępności odzwierciedlają zmiany wprowadzone w podstawowej usłudze dziennika transakcji, które przekazują rekordy dziennika z repliki 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óżną szybkością, a tym samym różne repliki mogą mieć różne opóźnienia danych względem repliki podstawowej.

Nazwana replika

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, nie ma kopii danych potrzebnej do dodania nazwanej repliki.

Istnieją różnice między replikami wysokiej dostępności i nazwanych replik:

  • Nazwane repliki są wyświetlane jako zwykłe (tylko do odczytu) bazy danych Azure SQL Database w portalu i w wywołaniach interfejsu API (AZ CLI, PowerShell, T-SQL).
  • Nazwane repliki mogą 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).
  • Repliki nazwane mają własny cel poziomu usług, który można ustawić i zmienić niezależnie od repliki podstawowej.
  • Nazwane repliki obsługują maksymalnie 30 nazwanych replik (dla każdej repliki podstawowej).
  • Nazwane repliki obsługują różne uwierzytelnianie dla każdej nazwanej repliki, tworząc różne identyfikatory 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, co dotyczy 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ół; jednocześnie 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 umożliwienie szerokiej gamy scenariuszy skalowania odczytu w poziomie oraz ulepszanie obciążeń hybrydowych przetwarzania transakcyjnego i analitycznego (HTAP). Przykłady tworzenia takich rozwiązań są dostępne tutaj:

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

  • Izolacja dostępu: można udzielić dostępu do określonej nazwanej repliki, ale nie repliki podstawowej lub innych nazwanych replik.
  • Cel poziomu usług zależny od obciążenia: ponieważ 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ń usługi Power BI, a druga może służyć do obsługi danych na platformie Apache Spark na potrzeby zadań Nauka 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 umożliwia precyzyjne dostrajanie wydajności i kosztów dla każdej grupy.

Uwaga

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

Nadmiarowość stref dla replik nazwanych w warstwie Hiperskala

Uwaga

Nadmiarowość stref dla bazy danych Azure SQL Database w warstwie Hiperskala nazwanych replik jest obecnie dostępna w wersji zapoznawczej.

Nadmiarowość strefy dla bazy danych Azure SQL Database w warstwie Hiperskala o nazwie replik używa usługi Azure Strefy dostępności do dystrybucji nazwanych replik obliczeniowych węzłów obliczeniowych w różnych lokalizacjach fizycznych w regionie świadczenia usługi Azure. Wybierając nadmiarowość strefową dla nazwanych replik, można zwiększyć odporność wszystkich warstw baz danych hiperskala na szerszy zakres awarii, w tym awarii centrum danych, bez żadnych modyfikacji logiki aplikacji. Aby uzyskać więcej informacji, zobacz Dostępność strefowo nadmiarowa w warstwie Hiperskala.

Aby zapoznać się z samouczkiem dotyczącym tworzenia strefowo nadmiarowej warstwy Hiperskala o nazwie replica, zobacz Tworzenie repliki o nazwie Hiperskala.

Aby uzyskać informacje na temat rozwiązywania problemów i testowania odporności błędów aplikacji, zobacz Testowanie odporności błędów aplikacji.

Replika geograficzna

Dzięki aktywnej replikacji geograficznej można utworzyć czytelną replikę pomocniczą podstawowej bazy danych w warstwie 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ść w przypadku przechodzenia w tryb 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 na potrzeby scenariuszy skalowania odczytu geograficznego w poziomie. Od października 2022 r. obsługiwana jest kopia bazy danych z repliki pomocniczej geograficznej hiperskala.

Replikacja geograficzna bazy danych w warstwie Hiperskala ma następujące bieżące ograniczenia:

  • Można utworzyć tylko jedną replikę geograficzną (w tym samym lub innym regionie).
  • Przywracanie do punktu w czasie repliki geograficznej nie jest obsługiwane.
  • Tworzenie repliki geograficznej repliki geograficznej (nazywanej również "łańcuchem replik geograficznych") nie jest obsługiwane.

Rozwiązywanie problemów

Rozwiązywanie problemów z nadmiarową warstwą Hiperskala nazwanych replik

  • Aby uzyskać informacje na temat rozwiązywania problemów i testowania odporności błędów aplikacji, zobacz Testowanie odporności błędów aplikacji.

  • Upewnij się, że podczas tworzenia strefowo nadmiarowej repliki nazwanej w programie PowerShell i interfejsie wiersza polecenia określono co najmniej jedną replikę o wysokiej dostępności. Aby zapoznać się z przykładem, zobacz Tworzenie repliki o nazwie Hiperskala.

    • W interfejsie wiersza polecenia platformy Azure należy określić zarówno parametry "ha-replicas" i "redundant".
    • W programie PowerShell należy określić parametr "HighAvailabilityReplicaCount" i "ZoneRedundant".
    • W przypadku pominięcia zostanie wyświetlony komunikat o błędzie: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.

  • Baza danych w warstwie Hiperskala powinna mieć już włączoną nadmiarowość strefy jako wymaganie wstępne, aby włączyć tę funkcję dla nazwanych replik.

    • Opcjonalnie można włączyć nadmiarowość strefy dla nazwanych replik, nawet jeśli podstawowa baza danych ma włączoną nadmiarowość strefy.
    • Jeśli nie jest włączona, zostanie wyświetlony komunikat o błędzie: (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Znane problemy

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

Wartości wierszy zwracane z elementu dla sys.databasesnazwanych replik w kolumnach innych niż name i database_idmogą być niespójne i niepoprawne. Na przykład kolumna compatibility_level nazwanej repliki może zostać zgłoszona 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.

Powiązana zawartość

Aby uzyskać samouczki dotyczące konfigurowania replik nazwanych w warstwie Hiperskala i zarządzania nimi, zobacz:

Aby uzyskać więcej informacji, zobacz: