Replikacja a In-Memory OLTP

Replikacja tabel In-Memory OLTP wymaga specjalnej obsługi ze względu na odmienną strukturę przechowywania danych.

Dlaczego In-Memory OLTP zmienia zasady replikacji

In-Memory OLTP to technologia silnika Microsoft SQL Server przeznaczona do obsługi tabel zoptymalizowanych pod kątem przechowywania danych w pamięci operacyjnej. Tabela memory-optimized nie jest zwykłą tabelą dyskową z dodatkowym buforem pamięci. Ma odmienny model współbieżności, własne struktury indeksów oraz specjalny mechanizm trwałości danych. Zmiany są zapisywane w dzienniku transakcji, a dane trwałej tabeli są odtwarzane z plików kontrolnych i logu po ponownym uruchomieniu bazy.

Replikacja musi więc uwzględniać nie tylko wartości wierszy, ale także sposób, w jaki SQL Server zatwierdza, odczytuje i odtwarza zmiany. Standardowe założenie, że każdą tabelę można obsłużyć identycznym zestawem procedur replikacji, nie jest tu prawidłowe. Znaczenie ma również kierunek przepływu: baza pełniąca rolę wydawcy, baza subskrybenta oraz typ użytej replikacji mogą mieć różne ograniczenia.

Zakres obsługi w replikacji transakcyjnej SQL Server

W SQL Server tabele uczestniczące w replikacji transakcyjnej mogą być skonfigurowane jako tabele zoptymalizowane pamięciowo po stronie subskrybenta. Oznacza to, że dane są dostarczane przez mechanizm replikacji transakcyjnej, natomiast tabela docelowa w bazie subskrybenta korzysta z modelu In-Memory OLTP. Sama tabela musi spełniać wymagania stawiane obiektom memory-optimized, w tym ograniczenia dotyczące typów danych, indeksów, kluczy i obsługiwanych konstrukcji języka Transact-SQL.

Nie oznacza to pełnej zgodności In-Memory OLTP ze wszystkimi wariantami replikacji. Dokumentacja SQL Server wskazuje, że konfiguracje inne niż replikacja transakcyjna do tabel zoptymalizowanych pamięciowo po stronie subskrybenta są niezgodne z tabelami lub widokami odwołującymi się do obiektów In-Memory OLTP. Szczególnej ostrożności wymaga replikacja transakcyjna peer-to-peer, która nie jest objęta tym scenariuszem. Przed wdrożeniem trzeba zatem potwierdzić dokładny wariant topologii, a nie ograniczać się do sprawdzenia, czy w bazie istnieje włączona replikacja.

Struktura tabeli docelowej i ograniczenia obiektów

Subskrybent z tabelą memory-optimized nie może być traktowany jak zwykła tabela dyskowa. Definicja tabeli musi uwzględniać wymagania In-Memory OLTP, na przykład obowiązek określenia indeksu dla tabeli zoptymalizowanej pamięciowo oraz zastosowanie typów indeksów dostępnych dla tego mechanizmu. Indeks hash wymaga poprawnie dobranej liczby kubełków, ponieważ zbyt mała wartość może zwiększać liczbę kolizji i pogarszać wyszukiwanie. Indeks nie jest przy tym kopią klasycznego indeksu B-tree używanego przez typową tabelę dyskową.

Problemy mogą pojawić się także przy odtwarzaniu schematu i zmianach DDL. Nie każda konstrukcja T-SQL dostępna dla tabel dyskowych jest obsługiwana przez tabele memory-optimized, a operacje tworzenia, zmiany lub usuwania obiektów In-Memory OLTP mają własne reguły transakcyjne. Z tego powodu automatyczne generowanie tabeli subskrybenta może wymagać kontroli albo przygotowania docelowego schematu zgodnie z wymaganiami In-Memory OLTP. Należy sprawdzić między innymi klucze główne, ograniczenia, kolumny tożsamości, typy danych, indeksy oraz procedury wywoływane przez agenta dystrybucji.

Weryfikacja przepływu danych i diagnostyka konfiguracji

Diagnostyka powinna rozpocząć się od ustalenia, czy problem dotyczy odczytu zmian przez agenta logu, przekazania ich przez agenta dystrybucji, czy wykonania operacji na tabeli subskrybenta. Sam fakt, że transakcja została zatwierdzona u wydawcy, nie potwierdza jeszcze jej zastosowania w tabeli memory-optimized. Trzeba porównać opóźnienie replikacji, komunikaty agenta, stan subskrypcji oraz liczbę i zakres transakcji oczekujących na dostarczenie.

W praktycznej kontroli należy zestawić definicję tabeli u wydawcy z definicją tabeli u subskrybenta, sprawdzić zgodność kolumn i kluczy oraz zweryfikować, czy wszystkie obiekty wywoływane podczas stosowania zmian są obsługiwane przez In-Memory OLTP. Warto również odróżnić tabelę z trwałością SCHEMA_AND_DATA od tabeli SCHEMA_ONLY. W przypadku SCHEMA_ONLY wiersze nie są zapisywane trwale, więc po ponownym uruchomieniu bazy tabela może pozostać pusta; nie jest to automatycznie dowód na błąd replikacji. Jeżeli wymagane jest zachowanie danych po restarcie, sposób utworzenia tabeli i jej właściwość trwałości muszą odpowiadać temu wymaganiu.

Przy ocenie konfiguracji trzeba także rozdzielić replikację od innych mechanizmów wysokiej dostępności. Always On Availability Groups może obsługiwać bazy zawierające tabele In-Memory OLTP, ale jest to mechanizm utrzymywania replik baz danych, a nie tożsamy z replikacją transakcyjną publikacji i subskrypcji. Prawidłowa diagnoza powinna wskazać konkretny mechanizm, rolę każdej instancji oraz miejsce, w którym zmiana przestaje przechodzić przez oczekiwany przepływ.