SQL Server Always On: Kompletny przewodnik dla administratorów baz danych [2026]

SQL Server Always On to kompleksowe rozwiązanie firmy Microsoft zapewniające wysoką dostępność i odzyskiwanie danych po awarii wprowadzone wraz z SQL Server 2012. Stanowi ona znaczący postęp w stosunku do poprzednich technologii, takich jak tworzenie kopii lustrzanych baz danych i przesyłanie dzienników, zapewniając ciągły dostęp do danych przy jednoczesnym zminimalizowaniu przestojów i utraty danych.

1.2 Dlaczego firmy potrzebują rozwiązań zawsze dostępnych

W dzisiejszej cyfrowej gospodarce przestoje w działaniu baz danych bezpośrednio przekładają się na utratę przychodów, utratę reputacji i problemy z przestrzeganiem przepisów. Organizacje potrzebują rozwiązań o wysokiej dostępności, które gwarantują niemal nieprzerwaną dostępność, chroniąc jednocześnie przed różnymi scenariuszami awarii.

Tradycyjne procedury tworzenia kopii zapasowych i przywracania danych są niewystarczające dla współczesnych wymagań biznesowych. W przypadku awarii krytycznej bazy danych firmy nie mogą sobie pozwolić na poświęcenie wielu godzin na odtworzenie danych z kopii zapasowych. Rozwiązania Always On zapewniają automatyczne przełączanie awaryjne, które pozwala na przywrócenie usługi w ciągu sekund lub minut, a nie godzin, co znacząco zmniejsza skutki awarii systemu.

Oprócz zapewnienia podstawowej dostępności przedsiębiorstwa muszą odciążyć produkcyjne bazy danych z obciążeń wymagających dużej ilości odczytu, przeprowadzać konserwację bez przestojów i zabezpieczyć się przed awariami na poziomie lokalizacji. SQL Server Always On spełnia wszystkie te wymagania za pośrednictwem ujednoliconej architektury, którą można skalować od małych wdrożeń do globalnie rozproszonych systemów.

1.3 Kluczowe koncepcje: RTO, RPO, HA i DR

Cel czasu odzyskiwania (RTO) określa maksymalny akceptowalny czas przestoju po awarii — jak szybko baza danych musi zostać ponownie uruchomiona.

Cel punktu odzyskiwania (RPO) definiuje maksymalną dopuszczalną utratę danych mierzoną w czasie — ile ostatnio przekazanych danych firma może sobie pozwolić stracić.

Wysoka dostępność (HA) koncentruje się na minimalizowaniu przestojów spowodowanych rutynowymi awariami, takimi jak awarie sprzętu lub oprogramowania w tym samym centrum danych.

Odzyskiwanie po awarii (DR) Rozwiązuje problemy związane z katastrofami, które wpływają na całe lokalizacje, przechowując kopie danych w geograficznie oddzielonych lokalizacjach. Podczas gdy HA koncentruje się na minimalizacji przestojów, DR koncentruje się na zapewnieniu ochrony danych i ciągłości działania w przypadku poważnych incydentów.

SQL Server Always On obsługuje zarówno HA, jak i DR w ramach jednej, ujednoliconej architektury. Tryb synchronicznego zatwierdzania zapewnia RPO = 0 z automatycznym przełączaniem awaryjnym dla RTO bliskiego zeru; tryb asynchronicznego zatwierdzania akceptuje potencjalną utratę danych w zamian za mniejszy wpływ opóźnień w odległych lokalizacjach.

1.4 Rozwiązania zawsze dostępne

SQL Server Always On oferuje trzy opcje wdrożenia, z których każda jest dostosowana do różnych wymagań dotyczących dostępności i infrastruktury. Niniejszy przewodnik obejmuje wszystkie trzy:

Grupy dostępności Always On (AG): Wysoka dostępność na poziomie bazy danych i odzyskiwanie danych po awarii bez konieczności współdzielenia pamięci masowej.
Zawsze włączone instancje klastra failover (FCI): Wysoka dostępność na poziomie instancji dzięki współdzielonej pamięci masowej.
AG + FCI łącznie: Dwuwarstwowa ochrona łącząca funkcje failover na poziomie instancji i bazy danych, zapewniająca maksymalną odporność.

