Replikacja między wersjami

Replikacja między wersjami SQL Server wymaga sprawdzenia zgodności funkcji dostępnych po obu stronach.

Role wersji w topologii SQL Server

Replikacja między wersjami SQL Server nie oznacza automatycznego uzgodnienia możliwości wszystkich instancji. Topologia składa się z wydawcy (Publisher), dystrybutora (Distributor) i subskrybentów (Subscriber), a zgodność trzeba oceniać osobno dla każdej z tych ról oraz dla wybranego typu replikacji. Dystrybutor może działać w tej samej lub nowszej wersji niż wydawca. Wydawca i dystrybutor muszą być tym samym produktem; reguły dotyczące SQL Server nie są bezpośrednio regułami dla innych silników baz danych ani dla Azure SQL Managed Instance.

W przypadku replikacji transakcyjnej subskrybent może znajdować się najwyżej dwie wersje przed wydawcą albo za nim, zgodnie z macierzą zgodności obowiązującą dla danej wersji SQL Server. Przykładowo wydawca SQL Server 2012 może mieć subskrybenta SQL Server 2014 lub SQL Server 2016. Przy replikacji scalającej subskrybent może mieć wersję równą wydawcy albo starszą, jeżeli dana wersja nadal jest obsługiwana. Replikacja nie jest wspierana, gdy uczestniczące instancje są oddalone o więcej niż dwie główne wersje.

Funkcje artykułu a możliwości subskrybenta

Najczęstszy błąd polega na sprawdzeniu wyłącznie numerów wersji serwerów i pominięciu schematu publikowanych artykułów. Jeżeli tabela, widok, procedura lub filtr korzysta z funkcji niedostępnej w starszym subskrybencie, sam fakt poprawnego połączenia agentów nie zapewni poprawnej synchronizacji. Ograniczenie dotyczy zarówno funkcji specyficznych dla replikacji, jak i możliwości całego produktu. Trzeba więc porównać typy danych, kolumny obliczane, indeksy, ograniczenia, wyzwalacze, procedury składowane oraz sposób generowania skryptu tworzącego obiekty u subskrybenta.

Szczególnej kontroli wymagają typy danych i elementy schematu dodane w nowszej wersji SQL Server. Starsza instancja może nie rozpoznać typu kolumny, składni procedury albo właściwości indeksu użytej w skrypcie migawki. Nawet gdy dane tabeli są zgodne, utworzenie obiektu może zakończyć się błędem podczas stosowania migawki. Przed zmianą wersji należy wygenerować i przejrzeć skrypty publikacji, sprawdzić właściwości artykułów oraz wykonać próbne odtworzenie subskrypcji na kopii środowiska. Warto również zweryfikować, czy zmiana schematu na wydawcy jest przewidziana przez wybrany model replikacji.

Agenty, migawka i kolejność aktualizacji

W replikacji transakcyjnej Log Reader Agent odczytuje zmiany z dziennika transakcji wydawcy i przekazuje je do bazy dystrybucyjnej, a Distribution Agent dostarcza je do subskrybenta. Przy inicjalizacji subskrypcji migawka tworzy obiekty oraz dane w kolejności określonej przez mechanizm replikacji. Z tego powodu zgodność należy sprawdzić nie tylko dla samego aparatu Database Engine, lecz także dla wersji komponentów replikacji i narzędzi używanych do konfiguracji. Błąd może ujawnić się dopiero podczas generowania migawki, nakładania skryptu lub wykonywania polecenia na subskrybencie.

Podczas uaktualniania topologii bezpieczniej jest zachować kolejność wynikającą z zależności ról: dystrybutor powinien być w wersji co najmniej równej wydawcy, a zmianę subskrybenta trzeba oceniać według rodzaju publikacji. Przed operacją należy sprawdzić stan agentów, opóźnienie w bazie dystrybucyjnej, błędy w historii zadań SQL Server Agent oraz możliwość ponownego wygenerowania migawki. Nie należy zakładać, że backup bazy wydawcy sam odtworzy konfigurację replikacji. Metadane publikacji, subskrypcji, dystrybucji i uprawnień wymagają osobnego planu odtworzenia.

Sprawdzenie zgodności przed naprawą lub migracją

Diagnostykę warto rozpocząć od zapisania dokładnych numerów wersji i poziomów kompilacji wszystkich instancji. Informacje te można odczytać poleceniem SELECT @@VERSION;, a następnie zestawić z rolami Publisher, Distributor i Subscriber oraz typem publikacji: migawkowej, transakcyjnej albo scalającej. Następnie trzeba sprawdzić macierz zgodności dla konkretnej wersji SQL Server, ponieważ ogólne stwierdzenie „nowszy serwer obsłuży starszy” nie opisuje wszystkich kierunków i ograniczeń.

Jeżeli problem pojawia się po zmianie wersji, należy rozdzielić błąd schematu od błędu transportu i od błędu agenta. W historii replikacji trzeba ustalić, czy migawka została wygenerowana, czy Distribution Agent ją zastosował oraz czy Log Reader Agent przekazał wszystkie transakcje. Dalsza naprawa może wymagać ograniczenia artykułu do wspólnego zestawu funkcji, wygenerowania nowej migawki, ponownej inicjalizacji subskrypcji albo etapowej aktualizacji instancji. Po każdej zmianie trzeba potwierdzić zgodność liczby i struktury obiektów, działanie agentów oraz brak narastającego opóźnienia w dystrybucji.