Udostępnij za pośrednictwem

Ciągłość działania i odzyskiwanie bazy danych — SQL Server

Dotyczy: SQL Server 2016 (13.x) i nowsze wersje

Ten artykuł zawiera omówienie rozwiązań ciągłości działania na potrzeby wysokiej dostępności i odzyskiwania po awarii w programie SQL Server w systemach Windows i Linux.

Jednym z typowych zadań, które muszą wziąć pod uwagę wszyscy wdrażający SQL Server, jest upewnienie się, że wszystkie instancje SQL Server o znaczeniu krytycznym i bazy danych w nich zawarte są dostępne, kiedy firma i użytkownicy końcowi tego potrzebują, niezależnie od tego, czy jest to od 9 do 17, czy przez całą dobę. Celem jest utrzymanie działalności firmy z minimalnymi przerwami lub bez przerw. Ta koncepcja jest również znana jako ciągłość działalności biznesowej.

Program SQL Server 2017 (14.x) wprowadził wiele nowych funkcji lub ulepszeń istniejących, z których niektóre są dostępne. Największym dodatkiem do programu SQL Server 2017 (14.x) była obsługa dystrybucji programu SQL Server w systemie Linux. Aby uzyskać pełną listę nowych funkcji w programie SQL Server, zobacz następujące artykuły:

Ten artykuł koncentruje się na scenariuszach dostępności w programie SQL Server 2017 (14.x) i nowszych wersjach, a także nowych i rozszerzonych funkcjach dostępności. Scenariusze obejmują hybrydowe, które będą mogły obejmować wdrożenia programu SQL Server zarówno w systemie Windows Server, jak i Linux, oraz te, które mogą zwiększyć liczbę czytelnych kopii bazy danych.

Chociaż ten artykuł nie obejmuje opcji dostępności zewnętrznych dla programu SQL Server, takich jak te udostępniane przez wirtualizację, wszystkie omówione tutaj elementy dotyczą instalacji programu SQL Server wewnątrz maszyny wirtualnej gościa niezależnie od tego, czy w chmurze publicznej, czy hostowanej przez lokalny serwer funkcji hypervisor.

Scenariusze programu SQL Server korzystające z funkcji dostępności

Always On Availability Groups, instancje Always On Failover Cluster i przesyłanie dzienników mogą być używane na różne sposoby, a niekoniecznie tylko do celów dostępności. Istnieją cztery główne sposoby użycia funkcji dostępności:

  • Wysoka dostępność
  • Odzyskiwanie po awarii
  • Migracje i uaktualnienia
  • Skalowanie w poziomie czytelnych kopii jednej lub więcej baz danych

W poniższych sekcjach omówiono odpowiednie funkcje, które mogą być używane w danym scenariuszu. Jedną z funkcji, która nie została omówiona, jest replikacja programu SQL Server. Chociaż nie jest oficjalnie wyznaczona jako funkcja dostępności w ramach koncepcji Always On, replikacja programu SQL Server jest często używana do tworzenia danych redundantnych w niektórych scenariuszach. Replikacja scalania nie jest obsługiwana w przypadku programu SQL Server w systemie Linux. Aby uzyskać więcej informacji, zobacz Replikacja programu SQL Server w systemie Linux.

Ważne

Funkcje dostępności programu SQL Server nie zastępują wymagania, aby mieć niezawodną, dobrze przetestowaną strategię tworzenia i przywracania kopii zapasowych, która stanowi najbardziej podstawowy blok konstrukcyjny dowolnego rozwiązania dostępności.

Wysoka dostępność

Ważne jest, aby upewnić się, że instancje i bazy danych SQL Server są dostępne w przypadku problemu, który dotyczy lokalnego centrum danych lub pojedynczego regionu chmury. W tej sekcji opisano, jak funkcje dostępności programu SQL Server mogą pomóc w tym zadaniu. Wszystkie opisane funkcje są dostępne zarówno w systemie Windows Server, jak i w systemie Linux.

Grupy dostępności

Wprowadzone w programie SQL Server 2012 (11.x), grupy dostępności zapewniają ochronę na poziomie bazy danych, wysyłając każdą transakcję bazy danych do innego wystąpienia lub repliki, która zawiera kopię tej bazy danych w specjalnym stanie. Grupę dostępności można wdrożyć w edycjach Standard lub Enterprise. Wystąpienia uczestniczące w AG mogą być wystąpieniami autonomicznymi lub wystąpieniami klastrowymi trybu failover (FCI, opisanymi w następnej sekcji). Ponieważ transakcje są wysyłane do repliki w miarę ich wystąpienia, zalecane są grupy zabezpieczeń, w przypadku których istnieją wymagania dotyczące niższych celów punktu odzyskiwania i czasu odzyskiwania. Przenoszenie danych między replikami może być synchroniczne lub asynchroniczne. W edycji Enterprise można skonfigurować do trzech replik (w tym podstawową) jako synchroniczne. Grupa dostępności ma jedną pełną kopię bazy danych z możliwością odczytu i zapisu, która znajduje się w replice podstawowej, podczas gdy wszystkie repliki wtórne nie mogą przyjmować transakcji bezpośrednio od użytkowników końcowych lub aplikacji.

Uwaga / Notatka

Always On to termin parasolowy dla funkcji dostępności w programie SQL Server i obejmuje zarówno grupy dostępności, jak i klastry trybu failover. "Always On" nie jest nazwą funkcji grupy dostępności.

W przypadku SQL Server 2022 (16.x) grupy dostępności (AG) zapewniają ochronę tylko na poziomie bazy danych, a nie na poziomie wystąpienia. Wszystkie elementy, które nie zostały przechwycone w dzienniku transakcji lub skonfigurowane w bazie danych, muszą być synchronizowane ręcznie dla każdej repliki pomocniczej. Niektóre przykłady obiektów, które muszą być synchronizowane ręcznie, to logowania na poziomie wystąpienia, serwerów połączonych i zadań agenta programu SQL Server.