2. Grupy dostępności zawsze włączone

Grupy dostępności Always On (AG) jest rozwiązaniem zapewniającym wysoką dostępność i odzyskiwanie danych po awarii na poziomie bazy danych, które replikuje zestaw baz danych użytkowników do maksymalnie ośmiu replik wtórnych poprzez ciągłe przesyłanie dziennika transakcji.

Najważniejsze funkcje 2.1

Przełączanie awaryjne na poziomie bazy danych: poszczególne bazy danych lub grupy mogą przełączać się awaryjnie niezależnie od SQL Server przykład;
do dziewięciu replik (jedna podstawowa, osiem zapasowych) w wersji Enterprise Edition;
tryb zatwierdzania synchronicznego w celu zerowej utraty danych; tryb zatwierdzania asynchronicznego w przypadku odległych replik DR;
automatyczne przełączanie awaryjne replik synchronicznych w przypadku, gdy replika podstawowa staje się niedostępna;
czytelne repliki wtórne umożliwiające odciążenie zadań raportowania i tworzenia kopii zapasowych;
Nasłuchiwacz grupy dostępności zapewnia pojedynczy punkt końcowy połączenia, który automatycznie kieruje do bieżącego punktu podstawowego.

2.2 Etapy wdrożenia

Przygotuj konta usługi Active Directory i skonfiguruj uprawnienia na wszystkich węzłach;
zainstalować i zweryfikować klaster trybu failover systemu Windows Server na wszystkich uczestniczących serwerach;
zainstalować SQL Server jako samodzielna instancja na każdym węźle, wykorzystująca spójne ścieżki i ustawienia;
włącz funkcję Zawsze włączonych grup dostępności za pomocą SQL Server Menedżer konfiguracji lub PowerShell;
ustaw bazy danych na model pełnego odzyskiwania i wykonaj pełne kopie zapasowe oraz kopie dziennika;
utwórz grupę dostępności, dodaj repliki i skonfiguruj tryby dostępności i przełączania awaryjnego;
tworzenie replik wtórnych za pomocą automatycznego tworzenia kopii zapasowych lub ręcznego tworzenia kopii zapasowych i przywracania;
utwórz grupę nasłuchującą dostępności i zweryfikuj łączność klienta.

Aby zapoznać się z pełnym przewodnikiem krok po kroku, zobacz nasz Kompletny przewodnik po grupach dostępności Always On.

2.3 Najlepsze dla

Bazy danych o znaczeniu krytycznym, wymagające zerowej utraty danych i automatycznego przełączania awaryjnego;
obciążenia wymagające czytelnych danych pomocniczych do raportowania lub odciążania tworzenia kopii zapasowych;
wdrożenia obejmujące wiele lokalizacji w celu odzyskiwania po awarii;
środowiska bez istniejącej infrastruktury współdzielonej pamięci masowej.

2.4 Plusy

Nie jest wymagana żadna współdzielona pamięć masowa — każda replika korzysta z niezależnej lokalnej pamięci masowej;
obsługuje zarówno HA, jak i DR w jednej konfiguracji;
czytelne materiały pomocnicze zmniejszają obciążenie pracą podstawową;
granularność na poziomie bazy danych umożliwia stosowanie różnych zasad przełączania awaryjnego dla każdej grupy baz danych.

2.5 Wady

Wymagana jest edycja Enterprise Edition dla pełnego zestawu funkcji (wersja Standard obsługuje wersję Basic AG ze znacznymi ograniczeniami);
tryb synchronicznego zatwierdzania dodaje opóźnienie zapisu proporcjonalne do czasu obiegu danych w sieci;
logowania, zadania agenta SQL i połączone serwery wymagają ręcznej synchronizacji SQL Server 2019 i starsze;
wszystkie repliki muszą znajdować się na węzłach tego samego klastra trybu failover systemu Windows Server.

Referencje 2.6

Oficjalny dokument firmy Microsoft: Czym jest grupa dostępności Always On?
Oficjalny dokument firmy Microsoft: Wprowadzenie do grup dostępności Always On

3. Zawsze włączone instancje klastra failover

