SQL Server Failover Cluster Instance (FCI) i Always On Availability Groups (AG) to dwa główne mechanizmy wysokiej dostępności (HA) i odzyskiwania po awarii (DR) w Microsoft SQL Server, które zasadniczo różnią się poziomem ochrony: FCI chroni na poziomie całej instancji serwera przez współdzieloną macierz dyskową, natomiast AG chroni na poziomie konkretnych baz danych przez replikację transakcji między niezależnymi serwerami. W środowiskach produkcyjnych obie technologie często łączy się ze sobą — AG zapewnia elastyczną replikację baz, a FCI podnosi odporność każdego węzła AG niezależnie.
Werdykt w 30 sekund:
- FCI = jeden serwer SQL widoczny w sieci, uruchomiony na 2+ węzłach klastra Windows, wszystkie węzły widzą te same dane na współdzielonej macierzy (SAN, SMB, Storage Spaces Direct). Awaria węzła → automatyczne przejęcie przez drugi węzeł w < 2 minuty. Chroni instancję, ale nie dane — uszkodzenie macierzy = awaria całkowita.
- AG = replikacja każdej bazy danych między 2–9 serwerami (do 8 replik dodatkowych w Enterprise). Każdy serwer ma własne dyski. Awaria głównej repliki → przełączenie na replikę dodatkową (automatyczne lub ręczne) w ciągu sekund. Chroni dane, ale wymaga osobnej konfiguracji dla każdej bazy.
- FCI + AG razem = najlepsze z obu światów: każdy węzeł AG jest jednocześnie klastrem FCI, co daje odporność sprzętową węzłów i geograficzną replikację danych.
W skrócie
| Kryterium | FCI | Always On AG |
|---|---|---|
| Poziom ochrony | Instancja SQL Server | Baza danych (per database) |
| Punkt awarii (SPOF) | Macierz dyskowa | Brak — każda replika ma własny storage |
| Maks. liczba węzłów | 16 (Enterprise), 2 (Standard) | 9 replik (1 primary + 8 secondary) w Enterprise; 2 repliki w Basic AG (Standard) |
| Storage | Współdzielony (SAN, SMB, S2D) | Własny na każdym serwerze |
| Odległość między węzłami | To samo centrum danych (lub metro cluster) | Dowolna — replikacja async działa między kontynentami |
| Automatyczny failover | Tak, przez WSFC | Tak (tylko sync commit + auto failover) |
| Czas failover | 30 s – 2 min (zależnie od checkpointów) | < 30 s dla sync; zmienny dla async |
| Odczyt z replik dodatkowych | Nie (tylko jeden aktywny węzeł) | Tak — readable secondaries |
| Backup z replik | Nie | Tak (copy-only, od SQL Server 2025 także full/differential) |
| Koszty licencyjne | Licencja na każdy węzeł (chyba że pasywny) | Analogicznie — każda replika wymaga licencji (z wyjątkami dla pasywnych) |
| Wymagania sieciowe | Standard LAN (dla heartbeat) | Niskie opóźnienia dla sync; async działa przez WAN |
| Kompleksowość konfiguracji | Średnia (WSFC + storage) | Wysoka (WSFC + replikacja + listener) |
| SQL Server 2025 nowości | TLS 1.3 + TDS 8.0 (strict encryption) | TLS 1.3 + TDS 8.0, fast failover, ulepszona diagnostyka |
Czym jest Failover Cluster Instance (FCI)
Failover Cluster Instance to pojedyncza instancja SQL Server zainstalowana jednocześnie na wielu serwerach (węzłach klastra Windows Server Failover Clustering — WSFC). W danej chwili tylko jeden węzeł aktywnie obsługuje ruch — pozostałe pozostają w trybie pasywnym, gotowe do przejęcia. Wszystkie węzły widzą te same pliki danych i logów transakcyjnych na współdzielonej macierzy dyskowej (SAN, iSCSI, Fiber Channel, SMB 3.0 lub Storage Spaces Direct).
Klienci łączą się z FCI przez wirtualną nazwę sieciową (VNN) i wirtualny adres IP — nie muszą wiedzieć, który fizyczny węzeł jest aktywny. W przypadku awarii sprzętu, systemu operacyjnego lub samej usługi SQL Server, WSFC automatycznie przenosi własność grupy zasobów na inny węzeł. Proces obejmuje: zapisanie "brudnych stron" z bufora na dysk, zatrzymanie usług na dotychczasowym węźle, przeniesienie zasobów (dyski, IP, nazwa sieciowa) i uruchomienie SQL Server na nowym węźle.
Kluczowe cechy FCI
- Jeden zestaw danych — nie ma replikacji, nie ma synchronizacji; dane fizycznie istnieją w jednym miejscu.
- Ochrona na poziomie instancji — wszystkie bazy, loginy, agent jobs, SSIS, linked servers są automatycznie objęte ochroną.
- Brak konfiguracji per baza — dodajesz bazę i jest chroniona automatycznie.
- Macierz to pojedynczy punkt awarii (SPOF) — awaria storage'u = awaria całego FCI.
- Wymaga identycznego sprzętu/OS/SQL na wszystkich węzłach — każdy węzeł musi mieć ten sam patch level, te same ścieżki instalacji.
- Ograniczony geograficznie — w praktyce do jednego centrum danych (lub dwóch bardzo bliskich z replikacją storage).
Wspierane edycje i limity (SQL Server 2022/2025)
- Enterprise: do 16 węzłów
- Standard: dokładnie 2 węzły
- Express/Web: nie wspierają FCI
Czym są Always On Availability Groups
Always On Availability Groups to technologia replikacji baz danych wprowadzona w SQL Server 2012, która w 2026 roku jest już dojrzałym, sprawdzonym rozwiązaniem. AG działa na poziomie grupy baz danych (availability group), które są replikowane między wieloma niezależnymi instancjami SQL Server. Każda instancja ma własny storage — nie ma współdzielonej macierzy, nie ma SPOF na poziomie dysków.
W skład availability group wchodzi:
- Jedna replika główna (primary) — przyjmuje zapisy i odczyty.
- 1–8 replik dodatkowych (secondary) — otrzymują dane przez replikację logów transakcyjnych.
- Listener AG — wirtualna nazwa sieciowa kierująca ruch do odpowiedniej repliki.
Tryby synchronizacji
| Tryb | Jak działa | Ryzyko utraty danych | Zastosowanie |
|---|---|---|---|
| Synchronous commit | Primary czeka na potwierdzenie zapisu na secondary przed commit | Zero | HA w jednym DC, < 5 ms latency |
| Asynchronous commit | Primary commit nie czeka na secondary | Możliwa utrata (seconds of data) | DR między lokalizacjami |
Tryby failover
- Automatyczny (bez utraty danych) — tylko sync commit, obie repliki ustawione na "automatic failover".
- Ręczny planowany (bez utraty danych) — sync commit, administrator ręcznie przełącza.
- Wymuszony (forced) — async lub awaryjnie; możliwa utrata danych.
Kluczowe cechy AG
- Ochrona per baza — musisz jawnie dodać każdą bazę do availability group.
- Brak SPOF na storage — każda replika ma własne dyski; awaria macierzy nie wyłącza całej grupy.
- Readable secondaries — repliki dodatkowe mogą obsługiwać odczyty (odciążenie primary, reporting).
- Backup z secondary — możesz wykonywać backupy logów i copy-only full z replik dodatkowych (od SQL 2025 także pełne backupy i różnicowe).
- Dowolna odległość geograficzna — async commit działa przez WAN, zapewniając disaster recovery.
- Listener AG — jedna nazwa DNS do łączenia, automatycznie przekierowuje po failoverze.
- Automatic page repair — uszkodzone strony są automatycznie naprawiane z innej repliki.
Wspierane edycje i limity
- Enterprise: do 9 replik (1 primary + 8 secondary), z czego do 5 w sync commit; pełna funkcjonalność.
- Standard (Basic AG): dokładnie 2 repliki, jedna baza na grupę; bez readable secondaries, bez backup z secondary, tylko tryb synchronous. To nie jest pełnoprawny AG — to następca database mirroring.
Porównanie szczegółowe: FCI vs AG
| Obszar | FCI | Always On AG |
|---|---|---|
| Co chroni | Całą instancję SQL (wszystkie bazy, agent, loginy, linked servers) | Wybrane bazy danych |
| Storage | Współdzielony (SAN, SMB, S2D) — SPOF | Niezależny per węzeł — brak SPOF |
| Replikacja danych | Brak — jeden fizyczny zestaw plików | Replikacja logów transakcyjnych |
| Opóźnienie danych | Brak | Sync: zerowe (przy commit); Async: kilka sekund |
| Odległość między węzłami | Ograniczona (storage latency) — typowo < 10 km | Nieograniczona dla async; sync wymaga < 5 ms RTT |
| Czas failover | 30 s – 2 minuty | < 30 s (sync + auto failover) |
| Wykorzystanie sprzętu | Pasywne węzły marnują zasoby | Secondary mogą obsługiwać odczyty i backupy |
| Złożoność licencjonowania | Każdy węzeł FCI wymaga licencji (z wyjątkiem 1 pasywnego na umowie SA) | Każda replika wymaga licencji Enterprise/Standard |
| Instancje per węzeł | Jedna (FCI zajmuje całą instancję) | Wiele — jeden serwer może hostować repliki z wielu AG |
| Konfiguracja nowej bazy | Automatyczna — dodajesz i jest chroniona | Ręczna — backup/restore z NORECOVERY, join do AG |
| Automatyczny failover | Tak (WSFC) | Tak (tylko sync + auto) |
| Odzyskiwanie po awarii storage | Tylko backup/restore | Failover na inną replikę |
Kiedy wybrać FCI, a kiedy AG
Wybierz FCI gdy:
- Potrzebujesz ochrony całej instancji bez konfiguracji per baza (działy finansowe, systemy legacy z wieloma małymi bazami).
- Masz już inwestycję w macierz SAN i akceptujesz ją jako SPOF (z backupem oczywiście).
- Używasz Standard Edition z ograniczonym budżetem — FCI na 2 węzłach jest prostsze niż Basic AG.
- Nie potrzebujesz readable secondaries ani geograficznego DR na poziomie SQL (DR robisz na poziomie storage lub backup).
- Masz krytyczne obiekty na poziomie instancji (loginy, SQL Agent jobs, linked servers), które muszą być objęte ochroną automatycznie.
Wybierz Always On AG gdy:
- Potrzebujesz disaster recovery między lokalizacjami (np. primary w Warszawie, secondary we Frankfurcie).
- Chcesz odciążyć primary przez readable secondaries (zapytania raportowe na secondary).
- Masz krytyczne bazy, ale nie całą instancję — chronisz tylko to, co ważne.
- Nie chcesz mieć SPOF na storage — każdy węzeł ma własne dyski.
- Potrzebujesz szybkiego failover (< 30 s) z zerową utratą danych.
- Prowadzisz backupy z secondary, odciążając primary.
Wybierz FCI + AG (architektura hybrydowa) gdy:
- Potrzebujesz maksymalnej dostępności dla najbardziej krytycznych systemów.
- Każdy węzeł AG jest jednocześnie dwuwęzłowym FCI — otrzymujesz zarówno odporność sprzętową, jak i geograficzną replikację.
- Uwaga: FCI jako replika w AG nie wspiera automatycznego failover AG — tylko ręczny. Automatyczny failover w AG działa tylko między standalone instances.
SQL Server 2025 — co nowego w HA
Wersja 2025 (17.x) wprowadziła istotne ulepszenia dla obu technologii:
- TLS 1.3 + TDS 8.0 — obowiązkowe szyfrowanie (strict encryption) komunikacji między węzłami WSFC a FCI oraz między replikami AG. To istotne podniesienie bezpieczeństwa.
- Fast failover dla AG — nowy parametr
RestartThreshold = 0wymusza natychmiastowe przełączenie przy wykryciu trwałego problemu zdrowotnego AG. - Ulepszona diagnostyka health check timeout — lepsze logowanie przyczyn timeoutów, co ułatwia root cause analysis.
- AG group commit w milisekundach — możliwość konfiguracji czasu oczekiwania na commit grupy w ms zamiast domyślnych wartości.
- Pełne i różnicowe backupy z secondary (nie tylko copy-only) — duże ułatwienie dla strategii backupu.
- Zwiększone limity Standard Edition: 32 rdzenie, 256 GB RAM, Resource Governor dostępny także w Standard.
- Persisted statistics na readable secondaries — lepsza wydajność zapytań raportowych na replikach.
Częste pytania
Czy FCI i Always On AG wymagają Windows Server Failover Clustering?
Tak, oba rozwiązania na Windows wymagają klastra WSFC. FCI używa go do zarządzania zasobami współdzielonymi i failoveru na poziomie instancji. AG używa WSFC do monitorowania zdrowia replik i koordynowania failoveru. Na Linux SQL Server używa Pacemaker zamiast WSFC. Od SQL Server 2017 istnieje też wariant read-scale AG bez klastra — replikuje dane, ale bez automatycznego failoveru.
Ile licencji SQL Server potrzebuję dla FCI i AG?
Dla FCI: każdy aktywny węzeł wymaga pełnej licencji. Jeśli posiadasz Software Assurance (SA), jeden pasywny węzeł FCI może działać bez dodatkowej licencji. Dla AG: każda replika (primary i secondary) wymaga licencji. Z SA przysługuje Ci jeden pasywny secondary bez dodatkowej licencji. Jeśli secondary obsługuje odczyty (readable secondary), zawsze wymaga licencji — nie jest wtedy "pasywny".
Czy mogę używać Always On AG w SQL Server Standard Edition?
Tak, ale w ograniczonej formie — Basic Availability Group. Obsługuje dokładnie 2 repliki i jedną bazę danych na grupę, tylko w trybie synchronous commit. Brak readable secondaries, brak backupów z secondary, brak listenera AG (używasz connection string z Failover Partner). Basic AG zastąpił przestarzałe database mirroring. W praktyce dla większości przypadków w Standard Edition lepszym wyborem jest dwuwęzłowe FCI, które chroni całą instancję.
Jaki jest rzeczywisty czas failover?
Dla FCI: typowo 30 sekund do 2 minut, zależnie od liczby "brudnych stron" w buforze do zapisania na dysk. Od SQL Server 2012 indirect checkpoints pozwalają kontrolować maksymalny RTO. Dla AG z synchronous commit: poniżej 30 sekund przy automatycznym failoverze. Dla async: zależnie od opóźnienia sieci i ilości niezsynchronizowanych transakcji — od kilkunastu sekund do kilku minut.
Czy FCI chroni przed awarią storage?
Nie — i to jest kluczowe ograniczenie. W FCI wszystkie węzły widzą tę samą macierz. Awaria macierzy oznacza awarię całego klastra. Dlatego w architekturach mission-critical łączy się FCI z AG: FCI chroni przed awarią serwera, a AG (z własnym storage na każdym węźle) chroni przed awarią macierzy i katastrofą całego centrum danych.
Czy mogę łączyć różne wersje SQL Server w AG?
Nie — wszystkie repliki w availability group muszą mieć tę samą wersję SQL Server (ten sam major version, np. wszystkie SQL Server 2022). Różne build numbers (CU/patch level) w obrębie tej samej wersji są dopuszczalne, ale niezalecane w produkcji. Podczas upgrade'u można tymczasowo mieć mieszane wersje w trakcie rolling upgrade. Distributed AG (wprowadzone w SQL Server 2016) pozwala łączyć różne wersje SQL Server między osobnymi availability groups.
Czy rozwiązania HA SQL Server wymagają Active Directory?
Tradycyjnie tak — WSFC wymaga domeny Active Directory dla uwierzytelniania i autoryzacji zasobów klastra. Od Windows Server 2012 R2 możliwe jest utworzenie klastra bez domeny (Workgroup Cluster), ale Microsoft oficjalnie wspiera tę konfigurację tylko z AG (nie z FCI). Od SQL Server 2017 na Linux nie ma wymogu AD — używa się certyfikatów, a na Windows od SQL Server 2022 wprowadzono wsparcie dla Microsoft Entra ID (dawniej Azure AD) jako alternatywy dla klasycznego AD.
Które rozwiązanie wybrać dla swojej firmy?
Wybór między FCI a AG — lub oboma naraz — zależy od krytyczności systemu, budżetu licencyjnego i akceptowalnego RTO/RPO. Dla małych firm korzystających ze Standard Edition dwuwęzłowe FCI pozostaje najprostszą drogą do wysokiej dostępności. Dla średnich i dużych organizacji na Enterprise Edition, Always On AG daje znacznie więcej elastyczności: geograficzne disaster recovery, odczyty z secondary, szybszy failover i brak SPOF na storage.
Niezależnie od wyboru architektury, podstawą jest posiadanie legalnych, aktywowanych licencji SQL Server — dotyczy to każdego węzła w klastrze i każdej repliki w AG. Jeśli planujesz wdrożenie lub modernizację środowiska SQL Server, sprawdź ofertę licencji:
→ Licencje Microsoft SQL Server — od sprawdzonych dostawców — legalne klucze do SQL Server 2022 i 2025 w cenie nawet 70% niższej niż sugerowana cena detaliczna.
Artykuł opracowano na podstawie oficjalnej dokumentacji Microsoft Learn (stan na maj 2026) — SQL Server 2022 (16.x) i SQL Server 2025 (17.x). KluczeSoft.pl jest niezależnym sprzedawcą oprogramowania i nie jest powiązany z Microsoft Corporation.