Replikacja transakcyjna

Replikacja transakcyjna przekazuje zmiany niemal w czasie rzeczywistym, odczytując je bezpośrednio z dziennika wydawcy.

Mechanizm replikacji transakcyjnej

Replikacja transakcyjna to mechanizm kopiowania zmian danych z jednej bazy do jednej lub wielu baz docelowych. Źródłowa baza pełni rolę wydawcy, a bazy odbierające są subskrybentami. Zmiany wykonane w transakcjach na wydawcy są wykrywane na podstawie dziennika transakcji, a następnie przekazywane do systemu dystrybucji i dalej do subskrybentów. Dzięki temu nie trzeba za każdym razem porównywać całej zawartości tabel ani wykonywać pełnego eksportu danych.

W praktyce replikacja transakcyjna służy do utrzymywania kopii danych przeznaczonych przede wszystkim do odczytu, raportowania albo obsługi dodatkowych aplikacji. Typowy przepływ obejmuje publikację wybranych artykułów, czyli tabel, widoków lub innych obiektów objętych replikacją, odczyt zmian z dziennika, zapis poleceń w bazie dystrybucyjnej oraz zastosowanie tych poleceń na subskrybencie. Przekazywane są operacje odpowiadające zmianom, takie jak wstawienie, modyfikacja lub usunięcie wiersza, a nie tylko końcowy stan całej tabeli.

Wydawca, dystrybutor i subskrybent

W architekturze występują trzy podstawowe role. Wydawca udostępnia dane i rejestruje transakcje zmieniające objęte nimi obiekty. Dystrybutor przechowuje informacje potrzebne do przekazania zmian; może działać na tym samym serwerze co wydawca albo na odrębnym serwerze. Subskrybent odbiera zmiany i wykonuje je we własnej bazie. W zależności od konfiguracji subskrypcja może być wypychana przez agenta działającego po stronie dystrybutora albo pobierana przez agenta uruchomionego po stronie subskrybenta.

Proces kopiowania zwykle rozpoczyna się od migawki początkowej. Migawka tworzy stan wybranych obiektów i danych, który pozwala przygotować subskrybenta do odbierania kolejnych zmian. Po zakończeniu inicjalizacji agent dziennika odczytuje zatwierdzone zmiany z dziennika wydawcy i zapisuje je w bazie dystrybucyjnej. Następnie agent dystrybucji przekazuje polecenia do subskrybenta. Kolejność operacji ma znaczenie, ponieważ zachowanie tej kolejności jest potrzebne do utrzymania spójności zależności między zmianami.

Opóźnienie, kolejność i spójność danych

Określenie „niemal w czasie rzeczywistym” nie oznacza, że zapis na subskrybencie następuje dokładnie w tej samej chwili co zapis na wydawcy. Opóźnienie zależy między innymi od obciążenia serwera, rozmiaru transakcji, szybkości odczytu dziennika, przepustowości połączenia, wydajności bazy dystrybucyjnej i czasu wykonywania poleceń u subskrybenta. Mała liczba zmian może być przekazywana z niewielkim opóźnieniem, natomiast duża transakcja albo zaległości agenta mogą utworzyć kolejkę oczekujących poleceń.

Ważnym parametrem diagnostycznym jest odległość między najstarszą zmianą oczekującą na przekazanie a aktualnym położeniem dziennika. Analizuje się również liczbę poleceń oczekujących w bazie dystrybucyjnej, czas ostatniego poprawnego uruchomienia agentów oraz komunikaty o błędach zastosowania zmian. Sama obecność danych na subskrybencie nie potwierdza aktualności repliki. Kopia może odpowiadać stanowi sprzed pewnego czasu, jeżeli agent dystrybucji zatrzymał się, utracił połączenie lub napotkał konflikt ograniczeń integralności.

Replikacja transakcyjna nie jest automatycznie pełnym mechanizmem kopii zapasowej. Subskrybent może zawierać tylko wybrane tabele lub kolumny, a konfiguracja może zmieniać sposób obsługi indeksów, ograniczeń i procedur. Odzyskanie danych po awarii wymaga właściwie zaplanowanych kopii zapasowych oraz sprawdzenia, czy odtwarzanie obejmuje zarówno bazę wydawcy, jak i elementy niezbędne do ponownego uruchomienia przepływu replikacji.

Warunki poprawnego działania i diagnostyka

Przed uruchomieniem replikacji trzeba ustalić, które tabele i operacje mają być przekazywane, jak będzie inicjalizowany subskrybent oraz jaki poziom opóźnienia jest akceptowalny dla aplikacji. Należy sprawdzić istnienie kluczy podstawowych, zgodność typów danych, relacje między tabelami oraz uprawnienia kont używanych przez agentów. Istotne są także ustawienia połączeń, dostępność katalogów dla plików migawki, wolne miejsce na dyskach i retencja danych w bazie dystrybucyjnej.

Objawem problemu może być nie tylko jawny błąd agenta. Niespójność ujawnia się czasem jako brak najnowszych rekordów, opóźnione raporty, różne wyniki zapytań albo nieoczekiwane zatrzymanie przetwarzania kolejnych zmian. Diagnostyka powinna rozdzielać etap odczytu dziennika, etap zapisu zmian w dystrybutorze i etap wykonania poleceń u subskrybenta. Jeżeli błąd dotyczy pojedynczego wiersza, trzeba sprawdzić wartości kluczy, ograniczenia, kolejność zależnych operacji oraz to, czy administrator nie zmienił danych bezpośrednio na subskrybencie.

W środowisku z laptopem lub komputerem PC replikacja transakcyjna może pojawić się jako element konfiguracji firmowej bazy danych, z którą urządzenie łączy się przez aplikację. Diagnostyka komputera powinna wtedy obejmować stan połączenia sieciowego, rozwiązywanie nazw, konfigurację zapory, działanie klienta bazy danych i treść komunikatów aplikacji. Sam komputer nie naprawi kolejki po stronie wydawcy ani dystrybutora, dlatego trzeba wyraźnie oddzielić usterkę stacji roboczej od problemu serwera, agenta lub konfiguracji replikacji.