Jak skonfigurować przesyłanie dziennika transakcji (Log shipping) w SQL Management Studio.
24 listopada 2009 |
Przed konfiguracją Log shipping należy stworzyć udział plików na backup logów transakcyjnych, aby nie obciążać serwera głównego i aby zapewnić wysoką dostępność najlepiej jest to zrobić na innym serwerze.
Następnie dla każdego serwera pomocniczego należy stworzyć folder, do którego będą kopiowane backupy logów transakcyjnych.
W SQL Management Studio klikamy prawym przyciskiem na nazwę bazy danych, dla której chcemy skonfigurować przesyłanie dziennika i przechodzimy do jej właściwości. Klikamy na stronę Transaction Log Shipping i zaznaczamy Enable this as a primary database in a log shopping configuration.
Poniżej w sekcji Trasaction log backups wciskamy przycisk Backup Settings, aby skonfigurować opcję wykonywania kopi zapasowej logu transakcyjnego
Backup logów transakcyjnych jest wykonywany poprzez zadanie Agenta serwera SQL działającego na głównym serwerze SQL.
Na stronie Transaction Log Backup Settings określamy ścieżkę do udziału sieciowego, gdzie będą przechowywane backupy. Poniżej, jeśli folder backupów znajduje się na głównym serwerze, możemy wpisać lokalną ścieżkę do tego folderu.
Mamy tu również możliwość określenia, po ilu godzinach pliki backupu będą kasowane. Domyślnie są to 72 godziny.
Poniżej w Backup Job klikamy na przycisk Schedule i określamy harmonogram, kiedy zadanie ma się wykonywać.
Klikamy przycisk OK. i wracamy do głównego okna konfiguracyjnego.
Uwaga: Jeśli wykonujemy kopię zapasową logów transakcyjnych wraz z innym zadaniem lub planem konserwacyjnym, Management Studio nie będzie w stanie wykonać odzyskiwania backupu na instancjach na serwerze pomocniczym.
Następnie w głównym oknie, w sekcji Secondary Server instances and databases wciskamy przycisk Add, aby dodać serwer pomocniczy.
Na stronie Secondary Database Settings wciskamy przycisk Connect i łączymy się z serwerem, który będzie pełnił rolę standby i w pozycji Secondary database wybieramy nazwę bazy danych.
Na serwerze pomocniczym należy odzyskać pełną kopię zapasową głównej bazy danych przed tym, gdy serwer pomocniczy stanie się miejscem przeznaczenia przesyłania dzienników transakcji. Na zakładce Initialize Secondary Database możemy zaznaczyć w jaki sposób będzie przebiegał proces odzyskiwania z backupu na serwerze pomocniczym. Do wyboru mamy opcje:
- Tak, stwórz pełny backup głównej bazy danych i odzyskaj ją na serwerze pomocniczym (oraz utwórz bazę pomocniczą, jeśli taka nie istnieje),
- Tak, odzyskaj istniejący plik backupu serwera głównego na bazę danych na serwerze pomocniczym (oraz utwórz pomocniczą bazę danych, jeśli taka nie istnieje).
- Nie, pomocnicza baza danych jest zainicjowana.
Jeśli wybierzemy opcję pierwszą, należy kliknąć przycisk Restore Options. Jeśli baza pomocnicza będzie utworzona w momencie odtwarzania backupu, możemy określić folder, w którym zostaną stworzone pliki danych oraz logu transakcyjnego. Wpisujemy zatem ścieżkę do folderów na serwerze pomocniczym.
Jeśli wybierzemy opcję drugą, musimy określić ścieżkę do zasobu sieciowego, gdzie znajduje się plik kopii zapasowej, do którego ma dostęp serwer pomocniczy.
Trzecią opcję wybieramy w przypadku wypromowania pomocniczej bazy danych na główną.
Pliki są kopiowane z katalogu backup, na serwer docelowy poprzez zadanie Agenta serwera SQL działające na serwerze pomocniczym. Zakładka Copy Files służy do skonfigurowania folderu docelowego.
Poniżej możemy określić, po jakim czasie skopiowane pliki mają zostać usunięte. Domyślnie są to 72 godziny.
W sekcji Copy Job możemy określić, kiedy zadanie kopiowania ma się wykonywać. Wciskamy przycisk Schedule i określamy harmonogram wykonywania zadania.
Pliki są odzyskiwane z katalogu docelowego przy użyciu zadania Agenta serwera SQL działającego na serwerze pomocniczym. W zakładce Restore Transaction Log możemy określić stan bazy danych po wykonaniu zadania odzyskiwania z backupu. Do wyboru mamy No recovery mode lub Standby mode. Rzecz jasna jak i w poprzednich zakładkach, możemy określić, kiedy zadanie ma się wykonywać.
Klikamy OK aby zamknąć okno konfiguracji serwera pomocniczego oraz OK aby zamknąć główne okno konfiguracyjne i rozpocząć proces przesyłania dzienników.
Po zakończeniu możemy prześledzić raport z wykonanej operacji.
Natomiast na serwerze pomocniczym możemy zauważyć, że baza danych ma status Restoring.
Jak wypromować serwer standby na serwer główny.
Przesyłanie dziennika transakcji odtwarza pełny backup bazy danych serwera głównego na serwer pomocniczy. Następnie cyklicznie przenosi transakcje ze zmianami z serwera głównego, na serwer standby.
Niestety w przypadku awarii serwera głównego, serwer standby działa jedynie w trybie tylko do odczytu (read-only) i nie może służyć jako serwer awaryjny. Jeśli po awarii chcemy użyć serwera standby jako serwera głównego, należy go wypromować ręcznie.
Aby to zrobić należy odtworzyć plik logu transakcyjnego serwera głównego na serwerze standby, a następnie wyłączyć zadania i kopiowania i odtwarzania. W dalszej kolejności należy uruchomić usługę przesyłania dziennika transakcji w taki sposób, jak zostało opisane powyżej z jedną zmianą: dodając nowy serwer pomocniczy na stronie Secondary Detabase Settings, w sekcji Secondary database wpisujemy nazwę bazy danych oryginalnego serwera głównego, a w zakładce Initialize Secondary Database zaznaczamy No, the secondary database is initialized.
Posted in 
Tags: 