Zawsze włączone instancje klastra failover (FCI) zapewnia wysoką dostępność na poziomie instancji poprzez uruchomienie pojedynczego SQL Server instancję na wielu węzłach fizycznych, które współdzielą tę samą pamięć masową. W przypadku awarii aktywnego węzła SQL Server instancja na węźle zapasowym zostanie automatycznie uruchomiona ponownie, dzięki czemu przejście stanie się niewidoczne dla aplikacji klienckich.

Najważniejsze funkcje 3.1

Przełączanie awaryjne na poziomie instancji: wszystkie bazy danych na instancji przełączają się awaryjnie razem jako pojedyncza jednostka;
współdzielona pamięć masowa (SAN, iSCSI, Storage Spaces Direct lub SMB) dostępna dla wszystkich węzłów;
wirtualna nazwa sieciowa i wirtualny adres IP zapewniają stabilny punkt końcowy połączenia niezależnie od tego, który węzeł jest aktywny;
Windows Server Failover Clustering zarządza monitorowaniem stanu węzła, kworum i koordynacją trybu failover;
obsługuje następujące typy konfiguracji węzłów: Aktywny/Rezerwowy, Aktywny/Aktywny, N+1 i N+M.

3.2 Etapy wdrożenia

Zapewnij i dołącz współdzieloną pamięć masową do wszystkich węzłów klastra;
zainstaluj funkcję klastrowania awaryjnego i sprawdź poprawność konfiguracji klastra;
utwórz klaster trybu failover systemu Windows Server i skonfiguruj kworum;
uruchom SQL Server instalacja polega na wybraniu opcji klastra trybu failover oraz określeniu nazwy sieci wirtualnej i ścieżek do współdzielonych pamięci masowych;
dodaj dodatkowe węzły do SQL Server instancja klastra trybu failover;
sprawdź zachowanie funkcji failover, testując ręczne przełączanie awaryjne między węzłami.

Aby zapoznać się z pełnym przewodnikiem krok po kroku, zobacz nasz SQL Server Kompletny przewodnik po klastrze failover.

3.3 Najlepsze dla

Środowiska z istniejącą infrastrukturą współdzielonej pamięci masowej (SAN lub iSCSI);
aplikacje wymagające przełączania awaryjnego na poziomie instancji, w których wszystkie bazy danych muszą przełączać się awaryjnie jednocześnie;
scenariusze, w których przejrzystość klienta ma kluczowe znaczenie i nie są dopuszczalne żadne zmiany po stronie aplikacji;
organizacje, dla których priorytetem jest prostota modelu przełączania awaryjnego z pojedynczą instancją.

3.4 Plusy

Automatyczne przełączanie awaryjne na poziomie instancji bez konieczności ponownej konfiguracji klienta;
brak konieczności replikacji danych — wszystkie węzły mają dostęp do tej samej pamięci masowej;
przewidywalne zachowanie w przypadku awarii wszystkich baz danych jednocześnie;
obsługuje elastyczne konfiguracje węzłów (Aktywny/Aktywny, N+1, N+M) w celu optymalizacji wykorzystania sprzętu.

3.5 Wady

Współdzielona pamięć masowa stanowi potencjalny pojedynczy punkt awarii, chyba że sama pamięć masowa jest redundantna;
działa tylko jeden węzeł SQL Server na raz — brak równoważenia obciążenia odczytu na węzłach drugorzędnych;
brak wbudowanego odzyskiwania po awarii bez sparowania z grupą dostępności;
Współdzielona infrastruktura pamięci masowej zwiększa koszty i złożoność w porównaniu z AG.

Referencje 3.6

Oficjalny dokument firmy Microsoft: Zawsze włączone wystąpienia klastra failover (SQL Server)

4. Połącz grupy dostępności z instancjami klastra trybu failover

Dla organizacji wymagających ochrony na poziomie instancji i bazy danych, SQL Server Obsługuje hostowanie replik grup dostępności w instancjach klastra trybu failover (FCI). W tej konfiguracji każdy węzeł FCI działa jako pojedyncza replika dostępności, dzięki czemu przełączanie awaryjne FCI jest transparentne dla grupy dostępności, podczas gdy przełączanie awaryjne AG zapewnia ochronę na poziomie bazy danych w różnych lokalizacjach. Ta kombinacja zapewnia najbardziej kompleksowe zabezpieczenie wysokiej dostępności i odzyskiwania po awarii dostępne w SQL Server.