Począwszy od programu SQL Server 2022 (16.x), można zarządzać obiektami metadanych, w tym użytkownikami, loginami, uprawnieniami i zadaniami agenta programu SQL Server na poziomie grupy dostępności (AG) oprócz poziomu wystąpienia. Aby uzyskać więcej informacji, zobacz Grupy dostępności o ograniczonej dostępności.

Grupa dostępności ma również inny składnik o nazwie słuchacz, który umożliwia aplikacjom i użytkownikom końcowym łączenie się bez konieczności wiedzy, która instancja programu SQL Server hostuje replikę podstawową. Każda AG będzie miała swój własny nasłuchiwacz. Chociaż implementacje odbiornika są nieco inne w systemie Windows Server i Linux, zapewniane przez niego funkcje i sposób ich użycia są takie same. Na poniższym diagramie przedstawiono grupę dostępności opartą na systemie Windows Server wykorzystującą klaster Samoistnej Awarii systemu Windows Server (WSFC). Podstawowy klaster w warstwie systemu operacyjnego jest wymagany do zapewnienia dostępności niezależnie od tego, czy jest w systemie Linux, czy Windows Server. W przykładzie pokazano prostą konfigurację z dwoma serwerami lub węzłami z klastrem WSFC jako bazowym klastrem.

Diagram prostej grupy dostępności.

Wersje Standard i Enterprise mają różne maksimum, jeśli chodzi o repliki. Grupa dostępności w wersji standardowa, znana jako podstawowa grupa dostępności, obsługuje dwie repliki (jedną podstawową i jedną pomocniczą) z jedną tylko bazą danych w grupie dostępności. Wersja Enterprise umożliwia nie tylko skonfigurowanie wielu baz danych w jednej grupie dostępności, ale także może mieć maksymalnie dziewięć replik w sumie (jedna podstawowa, osiem pomocniczych). Wersja Enterprise zapewnia również inne opcjonalne korzyści, takie jak repliki pomocnicze z możliwością odczytu, możliwość tworzenia kopii zapasowych z repliki pomocniczej i nie tylko.

Uwaga / Notatka

Dublowanie bazy danych, które zostało uznane za przestarzałe w programie SQL Server 2012 (11.x), nie jest dostępne w wersji systemu Linux programu SQL Server ani nie zostanie dodane. Klienci nadal korzystający z mirroringu baz danych powinni zaplanować migrację do grup dostępności, które zastępują mirroring baz danych.

Jeśli chodzi o dostępność, grupy zabezpieczeń mogą zapewnić automatyczne lub ręczne przejście w tryb failover. Automatyczne przełączenie awaryjne może wystąpić, jeśli przenoszenie danych jest skonfigurowane synchronicznie, a baza danych na replice podstawowej i pomocniczej znajduje się w stanie synchronizacji. Tak długo, jak odbiornik jest używany, a aplikacja używa nowszej wersji programu .NET Framework (3.5 z aktualizacją lub 4.0 lub nowszej), tryb failover powinien być obsługiwany z minimalnym skutkiem dla użytkowników końcowych, jeśli odbiornik jest używany. Przełączenie na replikę pomocniczą jako nową replikę podstawową może być skonfigurowane jako automatyczne lub ręczne i zazwyczaj trwa kilka sekund.

Poniższa lista wyróżnia pewne różnice w przypadku grup AG w systemie Windows Server i Linux:

  • Ze względu na różnice w sposobie działania klastra bazowego w systemach Linux i Windows Server wszystkie tryby failover (ręczne lub automatyczne) grup AG są wykonywane za pośrednictwem klastra w systemie Linux. W przypadku wdrożeń grup dostępności opartych na systemie Windows Server należy przeprowadzać ręczne przełączenia w tryb awaryjny za pośrednictwem programu SQL Server. Automatyczne przełączenia awaryjne są obsługiwane przez klaster zarówno w systemach Windows Server, jak i Linux.
  • W przypadku programu SQL Server w systemie Linux zalecana konfiguracja dla grup AG to co najmniej trzy repliki. Jest to spowodowane sposobem działania klastrowania bazowego.
  • W systemie Linux nazwa pospolita używana przez każdy odbiornik jest definiowana w systemie DNS, a nie w klastrze, tak jak w systemie Windows Server.

Począwszy od programu SQL Server 2017 (14.x), istnieją pewne nowe funkcje i ulepszenia grup zabezpieczeń:

  • Typy klastrów
  • WYMAGANE_POMOCNICZE_DO_ZATWIERDZENIA
  • Ulepszona obsługa koordynatora transakcji dystrybutora firmy Microsoft (DTC) dla konfiguracji opartych na systemie Windows Server
  • Dodatkowe scenariusze skalowania w poziomie dla baz danych tylko do odczytu (opisane w dalszej części artykułu)

Typy klastrów grup dostępności

Wbudowana forma klastrowania dla zapewnienia dostępności w systemie Windows Server jest włączana za pomocą funkcji o nazwie Klaster awaryjny. Umożliwia utworzenie klastra WSFC do użycia z grupą dostępności lub wystąpieniem FCI. Integracja z Grupami Dostępności (AG) i Wystąpieniami Klastra (FCI) jest zapewniana przez biblioteki DLL zasobów obsługujące klaster, dostarczane przez program SQL Server.

Program SQL Server w systemie Linux obsługuje wiele technologii klastrowania. Firma Microsoft obsługuje składniki programu SQL Server, a nasi partnerzy obsługują odpowiednią technologię klastrowania. Na przykład wraz z programem Pacemaker program SQL Server w systemie Linux obsługuje usługę HPE Serviceguard i DH2i DxEnterprise jako rozwiązanie klastra.

