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



20.12.2018

Większa moc

QNAP Mustang-200
20.12.2018

Nowa era Wi-Fi

NETGEAR Nighthawk AX8
20.12.2018

Szybkie skanowanie

Brother ADS-1700W i ADS-1200
06.12.2018

Niższe moce

UPS Eaton 9SX
03.12.2018

Monitory dla MŚP

AOC E1
29.11.2018

Wykrycie szkodliwego...

Sophos Intercept X Advanced
27.11.2018

Automatyzacja zabezpieczeń

Red Hat Ansible Automation
23.11.2018

Nieograniczona skalowalność

SUSE Enterprise Storage 5.5
20.11.2018

Dwa procesory Threadripper

AMD Ryzen Threadripper 2970WX i 2920X

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 © 2013 Presscom / Miesięcznik "IT Professional"