Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



22.03.2019

Pożegnanie z systemem Windows...

System operacyjny Windows 7 wciąż cieszy się dużą popularnością wśród użytkowników...
22.03.2019

Segmentacja sieci

Fortinet FortiGate 3600E, 3400E, 600E i 400E
22.03.2019

Monitoring IP

TP-Link TL-SL1218MP
22.03.2019

Efektywność energetyczna

UPS Eaton 93E
21.02.2019

Wdrażanie projektów AI

Infrastruktura OVH
21.02.2019

Certyfikacja kluczy

HEUTHES-CAK
21.02.2019

Kopie zapasowe

Veeam Availability for AWS
21.02.2019

Dysk SSD Samsung 970 EVO Plus

Dysk SSD Samsung 970 EVO Plus
21.02.2019

Szyfrowane USB

Kingston IronKey D300 Serialized

Wysoka dostępność serwerów SQL. Grupy wysoko dostępnych baz danych

Data publikacji: 26-11-2018 Autor: Marcin Szeliga
Rys. 1. Włączenie opcji...

W drugim artykule z cyklu „Wysoka dostępność serwerów SQL” przyjrzymy się technologii AlwaysOn Availability Groups. Wprowadzona w wersji SQL Server 2012, szybko stała się najpopularniejszym sposobem zapewniania ciągłej dostępności baz danych i minimalizowania skutków awarii serwerów SQL.


Grupy wysoko dostępnych baz danych (AG) są technologią replikacji (powielania) baz danych pomiędzy serwerami SQL Server uzupełnioną o mechanizmy wykrywania awarii i automatycznego przełączania użytkowników na aktywny w danym momencie serwer. Dodatkowo zawierają one zestaw narzędzi administracyjnych, które upraszczają zarządzanie i monitorowanie pracy grup wysoko dostępnych baz danych.

 

Grupa AG może zawierać dowolną liczbę chronionych baz danych. W artykule opisujemy technologię AlwaysOn Availability Groups dostępną w ramach licencji SQL Server Enterprise Edition. Edycja SQL Server Standard oferuje ograniczoną pod wieloma względami wersję tej technologii o nazwie Basic Availability Groups. Lista tych ograniczeń jest dostępna pod adresem tinyurl.com/BasicAvailability.

Ochronę baz zapewnia do dziewięciu replik – osobnych instancji serwerów SQL Server – z których każda zawiera kopie należących do grupy AG baz danych. Każda replika musi działać na osobnym węźle klastra Windows (WSFC). W wersji Windows Server 2012 R2 wprowadzona została możliwość tworzenia klastrów WSFC, których węzły, choć muszą należeć do tej samej domeny AD, do pracy nie wymagają połączenia z kontrolerem domeny. W wersji Windows Server 2016 funkcja ta została uzupełniona o możliwość tworzenia klastrów WSFC z niepodłączonych do domeny AD komputerów. Oba typy klastrów mogą być używane przez grupy AG. Najważniejsze informacje o klastrach WSFC przedstawione zostały w pierwszej części artykułu („IT Professional” 11/2018, s. 28).

Wersja SQL Server 2017 umożliwia tworzenie grup AG z replik działających na wolnostojących (niebędących węzłami klastra) serwerach Windows. Rozwiązanie to nie zapewnia jednak ciągłej dostępności baz danych, ponieważ nie wspiera automatycznego przełączania użytkowników na aktywną replikę i nie gwarantuje braku utraty danych w przypadku awarii aktywnej repliki.

> SYNCHRONIZACJA DANYCH

Jedna (aktywna) replika bazy danych jest w pełni dostępna, pozostałe (pasywne) repliki albo nie są dostępne, albo są dostępne wyłącznie do odczytu. Synchronizacja danych pomiędzy aktywną i pasywnymi replikami odbywa się automatycznie i może zostać skonfigurowana dla każdej repliki w trybie synchronicznym lub asynchronicznym.

 

  • W trybie synchronicznym zmiany zostają zatwierdzone przez aktywną replikę dopiero po ich utrwaleniu przez pasywne repliki. Tryb ten gwarantuje, że wszystkie operacje potwierdzone przez aktywną replikę będą wykonane również przez jej pasywne, synchroniczne repliki. Ma on jednak bezpośredni wpływ na wydajność, bo aktywna replika potwierdzi wykonanie operacji dopiero po otrzymaniu ich utrwalenia przez wszystkie synchroniczne repliki. W tym trybie może działać do trzech replik.
  • W trybie asynchronicznym zmiany zostają zatwierdzone przez aktywną replikę natychmiast po ich wysłaniu do pasywnych replik. Oznacza to, że zmiany zatwierdzone przez aktywną replikę mogą po jej awarii zostać utracone, jeżeli nie zostały wysłane do pasywnej, asynchronicznej repliki. Z drugiej strony w tym trybie opóźnienie związane z przesyłaniem zmian do repliki nie ma bezpośredniego wpływu na wydajność.


Synchronizacja danych pomiędzy replikami przebiega następująco:

 

  • Aplikacja kliencka wysyła transakcję do aktywnej repliki.
  • Aktywna replika wykonuje żądaną operację, w tym zapisuje jej opis do pliku dziennika transakcyjnego.
  • Opis tej operacji zostaje skompresowany i wysłany do pasywnych replik. Jeżeli wszystkie repliki działają w trybie asynchronicznym, w tym momencie aktywna replika wysyła do aplikacji klienckiej potwierdzenie wykonania transakcji.
  • Pasywne repliki odbierają opis transakcji, zapisują go w plikach dzienników transakcyjnych i wysyłają do aktywnej repliki potwierdzenie utrwalenia transakcji.
  • Po odebraniu potwierdzeń od replik działających w trybie synchronicznym aktywna replika wysyła do aplikacji klienckiej potwierdzenie wykonania transakcji.
  • W międzyczasie pasywne repliki wykonują tę samą operację, która została wykonana przez aktywną replikę.


[...]

Pracownik naukowy Wyższej Szkoły Bankowej w Poznaniu Wydział Zamiejscowy w Chorzowie; jest autorem książek poświęconych analizie danych i posiada tytuł Microsoft Most Valuable Professional w kategorii Artificial Intelligence.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"