Klaster typu failover oparty na systemie Windows i rozwiązanie klastra opartego na systemie Linux są do siebie bardziej podobne niż różne. Obie zapewniają sposób wykorzystania poszczególnych serwerów i łączenia ich w konfiguracji w celu zapewnienia dostępności oraz obejmują koncepcje takie jak zasoby, ograniczenia (nawet jeśli zostały zaimplementowane inaczej), przełączanie awaryjne i tak dalej.

Na przykład, aby obsługiwać Pacemaker w konfiguracjach zarówno grup dostępności (AG), jak i wystąpień klastrów trybu failover (FCI), w tym takich elementów jak automatyczne przełączanie awaryjne, firma Microsoft udostępnia pakiet mssql-server-ha, który jest podobny, ale nie dokładnie taki sam jak biblioteki DLL zasobów w usłudze WSFC dla Pacemakera. Jedną z różnic między WSFC a Pacemakerem jest to, że w Pacemakerze nie ma zasobu nazwy sieciowej, który jest komponentem pomagającym w abstrakcji nazwy nasłuchującego (lub nazwy FCI) w WSFC. System DNS zapewnia rozpoznawanie nazw w systemie Linux.

Ze względu z uwagi na różnice w architekturze stosu klastra należy wprowadzić pewne modyfikacje w przypadku grup dostępności, gdyż SQL Server musi obsługiwać niektóre metadane obsługiwane natywnie przez usługę WSFC. Jedną z takich znaczących zmian jest wprowadzenie typu klastra dla grupy dostępności. Jest on przechowywany w sys.availability_groups kolumnach cluster_type i cluster_type_desc . Istnieją trzy typy klastrów:

  • WSFC
  • Zewnętrzne
  • Żaden

Wszystkie grupy Zabezpieczeń wymagające wysokiej dostępności muszą używać klastra bazowego, który w przypadku programu SQL Server 2017 (14.x) i nowszych wersji oznacza WSFC lub agenta klastrowania systemu Linux. W przypadku grup AG opartych na systemie Windows Server korzystających z bazowej usługi WSFC domyślny typ klastra to WSFC i nie trzeba go ustawiać. W przypadku grup dostępności opartych na systemie Linux podczas tworzenia grupy dostępności typ klastra musi być ustawiony na Wartość Zewnętrzna. Integracja z zewnętrznym rozwiązaniem klastra w systemie Linux jest konfigurowana po utworzeniu grupy dostępności, natomiast na platformie WSFC jest konfigurowana w czasie tworzenia.

Typ klastra None może być używany zarówno z systemami Windows Server, jak i Linux AGs. Ustawienie typu klastra na Brak oznacza, że AG nie wymaga klastra wspierającego. Oznacza to, że SQL Server 2017 (14.x) jest pierwszą wersją SQL Server obsługującą Availability Groups bez klastra, ale kosztem jest to, że ta konfiguracja nie jest wspierana jako rozwiązanie wysokiej dostępności.

Ważne

Począwszy od SQL Server 2017 (14.x), nie można zmienić typu klastra grupy dostępności po jej utworzeniu. Oznacza to, że nie można przełączyć grupy dostępności z opcji None na External lub WSFC ani odwrotnie.

Dla tych, którzy chcą dodać jedynie dodatkowe kopie bazy danych do odczytu, lub potrzebują tego, co grupa dostępności zapewnia w zakresie migracji/uaktualnień, ale nie chcą być związani z dodatkowymi złożonościami klastra bazowego, a nawet replikacji, grupa dostępności z typem klastra "Brak" jest idealnym rozwiązaniem. Aby uzyskać więcej informacji, zobacz sekcje Migracje i Aktualizacje oraz skalowanie do odczytu.

Poniższy zrzut ekranu przedstawia obsługę różnych typów klastrów w programie SQL Server Management Studio (SSMS). Musisz mieć wersję 17.1 lub nowszą. Poniższy zrzut ekranu pochodzi z wersji 17.2.

Zrzut ekranu przedstawiający opcje AG programu SSMS.

WYMAGANE_ZSYNCHRONIZOWANE_DRUGORZĘDNE_DO_ZATWIERDZENIA

Program SQL Server 2016 (13.x) zwiększył obsługę liczby synchronicznych replik z dwóch do trzech w wersji Enterprise. Jeśli jednak jedna replika pomocnicza została zsynchronizowana, ale druga miała problem, nie było możliwości kontrolowania zachowania, by nakazać serwerowi głównemu zaczekać na sprawiającą problem replikę lub pozwolić mu przejść dalej. Oznacza to, że główna replika w pewnym momencie będzie nadal odbierać zapisy, mimo że replika drugorzędna nie będzie zsynchronizowana, co oznacza utratę danych w replikach drugorzędnych. Począwszy od programu SQL Server 2017 (14.x), możesz kontrolować zachowanie tego, co się dzieje, gdy istnieją synchroniczne repliki za pomocą polecenia REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Ta opcja działa w następujący sposób:

  • Istnieją trzy możliwe wartości: 0, 1i 2
  • Wartość to liczba replik pomocniczych, które muszą być zsynchronizowane, co ma wpływ na utratę danych, dostępność grupy wysokiej dostępności oraz tryb przełączenia awaryjnego.
  • W przypadku WSFC i typu klastra None wartość domyślna to 0, a można ją ustawić ręcznie na 1 lub 2.
  • W przypadku klastra typu zewnętrznego, domyślnie mechanizm klastra ustawi tę wartość, którą można następnie ręcznie zastąpić. W przypadku trzech synchronicznych replik wartość domyślna to 1.

W systemie Linux wartość dla REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT jest skonfigurowana w zasobie AG w klastrze. W systemie Windows jest on ustawiany za pomocą języka Transact-SQL.

Wartość wyższa niż 0 zapewnia wyższą ochronę danych, ponieważ jeśli wymagana liczba replik pomocniczych nie jest dostępna, podstawowa nie będzie dostępna, dopóki nie zostanie rozpoznana. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT Ma również wpływ na zachowanie przełączenia awaryjnego, ponieważ automatyczne przełączenie nie może wystąpić, jeśli odpowiednia liczba replik zapasowych nie była w odpowiednim stanie. W systemie Linux wartość 0 nie pozwala na automatyczne przełączanie awaryjne, więc podczas korzystania z trybu synchronicznego z automatycznym przełączaniem awaryjnym wartość musi być ustawiona wyżej niż 0, aby osiągnąć automatyczne przełączanie awaryjne. 0 w systemie Windows Server jest to zachowanie w programie SQL Server 2016 (13.x) i starszych wersjach.

Rozszerzona obsługa koordynatora transakcji rozproszonych firmy Microsoft

Przed SQL Server 2016 (13.x) jedynym sposobem uzyskania dostępności w SQL Server dla aplikacji, które wymagają transakcji rozproszonych, używających usługi DTC na poziomie systemu, było wdrożenie klastrów trybu failover (FCI). Transakcję rozproszoną można wykonać na jeden z dwóch sposobów:

  • Transakcja, która obejmuje więcej niż jedną bazę danych w tym samym wystąpieniu programu SQL Server
  • Transakcja obejmująca więcej niż jedno wystąpienie programu SQL Server lub prawdopodobnie obejmuje źródło danych programu innego niż SQL Server

Program SQL Server 2016 (13.x) wprowadził częściową obsługę usługi DTC z grupami ZG, które obejmowały ten ostatni scenariusz. Program SQL Server 2017 (14.x) ukończy scenariusz, obsługując oba scenariusze przy użyciu usługi DTC.

W programie SQL Server 2017 (14.x) i nowszych wersjach można również dodać obsługę DTC do AG po jej utworzeniu. W programie SQL Server 2016 (13.x) włączanie obsługi usługi DTC dla grupy dostępności można wykonać tylko podczas tworzenia grupy dostępności.

Instancje klastra przełączenia awaryjnego

Instalacje klastrowane są funkcją programu SQL Server od wersji 6.5. Klastry FCI to sprawdzona metoda zapewniania dostępności w całej instalacji programu SQL Server, określane jako wystąpienie. Oznacza to, że wszystkie elementy w wystąpieniu, w tym bazy danych, zadania agenta programu SQL Server, serwery połączone itd., zostaną przeniesione na inny serwer, jeśli serwer bazowy napotka problem. Wszystkie instancje FCI wymagają pewnego rodzaju magazynu współdzielonego, nawet jeśli jest on udostępniany za pośrednictwem sieci. Zasoby Failover Cluster mogą być uruchomione i należeć tylko do jednego węzła w danym momencie. Na poniższym diagramie pierwszy węzeł klastra jest właścicielem FCI, co oznacza również, że jest właścicielem udostępnionych zasobów pamięci masowej skojarzonych z nim, co oznacza, że są oznaczone linią ciągłą prowadzącą do pamięci masowej.

Diagram instancji klastra awaryjnego.

Po przejściu w tryb failover następuje zmiana własności, jak pokazano na poniższym diagramie.

Diagram instancji klastra po przełączeniu awaryjnym.

Nie występuje utrata danych dzięki klastrowi trybu awaryjnego, ale bazowy wspólny magazyn stanowi pojedynczy punkt awarii, ponieważ istnieje tylko jedna kopia danych. Instancje klastrów w trybie przełączenia awaryjnego są często łączone z inną metodą dostępności, taką jak grupa dostępności lub wysyłka dziennika, w celu zapewnienia redundantnych kopii baz danych. Wdrożona dodatkowa metoda powinna używać fizycznie oddzielnego magazynu od instancji FCI. Gdy FCI przełącza się na inny węzeł, zatrzymuje się na jednym węźle i uruchamia na innym, podobnie jak wyłączanie serwera i ponowne jego włączanie. Instancja klastra odporności na awarie przechodzi przez normalny proces odzyskiwania, co oznacza, że wszelkie transakcje, które muszą zostać kontynuowane, będą kontynuowane, a wszelkie transakcje niekompletne zostaną wycofane. W związku z tym baza danych jest spójna z punktu danych do czasu awarii lub ręcznego przejścia w tryb failover, dlatego nie ma utraty danych. Bazy danych są dostępne tylko po zakończeniu odzyskiwania, więc czas odzyskiwania będzie zależeć od wielu czynników i zazwyczaj będzie dłuższy niż przełączenie grupy dostępności w tryb failover. Kompromis polega na tym, że w przypadku przełączenia grupy dostępności (AG), mogą być wymagane dodatkowe zadania do przywrócenia funkcjonalności bazy danych, takie jak włączenie zadania agenta programu SQL Server.

Podobnie jak AG, FCIs wprowadzają abstrakcję, który węzeł bazowego klastra je hostuje. FCI zawsze zachowuje taką samą nazwę. Aplikacje i użytkownicy końcowi nigdy nie łączą się z węzłami; korzystają z unikalnej nazwy FCI. Klaster z funkcją przełączania awaryjnego może uczestniczyć w grupie dostępności jako jedno z wystąpień hostujących replikę podstawową lub pomocniczą.

Poniższa lista wyróżnia pewne różnice w przypadku instancji klastra trybu przełączania awaryjnego (FCI) w Windows Server i Linux.

  • Na Windows Server, FCI (failover cluster instance) jest częścią procesu instalacji. Instancja klastra awaryjnego w systemie Linux konfiguruje się po zainstalowaniu SQL Server.
  • System Linux obsługuje tylko jedną instalację programu SQL Server na hosta, więc wszystkie FCIs będą wystąpieniami domyślnymi. System Windows Server obsługuje maksymalnie 25 wystąpień klastra trybu failover na usługę WSFC.
  • Nazwa wspólna używana przez instancje klastrów awaryjnych w systemie Linux jest zdefiniowana w systemie DNS i powinna być taka sama jak zasób utworzony dla instancji klastra awaryjnego.

Przesyłanie dzienników transakcji

Jeśli cele punktu odzyskiwania i czasu odzyskiwania są bardziej elastyczne lub bazy danych nie są uważane za bardzo krytyczne, wysyłka dziennika jest kolejną sprawdzoną funkcją dostępności w programie SQL Server. Na podstawie wbudowanych kopii zapasowych SQL Server, proces wysyłania dzienników automatycznie generuje kopie zapasowe dziennika transakcji, kopiuje je do co najmniej jednego wystąpienia znanego jako tryb gotowości (warm standby) i automatycznie stosuje kopie zapasowe dziennika transakcji do tego wystąpienia. Log shipping wykorzystuje zadania agenta programu SQL Server do automatyzacji procesu tworzenia kopii zapasowych, kopiowania i przywracania kopii dziennika transakcji.

Diagram wysyłki dziennika.

Prawdopodobnie największą zaletą korzystania z przesyłania dzienników w pewnym stopniu jest to, że uwzględnia błędy ludzkie. Zastosowanie dzienników transakcji może być opóźnione. W związku z tym, jeśli ktoś wykonuje coś takiego jak AKTUALIZACJA bez klauzuli WHERE, serwer zapasowy może nie mieć tej zmiany, więc można przełączyć się na niego podczas naprawy systemu podstawowego. Podczas gdy wysyłanie dzienników jest łatwe do skonfigurowania, proces przełączania z serwera głównego na rezerwę gotową do pracy, określaną jako zmiana roli, jest zawsze ręczny. Zmiana roli jest inicjowana za pomocą Transact-SQL, a podobnie jak w przypadku AG, wszystkie obiekty, które nie są przechwytywane w dzienniku transakcji, muszą być zsynchronizowane ręcznie. Wysyłanie dzienników musi być również skonfigurowane dla każdej bazy danych, natomiast jedna grupa dostępności może zawierać wiele baz danych.

W przeciwieństwie do grupy dostępności lub wystąpienia klastra trybu failover, wysyłanie dzienników nie posiada mechanizmu zmiany roli, co aplikacje muszą być w stanie obsłużyć. Można użyć technik, takich jak alias DNS (CNAME), ale istnieją zalety i wady, takie jak czas potrzebny na odświeżenie dns po przełączeniu.

Odzyskiwanie po awarii

Gdy główna lokalizacja dostępności doświadcza katastrofalnego zdarzenia, takiego jak trzęsienie ziemi lub powódź, firma musi być przygotowana, aby jej systemy zostały uruchomione gdzie indziej. W tej sekcji opisano, jak funkcje dostępności programu SQL Server mogą pomóc w ciągłości działania.

Grupy dostępności

Jedną z zalet Grup dostępności (AG) jest to, że zarówno wysoka dostępność, jak i odzyskiwanie po awarii można skonfigurować przy użyciu jednej funkcji. Bez konieczności zapewniania wysokiej dostępności przechowywania udostępnionego znacznie łatwiej jest mieć lokalne repliki w jednym centrum danych dla zapewnienia wysokiej dostępności, oraz zdalne repliki w innych centrach danych w celu przywracania po awarii, każde z oddzielnym systemem przechowywania. Posiadanie dodatkowych kopii bazy danych jest kompromisem w celu zapewnienia nadmiarowości. Poniżej przedstawiono przykład grupy dostępności obejmującej wiele centrów danych. Jedna replika podstawowa jest odpowiedzialna za synchronizowanie wszystkich replik pomocniczych.

Diagram grupy dostępności obejmującej centra danych.

** Poza grupą dostępności, w której typ klastra jest ustawiony na "brak", wymaga się, aby wszystkie repliki były częścią tego samego klastra podstawowego, niezależnie od tego, czy jest to klaster WSFC, czy rozwiązanie zewnętrznego klastra. Oznacza to, że na powyższym diagramie interfejs WSFC jest rozproszony do pracy w dwóch różnych centrach danych, co zwiększa złożoność. niezależnie od platformy (Windows Server lub Linux). Rozciąganie klastrów na odległość zwiększa złożoność.

Wprowadzona w programie SQL Server 2016 (13.x) rozproszona grupa dostępności umożliwia jednej grupie dostępności łączenie grup dostępności skonfigurowanych w różnych klastrach. Rozproszone grupy dostępności rozdzielają wymaganie, aby wszystkie węzły brały udział w tym samym klastrze, co znacznie ułatwia konfigurowanie odzyskiwania po awarii. Aby uzyskać więcej informacji na temat rozproszonych grup dostępności, zobacz Rozproszone grupy dostępności.

Diagram rozproszonej grupy dostępności.

Instancje klastra przełączenia awaryjnego

Instancje klastrów przełączania awaryjnego mogą służyć do odzyskiwania po awarii. Podobnie jak w przypadku normalnego AG, mechanizm klastra u podstaw musi być rozszerzony na wszystkie lokalizacje, co zwiększa złożoność. Istnieje dodatkowa kwestia dotycząca instancji klastra trybu failover (FCI): pamięć współdzielona. Te same dyski muszą być dostępne w lokacjach głównych i dodatkowych. Zewnętrzna metoda, taka jak funkcjonalność dostarczana przez dostawcę magazynu w warstwie sprzętowej lub przy użyciu Storage Replica w systemie Windows Server, jest wymagana, aby upewnić się, że dyski używane przez FCI są zduplikowane w innym miejscu.

Diagram przedstawiający instancję klastra przełączania awaryjnego obejmującą centra danych.

Przesyłanie dzienników transakcji