Najważniejsze funkcje 4.1

Dwuwarstwowe przełączanie awaryjne: FCI obsługuje awarie węzłów na poziomie instancji; AG obsługuje awarie na poziomie lokalizacji lub repliki;
każdy FCI jest liczony jako pojedyncza replika w grupie dostępności, niezależnie od liczby węzłów zawartych w FCI;
Repliki hostowane przez FCI nadal wymagają współdzielonej pamięci masowej zgodnie ze standardowymi wymaganiami FCI;
Repliki AG hostowane na FCI obsługują wyłącznie ręczne przełączanie awaryjne — automatyczne przełączanie awaryjne nie jest dostępne w przypadku replik hostowanych na FCI;
samodzielne instancje mogą uczestniczyć w tej samej grupie dostępności co repliki hostowane w FCI.

4.2 Etapy wdrożenia

Wdrażaj i waliduj każdy FCI niezależnie, postępując zgodnie ze standardowymi procedurami konfiguracji FCI;
upewnij się, że wszystkie węzły FCI i autonomiczne węzły replik należą do tego samego klastra trybu failover systemu Windows Server;
włącz funkcję Zawsze Włączonych Grup Dostępności na każdej instancji FCI;
sprawdź, czy żaden pojedynczy węzeł WSFC nie będzie obsługiwał dwóch replik tej samej grupy dostępności po jakimkolwiek możliwym przełączeniu awaryjnym FCI;
utwórz grupę dostępności, wyznaczając instancje FCI jako repliki i konfigurując ręczny tryb przełączania awaryjnego dla wszystkich replik hostowanych w FCI;
utworzyć repliki wtórne i skonfigurować nasłuchiwanie grupy dostępności.

Aby uzyskać szczegółowe informacje na temat konfiguracji FCI, zapoznaj się z naszą SQL Server Kompletny przewodnik po klastrze failover. Szczegółowe informacje na temat konfiguracji grup AG znajdziesz w naszym kompletnym przewodniku po grupach dostępności Always On.

4.3 Najlepsze dla

Środowiska o znaczeniu krytycznym, wymagające ochrony zarówno przed awariami pojedynczych węzłów, jak i katastrofami na poziomie lokalizacji;
organizacje, które już korzystają z FCI i muszą dodać odzyskiwanie danych po awarii w wielu lokalizacjach;
branże regulowane, w których obowiązkowe są umowy SLA dotyczące maksymalnej ochrony danych i dostępności;
wdrożenia na dużą skalę, w których zasady awaryjnego przełączania na poziomie instancji i bazy danych muszą współistnieć.

4.4 Plusy

Maksymalna ochrona: awarie węzłów obsługiwane przez FCI, awarie lokalizacji obsługiwane przez AG;
Przełączanie awaryjne FCI jest transparentne dla grupy dostępności — AG nie widzi żadnej zmiany repliki podczas przełączania awaryjnego FCI;
elastyczna topologia: łącz repliki hostowane w FCI i autonomiczne w tej samej grupie dostępności.

4.5 Wady

Repliki hostowane w FCI obsługują wyłącznie ręczne przełączanie awaryjne AG — automatyczne przełączanie awaryjne AG jest niedostępne w przypadku tych replik;
wymaga starannego planowania węzłów WSFC, aby zapobiec sytuacji, w której pojedynczy węzeł będzie hostował dwie repliki tej samej grupy AG po awarii FCI;
wyższe koszty infrastruktury i złożoność operacyjna niż w przypadku AG lub FCI osobno;
współdzielona pamięć masowa nadal wymagana dla każdego komponentu FCI.

Referencje 4.6

Oficjalny dokument firmy Microsoft: Klasterowanie awaryjne i grupy dostępności Always On (SQL Server)
Oficjalny dokument firmy Microsoft: Czym jest grupa dostępności Always On?
Oficjalny dokument firmy Microsoft: Wprowadzenie do grup dostępności Always On
Oficjalny dokument firmy Microsoft: Zawsze włączone wystąpienia klastra failover (SQL Server)

5. Porównanie rozwiązań Always On

5.1 Tabela porównawcza funkcji

