SQL Server Always On Availability Groups — architektura wysokiej dostępności dla baz danych enterprise

Always On Availability Groups to flagowa technologia wysokiej dostępności i odzyskiwania awaryjnego w Microsoft SQL Server, wprowadzona w SQL Server 2012 i systematycznie rozwijana w kolejnych edycjach aż do SQL Server 2022. Mechanizm ten umożliwia replikację grupy baz danych między wieloma instancjami SQL Server — zwanymi replikami — przy zachowaniu pełnej integralności transakcyjnej i możliwości automatycznego przełączania w przypadku awarii serwera głównego. W przeciwieństwie do starszego mirroringu bazodanowego, Availability Groups operują na poziomie grupy baz, a nie pojedynczej bazy, oraz wspierają do 8 replik pomocniczych w SQL Server 2022 Enterprise Edition.

Technologia ta bazuje na architekturze klastra failover Windows Server (WSFC) i od SQL Server 2017 również na klastrze Kubernetes z operatorem Big Data. Always On Availability Groups zapewniają trzy poziomy ochrony: synchroniczną replikację z automatycznym failoverem, synchroniczną replikację bez automatycznego failoveru oraz asynchroniczną replikację dla scenariuszy odzyskiwania awaryjnego między oddalonymi geograficznie centrami danych. W 2026 roku technologia ta pozostaje złotym standardem w architekturze bazodanowej Microsoftu — szczególnie istotnym w kontekście rosnących wymagań RPO (Recovery Point Objective) bliskiego zeru i RTO mierzonego w sekundach.

Przy wdrażaniu Always On Availability Groups kluczowe znaczenie ma legalne licencjonowanie SQL Server. Zarówno replika główna, jak i każda replika pomocnicza wymaga pełnej licencji SQL Server — w przypadku edycji Enterprise umożliwiającej pełną funkcjonalność AG z wieloma replikami odczytywalnymi. Licencje SQL Server 2022 Enterprise w KluczeSoft.pl dostarczane są z fakturą VAT 23%, co pozwala polskim firmom na pełne odliczenie podatku naliczonego.

Architektura Always On Availability Groups — komponenty i przepływ danych

Podstawową jednostką organizacyjną w Always On jest grupa dostępności (Availability Group), która stanowi kontener dla zestawu baz danych użytkownika replikowanych jako spójna jednostka. Każda grupa dostępności definiuje:

• Replikę główną (primary replica) — jedyna replika akceptująca zapisy od aplikacji. Wszystkie transakcje commitowane na replice głównej są propagowane do replik pomocniczych zgodnie z wybranym trybem synchronizacji.
• Repliki pomocnicze (secondary replicas) — instancje SQL Server przechowujące kopię baz danych z grupy dostępności. W zależności od konfiguracji, repliki pomocnicze mogą być nieczytelne, dostępne tylko do odczytu, lub w ogóle niedostępne dla klientów.
• Listener grupy dostępności — wirtualny punkt końcowy sieciowy (VIP i nazwa DNS), który kieruje połączenia klientów do aktualnej repliki głównej. Listener automatycznie przekierowuje ruch po failoverze, eliminując konieczność zmiany connection stringów po stronie aplikacji.
• WSFC (Windows Server Failover Cluster) — warstwa klastrowa zapewniająca detekcję awarii, mechanizm quorum i arbitraż przy podejmowaniu decyzji o failoverze.

Przepływ danych w Availability Group opiera się o log stream — replika główna wysyła rekordy dziennika transakcyjnego do wszystkich replik pomocniczych, gdzie są one odtwarzane w procesie zwanym redo. Równolegle replika główna utrzymuje dziennik transakcyjny do momentu potwierdzenia utwardzenia rekordu na wszystkich replikach synchronicznych — mechanizm log hardening gwarantuje zero utraty danych w trybie synchronicznym.

Kluczową innowacją wprowadzoną w SQL Server 2019 i udoskonaloną w SQL Server 2022 jest Accelerated Database Recovery (ADR), które drastycznie skraca czas odtwarzania bazy po failoverze — z minut do sekund — poprzez eliminację fazy UNDO wymagającej skanowania całego dziennika transakcyjnego. ADR wykorzystuje magazyn wersji trwałych (Persistent Version Store — PVS) do śledzenia zmian w wierszach, co pozwala na natychmiastowe udostępnienie bazy po przełączeniu.

Tryby synchronizacji i failoveru — jak dobrać poziom ochrony?

W Always On Availability Groups dostępne są trzy podstawowe tryby pracy replik pomocniczych, które bezpośrednio determinują gwarancje RPO i RTO:

Tryb synchroniczny z automatycznym failoverem wymaga co najmniej dwóch replik w trybie synchronicznym plus udziału WSFC z quorum. W praktyce oznacza to minimum 3 węzły: dwie repliki SQL Server (główna i pomocnicza synchroniczna) oraz serwer plików kopii zapasowej (file share witness) dla osiągnięcia większości głosów w klastrze.

Wybór trybu asynchronicznego dla repliki geograficznej (np. oddalonej o 200 km) wynika z fizyki — prędkość światła w światłowodzie wprowadza opóźnienie rzędu 1 ms na każde 100 km, co przy transakcyjnym charakterze replikacji sumuje się do wartości nieakceptowalnych dla trybu synchronicznego. SQL Server 2022 wprowadza mechanizm enhanced Database Recovery usprawniający odtwarzanie replik asynchronicznych z minimalnym opóźnieniem.

W scenariuszach hybrydowych — na przykład replika główna w on-premises i pomocnicza w Azure SQL Managed Instance — wykorzystuje się Distributed Availability Groups, osobny wariant architektury łączący dwie osobne grupy dostępności w federację. Distributed AG nie zastępuje standardowych AG, lecz stanowi nakładkę umożliwiającą replikację między domenami, wersjami SQL Server czy nawet fizycznymi lokalizacjami bez wspólnego klastra WSFC.

Wymagania wstępne i przygotowanie środowiska

Poprawne wdrożenie Always On Availability Groups wymaga spełnienia szeregu wymagań sprzętowych, programowych i sieciowych. Poniższa tabela agreguje kluczowe wymagania dla środowiska on-premises opartego o Windows Server 2025 i SQL Server 2022:

Najczęstszym błędem konfiguracyjnym popełnianym przez administratorów jest brak dedykowanej sieci do ruchu replikacji między węzłami — współdzielenie karty sieciowej z ruchem klienckim prowadzi do przeciążenia łącza w momencie wzmożonego zapisu na replice głównej i lawinowego wzrostu opóźnienia na replikach pomocniczych. Drugim częstym problemem jest pozostawienie domyślnej konfiguracji quorum WSFC wykorzystującej wyłącznie głosy węzłów — dla klastra 2-węzłowego oznacza to brak możliwości osiągnięcia większości po utracie jednego węzła.

SQL Server 2022 wprowadził również w pełni funkcjonalną obsługę Availability Groups na Linuxie z wykorzystaniem Pacemaker jako warstwy klastrowej zamiast WSFC. W tym wariancie do synchronizacji węzłów używany jest corosync, a resource agent ocf:mssql:ag zarządza przełączaniem replik. Konfiguracja ta wymaga certyfikatów SSL do uwierzytelnienia endpointów mirroringu — w przeciwieństwie do Windows Server, gdzie domyślnie używane jest uwierzytelnienie Kerberos przez domenę AD.

Konfiguracja krok po kroku — Always On z WSFC i SQL Server 2022

Proces konfiguracji grupy dostępności od podstaw obejmuje osiem kluczowych etapów. Poniższa instrukcja zakłada środowisko dwuwęzłowe z Windows Server 2025 Datacenter i SQL Server 2022 Enterprise:

Krok 1: Instalacja i konfiguracja klastra WSFC. Na obu serwerach należy zainstalować rolę Failover Clustering przez Server Manager lub PowerShell: Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools. Następnie uruchomić walidację konfiguracji klastra: Test-Cluster -Node Server1, Server2 i utworzyć klaster: New-Cluster -Name WSFC-Cluster01 -Node Server1, Server2 -StaticAddress 192.168.10.100. Jako quorum dla klastra 2-węzłowego ustawić file share witness na niezależnym serwerze plików.

Krok 2: Instalacja SQL Server 2022 z funkcją Always On. Podczas instalacji SQL Server na każdym węźle należy zaznaczyć checkbox "Włącz funkcję Always On Availability Groups" w oknie konfiguracji silnika bazy danych. Alternatywnie — dla już istniejących instancji — w SQL Server Configuration Manager włączyć flagę "Włącz Always On" w zakładce właściwości usługi SQL Server.

Krok 3: Konfiguracja endpointów mirroringu bazy danych. Każda instancja SQL Server wymaga endpointu komunikacyjnego dla ruchu replikacji. Domyślnie wykorzystuje się port TCP 5022. Tworzenie endpointu przez T-SQL: CREATE ENDPOINT [Hadr_endpoint] STATE=STARTED AS TCP (LISTENER_PORT = 5022) FOR DATABASE_MIRRORING (ROLE = ALL). Uwierzytelnienie endpointu może opierać się o konta domenowe (Kerberos) lub certyfikaty — to drugie obowiązkowe na Linuxie.