Wysyłanie dziennika jest jedną z najstarszych metod zapewniania odzyskiwania po awarii dla baz danych programu SQL Server. Wysyłanie dzienników jest często używane z Grupami dostępności i FCI (zawodnymi klastrami wystąpień) aby zapewnić odzyskiwanie po awarii w sposób bardziej ekonomiczny i prostszy, w sytuacjach gdzie inne opcje mogą być trudne ze względu na środowisko, umiejętności administracyjne lub budżet. Podobnie jak w scenariuszu wysokiej dostępności dla przesyłania dziennika, wiele środowisk opóźnia ładowanie dziennika transakcji, aby uwzględnić błędy ludzkie.

Migracje i uaktualnienia

Podczas wdrażania nowych wystąpień lub uaktualniania starych firma nie może tolerować długich przestojów. W tej sekcji omówiono, w jaki sposób funkcje dostępności programu SQL Server mogą służyć do zminimalizowania przestojów w planowanej zmianie architektury, przełączniku serwera, zmianie platformy (takiej jak Windows Server w systemie Linux lub odwrotnie) lub podczas stosowania poprawek.

Uwaga / Notatka

Inne metody, takie jak używanie kopii zapasowych i przywracanie ich w innym miejscu, mogą być również używane do migracji i uaktualnień. Nie zostały one omówione w tym artykule.

Grupy dostępności

Istniejące wystąpienie zawierające co najmniej jedną grupę zabezpieczeń można uaktualnić do nowszych wersji programu SQL Server. Chociaż będzie to wymagało pewnej ilości przestojów, przy odpowiednim planowaniu można go zminimalizować.

Jeśli celem jest migracja do nowych serwerów, a nie zmiana konfiguracji (w tym systemu operacyjnego lub wersji SQL Server), te serwery można dodać jako węzły do istniejącego klastra i dołączyć do grupy dostępności. Gdy replika lub repliki są w odpowiednim stanie, może nastąpić ręczne przełączenie się na nowy serwer w trybie failover, a następnie stare można usunąć z grupy dostępności i ostatecznie zlikwidować.

Rozproszone grupy zabezpieczeń to również inna metoda migracji do nowej konfiguracji lub uaktualnienia programu SQL Server. Ponieważ rozproszona grupa dostępności obsługuje różne podstawowe grupy dostępności w różnych architekturach, na przykład można zmienić z SQL Server 2016 (13.x) działającego w systemie Windows Server 2012 R2 na SQL Server 2017 (14.x) działającego w systemie Windows Server 2016.

Diagram przedstawiający rozproszoną grupę dostępności łączącą usługi WSFC i Pacemaker.

Na koniec grupy Zabezpieczeń z typem klastra None mogą być również używane do migracji lub uaktualniania. Nie można mieszać i dopasowywać typów klastrów w typowej konfiguracji grupy dostępności, więc wszystkie repliki muszą być typem None. Rozproszona grupa dostępności może służyć do określania zakresu grup dostępności skonfigurowanych przy użyciu różnych typów klastrów. Ta metoda jest również obsługiwana na różnych platformach systemu operacyjnego.

Wszystkie warianty grup dostępności (AG) stosowane do migracji i uaktualnień umożliwiają przeprowadzanie najbardziej czasochłonnej części pracy, jaką jest synchronizacja danych, w sposób rozłożony w czasie. Jeśli dojdzie do zainicjowania przełączenia się do nowej konfiguracji, migracja jednorazowa będzie krótką przerwą w działaniu w porównaniu z jednym długim okresem przestoju, w którym wszystkie prace, w tym synchronizacja danych, muszą zostać ukończone.

Grupy Zabezpieczeń mogą zapewnić minimalny przestój podczas stosowania poprawek podstawowego systemu operacyjnego, ręcznie przechodząc w tryb failover do repliki pomocniczej podczas wykonywania poprawek. Z punktu widzenia systemu operacyjnego wykonanie tego działania byłoby bardziej powszechne w systemie Windows Server, ponieważ często, ale nie zawsze obsługa bazowego systemu operacyjnego może wymagać ponownego uruchomienia. Stosowanie poprawek w systemie Linux czasami wymaga ponownego uruchomienia, ale może być rzadko.

Instalacja poprawek dla wystąpień programu SQL Server biorących udział w grupie dostępności może zmniejszyć przestoje, w zależności od złożoności architektury grupy dostępności. Aby zaktualizować serwery uczestniczące w AG, najpierw aktualizuje się replikę pomocniczą. Po wprowadzeniu poprawek odpowiedniej liczby replik, podstawowa replika zostanie ręcznie przełączona do innego węzła, aby przeprowadzić uaktualnienie. Wszystkie pozostałe repliki pomocnicze w tym momencie można również uaktualnić.

Instancje klastra przełączenia awaryjnego

Instancje klastrów trybu przełączenia awaryjnego (FCI) same z siebie nie mogą pomóc w tradycyjnej migracji lub uaktualnieniu; dla baz danych w klastrze trybu przełączenia awaryjnego oraz wszystkich innych uwzględnionych obiektów, musiałaby zostać skonfigurowana Grupa dostępności lub wysyłka dziennika. Jednak klastry trybu failover w systemie Windows Server są nadal popularną opcją, gdy podstawowe serwery Windows wymagają aktualizacji. Można zainicjować ręczne przejście w tryb failover, co oznacza krótką awarię zamiast niedostępności wystąpienia przez cały czas stosowania poprawek systemu Windows Server. Instancję klastra trybu failover można uaktualnić w miejscu do nowszych wersji programu SQL Server. Aby uzyskać informacje, zobacz Uaktualnianie wystąpienia klastra trybu failover programu SQL Server.

Przesyłanie dzienników transakcji

