Udostępnij za pośrednictwem

Repliki drugorzędne Hiperskala

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. Replik pomocniczych można używać z bezserwerowymi lub aprowizowanymi warstwami obliczeniowymi.

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 do zwiększania 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. Ciąg połączenia nie musi się zmieniać; podczas przełączania awaryjnego aplikacje mogą doświadczać minimalnych przestojów z powodu zrywanych 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.

HA repliki używają tej samej nazwy serwera i bazy danych, co replika podstawowa. Ich cel poziomu usług (SLO) zawsze jest taki sam jak w przypadku repliki podstawowej. Repliki wysokiej dostępności nie są widoczne ani zarządzalne jako niezależne zasoby, za pośrednictwem portalu ani poprzez jakikolwiek interfejs API. Są one rozliczane z taką samą szybkością obliczeniową jak replika podstawowa, ale koszty magazynowania nie mają zastosowania do replik pomocniczych.

Może istnieć zero do czterech replik wysokiej dostępności. Repliki liczbowe można określić podczas tworzenia nowej bazy danych lub zaktualizować liczbę replik dla istniejącej bazy danych. Do określenia liczby replik HA można użyć typowych punktów końcowych i narzędzi zarządzania (na przykład: Azure PowerShell, Azure CLI, Azure Portal, interfejs API REST). Tworzenie lub usuwanie replik wysokiej dostępności nie ma wpływu na aktywne połączenia w replice głównej.

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

W hiperskalowych bazach danych argument ApplicationIntent w ciągu połączenia używanym przez klienta określa, czy połączenie jest kierowane do podstawowej repliki odczytu i zapisu, czy do repliki wysokiej dostępności o trybie tylko do odczytu. Jeśli ApplicationIntent jest ustawiona na ReadOnly, a baza danych nie ma repliki pomocniczej, połączenie jest kierowane do repliki podstawowej i domyślnie przyjmuje zachowanie ReadWrite.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<password>;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 związane z intencją odczytu jest rozmieszczane losowo 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 replice poprzez usługę dziennika transakcji, która przekazuje rekordy dziennika z repliki podstawowej do replik wysokiej dostępności. W związku z tym, w zależności od obciążenia wykonywanego na replice wysokiej dostępności, zastosowanie rekordów dziennika logów może odbywać się w różnym tempie, a tym samym różne repliki mogą mieć różne opóźnienia danych względem głównej repliki.

Nazwana replika

Nazwana replika, podobnie jak replika HA, 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 a nazwanymi replikami:

  • Nazwane repliki pojawiają się jako zwykłe (tylko do odczytu) bazy danych Azure SQL w portalu oraz w wywołaniach API (Azure CLI, Azure 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.
  • Obsługa nazwanych replik obejmuje maksymalnie 30 nazwanych replik (dla każdej repliki podstawowej).
  • Nazwane repliki umożliwiają różne uwierzytelnianie dla każdej nazwanej repliki poprzez tworzenie różnych loginów na serwerach logicznych hostujących nazwane repliki.

W związku z tym nazwane repliki oferują kilka korzyści w porównaniu z replikami HA pod względem obciążeń tylko do odczytu:

  • Użytkownicy połączeni z nazwaną repliką nie zostaną rozłączeni, jeśli replika podstawowa jest skalowana w górę albo w dół.
  • Użytkownicy połączeni z repliką podstawową nie są dotknięci, gdy nazwane repliki są skalowane w górę lub w dół.

Głównym celem nazwanych replik jest umożliwienie szerokiej różnorodności scenariuszy skalowania odczytu w poziomie oraz poprawę wydajności obciążeń hybrydowych w zakresie przetwarzania transakcyjnego i analitycznego (HTAP). Przykłady tworzenia takich rozwiązań są dostępne tutaj:

Ponadto nazwane repliki zapewniają elastyczność i skalowalność, aby spełnić wiele innych przypadków użycia.

  • Izolacja dostępu: można udzielić dostępu do określonej nazwanej repliki, ale nie do repliki podstawowej ani 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 być używana do dostarczania danych do Apache Spark w zadaniach związanych z Data Science. Każdy z nich może mieć niezależny cel poziomu usług i skalować niezależnie.
  • Routing zależny od obciążenia: przy użyciu maksymalnie 30 nazwanych replik można tworzyć grupy nazwanych replik, aby jedna aplikacja mogła być izolowana od innych aplikacji. 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ć odpowiedzi na często zadawane pytania dotyczące nazwanych replik w warstwie Hiperskala, zobacz Azure SQL Database Hiperskala — często zadawane pytania dotyczące nazwanych replik.

Redundancja strefowa dla nazwanych replik w Hiperskali

Hiperskala nazwane repliki skonfigurowane na potrzeby nadmiarowości strefy używają 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 Hyperscale na szerszy zakres usterek, w tym przerw w centrum danych, bez żadnych modyfikacji logiki aplikacji. Aby uzyskać więcej informacji, zobacz Strefowa nadmiarowa dostępność 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 utrzymania transakcyjnie spójnej kopii bazy danych dzięki replikacji asynchronicznej. Jeśli replika geograficzna znajduje się w innym regionie Azure, może służyć do odzyskiwania po katastrofie lub awarii, jeśli wystąpią one w regionie podstawowym. Repliki geograficzne mogą być również używane na potrzeby scenariuszy opisujących skalowanie geograficznego odczytu. Od października 2022 r. obsługiwana jest kopia bazy danych z repliki geograficznej kopii zapasowej hiperskalowej.

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 repliki geograficznej do punktu w czasie nie jest obsługiwane.
  • Tworzenie repliki geograficznej repliki geograficznej (nazywanej również "łańcuchem replik geograficznych") nie jest wspierane.

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 repliki odpornej na awarie strefowe w PowerShell i CLI, 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ć 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ż aktywowaną nadmiarowość między strefami jako warunek wstępny, aby ta funkcja mogła działać 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

Zwrócone z sys.databases częściowo nieprawidłowe dane

Wartości wierszy zwracane z sys.databases dla nazwanych replik w kolumnach innych niż name i database_id mogą być niespójne i niepoprawne. Na przykład kolumna compatibility_level dla nazwanej repliki może zostać zgłoszona jako 140, nawet jeśli podstawowa baza danych odpowiadająca tej nazwanej replikie jest ustawiona na poziom zgodności 150. Obejściem, jeśli to możliwe, jest pobranie tych samych danych przy użyciu DATABASEPROPERTYEX() funkcji, która zwraca 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: