В этой статье я расскажу, как работает Log Shipping, какие
задания создаются при его на-стройке, как они функционируют,
где хранится системная информация о передаче журналов, а также
немного расскажу, как найти причину ошибки, возникающую в
процессе работы.
1 Описание
работы заданий Log Shipping
Log Shipping - это фактически некоторое множество заданий
(SQL-job). Суть Log Shipping состоит в передачи копий
журналов транзакций с одного сервера на другой, что при
определенных дополнениях (например, таких, как перенос логинов
и сопоставление SID-ов) позволяет создать и поддерживать в
актуальном состоянии резервный сервер. При этом нужно помнить,
что данные на резервный сервер попадают не сразу, а через
некоторый промежуток времени, зависящий от на-строек Log
Shipping: частоты создания резервных копий журнала; частоты
переноса копий на вто-ричный сервер и их восстановления там и
эту частоту нельзя установить меньше чем 1 минута. Т.о. нельзя
заставить работать Log Shipping в непрерывном режиме, как
например репликацию.
При настройке Log Shipping создаются
четыре или пять (если предусмотрена смена ролей серверов)
заданий.
1.1 Первичный
сервер
1.1.1 Задание: "Transaction Log
Backup Job for DB Maintenance Plan"
На первичном
сервере создается задание: "Transaction Log Backup Job
for DB Maintenance Plan - <Имя плана
обслуживания>".
Основная функция этого задания -
выполнение резервных копий журнала транзакций на первичном
(основном) сервере в указанную при создании плана
обслуживания папку. Поскольку при выполнении этого задания
информация о последней копии журнала прописывается на сервер
мониторинга, в таблицу
msdb..log_shipping_primaries, у учетной записи,
которая используется для подключения к серверу мониторинга,
должны быть права на изменение этой таблицы. Отсут-ствие
этих возможностей может привести к тому, что задания
мониторинга будут завершаться с ошибкой. Это описано в
следующей статье Базы знаний Microsoft (MSDN): PRB:
Backup, Copy, and Load Job Information Is Not Updated on the
Log Shipping Monitor
1.2 Вторичный
сервер
На вторичном сервере создаются два задания, или их может
быть три, если предусмотрена возможность смены ролей:
1.2.1 Задание: "Log Shipping
copy for <Имя первичного сервера>. <Имя
БД_logshipping>"
Это задание под учетной записью
SQL Server Agent подключается к первичному серверу и
последовательно, по одному файлу при каждом запуске,
копирует файлы журналов транзакций на локальный диск
вторичного сервера. Соответственно у учетной записи SQL
Server Agent вто-ричного сервера должны быть права на чтение
из той папки, в которую задание "Transaction Log Backup
Job for DB Maintenance Plan <Имя плана
обслуживания>" на первичном сервере со-храняет копии
журналов транзакций. Кроме того, у неё должны быть права на
запись в папку, где копии журналов транзакций будут
храниться на вторичном сервере.1.2.2 Задание: "Log Shipping
Restore for <Имя вторичного сервера>. <Имя
БД_logshipping>"
Это задание восстанавливает копии
журналов транзакций на вторичном сервере.1.2.3 Задание: "Transaction Log
Backup Job for DB Maintenance Plan <Имя плана
об-служивания>"
Это задание создается только в том
случае, если предусмотрена необходимость смены ролей
серверов. Функциональные возможности состоят в том, чтобы
при смене ролей серверов создавать резервные копии журнала
транзакций уже на вторичном сервере. У этого задания должен
быть отключен статус "Enabled".
1.3 Сервер
мониторинга
1.3.1 Задание: "Log Shipping
Alert Job Restore"
Данное задание запускает хранимую
процедуру msdb.dbo.sp_log_shipping_monitor_restore,
которая и звлекает название файла последней резервной копии
журнала из поля last_backup_filename таблицы
msdb..log_shipping_primaries, и вытаскивает из
названия файла дату его создания. Далее дата создания файла
последней резервной копии журнала транзакций сравни-вает с
датой, полученной из поля last_loaded_filename
таблицы msdb..log_shipping_secondaries. Если
разница в минутах между двумя этими значениями больше чем
значение поля
log_shipping_secondaries.out_of_sync_threshold,
задание завершается с ошибкой.
То есть проверяется, чтобы
время, прошедшее между созданием последней резервной копией
журнала и ее восстановлением на вторичном сервере не
превышало заданного при настройке Log Shipping значения. И
таким образом проверяется, что период рассинхронизации не
превышает за-данный интервал.1.3.2 Задание: "Log Shipping
Alert Job - Backup"
Это задание запускает процедуру
msdb.dbo.sp_log_shipping_monitor_backup. В
процедуре сравнивается дата из поля last_updated
таблицы log_shipping_primaries с текущей датой и
если разница больше, чем значение поля
backup_threthold таблицы
log_shipping_primaries, задание за-вершается с
ошибкой. То есть это задание поверяет, чтобы промежуток
времени, прошедший с момента создания последней резервной
копии, не превышает установленного значения. Следует также
заметить что проверка производится в курсоре по всем строкам
таблицы log_shipping_primaries, и если хоть одно значение
поля last_updated отличается от текущей даты более чем
задано в поле backup_threthold, задание завершится с
ошибкой. Поэтому могут возникать такие ситуации, когда
задание завершилось с ошибкой и помечено красным кружком, а
на сервере мониторинга показано что пара первичный-резервный
сервер находятся в синхронизации друг с другом.
Эти два задания по умолчанию выполняются раз в минуту и
записывают сообщения об ошибках в журнал приложений
операционной системы.
Важно: Серверы должны быть синхронизированы по времени и
формат времени должен быть одинаковым (то есть, например, на
всех серверах использовать 24 часовой формат времени), иначе
это может привести к тому, что задания передачи журналов будут
завершаться с ошибками. Также к ошибкам могут приводить
следующие причины:
-
Расписание выполнения заданий по переносу журналов имеет
временнЫе промежутки больше установленных и допустимых.
-
Процессы выполнения заданий на сервере могут быть
блокированы другими процессами. Например, если долго
выполняется процесс создания резервной копии БД сторонней
про-граммой резервного копирования, это приведет к тому, что
задание выполнения резервных копий журнала будет блокировано
этим процессом и не сможет начать свое выполнение до тех
пор, пока процесс, инициированный сторонней программой, не
закончит свою работу или не будет прерван. Вследствие этого
задания на сервере мониторинга будут выдавать ошибку
синхронизации.
Для того чтобы лучше понять, как функционируют задания
передачи журналов, в Приложении к этой статье будет приведена
схема работы Log Shipping.
2 Параметры
Log Shipping, доступные уже после его настройки
2.1 Изменение
параметров подключения к серверу мониторинга
Для того чтобы изменить учетную запись, под которой
первичный и вторичный сервер под-ключаются к серверу
мониторинга, необходимо открыть список объектов в Enterprise
Manager, выбрать базу данных, для которой настроена передача
журналов, и из контекстного меню выбрать пункт
"Properties". Появится окно свойств базы данных,
показанное на Рисунке 1.
Рисунок
1. Окно свойств базы данных
Из информации на вкладке "General", в окне свойств
базы данных, можно увидеть, что данный сервер играет роль
первичного, а также можно узнать имя плана обслуживания, время
создания последней полной копии БД и последней копии журнала
транзакций, и определить какой сервер является сервером
мониторинга.
Для того чтобы изменить учетную запись
подключения к серверу мониторинга, нужно на-жать кнопку
"Details" и в появившемся окне (См.Рисунок 2. Log
Shipping Details) задать использование учетной записи SQL
Server log_shipping_monitor_probe или использовать Windows
аутентификацию (при этом будет использоваться учетная запись,
под которой запущен SQL Server Agent).
Рисунок
2. Log Shipping Details
2.2 Добавление
возможности изменения роли серверов
Для этого в Enterprise Manager в дереве объектов необходимо
выбрать <Имя Резервного Сервера> -> Management ->
Database Maintenance Plan, в окне детализации выбрать план
об-служивания, и в контекстном меню выбрать пункт
"Properties". В открывшемся окне перейти на вкладку
"Log Shipping". Выбрать нужный вторичный сервер и
нажать кнопку "Edit".
Рисунок
3. Database Maintenance Plan
В окне "Edit Destination Database" в разделе
"Future Primary Option" установить флаг "Allow
Database to assume primary role", и задать путь к
локальной папке вторичного сервера, в ко-торую в случае смены
ролей SQL Server будет записывать копии журнала
транзакций.
2.3 Изменение
состояния базы данных на резервном сервере после
восстановления; изменение поведения сервера при восстановлении
журнала, когда имеются подключения к БД; изменение частоты
копирования и восстановления
Все эти настройки доступны на следующей вкладке
"Initialize" окна "Edit Destination Data-base"
(Рисунок 4. Вкладка Initialize)
Рисунок
4. Вкладки General и Initialize
Раздел Secondary Load State:
Если выбран параметр "No Recovery Mode", после
восстановления следующей копии журнала на резервном сервере
база данных будет недоступна пользователям.
При выборе
"Standby Mode" база данных будет доступна пользователям
для чтения.
При установке флага "Terminate users in
database", когда начинается процесс восстановления, все
соединения пользователей с БД разрываются. Если снять этот
флаг, то пользователи смо-гут продолжать работать с базой
данных, но процесс восстановления не сможет начаться до тех
пор, пока есть подключения к БД.
Раздел Schedules:
Параметр "Copy Frequency" задает частоту копирования
файлов копий журналов из папки первичного сервера в папку на
вторичном сервере.
Параметр "Load Frequency" задает
частоту восстановления журналов на вторичном сервере.
2.4 Настройка
допустимого времени, в течение которого сервера могут
находиться в со-стоянии рассинхронизации; настройка времени
задержки восстановления; настройка периода хранения копий
журналов транзакций и истории
Все эти параметры также доступны в окне "Edit
Destination Database" на вкладке "Threshold"
(Рисунок 5. Вкладка "Thresholds").
Рисунок
5. Вкладка Thresholds
Параметр "Out Of Sync Threshold" задает максимальный
промежуток времени, который может пройти между последним
резервированием журнала транзакций на первичном сервере, и
последним восстановлением журнала транзакций на вторичном
сервере.
"Load Time Delay" - время задержки
восстановления.
"File Retention Period" - если файлы
копий журнала транзакций созданы ранее, чем это значение, они
удаляются. Например, для значения, установленного на Рисунок
5, будут удаляться файлы, созданные более суток назад (1
Day).
"History Retention Period" - задает время
хранения истории, до того как она будет удалена.
2.5 Параметры,
которые можно изменить с сервера мониторинга
В дереве объектов Enterprise Manager нужно выбрать <Имя
Сервера Мониторинга> -> Management -> Log Shipping
Monitor. В окне детализации выбрать нужную пару серверов,
участвующий в передаче журналов и из контекстного меню выбрать
пункт "Properties". Откроется окно "Log Shipping
Pair Properties". На вкладке "Status" нет значений,
которые можно устано-вить, но можно почерпнуть некоторую
информацию (Рисунок 6)
Рисунок
6. Окно Log Shipping Pair Properties
Перейдем на вкладку "Source" (Рисунок 7)
Рисунок
7. Вкладка "Source"
"Alert threshold" - время, которое может пройти с
момента создания последней резервной копии журнала до того как
сервер мониторинга выдаст сообщение об ошибке.
"Alert
number" - номер сообщения.
Если снять флаг
"Enabled", то проверка производиться будет, но
сообщения об ошибках появляться не будет. Также эту
возможность можно включить / отключить следующим образом: В
дереве объектов Enterprise Manager нужно выбрать <Имя
сервера Мониторинга> -> Manage-ment -> Log Shipping
Monitor. В окне детализации выбрать нужную пару серверов,
участвующий в передаче журналов и из контекстного меню выбрать
пункт: "Enable / Disable Backup Alert"
В разделе
"Supress Alert Generation Between" можно установить
время, когда сообщения генерироваться не будут.
Если нажать
кнопку "View Backup Schedule" можно посмотреть
расписание резервного копирования журналов.
Теперь перейдем
на следующую вкладку "Destination" (Рисунок 8)
Рисунок
8. Вкладка "Destination"
Здесь можно установить максимально возможное время
рассинхронизации (Alert threshold) и номер сообщения об
ошибке при рассинхронизации (Alert number).
Если
снять флаг "Enabled", проверка производиться будет, но
сообщения об ошибках появляться не будут. Также эту
возможность можно включить / отключить следующим образом: В
дереве объектов Enterprise Manager нужно выбрать <Имя
Сервера Мониторинга> -> Management -> Log Shipping
Monitor. В окне детализации выбрать нужную пару серверов,
участвующий в передаче журналов и из контекстного меню выбрать
пункт "Enable / Disable out-of-sync Alert".
В
разделе "Supress Alert Generation Between" можно
установить время, когда сообщение генерироваться не
будет.
А также можно посмотреть расписание копирования
файлов с первичного сервера на вторичный (View Copy
Schedule), и расписание восстановления журналов (View
Load Schedule).
3 Мониторинг
передачи журналов
После того, как передача журналов настроена, на сервере
мониторинга, в папке "Management", появляется новая
вкладка "Log Shipping Monitor". Некоторые возможности,
доступные с помощью этой утилиты, мы уже рассмотрели в
предыдущем разделе.
Помимо того, что уже было сказано, она
дает возможность посмотреть историю создания резервных копий,
их копирования и восстановления.
Для этого нужно выбрать
<Имя сервера мониторинга> -> Management -> Log
Shipping Monitor. В окне детализации выбрать нужную пару
серверов, участвующий в передаче журналов и из контекстного
меню выбрать пункт View Backup History или View Copy / Load
history.
При разрешении проблем, необходимо помнить, что
Log Shipping создает задания и поэтому необходимо также
посмотреть историю выполнения этих заданий для получения
дополнительной информации об ошибках. Для этого нужно в
Enterprise Manager выбрать <Имя сервера> ->
Management -> SQL Server Agent -> Jobs, в окне
детализации выбрать нужное задание и из контекстного меню
выбрать пункт "View Job History". Появится окно "Job
History", в нем необходимо установить флаг "Show step
details" и перейти на нужный шаг задания, чтобы в окне
детализации увидеть более подробную информацию.
4 Где хранится
информация о Log Shipping
Информация о передаче журналов хранится в базе данных msdb
в следующих таблицах:
Эти таблицы присутствуют на всех серверах, участвующих в
передаче журналов. При этом на каждом из серверов данными
заполняется только часть таблиц, в зависимости от того, какую
функцию выполняет сервер в процессе передачи журналов:
является ли он первичным, вторичным или сервером
мониторинга.
Также не нужно забывать о том, что поскольку
при передаче журналов создаются задания и план обслуживания,
то задействуется также еще ряд других таблиц из базы msdb,
таких как sysjobs, sysjobssteps и т.д.
5
Синхронизация передачи журналов c репликацией
транзакций
Для того чтобы в случае выхода из строя сервера - издателя,
можно было бы его заменить резервным сервером, на который
выполняется передача журналов, существует два режима
синхронизации Log Shipping с транзакционной репликацией:
синхронный и полусинхронный.
5.1 Синхронный
режим:
Для перехода в этот режим для базы данных устанавливается
опция sync with backup.
В этом режиме Log Reader Agent не
отбирает транзакции для передачи подписчикам до тех пор,
пока они не будут помещены в копию журнала транзакций,
которые создает Log Shipping.
Этот метод гарантирует, что
в случае отказа основного сервера – издателя, информация на
всех серверах, участвующей в репликации и передаче журналов,
будет синхронизирована, что упрощает процесс переключения на
резервный сервер в случае сбоя.
Но в то же время
замедляется процесс репликации, поскольку он теперь
становится зависимым от интервала, с которым Log Shipping
выполняет резервные копии журнала.
5.2 Полусинхронный
режим:
Этот режим используется, когда недопустимы задержки в
работе репликации. Работа Log Reader Agent уже не зависит от
создания резервных копий журнала. При этом резервный сервер
также можно ввести в качестве издателя в случае сбоя
первичного, несмотря на то, что данные не
синхронны.
Имейте в виду, что если дистрибьютор и издатель - это один
и тот же сервер, то при переходе на резервный сервер, даже
после восстановления последней копии журнала с параметром
KEEP_REPLICATION, информация о репликации будет неполная на
резервном сервере, т.к. сохранится только та информация,
которая хранится в пользовательской БД, а информация о
репликации хранится также в базах данных Distribution и
msdb.
6
Заключение
Для того чтобы процесс передачи журналов функционировал без
сбоев, администратору необходимо хорошо обдумывать свои
действия и их последствия.
Например, необходимо помнить,
что нельзя применять к базе данных, участвующей в передаче
журналов, команду "Backup Log" с опцией "No_Log"
(Truncate_only), поскольку это приведет к тому, что
последовательная цепочка строк (LSN) журнала транзакций будет
разорвана и процесс передачи журналов перестанет
функционировать. После этого необходимо будет предпринимать
некоторые дополнительные по восстановлению передачи
журналов.
Нельзя использовать переключения между разными
моделями восстановления базы данных, это также может нарушить
работу Log Shipping.
Среди положительных особенностей можно
отметить, что при определенных условиях вторичный сервер может
быть настроен для получения отчетности. Для этого при
настройке Log Shipping следует учесть, что база данных на
резервном сервере после восстановления должна находиться в
состоянии "Read-Only", и также учесть тот факт, что
если в настройках передачи журналов выбрана опция
"Terminate users in database", то когда начнется
восстановление очередной копии журнала соединения
пользователей будут отключены и на тот период времени, пока
восстановление проходит, пользователи не смогут подключаться к
БД. Если же эта опция не выбрана, то восстановление не сможет
начаться, если к БД есть подключения и задания будут
завершаться с ошибкой до тех пор, пока пользователи не
отключатся и процесс восстановления не возобновится.
Также,
несомненно - положительной особенностью является и то, что
настройка Log Shipping не требует предварительного изменения
схемы данных и не вносит изменений в их схему, как например
некоторые виды репликации. А также переносятся все
пользователи, роли и разрешения для базы данных.
Но следует
также отметить, что если необходимо реализовать переход на
резервный сервер, а затем снова ввести в работу основной, то
этот обратный переход может стать достаточно трудоемкой и
продолжительной операцией, если в базу данных вносится много
изменений, копии журнала для обратного перехода выполняются
часто или период работы с резервным сервером достаточно
продолжителен, поскольку накапливается большое количество
копий журналов транзакций, которые потом нужно восстановить на
основном сервере для ввода его в работу. В некоторых случаях
легче сделать полную копию базы данных и восстановить ее на
основном сервере, что для больших баз данных также может
занимать достаточно продолжительное время. К тому же при
использовании стандартной процедуры перехода на резервный
сервер, описанной в статье MSDN: How
to set up and perform a log shipping role change, после
перехода на основной сервер передачу журналов нужно
пересоздавать.
7 Статьи MSDN,
в которых описывается, как решать некоторые проблемы,
возникающие при настройке и работе Log Shipping
Часто повторная настройка Log shipping вызывает ошибку,
поскольку остается информация в таблицах от предыдущей
настройки. Эта ошибка и методы ее устранения описаны в статье
MSDN:
Разрешение причин возникновения ошибок в работе заданий
Log Shipping Alert Job - Backup и Log Shipping Alert
Job – Restore:
А также некоторые причины описаны в пункте
1.3.2
Следующая ошибка может возникать при попытке
просмотреть историю выполнения восстановлений на сервере
мониторинга:
Ошибка, возникающая после добавления нового или удаления
одного из файлов базы данных между созданием резервных
копий:
Не удается произвести смену ролей, когда имена баз данных
на первичном и вторичном серверах отличаются:
Ошибка, возникающая если имя БД содержит имя устройства
(AUX, PRN, COM1, COM2, COM3, COM4):
Ошибка, возникающая после обновления версии SQL Server
Standard Edition до Enterprise Edition:
Ошибка при вызове процедуры sp_resolve_logins, при смене
ролей серверов:
Ошибка, возникающая при настройке передачи журналов на
серверах, задействованных в кластере:
Если при конфигурации Log Shipping используется опция No
Recovery, а база данных на вторичном сервере в состоянии
Standby:
Ошибка, возникающая при смене ролей серверов на именованных
экземплярах SQL Server:
Возросло количество используемого места в журнале после
восстановления копий журналов транзакций на вторичном
сервере:
Ошибка может возникнуть, если на сервере существует DTS
пакет, в котором используется Copy Objects Task:
Ошибка 3101, возникающая в работе процедуры
sp_change_secondary_role:
Если Вы изменили папку, в которой сохраняются копии журнала
транзакций через диалоговое окно свойств плана обслуживания, а
задание копирования журналов все еще продолжает просматривать
старую папку:
Ошибка 3456, возникающая при попытке применить копию
журнала транзакций:
В редких случаях, процесс передачи журналов может вызвать
проблему подключения к SQL Server. Это связано с тем, что
процессы, которые запущены в рабочем пространстве SQL Server,
могут блокировать ресурсы, что препятствует подключению к
TCP/IP порту. Это описано в следующей статье:
8 Другие
полезные ресурсы в Интернет, затрагивающие передачу журналов и
помогающие в разрешении проблем, возникающий в работе Log
Shipping
9 Приложение -
Схема работы Log Shipping
| 