Cecha	Grupy dostępności	Instancje klastra trybu failover	AG + FCI połączone
Zakres przełączania awaryjnego	Poziom bazy danych	Poziom instancji	Obie
Wymagana jest współdzielona pamięć masowa	Nie	Tak	Tak (dla komponentu FCI)
Replikacja danych	Logowane dla każdej repliki	Brak (pamięć współdzielona)	Logarytm między FCI
Automatyczne przełączanie awaryjne	Tak (repliki synchroniczne)	Tak	FCI: Tak; AG: Nie
Czytelne materiały wtórne	Tak	Nie	Tak (składnik AG)
odzyskiwanie po awarii	Wbudowany	Nie wbudowane	Wbudowany
Maksymalna liczba replik	9 (Przedsiębiorstwo)	N/A	9 (Przedsiębiorstwo)
Złożoność infrastruktury	Średni	Średni	Wysoki
Koszty:	Niższy (nie jest potrzebny SAN)	Wyższy (wymagany SAN)	Najwyższa

5.2 Wybierz rozwiązanie Always On

Zacznij od infrastruktury pamięci masowej: jeśli nie posiadasz współdzielonej pamięci masowej, grupy dostępności (Availability Groups) to naturalny wybór i najbardziej opłacalna ścieżka do zapewnienia wysokiej dostępności (HA) i odzyskiwania po awarii (DR). Jeśli korzystasz już ze środowiska SAN i potrzebujesz przełączania awaryjnego na poziomie instancji, prostszą opcją jest FCI — ale zaplanuj dodanie AG w przyszłości, jeśli w przyszłości wymagane będzie odzyskiwanie danych po awarii między lokalizacjami.

Wybierz kombinację AG + FCI tylko wtedy, gdy rzeczywiście potrzebujesz obu warstw ochrony i dojrzałości operacyjnej, aby poradzić sobie ze zwiększoną złożonością. Kluczowym ograniczeniem, o którym należy pamiętać, jest to, że repliki AG hostowane w FCI nie obsługują automatycznego przełączania awaryjnego AG, więc ta topologia wymaga ręcznej interwencji w celu zapewnienia dostępności na poziomie grupy.

W przypadku większości współczesnych wdrożeń typu greenfield zalecanym punktem wyjścia są grupy Always On Availability Groups: obejmują one zarówno HA, jak i DR, nie wymagają współdzielonej pamięci masowej i obsługują pomocnicze nośniki z możliwością odczytu — są to możliwości, z którymi sama technologia FCI nie jest w stanie się równać.

6. Najlepsze praktyki dot SQL Server Zawsze dostępne rozwiązania

6.1 Planowanie i projektowanie

Przed wybraniem rozwiązania Always On zdefiniuj wymagania RTO i RPO — cele te bezpośrednio decydują o tym, czy odpowiedni jest tryb zatwierdzania synchronicznego czy asynchronicznego, a także czy automatyczne przełączanie awaryjne jest wykonalne.
Określ rozmiar replik wtórnych tak, aby obsłużyć całe obciążenie podstawowe podczas wystąpienia awarii, w tym w przypadku szczytowego obciążenia.
W przypadku wdrożeń AG należy umieścić repliki synchroniczne w tym samym centrum danych lub sieci o niskim opóźnieniu, aby zminimalizować wpływ opóźnień zapisu. Należy zarezerwować tryb asynchroniczny dla replik DR oddalonych geograficznie.
Zaprojektuj kworum z nieparzystą liczbą głosów. W przypadku klastrów dwuwęzłowych dodaj udział plików lub obserwatora w chmurze jako trzeci głos, aby zapobiec scenariuszom z rozdwojonym mózgiem.
Starannie zaplanuj topologię sieci w przypadku wdrożeń obejmujących wiele podsieci. Każda podsieć wymaga własnego adresu IP odbiornika, a klienci muszą ustawić parametr MultiSubnetFailover=True w swoich ciągach połączeń.

6.2 Wytyczne dotyczące wdrożenia

