SQL Server Always On Availability Groups — konfiguracja krok po kroku (2026)

Always On Availability Groups to wbudowane w SQL Server rozwiązanie wysokiej dostępności i disaster recovery, które replikuje bazy danych na wiele serwerów i umożliwia automatyczne przełączanie w razie awarii. Poniższy przewodnik przeprowadzi Cię przez kompletną konfigurację — od wymagań wstępnych, przez utworzenie klastra WSFC, aż po uruchomienie grupy dostępności z listenerem.

W skrócie

• Always On AG wymaga Windows Server Failover Cluster (WSFC) oraz SQL Server Enterprise Edition (lub Standard Edition dla Basic AG — limit 2 repliki, 1 baza)
• Obsługuje 1 replikę główną (primary) i do 8 replik pomocniczych (secondary); do 5 z nich może działać w trybie synchronicznym
• Kluczowe komponenty: WSFC, Database Mirroring Endpoint, Availability Group, Listener
• W SQL Server 2025 (17.x) dodano wsparcie dla TLS 1.3 (TDS 8.0) w komunikacji między replikami
• Standard Edition obsługuje Basic Availability Groups (2 repliki, 1 baza) — wystarczające dla mniejszych środowisk
• Pełna konfiguracja zajmuje od 1 do 4 godzin w zależności od środowiska

Czym są Always On Availability Groups

Always On Availability Groups (AG) to technologia wysokiej dostępności (HA) i odzyskiwania po awarii (DR) wprowadzona w SQL Server 2012 i stale rozwijana w kolejnych wersjach. W przeciwieństwie do starszego database mirroring (przestarzałego), AG działa na poziomie grupy baz danych, a nie pojedynczej bazy — wszystkie bazy w grupie przełączają się razem.

Grupa dostępności składa się z replik — każda replika to osobna instancja SQL Server na osobnym węźle klastra WSFC. Replika główna (primary) przyjmuje operacje odczytu i zapisu, a repliki pomocnicze (secondary) otrzymują strumień transakcji logu i mogą być skonfigurowane do odczytu (read-only routing) lub wykonywania backupów.

Dostępne tryby synchronizacji

W trybie synchronicznym replika główna czeka na potwierdzenie zapisu logu przez replikę pomocniczą przed zatwierdzeniem transakcji. W trybie asynchronicznym transakcje są zatwierdzane natychmiast, bez oczekiwania — co jest szybsze, ale niesie ryzyko utraty ostatnich transakcji przy awarii.

Wymagania wstępne — co musisz mieć przed rozpoczęciem

Przed przystąpieniem do konfiguracji Always On AG upewnij się, że spełniasz wszystkie poniższe warunki. Pominięcie któregokolwiek z nich to najczęstsza przyczyna niepowodzeń.

1. Windows Server Failover Cluster (WSFC)

• Wszystkie serwery muszą być węzłami tej samej domeny Active Directory i tego samego klastra WSFC
• Nie instaluj na kontrolerze domeny — AG nie jest wspierane na DC
• Minimalnie 2 węzły (dla Basic AG) lub więcej; każdy węzeł może hostować tylko jedną replikę danej grupy dostępności
• System: Windows Server 2016 lub nowszy (dla SQL Server 2022/2025 zalecany Windows Server 2022/2025)

2. SQL Server — wymagania edycyjne

Wszystkie instancje SQL Server w grupie dostępności muszą być tej samej wersji i mieć takie samo sortowanie (collation).

3. Pozostałe wymagania techniczne

• Bazy danych: model pełnego odzyskiwania (full recovery), co najmniej jedna pełna kopia zapasowa, baza nie może być skonfigurowana z AUTO_CLOSE
• Konta usług: zalecane użycie kont domenowych; jeśli używasz Built-in (Local System), konieczne będzie uwierzytelnianie certyfikatami dla endpointów
• Sieć: dedykowana karta sieciowa dla ruchu AG między replikami, otwarty port TCP dla endpointu database mirroring (domyślnie 5022)
• Przestrzeń dyskowa: identyczna na wszystkich replikach — ścieżki plików .mdf i .ldf muszą być dostępne (lub użyj RESTORE WITH MOVE)

Konfiguracja krok po kroku

Krok 1: Włącz Always On Availability Groups na każdej instancji

Na każdej instancji SQL Server, która będzie hostować replikę:

1. Otwórz SQL Server Configuration Manager
2. Wybierz SQL Server Services, kliknij prawym na instancję SQL Server → Właściwości
3. Przejdź do zakładki Always On Availability Groups
4. Zaznacz Enable Always On Availability Groups
5. Zrestartuj usługę SQL Server

Alternatywnie — przez PowerShell (jako administrator):

Enable-SqlAlwaysOn -ServerInstance "NazwaSerwera\Instancja" -Force

Krok 2: Utwórz endpoint Database Mirroring