Krok 4: Przygotowanie baz danych. Każda baza przeznaczona do grupy dostępności musi być w trybie pełnego odzyskiwania (Full Recovery Model) i posiadać co najmniej jedną pełną kopię zapasową. Dodatkowo należy wykonać kopię zapasową dziennika transakcyjnego. Bazy tymczasowe (tempdb) i systemowe nie podlegają replikacji.

Krok 5: Utworzenie grupy dostępności z replikami. W SQL Server Management Studio — w węźle Always On High Availability — kreator New Availability Group prowadzi przez definicję nazwy grupy, wybór baz danych, dodanie replik z określeniem trybu synchronicznego/asynchronicznego i preferencji odczytu. Tożsamość repliki głównej w momencie tworzenia staje się pierwszym właścicielem grupy.

Krok 6: Utworzenie listenera grupy dostępności. Listener wymaga dedykowanego adresu IP w każdej podsieci, w której znajdują się repliki (dla konfiguracji wielopodsieciowych — multi-subnet failover). Nazwa DNS listenera i jego adres IP rejestrowane są w Active Directory jako obiekt komputera klastra. Port listenera domyślnie to 1433, ale może być zmieniony w przypadku współdzielenia instancji SQL Server.

Krok 7: Dołączenie replik pomocniczych. Po utworzeniu grupy dostępności na replice głównej, repliki pomocnicze czekają na dołączenie. Wykonuje się to przez ALTER AVAILABILITY GROUP [NazwaGrupy] JOIN na każdej replice pomocniczej, a następnie ALTER DATABASE [NazwaBazy] SET HADR AVAILABILITY GROUP = [NazwaGrupy]. Od tego momentu replika pomocnicza rozpoczyna synchronizację danych z repliki głównej.

Krok 8: Walidacja i monitorowanie. Dashboard Always On w SSMS wyświetla stan synchronizacji, opóźnienie (w sekundach), tryb pracy każdej repliki oraz alerty. Warto skonfigurować SQL Server Agent Alerts dla zdarzeń utraty quorum, failoveru i opóźnienia synchronizacji przekraczającego założony próg.

Rozwiązywanie problemów — najczęstsze usterki i diagnostyka

Problemy z Always On Availability Groups rzadko wynikają z samej technologii replikacji — najczęstszą przyczyną awarii jest błędna konfiguracja warstwy sieciowej, klastra lub uprawnień. Poniżej zestawienie typowych usterek i metod ich diagnozy:

Problem: endpoint mirroringu nie nasłuchuje. Objawia się komunikatem błędu 1418 przy próbie utworzenia grupy dostępności. Diagnostyka: SELECT * FROM sys.tcp_endpoints WHERE type_desc = 'DATABASE_MIRRORING' — jeśli kolumna state_desc wskazuje STOPPED, należy uruchomić endpoint przez ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED. Częstą przyczyną jest restart usługi SQL Server bez zaznaczonej flagi Always On w Configuration Manager.

Problem: "The Always On Availability Groups feature must be enabled for this server instance" — błąd pojawia się, gdy SQL Server Configuration Manager nie ma włączonej flagi Always On na danej instancji. Naprawa wymaga restartu usługi SQL Server po włączeniu flagi. W środowiskach produkcyjnych oznacza to zaplanowane okno serwisowe.

Problem: synchronizacja zawieszona (stan NOT SYNCHRONIZING). Najczęściej spowodowane przeciążeniem łącza replikacji lub przekroczeniem limitu czasu odpowiedzi między węzłami. Polecenie SELECT DB_NAME(database_id), synchronization_state_desc FROM sys.dm_hadr_database_replica_states identyfikuje bazy z problemem. Rozwiązaniem jest zwiększenie parametru session-timeout (domyślnie 10 sekund) lub przeniesienie ruchu replikacji na dedykowaną kartę sieciową.

Problem: utrata quorum klastra WSFC. W klasterze 2-węzłowym bez zewnętrznego witness, awaria jednego węzła powoduje utratę quorum i zatrzymanie całego klastra — obie repliki przechodzą w stan offline. Konieczne jest skonfigurowanie file share witness lub cloud witness (Azure Blob Storage) przed wdrożeniem produkcyjnym.

