Replikacja FILESTREAM

Replikacja FILESTREAM obejmuje synchronizację zarówno danych w tabeli, jak i powiązanych plików na dysku.

Jak SQL Server traktuje dane FILESTREAM podczas replikacji

Replikacja FILESTREAM w SQL Server dotyczy tabeli zawierającej kolumnę typu varbinary(max) z atrybutem FILESTREAM oraz przechowywanych poza głównym plikiem danych binarnych obiektów BLOB. Kolumna pozostaje częścią schematu tabeli, natomiast właściwa zawartość pliku jest umieszczana w kontenerze FILESTREAM należącym do grupy plików FILESTREAM. Dzięki temu SQL Server zachowuje zależność między rekordem, identyfikatorem file_stream i odpowiadającą mu zawartością na dysku. Replikacja nie polega więc na niezależnym kopiowaniu katalogu systemu plików. Zmiany muszą przejść przez mechanizm replikacji SQL Server, aby rekord i dane binarne zostały odtworzone w spójny sposób.

W typowym scenariuszu używa się replikacji transakcyjnej SQL Server. Log Reader Agent odczytuje zmiany oznaczone w dzienniku transakcji, a Distribution Agent przekazuje je do subskrybenta. Dla kolumn FILESTREAM można skonfigurować replikowanie samego atrybutu FILESTREAM albo replikowanie kolumny jako zwykłego varbinary(max). Microsoft zaleca zachowanie atrybutu FILESTREAM, ponieważ wtedy obiekt na serwerze docelowym również korzysta z magazynu FILESTREAM. Jeżeli atrybut zostanie pominięty, dane są traktowane jak zwykła wartość binarna w tabeli, co zmienia sposób ich przechowywania i wprowadza ograniczenia rozmiaru.

Różnica między kolumną FILESTREAM a zwykłym kopiowaniem plików

Plik znajdujący się w kontenerze FILESTREAM nie powinien być modyfikowany, usuwany ani przemieszczany bezpośrednio za pomocą Eksploratora Windows lub poleceń systemu plików. SQL Server kontroluje te dane transakcyjnie. Operacje strumieniowe mogą być wykonywane przez interfejs systemu plików, ale muszą być powiązane z rozpoczętą transakcją SQL Server i tokenem uzyskanym przez funkcję GET_FILESTREAM_TRANSACTION_CONTEXT(). Otwarte uchwyty plików trzeba zamknąć przed zatwierdzeniem albo wycofaniem transakcji. Samo skopiowanie katalogu kontenera na inny komputer nie tworzy poprawnej repliki tabeli i może prowadzić do rozbieżności między metadanymi a zawartością BLOB.

Replikacja utrzymuje logiczne zmiany danych, a nie ogólną synchronizację dwóch katalogów. Aktualizacja wiersza, usunięcie rekordu lub zapis nowej zawartości FILESTREAM musi zostać zarejestrowany przez SQL Server w ramach transakcji. Dopiero wtedy agent replikacji może przekazać zmianę dalej. Z tego powodu ręczna ingerencja w kontener, przywracanie pojedynczych plików bez wiedzy o stanie bazy albo używanie niezależnego programu do synchronizacji katalogów nie zastępuje replikacji. Backup i odtwarzanie bazy obejmują dane FILESTREAM razem z relacyjną częścią bazy, ale backup nie jest mechanizmem ciągłego przesyłania zmian do subskrybenta.

Ograniczenia konfiguracji subskrybenta i schematu

Podczas konfigurowania artykułu trzeba sprawdzić, czy schemat tabeli na subskrybencie zachowuje atrybut FILESTREAM i czy docelowa baza ma prawidłowo skonfigurowaną grupę plików FILESTREAM. Pominięcie atrybutu powoduje utworzenie zwykłej kolumny varbinary(max). W takim wariancie pojedyncza wartość nie może przekroczyć limitu 2 GB właściwego dla tego typu danych. Ograniczenie ma znaczenie przy dokumentach, obrazach, nagraniach i innych dużych obiektach. Zgodność typów, nazw kolumn, klucza podstawowego oraz ustawień artykułu należy zweryfikować przed wykonaniem synchronizacji inicjalnej.

W tabelach zawierających kolumny FILESTREAM obowiązują również szczególne ograniczenia dotyczące ustawień replikacji. Dla publikacji transakcyjnej nie można używać wartości database snapshot ani database snapshot character parametru @sync_method w sposób przewidziany dla tabel bez FILESTREAM. Nie należy też utożsamiać tej funkcji z FileTable: FileTable jest specjalnym obiektem SQL Server i ma odrębne zasady zgodności, a replikacja tabel FileTable nie jest obsługiwana. Przed uruchomieniem procesu trzeba więc ustalić, czy obiektem jest zwykła tabela z kolumną FILESTREAM, czy FileTable, ponieważ podobna nazwa nie oznacza tego samego mechanizmu.

Kontrola spójności po uruchomieniu replikacji

Ocena poprawności replikacji FILESTREAM powinna obejmować jednocześnie dane relacyjne i zawartość binarną. Na subskrybencie należy sprawdzić liczbę wierszy, wartości kluczy, długość danych zwracaną przez DATALENGTH(), a także możliwość odczytu obiektu przez Transact-SQL oraz przewidziany interfejs strumieniowy. Sam fakt, że rekord jest widoczny w tabeli, nie dowodzi jeszcze, że można poprawnie otworzyć odpowiadający mu plik. Warto testować osobno insert, aktualizację treści, zmianę metadanych, usunięcie rekordu i obsługę dużego BLOB-a. Należy również obserwować opóźnienie dystrybucji, błędy agenta oraz miejsce zajmowane przez grupę plików FILESTREAM.

Problemy mogą wynikać z zatrzymanego Log Reader Agent, błędu Distribution Agent, braku miejsca na woluminie, niezgodnego schematu albo próby traktowania kontenera jak zwykłego katalogu. Diagnostyka powinna zaczynać się od komunikatów agentów replikacji i stanu publikacji, a następnie obejmować porównanie rekordów oraz długości danych po obu stronach. Szczegóły zgodności FILESTREAM z replikacją opisuje dokumentacja Microsoft SQL Server. W środowisku produkcyjnym trzeba także ustalić procedurę odtwarzania po awarii, ponieważ ponowne utworzenie subskrypcji lub ponowna synchronizacja może wymagać odpowiedniego przygotowania dużych danych binarnych.