| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
|
|
Описание технологии работы Log Shipping SQL Server 2000 В этой статье я расскажу, как работает Log Shipping, какие задания создаются при его на-стройке, как они функционируют, где хранится системная информация о передаче журналов, а также немного расскажу, как найти причину ошибки, возникающую в процессе работы. СОДЕРЖАНИЕ
1 Описание работы заданий Log Shipping Log Shipping - это фактически некоторое множество заданий
(SQL-job). Суть Log Shipping состоит в передачи копий
журналов транзакций с одного сервера на другой, что при
определенных дополнениях (например, таких, как перенос логинов
и сопоставление SID-ов) позволяет создать и поддерживать в
актуальном состоянии резервный сервер. При этом нужно помнить,
что данные на резервный сервер попадают не сразу, а через
некоторый промежуток времени, зависящий от на-строек Log
Shipping: частоты создания резервных копий журнала; частоты
переноса копий на вто-ричный сервер и их восстановления там и
эту частоту нельзя установить меньше чем 1 минута. Т.о. нельзя
заставить работать Log Shipping в непрерывном режиме, как
например репликацию.
На первичном сервере создается задание: "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 На вторичном сервере создаются два задания, или их может быть три, если предусмотрена возможность смены ролей:
Это задание под учетной записью 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".
Данное задание запускает хранимую процедуру 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", в окне свойств
базы данных, можно увидеть, что данный сервер играет роль
первичного, а также можно узнать имя плана обслуживания, время
создания последней полной копии БД и последней копии журнала
транзакций, и определить какой сервер является сервером
мониторинга.  Рисунок 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", после
восстановления следующей копии журнала на резервном сервере
база данных будет недоступна пользователям. Раздел Schedules: Параметр "Copy Frequency" задает частоту копирования
файлов копий журналов из папки первичного сервера в папку на
вторичном сервере. 2.4 Настройка допустимого времени, в течение которого сервера могут находиться в со-стоянии рассинхронизации; настройка времени задержки восстановления; настройка периода хранения копий журналов транзакций и истории Все эти параметры также доступны в окне "Edit Destination Database" на вкладке "Threshold" (Рисунок 5. Вкладка "Thresholds").  Рисунок 5. Вкладка Thresholds Параметр "Out Of Sync Threshold" задает максимальный
промежуток времени, который может пройти между последним
резервированием журнала транзакций на первичном сервере, и
последним восстановлением журнала транзакций на вторичном
сервере. 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" - время, которое может пройти с
момента создания последней резервной копии журнала до того как
сервер мониторинга выдаст сообщение об ошибке.  Рисунок 8. Вкладка "Destination" Здесь можно установить максимально возможное время
рассинхронизации (Alert threshold) и номер сообщения об
ошибке при рассинхронизации (Alert number). 3 Мониторинг передачи журналов После того, как передача журналов настроена, на сервере
мониторинга, в папке "Management", появляется новая
вкладка "Log Shipping Monitor". Некоторые возможности,
доступные с помощью этой утилиты, мы уже рассмотрели в
предыдущем разделе. 4 Где хранится информация о Log Shipping Информация о передаче журналов хранится в базе данных msdb в следующих таблицах:
Эти таблицы присутствуют на всех серверах, участвующих в
передаче журналов. При этом на каждом из серверов данными
заполняется только часть таблиц, в зависимости от того, какую
функцию выполняет сервер в процессе передачи журналов:
является ли он первичным, вторичным или сервером
мониторинга. 5 Синхронизация передачи журналов c репликацией транзакций Для того чтобы в случае выхода из строя сервера - издателя, можно было бы его заменить резервным сервером, на который выполняется передача журналов, существует два режима синхронизации Log Shipping с транзакционной репликацией: синхронный и полусинхронный. Для перехода в этот режим для базы данных устанавливается
опция sync with backup. Этот режим используется, когда недопустимы задержки в
работе репликации. Работа Log Reader Agent уже не зависит от
создания резервных копий журнала. При этом резервный сервер
также можно ввести в качестве издателя в случае сбоя
первичного, несмотря на то, что данные не
синхронны. Имейте в виду, что если дистрибьютор и издатель - это один и тот же сервер, то при переходе на резервный сервер, даже после восстановления последней копии журнала с параметром KEEP_REPLICATION, информация о репликации будет неполная на резервном сервере, т.к. сохранится только та информация, которая хранится в пользовательской БД, а информация о репликации хранится также в базах данных Distribution и msdb. Для того чтобы процесс передачи журналов функционировал без
сбоев, администратору необходимо хорошо обдумывать свои
действия и их последствия. 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  |
|
|
| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
|