Endpoint to kanał komunikacji między replikami. Utwórz go na każdej instancji:

CREATE ENDPOINT [Hadr_endpoint]
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );
GO

-- Nadaj uprawnienia kontu usługi
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DOMENA\konto_uslugi_sql];
GO

Ważne: jeśli instancje używają wbudowanych kont (Local System), zamiast WINDOWS NEGOTIATE użyj uwierzytelniania certyfikatami — utwórz certyfikat na każdej instancji i wymień klucze publiczne.

Krok 3: Przygotuj bazy danych

Dla każdej bazy, którą chcesz dodać do AG:

-- Ustaw pełny model odzyskiwania
ALTER DATABASE [NazwaBazy] SET RECOVERY FULL;
GO

-- Wykonaj pełną kopię zapasową
BACKUP DATABASE [NazwaBazy] TO DISK = 'E:\Backup\NazwaBazy_full.bak'
    WITH FORMAT, COMPRESSION;
GO

-- Wykonaj backup logu transakcyjnego
BACKUP LOG [NazwaBazy] TO DISK = 'E:\Backup\NazwaBazy_log.trn';
GO

Krok 4: Utwórz grupę dostępności

Użyj kreatora w SQL Server Management Studio (SSMS) lub T-SQL:

SSMS (zalecane dla pierwszej konfiguracji):

1. Object Explorer → Always On High Availability → prawy klik → New Availability Group Wizard
2. Podaj nazwę grupy, wybierz bazy danych, określ repliki i ich tryby synchronizacji
3. Wybierz metodę synchronizacji początkowej (zalecane: Full — automatycznie wykona backup/restore na secondary)
4. Utwórz Availability Group Listener (nazwa DNS, IP, port)
5. Zweryfikuj podsumowanie i kliknij Finish

T-SQL (dla zaawansowanych):

CREATE AVAILABILITY GROUP [AG_NazwaGrupy]
    FOR DATABASE [Baza1], [Baza2]
    REPLICA ON
        N'Serwer1' WITH (
            ENDPOINT_URL = 'TCP://Serwer1.domena.local:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = AUTOMATIC,
            SECONDARY_ROLE (
                READ_ONLY_ROUTING_URL = 'TCP://Serwer1.domena.local:1433'
            )
        ),
        N'Serwer2' WITH (
            ENDPOINT_URL = 'TCP://Serwer2.domena.local:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = AUTOMATIC,
            SECONDARY_ROLE (
                READ_ONLY_ROUTING_URL = 'TCP://Serwer2.domena.local:1433'
            )
        );
GO

Krok 5: Dołącz repliki pomocnicze i bazy danych

Na każdej instancji secondary:

-- Dołącz replikę do grupy dostępności
ALTER AVAILABILITY GROUP [AG_NazwaGrupy] JOIN;
GO

-- Dla każdej bazy — przywróć backup z NORECOVERY i dołącz
RESTORE DATABASE [Baza1] FROM DISK = 'E:\Backup\Baza1_full.bak'
    WITH NORECOVERY;
RESTORE LOG [Baza1] FROM DISK = 'E:\Backup\Baza1_log.trn'
    WITH NORECOVERY;

ALTER DATABASE [Baza1] SET HADR AVAILABILITY GROUP = [AG_NazwaGrupy];
GO

Jeśli używasz kreatora SSMS z opcją Full synchronizacji początkowej, te kroki zostaną wykonane automatycznie.

Krok 6: Skonfiguruj Availability Group Listener

Listener to wirtualna nazwa DNS, która zawsze wskazuje na aktualną replikę primary — aplikacje łączą się przez listener, nie przez nazwy serwerów fizycznych.

ALTER AVAILABILITY GROUP [AG_NazwaGrupy]
    ADD LISTENER N'AG_Listener' (
        WITH IP (
            ('10.0.0.100', '255.255.255.0')
        ),
        PORT = 1433
    );
GO

Connection string aplikacji powinien zawierać: Server=tcp:AG_Listener.domena.local,1433; Database=Baza1; MultiSubnetFailover=True;

Typowe problemy i ich rozwiązywanie

"Enable Always On jest wyszarzone / niedostępne"

Przyczyna: instancja SQL Server nie jest na węźle klastra WSFC lub usługa nie ma uprawnień. Upewnij się, że serwer jest członkiem klastra (sprawdź w Failover Cluster Manager) i że konto usługi SQL Server ma prawa administratora lokalnego.

"Endpoint nie może nasłuchiwać — port 5022 zajęty"

Sprawdź, która aplikacja używa portu: netstat -ano | findstr 5022. Zmień port endpointu na wolny (np. 5023) i zaktualizuj ENDPOINT_URL we wszystkich replikach.

"Baza danych nie synchronizuje się — stan NOT SYNCHRONIZING"