Używaj konsekwentnie SQL Server Wersja, edycja i poziomy aktualizacji zbiorczej we wszystkich replikach. Mieszane poziomy poprawek mogą powodować nieoczekiwane zachowanie podczas przełączania awaryjnego.
Skonfiguruj dedykowane interfejsy sieciowe dla ruchu klastra Heartbeat, oddzielnie od ruchu aplikacji.
Włącz automatyczne rozsiewanie w celu początkowej synchronizacji bazy danych w SQL Server Wersja 2016 i nowsze — eliminuje konieczność ręcznego kopiowania kopii zapasowych do replik pomocniczych w większości scenariuszy.
W przypadku topologii AG + FCI należy po każdej zmianie konfiguracji węzła FCI sprawdzić, czy żaden pojedynczy węzeł WSFC nie będzie hostował dwóch replik tej samej grupy dostępności.
Zawsze używaj SQL Server Management Studio lub Transact-SQL do zarządzania przełączaniem awaryjnym grup dostępności — nigdy nie używaj bezpośrednio Failover Cluster Manager, ponieważ nie zna on stanu synchronizacji AG i może to spowodować dłuższy przestój lub utratę danych.

6.3 Monitorowanie i konserwacja

Monitoruj regularnie stan synchronizacji, kolejkę wysyłania i kolejkę ponownych wykonań za pomocą pulpitu nawigacyjnego grupy dostępności w SQL Server Management Studio lub Dynamiczne Widoki Zarządzania (DMV). Rosnąca kolejka powtórzeń na serwerze zapasowym wskazuje na wąskie gardło wejścia/wyjścia, które opóźni odzyskiwanie po awarii.
Uruchom DBCC CHECKDB na replikach drugorzędnych, aby odciążyć replikę główną od sprawdzania integralności. Zobacz nasze Przewodnik DBCC CHECKDB .
Aplikuj SQL Server Poprawki z wykorzystaniem aktualizacji kroczących: najpierw popraw repliki zapasowe, wykonaj zaplanowane ręczne przełączenie awaryjne na poprawioną replikę zapasową, a następnie popraw poprzednią replikę główną. Ogranicza to czas przestoju do czasu trwania pojedynczego przełączenia awaryjnego.
Regularnie testuj przełączanie awaryjne w środowiskach nieprodukcyjnych. Automatyczne przełączanie awaryjne, które nigdy nie zostało przetestowane, nie jest niezawodną strategią odzyskiwania.
Konfiguruj alerty dotyczące zmian stanu grupy dostępności, przejść ról replik i błędów synchronizacji za pomocą SQL Server Agent lub dedykowane narzędzie monitorujące, takie jak SQL Server monitor wydajności.

7. FAQ

P: Co to jest SQL Server Zawsze włączone?

A: SQL Server Always On to platforma wysokiej dostępności i odzyskiwania po awarii firmy Microsoft wprowadzona w SQL Server 2012. Obejmuje dwie technologie — Always On Availability Groups i Always On Failover Cluster Instances — które zapewniają automatyczne przełączanie awaryjne, redundancję danych i ciągły dostęp do baz danych w przypadku awarii sprzętu, oprogramowania lub lokalizacji.

P: Jaka jest różnica między grupami dostępności Always On a instancjami klastra trybu failover?

A: Grupy dostępności działają na poziomie bazy danych, replikują dane do niezależnych replik pomocniczych poprzez przesyłanie logów i nie wymagają współdzielonej pamięci masowej. Instancje klastra trybu failover działają na poziomie instancji, wymagają współdzielonej pamięci masowej dostępnej dla wszystkich węzłów i przełączają wszystkie bazy danych w tryb failover jako całość. Grupy dostępności obsługują odczytywalne bazy pomocnicze i wbudowaną funkcję odzyskiwania po awarii (DR); FCI nie.

P: Czy potrzebuję współdzielonej pamięci masowej dla grup dostępności Always On?

O: Nie. Każda replika AG przechowuje własną, niezależną kopię baz danych w pamięci lokalnej. Pamięć współdzielona jest wymagana tylko wtedy, gdy używasz instancji klastra trybu failover do hostowania replik AG.

P: Czy mogę używać funkcji Always On z SQL Server Edycja standardowa?

