Replikacja danych binarnych

Replikacja danych binarnych obejmuje synchronizację kolumn typu VARBINARY między wydawcą a subskrybentem.

Jak działa synchronizacja wartości VARBINARY

Replikacja danych binarnych polega na przekazywaniu między instancjami bazy danych wartości przechowywanych w kolumnach typu VARBINARY. Taka kolumna zawiera ciąg bajtów, a nie tekst interpretowany według określonego kodowania znaków. Przykładem może być zawartość pliku, fragment dokumentu, podpis cyfrowy, skrót kryptograficzny, skompresowany obiekt albo inny materiał zapisany bezpośrednio w postaci binarnej. W układzie wydawca–subskrybent zmiana zatwierdzona na wydawcy jest wykrywana przez mechanizm replikacji, zapisywana w odpowiednim strumieniu zmian, a następnie stosowana w bazie subskrybenta.

Podczas synchronizacji system musi zachować nie tylko samą zawartość bajtową, lecz także przypisanie jej do właściwego wiersza i kolumny. Rekord jest identyfikowany na podstawie klucza lub innego mechanizmu używanego przez daną konfigurację replikacji. Jeżeli zmienia się wartość VARBINARY, subskrybent powinien otrzymać nową sekwencję bajtów w tej samej kolumnie. Jeżeli rekord zostaje dodany albo usunięty, odpowiednia operacja obejmuje także binarne pola tego rekordu. W praktyce oznacza to, że replikowane dane binarne są częścią spójnej zmiany dotyczącej całego wiersza, a nie niezależnym plikiem przesyłanym poza bazą.

Rozmiar danych i sposób przekazywania zmian

Kolumna VARBINARY może przechowywać zarówno krótkie wartości, takie jak skróty lub identyfikatory binarne, jak i większe fragmenty danych. Im większa wartość, tym więcej miejsca zajmuje zapis zmiany w dzienniku transakcyjnym, kolejce replikacji oraz po stronie subskrybenta. Aktualizacja jednego rekordu może więc wygenerować znacznie większy ruch niż zmiana kolumny liczbowej lub krótkiego pola tekstowego. Mechanizm replikacji musi uwzględniać maksymalny rozmiar obsługiwany przez konkretny silnik, sposób dzielenia dużych komunikatów oraz ograniczenia połączenia między serwerami.

Istotne jest rozróżnienie między zmianą wartości a zmianą metadanych opisujących kolumnę. Modyfikacja samej zawartości VARBINARY jest operacją na danych i może zostać przekazana w ramach zwykłego przepływu zmian. Zmiana typu kolumny, jej maksymalnego rozmiaru, wartości domyślnej albo struktury tabeli jest zmianą schematu. Taka operacja może wymagać osobnej obsługi, ponieważ subskrybent musi mieć strukturę zgodną z wydawcą. Niezgodność schematu może powodować odrzucanie zmian, błędy konwersji lub zatrzymanie kolejki zastosowania danych.

Integralność bajtów, kolejność i kontrola zgodności

Dane binarne nie powinny być podczas replikacji traktowane jako tekst. Konwersja przez stronę kodową, niejawne kodowanie znaków albo zapis w formacie przeznaczonym dla danych tekstowych może zmienić poszczególne bajty. Poprawna synchronizacja przekazuje wartość binarną jako dane tego samego typu, bez interpretowania jej jako znaków. Szczególnej uwagi wymagają aplikacje, które przed zapisem kodują dane, na przykład przez kompresję, szyfrowanie lub reprezentację Base64. Po stronie subskrybenta należy sprawdzić, czy zapisano dokładnie ten sam etap przetwarzania, który został zatwierdzony na wydawcy.

Kontrola zgodności powinna obejmować liczbę bajtów, wartość skrótu oraz powiązanie z kluczem rekordu. Sam fakt, że wiersz istnieje na obu serwerach, nie potwierdza identyczności zawartości VARBINARY. Dwa pola mogą mieć ten sam typ, lecz różną długość i inną treść. Przydatne jest porównanie długości wartości oraz obliczonego skrótu po obu stronach, o ile użyty sposób wyliczania skrótu jest taki sam i obejmuje dokładnie zawartość binarną. Należy również analizować opóźnienie replikacji, liczbę oczekujących zmian i komunikaty błędów zastosowania. W przypadku przerwania połączenia kolejka zmian może rosnąć, ale po jego przywróceniu dane powinny zostać zastosowane w kolejności wymaganej przez mechanizm replikacji.

Diagnostyka niespójności w środowisku wydawcy i subskrybenta

Gdy binarne wartości różnią się między bazami, diagnostykę należy rozpocząć od ustalenia zakresu problemu. Trzeba sprawdzić, czy rozbieżność dotyczy pojedynczego rekordu, całej tabeli, określonego przedziału czasu lub wszystkich kolumn VARBINARY. Następnie warto porównać klucz rekordu, długość pola, reprezentację używaną przez narzędzie diagnostyczne oraz skrót wyliczony bezpośrednio z bajtów. Widok heksadecymalny jest bardziej miarodajny niż próba wyświetlenia danych jako tekstu, ponieważ część sekwencji bajtów może nie mieć drukowalnej reprezentacji.

Jeżeli problem występuje tylko dla dużych wartości, należy przeanalizować limity rozmiaru komunikatów, dzielenie danych na fragmenty, czas oczekiwania i miejsce dostępne w dziennikach. Jeżeli błędy pojawiają się po zmianie struktury tabeli, prawdopodobną przyczyną jest niespójny schemat wydawcy i subskrybenta. Warto także sprawdzić, czy aplikacja nie modyfikuje danych ponownie po ich zastosowaniu na subskrybencie oraz czy nie istnieją wyzwalacze lub procesy okresowe zapisujące inną wartość. Przywrócenie zgodności wymaga ustalenia, która kopia jest źródłem prawidłowych danych, zabezpieczenia aktualnego stanu i wykonania kontrolowanej resynchronizacji zgodnie z możliwościami użytego silnika bazy danych.