Najczęstsze przyczyny:

• Backup logu nie został odtworzony na secondary z NORECOVERY
• Brak zgodności ścieżek plików między serwerami (użyj RESTORE WITH MOVE)
• Firewall blokuje port endpointu między serwerami — sprawdź Test-NetConnection Serwer2 -Port 5022

"Automatyczny failover nie działa mimo konfiguracji SYNCHRONOUS + AUTOMATIC"

Sprawdź:

1. Czy replika secondary jest w stanie SYNCHRONIZED (nie SYNCHRONIZING)
2. Czy klaster WSFC ma quorum — minimum głosów do podjęcia decyzji o przełączeniu
3. Sprawdź flexible failover policy — domyślnie wymaga, by secondary był zsynchronizowany, a klaster miał quorum

"Listener nie odpowiada — aplikacje nie mogą się połączyć"

Upewnij się, że:

• Nazwa DNS listenera jest zarejestrowana w Active Directory i rozwiązywalna (nslookup AG_Listener)
• Port listenera (domyślnie 1433) jest otwarty na firewallu
• Connection string zawiera MultiSubnetFailover=True (szczególnie ważne w konfiguracjach wielopodsieciowych)

Częste pytania

Czy Always On Availability Groups wymaga SQL Server Enterprise Edition?

Tak — pełne Always On AG (więcej niż 2 repliki, wiele baz danych) wymaga Enterprise Edition. Standard Edition obsługuje Basic Availability Groups — ograniczone do 2 replik i 1 bazy danych, ale wciąż zapewniające wysoką dostępność dla mniejszych wdrożeń. Developer Edition (bezpłatna, tylko do celów deweloperskich/testowych) obsługuje pełną funkcjonalność Enterprise.

Jaka jest różnica między Always On AG a Failover Cluster Instance (FCI)?

FCI chroni na poziomie całej instancji SQL Server — jeśli serwer fizyczny ulegnie awarii, cała instancja (wraz ze wszystkimi bazami) przełącza się na inny węzeł korzystający ze współdzielonej macierzy (SAN). AG chroni na poziomie grupy baz danych — każda replika ma własną kopię danych, nie ma pojedynczego punktu awarii jak macierz współdzielona. Możesz łączyć obie technologie: FCI wewnątrz AG dla maksymalnej odporności.

Ile replik mogę mieć w grupie dostępności?

Maksymalnie 9 replik: 1 primary + 8 secondary. Z tego do 5 replik (1 primary + 4 secondary) może działać w trybie synchronous commit. Dla Basic AG (Standard Edition) limit wynosi 2 repliki.

Czy mogę używać Always On AG w środowisku bez domeny Active Directory?

Na Windows — nie. WSFC wymaga domeny Active Directory. Na Linux można używać AG z Pacemakerem bez domeny. Istnieje też read-scale availability group (bez klastra, bez automatycznego failover), ale jest ona przeznaczona wyłącznie do odciążania odczytów, nie do wysokiej dostępności.

Jak skonfigurować odczyty z replik secondary (read-only routing)?

Skonfiguruj read-only routing list dla grupy dostępności:

ALTER AVAILABILITY GROUP [AG_NazwaGrupy]
    MODIFY REPLICA ON N'Serwer1' WITH
    (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('Serwer2', 'Serwer1')));

Następnie aplikacje muszą łączyć się przez listener z parametrem ApplicationIntent=ReadOnly w connection stringu. Listener automatycznie przekieruje zapytania odczytu do najbliższej dostępnej repliki secondary.

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

Nie. Repliki secondary nie są backupami — to kopie online odzwierciedlające bieżący stan bazy. Jeśli przypadkowo usuniesz dane na primary, zmiana zostanie natychmiast zreplikowana na secondary. Zawsze wykonuj regularne backupy — możesz je zlecać na replikach secondary (copy-only full, log), by odciążyć primary.

Co nowego w Always On AG w SQL Server 2025?

SQL Server 2025 (17.x) wprowadza:

• TLS 1.3 (TDS 8.0) — wymuszone szyfrowanie komunikacji między replikami i listenerem
• Contained availability groups — replikacja uprawnień na poziomie bazy wraz z danymi
• Większa wydajność parallel redo na secondary
• Lepsza integracja z Azure Arc do monitorowania AG w chmurze

Gotowe licencje SQL Server dla Twojej konfiguracji Always On

Konfiguracja Always On Availability Groups wymaga odpowiedniej edycji SQL Server. W KluczeSoft.pl znajdziesz legalne, pełnowartościowe licencje w cenach nawet 70% niższych od oficjalnego cennika Microsoft, z natychmiastową dostawą na e-mail:

→ Licencje SQL Server — sprawdź dostępne edycje

KluczeSoft.pl jest niezależnym sprzedawcą — nie jesteśmy powiązani z Microsoft Corporation.