A: SQL Server Wersja Standard obsługuje podstawowe grupy dostępności zaczynające się od SQL Server 2016, ale z istotnymi ograniczeniami: jedna baza danych na grupę AG, maksymalnie dwie repliki i brak obsługi odczytywalnych baz danych. FCI jest dostępne w wersji Standard Edition bez tych ograniczeń. Wersja Enterprise Edition jest wymagana do pełnej funkcjonalności Always On.

P: Jaka jest maksymalna liczba replik w grupie dostępności?

A: SQL Server Wersja Enterprise Edition obsługuje do dziewięciu replik: jedną główną i osiem zapasowych. Rozproszone grupy dostępności mogą rozszerzyć tę liczbę do 18 replik w dwóch oddzielnych grupach dostępności.

P: Czy repliki hostowane w FCI mogą korzystać z automatycznego przełączania awaryjnego AG?

O: Nie. Gdy replika dostępności jest hostowana na instancji klastra trybu failover, automatyczne przełączanie awaryjne grupy dostępności nie jest obsługiwane dla tej repliki. Wszystkie przełączania awaryjne grupy dostępności obejmujące repliki hostowane w klastrze FCI wymagają ręcznej interwencji.

P: Jaka jest różnica pomiędzy trybem zatwierdzania synchronicznego i asynchronicznego?

A: Tryb synchronicznego zatwierdzania wymaga, aby serwer główny czekał na wzmocnienie rekordów dziennika przez serwer pomocniczy przed zatwierdzeniem, co zapewnia zerową utratę danych (RPO = 0) kosztem dodatkowego opóźnienia zapisu. Tryb asynchronicznego zatwierdzania pozwala serwerowi głównemu na zatwierdzenie bez oczekiwania, zmniejszając opóźnienie, ale ryzykując utratę danych w przypadku awarii serwera głównego przed otrzymaniem przez serwer pomocniczy wszystkich rekordów dziennika. Tryb synchroniczny należy stosować w przypadku lokalnych replik HA, a asynchroniczny w przypadku odległych replik DR.

P: Jak długo trwa SQL Server Czy Always On failover ma jakieś zastosowanie?

A: Automatyczne przełączanie awaryjne synchronicznej repliki AG zazwyczaj trwa mniej niż 30 sekund w normalnych warunkach. Przełączanie awaryjne FCI trwa zazwyczaj od 20 do 60 sekund, w zależności od czasu odzyskiwania bazy danych. Rzeczywisty czas trwania zależy od obciążenia, rozmiaru bazy danych oraz ustawień limitu czasu kontroli stanu skonfigurowanych w WSFC.

P: Co dzieje się z połączeniami klientów podczas przełączania awaryjnego?

A: Istniejące połączenia są zrywane w przypadku wystąpienia przełączenia awaryjnego. Aplikacje korzystające z nasłuchiwacza grupy dostępności i zawierające logikę ponawiania połączenia automatycznie łączą się ponownie z nowym serwerem głównym po zakończeniu przełączenia awaryjnego. Dodanie parametru MultiSubnetFailover=True do parametrów połączenia poprawia szybkość ponownego łączenia we wdrożeniach wielopodsieciowych.

P: Jak złożyć wniosek SQL Server poprawki z minimalnym przestojem w środowisku Always On?

A: Korzystaj z aktualizacji kroczących: najpierw załataj repliki zapasowe, następnie wykonaj zaplanowane ręczne przełączenie awaryjne na poprawioną replikę zapasową, a na końcu załataj poprzednią replikę główną. Ogranicza to czas przestoju do czasu trwania pojedynczego zaplanowanego przełączenia awaryjnego — zazwyczaj poniżej minuty.

P: Czy mogę połączyć grupy dostępności Always On z instancjami klastra trybu failover?

O: Tak. Repliki AG można hostować na instancjach FCI, aby zapewnić ochronę przed awarią zarówno na poziomie instancji, jak i bazy danych. Każda FCI jest liczona jako pojedyncza replika AG. Ta topologia wymaga starannego planowania węzłów WSFC, aby żaden pojedynczy węzeł nie hostował dwóch replik tej samej AG po ewentualnym przełączeniu awaryjnym FCI.

P: Co powinienem zrobić, jeśli moja baza danych ulegnie uszkodzeniu w środowisku Always On?