Problem: log send queue narastający na replice głównej. Wskazuje, że replika główna nie może nadążyć z wysyłką danych do replik pomocniczych. Diagnostyka przez sys.dm_hadr_database_replica_states — kolumna log_send_queue_size wyrażona w KB. Przyczyny to przeciążenie sieci, zbyt wolny storage na replice pomocniczej do odtwarzania logu (redo) lub długotrwała transakcja na replice głównej trzymająca dziennik transakcyjny.

Distributed Availability Groups — replikacja między domenami i hybryda z chmurą

Distributed Availability Groups (DAG) to mechanizm dostępny od SQL Server 2016, który umożliwia połączenie dwóch niezależnych grup dostępności w jeden łańcuch replikacji. W odróżnieniu od standardowej grupy dostępności, DAG nie wymaga wspólnego klastra WSFC dla obu stron — każda grupa działa we własnym klastrze i domenie.

Architektura DAG sprawdza się w trzech scenariuszach:

• Migracja między wersjami SQL Server — np. z SQL Server 2017 do SQL Server 2022, gdzie DAG pozwala na replikację danych do nowszej wersji bez downtime'u, a następnie przecięcie połączenia i przełączenie aplikacji.
• Replikacja między on-premises a Azure SQL Managed Instance — Managed Instance wspiera natywnie Distributed AG, co umożliwia budowę hybrydowego środowiska wysokiej dostępności z repliką w chmurze.
• Disaster recovery między dwoma ośrodkami danych — każdy ośrodek posiada własną, w pełni autonomiczną grupę dostępności, a DAG łączy je na poziomie forwardera. Awaria całego ośrodka nie wpływa na działanie klastra w drugiej lokalizacji.

Konfiguracja Distributed AG różni się od standardowej AG tym, że zamiast dodawania replik do jednej grupy, tworzy się dwie osobne grupy, a następnie łączy je przez ALTER AVAILABILITY GROUP [DAG_Global] ADD AVAILABILITY GROUP [AG_OśrodekB]. Replika forwardera w każdej grupie przyjmuje log z grupy źródłowej i przekazuje go do lokalnych replik pomocniczych.

Monitorowanie i strojenie wydajności

Bieżące monitorowanie Availability Groups wymaga śledzenia kilku krytycznych metryk, które bezpośrednio przekładają się na RPO i RTO:

• RPO (Recovery Point Objective) — mierzone przez log_send_queue_size na replice głównej. W trybie synchronicznym wartość powinna oscylować wokół zera. Wzrost kolejki wskazuje na opóźnienie sieciowe lub przeciążenie replik pomocniczych.
• RTO (Recovery Time Objective) — zależne od redo_queue_size na replikach pomocniczych. Redo queue to liczba KB dziennika transakcyjnego czekającego na odtworzenie. SQL Server 2022 z ADR redukuje wpływ redo queue na RTO do pomijalnego poziomu.
• Estimated data loss (szacowana utrata danych) — dla replik asynchronicznych, różnica między LSN (Log Sequence Number) ostatniej transakcji utwardzonej na replice głównej a replice pomocniczej, dostępna przez sys.dm_hadr_database_replica_states.
• Failover readiness — sprawdzenie, czy replika pomocnicza jest w stanie SYNCHRONIZED i czy jej tryb failover pozwala na automatyczne przełączenie. Kolumna is_failover_ready w DMV sys.dm_hadr_database_replica_cluster_states.

Dla środowisk wieloreplikowych kluczowym parametrem strojenia jest równoległe odtwarzanie logu (parallel redo) — SQL Server 2022 domyślnie odtwarza dziennik transakcyjny na replikach pomocniczych w wielu wątkach, co eliminuje wąskie gardło pojedynczego wątku znane z wcześniejszych wersji. Równoległe redo wykorzystuje tyle wątków, ile rdzeni dostępnych jest na serwerze repliki pomocniczej — maksymalnie do 100 wątków.

Częste pytania

Czym różni się Always On Availability Group od Database Mirroring?

Database Mirroring to starsza technologia (wprowadzona w SQL Server 2005, przestarzała od SQL Server 2012), która replikuje pojedynczą bazę danych między dokładnie dwoma serwerami — głównym (principal) i lustrzanym (mirror). Availability Groups replikują grupy baz danych między maksymalnie 9 replikami (1 główna + 8 pomocniczych w Enterprise 2022), umożliwiają czytanie z replik pomocniczych i oferują listener do automatycznego przekierowania połączeń. Database Mirroring nie jest już rozwijany i Microsoft rekomenduje migrację do AG.

