Serwisanci dostępni teraz · czynne całą dobę, także w weekendy i świętaWarszawa i okolice · dojazd bezpłatny
Darmowa diagnoza laptopa
Darmowa diagnoza laptopa
Dojazd do klienta bezpłatnie
Dojazd do klienta bezpłatnie
Laptopy zastępcze bezpłatnie
Laptopy zastępcze bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie

FILESTREAM i Always On

Termin Definicja
FILESTREAM i Always On

FILESTREAM i Always On opisuje specyfikę wykorzystania tego mechanizmu w konfiguracji wysokiej dostępności bazy danych.

FILESTREAM w SQL Server: dane poza stronami bazy

FILESTREAM jest mechanizmem programu Microsoft SQL Server przeznaczonym do przechowywania dużych obiektów binarnych, takich jak dokumenty, obrazy, nagrania lub pliki projektowe. Dane są powiązane z rekordami tabeli, lecz ich zawartość może być zapisywana w specjalnym kontenerze systemu plików zamiast bezpośrednio w stronach pliku danych MDF. W tabeli przechowywana jest wartość typu varbinary(max) oznaczona atrybutem FILESTREAM, a SQL Server utrzymuje zależność między rekordem, transakcją i fizycznym obiektem w kontenerze.

Do odczytu i zapisu można używać zwykłych poleceń Transact-SQL albo interfejsu strumieniowego Win32. Dostęp przez interfejs FILESTREAM wymaga transakcji SQL Server i wykorzystuje uchwyt uzyskany przez funkcję PathName() oraz procedurę GET_FILESTREAM_TRANSACTION_CONTEXT(). Dzięki temu operacje na pliku są powiązane z transakcją bazy, a aplikacja nie powinna samodzielnie modyfikować plików znajdujących się w kontenerze FILESTREAM.

Rola grupy dostępności Always On

Always On availability groups zapewnia wysoką dostępność wybranych baz SQL Server przez utrzymywanie kopii bazy na replikach. Replika podstawowa zapisuje zmiany w dzienniku transakcji, a mechanizm Always On przesyła rekordy dziennika do replik pomocniczych, gdzie są odtwarzane. W przypadku FILESTREAM oznacza to, że dane należące do grupy plików FILESTREAM są elementem bazy i podlegają replikacji razem z odpowiednimi zmianami transakcyjnymi.

Always On nie jest jednak synchronizacją całej instancji SQL Server. Do grupy dostępności dołączana jest konkretna baza, a nie wszystkie bazy, konta logowania, zadania SQL Server Agent, ustawienia instancji ani konfiguracja systemu Windows. Po przełączeniu na inną replikę trzeba więc uwzględnić zarówno stan bazy, jak i elementy infrastruktury wymagane przez aplikację korzystającą z FILESTREAM.

Warunki konfiguracji i przełączenia

Każda replika, na której ma działać baza z FILESTREAM, musi mieć poprawnie skonfigurowaną obsługę FILESTREAM oraz odpowiednią grupę plików i kontener danych. Kontenery nie mogą być traktowane jak zwykłe katalogi aplikacyjne. Ich lokalizacja musi być przygotowana zgodnie z wymaganiami SQL Server, a konfiguracja repliki pomocniczej powinna zapewniać miejsce, uprawnienia systemowe i strukturę umożliwiającą odtwarzanie danych.

Po przełączeniu grupy dostępności aplikacja powinna ponownie połączyć się z aktualną repliką podstawową i pobrać ścieżkę FILESTREAM za pośrednictwem SQL Server. Nie należy utrwalać w konfiguracji stałej ścieżki UNC wskazującej konkretny serwer, ponieważ po failoverze właścicielem zapisu może stać się inna replika. Istotne są również poprawne parametry połączenia, obsługa ponownego łączenia oraz zgodność wersji i ustawień instancji uczestniczących w grupie.

Diagnostyka spójności FILESTREAM i Always On

Analiza problemu powinna rozpocząć się od ustalenia, czy błąd dotyczy dostępności bazy, synchronizacji repliki, czy samego dostępu strumieniowego. W SQL Server sprawdza się stan baz w widokach dynamicznych Always On, w szczególności sys.dm_hadr_database_replica_states, oraz stan grupy i replik w widokach takich jak sys.availability_replicas i sys.availability_groups. Należy porównać stan synchronizacji, rolę repliki, opóźnienie odtwarzania dziennika i ewentualne komunikaty z dziennika SQL Server.

Jeżeli zapytania Transact-SQL działają, lecz operacja strumieniowa kończy się błędem, trzeba zweryfikować transakcję, kontekst FILESTREAM, uprawnienia konta oraz sposób uzyskania ścieżki przez PathName(). Diagnostyka powinna także obejmować dostępność kontenera na właściwej replice, wolne miejsce i błędy systemu plików. W środowisku enterprise naprawa wymaga zachowania kolejności: najpierw zabezpiecza się stan dziennika i repliki, następnie identyfikuje przyczynę niedostępności, a dopiero później wykonuje ponowne dołączenie, resynchronizację lub kontrolowane przełączenie.

+48 22 100 48 29Zadzwoń teraz · serwisant w 1 godzinę