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


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
21.02.2019

Bezpieczeństwo sieci

Check Point Maestro i seria 6000
21.02.2019

Ochrona danych

Commvault IntelliSnap i ScaleProtect
21.02.2019

Ułatwienie telekonferencji

Plantronics Calisto 3200 i 5200
21.02.2019

Transformacja centrów danych

Fujitsu PRIMEFLEX for VMware vSAN

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.

Artykuł pochodzi z miesięcznika: IT Professional

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"