Настройка доставки журналов MS SQL 2008 (Transaction Log Shipping). Шаг за шагом.

Доставка журналов (Transaction Log Shipping) - это один из способов резервирования данных, основанный на резервном копирование журнала транзакций и последующего автоматического восстановления их на другом сервере \инстансе MS SQL сервера.

В данной статье попробуем настроить доставку журналов, а также рассмотреть некоторые нюансы данного механизма.

Примерный механизм доставки журналов выглядит так:

С сервера Источника происходит периодическое резервное копирование журнала транзакций в общий каталог, где эти файлы хранятся указанное время.  С данного каталога так же по расписанию происходит копирование этих файлов на сервера, где находятся резервные БД, на этих серверах происходит автоматическое восстановление БД  из журналов транзакций, так же по расписанию.

Необходимые требования для доставки журналов описаны в первоисточнике msdn, отмечу лишь некоторые:

1)      Версия MS SQL должна быть выше Express редакции

2)      БД должна имееть модель восстановления Full(Полная) или Bulk-logger, указывается в свойствах БД, вкладка Option->Recovery model->Full,или следующий скрипт:

USE [master]

GO

ALTER DATABASE [Test_bd] SET RECOVERY FULL WITH NO_WAIT

GO

3)      Учетные записи MS SQL агента сервера источника и сервера получателя должны иметь права на запись и  чтение соответственно на каталоги журналов транзакций. В домене это права для учетной записи домена, вне домена учетные записи агентов источника и получателя должны иметь одинаковые имена и пароли, подробнее здесь.

Итак, давайте настроим нашу тестовую доставку журналов:

Имеем  два сервера с именами test1 и test2 c MS SQL 2008 Ent.Ed на ОС Win2008.

1.       Настройка Источника

1.1.    Укажем в свойствах нашей БД разрешить использовать БД в доставке журналов:

                                              

1.2.    Указываем путь для бекапов, глубина по времени сохранения резервных копий, время, после которого будет алерт об отсутствие бекапап, имя задания(джоба) в sql агенте ,  сжатие \ или нет резервных копий, так же здесь указывается расписание для снятия резервных копий(время запуска джоба, его можно потом без проблем поменять ), по умолчания запуск задания каждые 15 минут.

При указании каталога, куда будут скалываться журналы транзакций, на этот каталог и должна иметь учетная запись sql агента на запись.

Обязательно укажите приемлемое время, через которое необходимо оповещение о проблемах с доставкой журналов.

Время удаления журналов так-же важный параметр, слишком маленькое может произойти ситуация, когда при задержке копирования на получателя, файлы уже удалятся, придется заново создавать полный бекап или наоборот, при большом времени хранения, заполнить  жесткий диск. Его затем можно поменять, если изначальное время не устроит.

Укажите имя джоба и его расписание, расписание легко можно изменить в свойствах задания, а вот имя системного задания после настроек лучше не менять, нужное имя лучше задавать изначально.

Укажите необходимость сжатия резервных копий, рекомендую указывать «нет» на боевых серверах, т.к сжатие это нагрузка на CPU, что на боевых системах будет очень дорого в плане производительности, так же необходимо учесть, если резервные копии делаются локально, то это должен быть другой физический диск для каталога резервных копий отличный от диска с БД, иначе  проблемы с  I/O дисковой системы, но это в каждом случае надо анализировать.

2.        Настраиваем сервер получатель.

2.1.    Добавляем сервер получатель журналов, кнопка «Add»

Указываем, что необходимо создать полный бекап БД и восстановить его на вторичном сервере(получателе), либо восстановить уже существующий полный бекап на втором сервере.

2.2.    Указываем сетевое имя каталога, куда будут копироваться файлы бекапов, незабываем про права учетной записи к данным каталогам, смотрим требования вначале.

Так же здесь указывается период, после которого удаляются файлы в каталоге получателя.

Указываем имя задания, которое будет выполнять копирование файлов и их удаления, настройки данного задания.

2.3.    Указываем настройки восстановления БД на сервере получателя.

Режим БД после восстановления –Режим без восстановления (No recovery mode) – в данном режиме БД будет недоступна

Режим ожидания(Standby mode) – в данном режиме БД будет доступна для чтения данных. При данном режиме указываем опцию – отсоединять  пользователей, когда настало время очередного восстановления БД