Wysyłanie dzienników jest nadal popularną opcją migracji i uaktualniania baz danych. Podobnie jak w przypadku grup dostępności, ale tym razem przy użyciu dziennika transakcji jako metody synchronizacji, propagacja danych może zostać uruchomiona z dużym wyprzedzeniem przed przełączeniem serwera. W momencie przełączenia po zatrzymaniu całego ruchu w źródle należy pobrać, skopiować i zastosować do nowej konfiguracji końcowy dziennik transakcji. W tym momencie baza danych może zostać przeniesiona w tryb online. Wysyłka dzienników jest często bardziej odporna na wolniejsze sieci, a przejście może zająć nieco więcej czasu niż to przeprowadzane przy użyciu grupy dostępności lub rozproszonej grupy dostępności, lecz zazwyczaj mierzona jest w minutach — nie w godzinach, dniach czy tygodniach.

Podobnie jak w przypadku grup dostępności (AG), przesyłanie dzienników może zapewnić możliwość przełączenia się na inny serwer w razie potrzeby aktualizacji poprawek.

Inne metody wdrażania i dostępność programu SQL Server

Istnieją dwie inne metody wdrażania programu SQL Server w systemie Linux: kontenery i korzystanie z platformy Azure (lub innego dostawcy chmury publicznej). Ogólna potrzeba dostępności, jak przedstawiono w tym dokumencie, istnieje niezależnie od sposobu wdrażania programu SQL Server. Te dwie metody mają pewne specjalne zagadnienia, jeśli chodzi o zapewnienie wysokiej dostępności programu SQL Server.

Kontenery SQL Server i opcje wysokiej dostępności oraz odzyskiwania po awarii

Wdrażanie kontenera programu SQL Server to nowy sposób wdrażania programu SQL Server w systemie Linux. Kontener to kompletny obraz programu SQL Server, który jest gotowy do uruchomienia.

W zależności od używanej platformy kontenera, na przykład w przypadku używania orkiestratora kontenerów, takiego jak Kubernetes, jeśli kontener zostanie utracony, można go wdrożyć ponownie i dołączyć do magazynu udostępnionego, który został użyty. Chociaż zapewnia to pewną odporność, wystąpi pewien przestój związany z odzyskiwaniem bazy danych, a rozwiązanie to nie oferuje prawdziwie wysokiej dostępności, jak miałoby to miejsce w przypadku korzystania z grupy dostępności lub wystąpienia klastra trybu failover.

Jeśli chcesz skonfigurować wysoką dostępność dla kontenerów SQL Server wdrożonych na platformach Kubernetes lub innych niż Kubernetes, możesz użyć narzędzia DH2i DxEnterprise jako jednego z rozwiązań klastrowania, na których można skonfigurować Grupę Dostępności (AG) w trybie wysokiej dostępności. Ta opcja zapewnia docelowy punkt odzyskiwania (RPO) i docelowy czas odzyskiwania (RTO) oczekiwane przy rozwiązaniach o wysokiej dostępności.

Wdrożenie IaaS oparte na systemie Linux

Maszyny wirtualne IaaS z systemem Linux można wdrożyć przy użyciu programu SQL Server zainstalowanego przy użyciu platformy Azure. Podobnie jak w przypadku instalacji na miejscu, obsługiwana instalacja wymaga użycia funkcji "STONITH" (Shoot the Other Node in the Head), która działa poza samym agentem klastra. STONITH jest dostarczany za pośrednictwem agentów dostępności ogrodzenia. Niektóre dystrybucje wysyłają je jako część platformy, podczas gdy inne korzystają z zewnętrznego sprzętu i oprogramowania. Sprawdź preferowaną dystrybucję systemu Linux, aby zobaczyć, jakie formy rozwiązania STONITH są udostępniane, aby można było wdrożyć obsługiwane rozwiązanie w chmurze publicznej.

Przewodniki dotyczące instalowania programu SQL Server w systemie Linux są dostępne dla następujących dystrybucji:

Skala odczytu

Od czasu wprowadzenia do programu SQL Server 2012 (11.x) repliki pomocnicze miały możliwość korzystania z zapytań tylko do odczytu. Istnieją dwa sposoby, które można zastosować za pomocą Grupy Dostępności: zezwalając na bezpośredni dostęp do wtórnego i konfigurując routing tylko do odczytu, który wymaga użycia nasłuchiwacza. Program SQL Server 2016 (13.x) wprowadził możliwość równoważenia obciążenia połączeń tylko do odczytu za pośrednictwem listenera przy użyciu algorytmu round-robin, co umożliwia rozłożenie żądań tylko do odczytu we wszystkich czytelnych replikach.

Uwaga / Notatka

Repliki pomocnicze z możliwością odczytu są funkcją tylko w wersji Enterprise, a każde wystąpienie obsługujące replikę do odczytu wymaga licencji programu SQL Server.

Skalowanie kopii bazy danych do odczytu za pomocą Grup dostępności (AG) zostało po raz pierwszy wprowadzone wraz z rozproszonymi grupami dostępności w SQL Server 2016 (13.x). Pozwoliłoby to firmom mieć kopie tylko do odczytu bazy danych nie tylko lokalnie, ale lokalnie i globalnie z minimalną ilością konfiguracji i zmniejszyć ruch sieciowy i opóźnienia dzięki wykonywaniu zapytań lokalnie. Każda główna replika grupy dostępności może inicjować dwie inne grupy dostępności, nawet jeśli nie jest kopią z pełnym prawem do odczytu/zapisu, dzięki czemu każda rozproszona grupa dostępności może obsługiwać maksymalnie 27 kopii danych, które można odczytać.

Diagram przedstawiający rozproszoną grupę dostępności związaną z skalowaniem odczytu.

Począwszy od programu SQL Server 2017 (14.x), istnieje możliwość utworzenia niemal w czasie rzeczywistym, rozwiązania tylko do odczytu z grupami dostępności skonfigurowanymi z typem klastra None. Jeśli celem jest użycie grup dostępności dla replik pomocniczych z możliwością odczytu i braku dostępności, spowoduje to usunięcie złożoności korzystania z usługi WSFC lub zewnętrznego rozwiązania klastra w systemie Linux i zapewnia czytelne korzyści dla grupy dostępności w prostszej metodzie wdrażania.

