Czy Subiekt GT wspiera replikację danych w razie awarii?

Subiekt GT wspiera replikację danych w razie awarii poprzez standardowe mechanizmy wysokiej dostępności SQL Server.

Subiekt GT a mechanizm replikacji bazy danych

Subiekt GT nie jest samodzielnym systemem wysokiej dostępności i nie zawiera własnego mechanizmu przełączania aplikacji między serwerami. Dane programu są przechowywane w bazie Microsoft SQL Server, dlatego możliwość ich kopiowania lub utrzymywania na drugim serwerze zależy przede wszystkim od użytej edycji i wersji SQL Server, konfiguracji środowiska oraz sposobu uruchamiania samego Subiekta GT. W praktyce trzeba rozdzielić funkcje programu handlowego od funkcji silnika bazodanowego.

SQL Server udostępnia kilka mechanizmów związanych z ciągłością działania i odtwarzaniem danych. Nie wszystkie są jednak replikacją w tym samym znaczeniu. Replikacja SQL Server służy przede wszystkim do przekazywania zmian z jednej bazy do innych baz, natomiast rozwiązania wysokiej dostępności mają zapewnić możliwość uruchomienia tej samej usługi po awarii podstawowego serwera. Sam fakt używania SQL Server nie oznacza więc automatycznie, że Subiekt GT będzie działał w trybie bezprzerwowym po awarii.

Always On i inne funkcje SQL Server

W środowiskach wykorzystujących odpowiednią edycję SQL Server można zastosować grupy dostępności Always On. Podstawowa replika przyjmuje operacje zapisu, a replika pomocnicza otrzymuje zmiany dziennika transakcji. Po awarii podstawowej bazy możliwe jest przełączenie roli na replikę pomocniczą, ale zakres automatyzacji zależy od konfiguracji, trybu zatwierdzania transakcji, obecności klastra oraz ustawień punktu połączenia. Konfiguracja ta dotyczy SQL Server, a nie wewnętrznego kodu Subiekta GT.

Drugim rozwiązaniem jest SQL Server Failover Cluster Instance, czyli instancja SQL Server uruchamiana w ramach klastra pracy awaryjnej. W tym modelu przełączana jest usługa instancji wraz z zasobami, z których korzysta baza. Inną funkcją jest log shipping, polegający na regularnym wykonywaniu kopii dziennika transakcji i odtwarzaniu ich na serwerze pomocniczym. Log shipping jest mechanizmem odtwarzania po awarii, lecz zwykle wiąże się z określonym opóźnieniem między bazą główną a kopią.

Nie należy utożsamiać wysokiej dostępności z replikacją transakcyjną. Replikacja transakcyjna publikuje wybrane zmiany do subskrybentów i wymaga zaprojektowania topologii, zakresu artykułów oraz kierunku przepływu danych. Nie stanowi prostego zamiennika kopii zapasowej ani automatycznego przełącznika dla całej bazy Subiekta GT. W przypadku programu korzystającego z wielu powiązanych tabel częściowa replikacja mogłaby prowadzić do niespójności funkcjonalnej, jeżeli nie obejmowałaby wszystkich wymaganych obiektów i zależności.

Warunki bezpiecznego przełączenia po awarii

Żeby rozwiązanie wysokiej dostępności było użyteczne dla Subiekta GT, trzeba zachować spójność całej bazy oraz zapewnić aplikacji dostęp do właściwego serwera SQL Server po zmianie roli. Znaczenie ma między innymi sposób zapisania parametrów połączenia, nazwa instancji, adres używany przez stanowiska robocze oraz dostępność udziałów i innych zasobów wymaganych przez środowisko programu. Przełączenie samej bazy bez prawidłowego skierowania aplikacji do aktywnej repliki może zakończyć się komunikatem o braku połączenia.

Przed wdrożeniem należy ustalić, czy używana edycja SQL Server obsługuje wybrany mechanizm. Funkcje Always On mają ograniczenia zależne od edycji i wersji, a SQL Server Express nie zapewnia pełnego zestawu funkcji dostępności dostępnych w edycjach serwerowych. Nie można również zakładać, że każda konfiguracja klastrowa będzie obsługiwana przez producenta aplikacji handlowej. Wymagane jest sprawdzenie dokumentacji Subiekta GT, dokumentacji konkretnej wersji SQL Server oraz warunków licencyjnych.

Replikacja lub kopia pomocnicza nie zastępuje regularnych kopii zapasowych. Błąd użytkownika, usunięcie danych, wadliwa operacja wykonana na bazie albo zaszyfrowanie plików może zostać przeniesione na replikę razem z poprawnymi zmianami. Dlatego potrzebne są niezależne kopie pełne i kopie dziennika transakcji, kontrola ich poprawności oraz okresowe próby odtworzenia. Dopiero połączenie kopii zapasowych z odpowiednio zaprojektowanym mechanizmem SQL Server daje realną ochronę przed różnymi scenariuszami awarii.

Diagnostyka konfiguracji bazy Subiekta GT

Ocena możliwości replikacji powinna rozpocząć się od ustalenia, gdzie znajduje się baza Subiekta GT, jaka instancja SQL Server ją obsługuje oraz jaka edycja i wersja silnika jest zainstalowana. Następnie sprawdza się sposób wykonywania kopii, dostępność dzienników transakcji, rozmiar bazy, historię błędów SQL Server i obecność zależności od lokalnej nazwy komputera. Ważne jest także zweryfikowanie, czy wszystkie stanowiska korzystają z tego samego punktu połączenia i czy po awarii potrafią odnaleźć aktywną instancję.

Test powinien obejmować nie tylko techniczne przełączenie serwera, lecz także uruchomienie Subiekta GT, odczyt dokumentów, zapis nowego dokumentu oraz sprawdzenie operacji wykonywanych przez kilka stanowisk. Należy potwierdzić, że transakcje zapisane przed awarią są dostępne, a transakcje rozpoczęte w chwili przerwania połączenia nie pozostawiły niepełnych danych. Wynik takiego testu powinien wskazywać przewidywaną utratę danych, czas odtworzenia oraz czynności konieczne do powrotu do normalnej pracy.

Wniosek jest więc warunkowy: Subiekt GT może korzystać z ochrony zapewnianej przez mechanizmy SQL Server, ale nie oznacza to wbudowanego, automatycznego wsparcia replikacji przez sam program. Ostateczna odpowiedź zależy od konkretnej edycji SQL Server, topologii, licencji, konfiguracji połączeń i sprawdzenia działania po kontrolowanej awarii.