Так же здесь указывается время алертов, и время задержки восстановления БД (рекомендую 0).

Когда все указали, наживаем «Ok», создаются указанные задания, как на подписчике, так и на издателе.

После запуска задания создания бекапов на издателе ,при первоначальном запуске создается файл полного бекапа, если указали необходимость его создания.

Последующие файлы бекапов будут файлы бекапов транзакций, в имени которого к названию базы данных будет прибавляться дата и идентификатор файла.

В MS SQL Server есть стандартные отчеты мониторинга доставки журналов, как на издателе, так и на подписчике:

По нему можно оценить состояние доставки журналов, к примеру как ниже:

Здесь данные выделены красным цветом, т.к время задержки восстановления превышено указанного времени алерта при восстановлении.

Так же из данного отчета видно последний скопированный файл БД, восстановленный файл БД.

Ну а проблему данной задержки уже нужно смотреть в истории заданий, участвующих в доставке журналов, как на издателе, так и на получателе.

Вот и все доставка журналов настроена и работает.

Что еще?! а еще наверно нужно потренироваться сделать переход на БД получателя на момент сбоя, работ или других причин.

Что здесь помнить необходимо? То, что на БД не синхронизированы, у них всегда есть момент задержки, т.е нам нужно быть уверенным, что на БД получателе последние данные, и второе БД во время работы доставки журналов на сервере получателя БД в режиме только чтение

Итак, переход на работы на сервер получателя:

1) Нам нужно, пока мы переключались на второй сервер, данные не были изменены на исходном сервере. Если проблемы с сервером или СУБД  или БД недоступна, то данные уже нельзя изменить, а если, к примеру, регламентные работы,  то несколько вариантов:

- Запретить доступ к БД, в режим только администраторов или db_owner

- переключить БД в режим только чтение

-  и другие способы, ограничивающие доступ к БД

Переключим БД  в режим только чтение – в результате данные не изменяться:

Свойство БД  -> Опции ->База данных только чтение(Databases read-only) = «True» или через команду:

USE [master]

GO

ALTER DATABASE [AdventureWorks] SET  READ_ONLY WITH NO_WAIT

GO

После этого запускаем джоб создания резервной копии от  доставки журналов. Он создаст файл с последними изменениями.

2)Передаем на второй сервер все последние файлы бекапов транзакций и их применяем к БД – для этого либо запустите задание копирования файлов от доставки журналов или просто скопируйте эти  файлы. Когда убедитесь, что все файлы применились, необходимо БД перевести из режима «Только чтение» в режим доступности записи:

USE [master]

GO

ALTER DATABASE [AdventureWorks] SET  READ_WRITE WITH NO_WAIT

GO

После этого не забудьте выполнить иснструкцию Alter Login для каждой  sql учетной записи БД для привязки их с именами сервера.

Теперь БД готова к работе. Не забудь отключить БД  от доставки журналов.

Замечания при использование доставки журнало:

Т.к доставка журналов используется на основе технологий работы СУБД MS SQL Server с журналом транзакций, то их нужно учитывать при работе:

- если данные в БД не сильно изменяются, то объем журнала транзакций будет небольшим, но если объем изменений будет большим, то файлы журналов транзакций так же вырастет, что повлечёт и время их копирования, и самое главное, время их восстановления на получателе, и соответственно недоступности БД на получателе.

- протоколируемые операции обслуживания БД , такие как к примеру перестройка индексов, так же влияет на объем бекапов журнала транзакций, это надо учитывать при настройке доставки журналов, возможно даже  придется менять план обслуживания БД.

Область применения доставки журналов:

- дополнительная система отказоустойчивости, именно дополнительная, т.к как я уже указывал, существует задержка восстановления БД на сервере получателе. К примеру к кластеризации , добавить доставку журналов.  Одну доставку журналов можно использовать только на не кричных БД, где возможно потеря и задержка восстановления работоспособности БД.

- большой распространения использовать БД на получателе для отчетов, а если нужны оперативные данные, то направлять их на основную БД-источник. Минус, что нельзя создавать отдельно индексы на сервере получателе, для этого их надо сначала создать на источнике, после этого они появятся на получателе.

Нужно не забывать так же еще минус, что при  восстановление из очередного файла журнала транзакций, все пользователи отсоединяются от БД. Но это скорее всего организационные вопросы.

На этом пока все, удачного использования данного инструмента. :)