SQL.RU
 client/server technologies
 Главная | Документация | Статьи | Книги | Форум | Блоги | Опросы | Гостевая | Рассылка | Работа | Поиск | FAQ |

Описание технологии работы Log Shipping SQL Server 2000

ПУБЛИКАЦИИ  

Автор: Ирина Наумова

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

СОДЕРЖАНИЕ

1.Описание работы заданий Log Shipping
1.1.Первичный сервер
1.2.Вторичный сервер
1.3.Сервер мониторинга
2.Параметры Log Shipping, доступные уже после его настройки
2.1.Изменение параметров подключения к серверу мониторинга
2.2.Добавление возможности изменения роли серверов
2.3.Изменение состояния базы данных на резервном сервере после восстановления; изменение поведения сервера при восстановлении журнала, когда имеются подключения к БД; изменение частоты копирования и восстановления
2.4.Настройка допустимого времени, в течение которого сервера могут находиться в со-стоянии рассинхронизации; настройка времени задержки восстановления; настройка периода хранения копий журналов транзакций и истории
2.5.Параметры, которые можно изменить с сервера мониторинга
3.Мониторинг передачи журналов
4.Где хранится информация о Log Shipping
5.Синхронизация передачи журналов c репликацией транзакций
5.1.Синхронный режим
5.2.Полусинхронный режим
6.Заключение
7.Статьи MSDN, в которых описывается, как решать некоторые проблемы, возникающие при настройке и работе Log Shipping
8.Другие полезные ресурсы в Интернет, затрагивающие передачу журналов и помогающие в разрешении проблем, возникающий в работе Log Shipping
9.Приложение - Схема работы 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 в следующих таблицах:

  • log_shipping_databases

  • log_shipping_monitor

  • log_shipping_plan_databases

  • log_shipping_plan_history

  • log_shipping_plans

  • log_shipping_primaries

  • log_shipping_secondaries

Эти таблицы присутствуют на всех серверах, участвующих в передаче журналов. При этом на каждом из серверов данными заполняется только часть таблиц, в зависимости от того, какую функцию выполняет сервер в процессе передачи журналов: является ли он первичным, вторичным или сервером мониторинга.
Также не нужно забывать о том, что поскольку при передаче журналов создаются задания и план обслуживания, то задействуется также еще ряд других таблиц из базы msdb, таких как sysjobs, sysjobssteps и т.д.

[В начало]

5 Синхронизация передачи журналов c репликацией транзакций

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

5.1 Синхронный режим:

    Для перехода в этот режим для базы данных устанавливается опция sync with backup.
    В этом режиме Log Reader Agent не отбирает транзакции для передачи подписчикам до тех пор, пока они не будут помещены в копию журнала транзакций, которые создает Log Shipping.
    Этот метод гарантирует, что в случае отказа основного сервера – издателя, информация на всех серверах, участвующей в репликации и передаче журналов, будет синхронизирована, что упрощает процесс переключения на резервный сервер в случае сбоя.
    Но в то же время замедляется процесс репликации, поскольку он теперь становится зависимым от интервала, с которым Log Shipping выполняет резервные копии журнала.

5.2 Полусинхронный режим:

    Этот режим используется, когда недопустимы задержки в работе репликации. Работа Log Reader Agent уже не зависит от создания резервных копий журнала. При этом резервный сервер также можно ввести в качестве издателя в случае сбоя первичного, несмотря на то, что данные не синхронны.
    Подробнее об этом можно прочитать в следующей статье MSDN: Transactional Replication and Log Shipping

Имейте в виду, что если дистрибьютор и издатель - это один и тот же сервер, то при переходе на резервный сервер, даже после восстановления последней копии журнала с параметром 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

[В начало]

Автор: Ирина Наумова  2005г.

Rambler's Top100 Рейтинг@Mail.ru  Administrator: Обратная связь 
Copyright: SQL.Ru 2000-2013