O: Najpierw sprawdź, czy uszkodzenie występuje we wszystkich replikach, czy tylko w głównej. Jeśli istnieje sprawna replika zapasowa, natychmiast przełącz się na nią awaryjnie. W przypadku uszkodzenia wszystkich replik przywróć je z czystej kopii zapasowej. Regularnie uruchamiaj polecenie DBCC CHECKDB na replikach zapasowych, aby wcześnie wykryć uszkodzenie. Jeśli uszkodzenie dotyczy również kopii zapasowych, należy użyć wyspecjalizowanego narzędzia. SQL Server narzędzie do odzyskiwania danych w ostateczności można podjąć próbę wyodrębnienia danych z uszkodzonych plików MDF.

P: Jak grupy dostępności Always On wypadają w porównaniu ze starszymi SQL Server Rozwiązania HA?

A: AG zastępuje starsze technologie, takie jak wysyłka drewna i replikacjaPrzesyłanie dziennika wymaga ręcznego przełączania awaryjnego i nie obejmuje automatycznego przełączania ról; replikacja jest zaprojektowana z myślą o dystrybucji danych, a nie o wysokiej dostępności (HA). AG zapewnia automatyczne przełączanie awaryjne, zerową utratę danych dzięki synchronicznemu zatwierdzaniu i odczytywalne dane pomocnicze — możliwości, których te technologie nie są w stanie dorównać.

8. Wniosek

SQL Server Always On zapewnia elastyczną platformę klasy korporacyjnej do wysokiej dostępności i odzyskiwania po awarii. Grupy dostępności Always On to właściwy wybór dla większości nowoczesnych wdrożeń: eliminuje potrzebę współdzielonej pamięci masowej, obsługuje odczytywalne serwery zapasowe oraz obsługuje zarówno lokalną HA, jak i odzyskiwanie danych między lokalizacjami w ramach jednej konfiguracji. Instancje klastra trybu failover pozostają solidnym rozwiązaniem, gdy głównymi wymaganiami są przełączanie awaryjne na poziomie instancji i istniejąca infrastruktura współdzielonej pamięci masowej. Połączenie obu technologii zapewnia najgłębszą dostępną ochronę — kosztem większych inwestycji w infrastrukturę i złożoności operacyjnej.

Niezależnie od wybranego rozwiązania, podstawy są takie same: najpierw zdefiniuj wymagania RTO i RPO, zaprojektuj topologię wokół tych celów i regularnie testuj przełączanie awaryjne. Dobrze wdrożone i dokładnie przetestowane rozwiązanie Always On będzie w przewidywalny sposób odzyskiwać dane po wystąpieniu awarii produkcyjnych.

O autorze

Yuan Sheng jest starszym administratorem baz danych (DBA) z ponad 10-letnim doświadczeniem w SQL Server środowiskach i zarządzaniu bazami danych przedsiębiorstw. Z powodzeniem rozwiązał setki scenariuszy odzyskiwania baz danych w firmach z branży usług finansowych, opieki zdrowotnej i produkcji.

Yuan specjalizuje się w SQL Server Odzyskiwanie baz danych, rozwiązania wysokiej dostępności i optymalizacja wydajności. Jego bogate doświadczenie praktyczne obejmuje zarządzanie wieloterabajtowymi bazami danych, wdrażanie grup Always On Availability Groups oraz opracowywanie zautomatyzowanych strategii tworzenia kopii zapasowych i odzyskiwania danych dla systemów biznesowych o znaczeniu krytycznym.

Dzięki swojej wiedzy technicznej i praktycznemu podejściu Yuan skupia się na tworzeniu kompleksowych przewodników, które pomagają administratorom baz danych i specjalistom IT rozwiązywać złożone problemy SQL Server skutecznie stawia czoła wyzwaniom. Jest na bieżąco z najnowszymi SQL Server wydania i rozwijające się technologie baz danych firmy Microsoft, regularnie testując scenariusze odzyskiwania, aby mieć pewność, że jego zalecenia odzwierciedlają najlepsze praktyki stosowane w praktyce.

Masz pytania dot SQL Server Potrzebujesz pomocy w odzyskiwaniu danych lub dodatkowych wskazówek dotyczących rozwiązywania problemów z bazą danych? Yuan zaprasza opinie i sugestie w celu udoskonalenia tych zasobów technicznych.