Czy potrzebuję licencji SQL Server Enterprise dla każdej repliki?

Tak, każda replika wymaga pełnej licencji SQL Server. W przypadku replik pasywnych (nieobsługujących odczytów i nieprzyjmujących backupów) Microsoft oferuje licencjonowanie Fail-Over Rights w ramach Software Assurance — replika pasywna nie wymaga dodatkowej licencji, o ile jest używana wyłącznie do celów failoveru. Jeśli replika pomocnicza obsługuje odczyty raportowe, wymaga osobnej licencji Enterprise.

Czy mogę używać Always On na SQL Server Standard?

SQL Server 2022 Standard Edition wspiera Basic Availability Groups — ograniczoną wersję AG z dokładnie dwiema replikami (jedna główna, jedna pomocnicza), bez możliwości odczytu z repliki pomocniczej i z obsługą tylko jednej bazy danych na grupę. Pełna funkcjonalność Always On — wiele replik, repliki czytelne, Distributed AG — wymaga edycji Enterprise.

Jakie opóźnienie sieciowe jest akceptowalne dla replikacji synchronicznej?

Microsoft rekomenduje opóźnienie poniżej 2 ms dla replikacji synchronicznej między replikami w tym samym centrum danych. W praktyce oznacza to konieczność fizycznego połączenia switchami z obsługą 10 GbE i RDMA. Opóźnienie powyżej 5 ms drastycznie wydłuża czas commitowania transakcji na replice głównej, co bezpośrednio wpływa na wydajność aplikacji produkcyjnych.

Co się stanie z Always On po utracie quorum klastra WSFC?

Po utracie quorum (np. awaria obu węzłów klastra dwuwęzłowego bez witness), cały klaster WSFC przechodzi w stan offline, a wszystkie grupy dostępności zostają zatrzymane — repliki główna i pomocnicze przechodzą w stan rozwiązywania (resolving). Bazy danych pozostają dostępne do odczytu i zapisu tylko na ostatniej znanej replice głównej, ale failover jest niemożliwy do czasu przywrócenia quorum.

Czy mogę mieszać wersje SQL Server w ramach jednej grupy dostępności?

Standardowa grupa dostępności wymaga tej samej wersji SQL Server na wszystkich replikach — np. wszystkie repliki SQL Server 2022 CU16. Distributed Availability Groups umożliwiają łączenie różnych wersji SQL Server (np. SQL Server 2017 i 2022), ale rekomenduje się, aby forwarder działał na nowszej wersji.

Jak automatyczny failover współpracuje z connection stringiem aplikacji?

Aplikacja musi używać MultiSubnetFailover=True w connection stringu oraz wskazywać listener grupy dostępności (nie bezpośredni adres IP serwera). Parametr ten zapewnia, że klient SQL Native Client równolegle próbuje połączyć się ze wszystkimi adresami IP listenera, co skraca czas przełączania po failoverze z domyślnych kilkudziesięciu sekund do 2–3 sekund.

Czy Always On zastępuje potrzebę wykonywania backupów?

Nie. Always On chroni przed awarią serwera i utratą dostępności, ale nie chroni przed logiczną utratą danych — przypadkowym usunięciem wierszy, atakiem ransomware czy błędem aplikacji. Każda transakcja wykonana na replice głównej (w tym błędna) jest replikowana na repliki pomocnicze. Regularne kopie zapasowe z retention policy pozostają obowiązkowym elementem strategii ochrony danych.

Czy Always On działa na Linuxie bez Active Directory?

Tak, SQL Server na Linuxie z Always On wymaga Pacemaker i corosync zamiast WSFC. Uwierzytelnienie endpointów mirroringu odbywa się przez certyfikaty X.509 zamiast Kerberos. Konfiguracja jest w pełni wspierana od SQL Server 2017 CU1 i w żadnym momencie nie wymaga przyłączenia do domeny Active Directory.

Ile czasu zajmuje synchronizacja po dodaniu nowej repliki?

Czas synchronizacji zależy od rozmiaru bazy danych i przepustowości łącza sieciowego. SQL Server podczas dołączania repliki pomocniczej może skorzystać z mechanizmu automatic seeding (konfigurowalny przez SEEDING_MODE = AUTOMATIC), który przesyła pełną kopię bazy przez endpoint mirroringu, lub z ręcznego seedingu — przywrócenia kopii zapasowej na replice pomocniczej i dołączenia jej do grupy dostępności z poziomu tego backupu. Automatic seeding działa dobre dla baz do 100 GB; dla większych baz zaleca się seeding z backupu.