Jedynym głównym zastrzeżeniem jest to, że ze względu na brak klastra bazowego z typem klastra None konfigurowanie routingu tylko do odczytu jest nieco inne. Z perspektywy programu SQL Server odbiornik jest nadal wymagany do kierowania żądań, mimo że nie ma klastra. Zamiast konfigurować tradycyjny odbiornik, używany jest adres IP lub nazwa repliki podstawowej. Replika podstawowa jest następnie używana do kierowania żądań tylko do odczytu.

Rezerwa ciepłego trybu oczekiwania dla wysyłania dzienników może być technicznie skonfigurowana do odczytu przez przywrócenie bazy danych z opcją STANDBY. Jednak ponieważ dzienniki transakcji wymagają wyłącznego użycia bazy danych do przywrócenia, oznacza to, że użytkownicy nie mogą uzyskiwać dostępu do bazy danych, gdy tak się stanie. Dzięki temu wysyłanie dzienników nie jest idealnym rozwiązaniem — zwłaszcza jeśli wymagane są dane niemal w czasie rzeczywistym.

Jedną z rzeczy, które należy zauważyć we wszystkich scenariuszach skalowania odczytu z grupami dostępności, jest to, że w przeciwieństwie do korzystania z replikacji transakcyjnej, gdzie wszystkie dane są aktywne, każda replika pomocnicza nie jest w stanie, w którym można zastosować unikalne indeksy; replika jest dokładną kopią repliki podstawowej. Jeśli jakiekolwiek indeksy są wymagane do raportowania lub dane muszą być przetwarzane, należy je utworzyć w bazach danych na replice podstawowej. Jeśli potrzebujesz tej elastyczności, replikacja jest lepszym rozwiązaniem do odczytu danych.

Współdziałanie międzyplatformowe i dystrybucje systemu Linux

Program SQL Server jest teraz obsługiwany zarówno w systemach Windows Server, jak i Linux, w tej sekcji opisano scenariusze współpracy w celu zapewnienia dostępności oprócz innych celów oraz scenariusz rozwiązań, które będą zawierać więcej niż jedną dystrybucję systemu Linux.

Uwaga / Notatka

Nie ma scenariuszy, w których instancja klastra w trybie przełączania awaryjnego oparta na WSFC lub grupy dostępności będą działać bezpośrednio z instancją klastra w trybie przełączania awaryjnego opartą na systemie Linux lub z grupami dostępności. Nie można rozszerzyć WSFC przez węzeł Pacemaker ani odwrotnie.

Rozproszone grupy dostępności

Rozproszone grupy dostępności zostały zaprojektowane do obejmowania konfiguracji grupy dostępności, niezależnie od tego, czy dwa bazowe klastry pod grupą AG to dwa różne klastry WSFC, dwie różne dystrybucje Linuksa, czy jeden klaster jest na WSFC, a drugi na Linuksie. Rozproszona grupa dostępności (AG) będzie podstawowym sposobem wdrażania rozwiązań międzyplatformowych. Rozproszona grupa dostępności to także podstawowe rozwiązanie dla migracji, takich jak przejście z infrastruktury systemu SQL Server działającej na Windows Server na system Linux, jeśli właśnie tego chce Twoja firma. Jak wspomniano powyżej, grupy zabezpieczeń, a zwłaszcza rozproszone grupy zabezpieczeń, zminimalizowałyby czas, przez jaki aplikacja będzie niedostępna do użycia. Poniżej przedstawiono przykład rozproszonej grupy dostępności obejmującej usługi WSFC i Pacemaker.

Diagram przedstawiający rozproszoną grupę dostępności, która obejmuje usługi WSFC i Pacemaker.

Jeśli grupa dostępności jest skonfigurowana z typem klastra 'None', może obejmować systemy Windows Server i Linux, a także wiele dystrybucji systemu Linux. Ponieważ nie jest to prawdziwa konfiguracja wysokiej dostępności, nie powinna być używana w przypadku wdrożeń o znaczeniu krytycznym, ale raczej przy rozdzielaniu obciążeń odczytu lub w scenariuszach migracji/uaktualniania.

Przesyłanie dzienników transakcji

Ponieważ wysyłanie dzienników jest oparte na kopii zapasowej i przywracaniu, i nie ma różnic w bazach danych, strukturach plików itp., dla programu SQL Server w systemie Windows Server i programu SQL Server w systemie Linux. Oznacza to, że wysyłanie dzienników można skonfigurować między instalacją programu SQL Server z systemem Windows Server i systemem Linux, a także między dystrybucjami systemu Linux. Wszystko inne pozostaje takie samo. Jedynym zastrzeżeniem jest to, że wysyłanie dzienników, podobnie jak grupa dostępności, nie może działać, gdy źródło znajduje się w wyższej wersji głównej programu SQL Server niż serwer docelowy będący w niższej wersji SQL Server.

Podsumowanie

Wystąpienia i bazy danych programu SQL Server 2017 (14.x) i nowsze wersje mogą być wysoce dostępne przy użyciu tych samych funkcji zarówno w systemach Windows Server, jak i Linux. Oprócz standardowych scenariuszy zapewnienia wysokiej dostępności lokalnej i odzyskiwania po awarii, czas przestoju związany z uaktualnieniami i migracjami można zminimalizować dzięki funkcjom dostępności w programie SQL Server. Grupy dostępności mogą również udostępniać dodatkowe kopie bazy danych w ramach tej samej architektury w celu zwiększenia liczby kopii przeznaczonych do odczytu. Niezależnie od tego, czy wdrażasz nowe rozwiązanie, czy rozważasz uaktualnienie, program SQL Server ma wymaganą dostępność i niezawodność.

Dalsze kroki