По материалам статьи Ron Talmage: Log
Shipping in SQL Server 2000
СОДЕРЖАНИЕ
Введение
Log shipping предназначен для увеличения степени
доступности баз данных SQL Server, за счёт автоматического
копирования и восстановления журнала транзакция одной базы
данных в журнал другой базы данных на другом сервере.
Поскольку вторая база данных (далее: резервная) получает все
изменения из первой базы данных, она является точным
дубликатом первой базы данных с задержкой на процесс
копирования и загрузки записей журнала. В любой момент можно
сделать резервный сервер основным, если вдруг оригинальный,
первый сервер (далее: промышленный) станет недоступным. Когда
промышленный сервер снова станет доступным, его можно сделать
резервным, полностью изменив роли обеих серверов.
В
изданиях Microsoft SQL Server 2000 Enterprise и Developer, в
Enterprise Manager присутствует утилита для log shipping, как
часть Database Maintenance Plan Wizard. Предварительно, нужно
настроить систему log shipping или, в случае SQL Server 7.0,
использовать не поддерживаемые семёркой инструментальные
средства log shipping, доступные в Microsoft BackOffice 4.5
Resource Kit. Этот визард упрощает процесс установки,
конфигурации и контроля SQL Server 2000 log shipping.
[Содержание]
Установка log
shipping
Первый сервер (primary server) - это промышленный сервер,
на котором осуществляется реальная работа и на нём расположена
исходная база данных. Второй сервер (secondary server)
содержит резервную базу данных, в которую копируется и
восстанавливается журнал регистрации транзакций исходной базы
данных. Сервер мониторинга (monitor server) контролирует
первый и второй сервер. В отличие от метода контроля log
shipping в SQL Server 7.0 для secondary server, SQL Server
2000 log shipping использует для контроля утилиту Enterprise
Manager Log Shipping Monitor. Microsoft рекомендует
устанавливать эту утилиту на отдельном сервере
мониторинга.
Для установки SQL Server 2000 log shipping
используется Enterprise Manager Database Maintenance Plan
Wizard. Прежде, чем использовать этот визард, Вы должны
сделать некоторые первоначальные приготовления. Выполните
следующие шаги:
1. Определите пары серверов для log shipping (то есть,
primary server и резервные варианты сервера, которые должны
участвовать в log shipping). Хотя Вы можете устанавливать log
shipping между двумя базами данных на одном сервере, эта
статья предполагает, что Вы устанавливаете log shipping между
разными серверами.
2. Определите monitor server, который
должен быть отдельным от промышленного и резервных серверов.
3. Установите политики безопасности для всех серверов.
Учетная запись Windows NT, которая будет использоваться для
установки log shipping, должна иметь привилегии системного
администратора SQL Server (sa) на всех серверах.
4.
Создайте первичные и вторичные распределённые файловые
ресурсы. Сначала, создайте ресурс для папки, в которой
постоянно будет находиться журнал транзакций исходной базы
данных промышленного сервера. Во вторых, создайте ресурс для
папки резервного сервера, в которую Вы планируете копировать и
восстанавливать журналы транзакций. Чтобы было понятно
назначение файлового ресурса, пропишите имена сервера и базы
данных в имени файлового ресурса. Если файловые ресурсы уже
существуют, можно удалить или переместить другие файлы,
особенно старые резервные копии файлов журналов транзакций, из
этих файловых ресурсов. Установите разрешения на этот
совместно используемый файловый ресурс для учетной записи
Windows, которую использует SQL AGENT каждого сервера.
5.
Решите, каким способом Вы создадите и проведёте первоначальную
синхронизацию резервных баз данных. Вы можете воспользоваться
встроенными средствами при установке log shipping для создания
и первоначальной синхронизации резервных баз данных, или
восстановить полную резервную копию базы данных вручную.
6. Зарегистрируйте все три сервера (то есть: primary
server, secondary сервера и monitor server) в Enterprise
Manager.
После того, как будут завершены эти предварительные
приготовления, Вы готовы использовать Database Maintenance
Plan Wizard для установки log shipping. Вы можете
рассматривать процесс установки, как последовательность из
пяти шагов, которые изображены на рисунке №1.
|
Primary server |
|
|
|
Secondary server |
|
Промышленная база данных
|
—> |
1. Инициализация полной резервной
копии |
—> |
2. Восстановление полной
копии без RECOVERY |
—> |
Резервная база данных |
|
|
|
|
|
|
V |
|
|
|
|
|
|
|
^
| |
|
|
3. Периодические резервные
копии журнала |
|
|
|
SQL Agent Xp_sqlmaint |
—> |
5. Восстановление
резервной копии журнала без RECOVERY |
|
|
|
V |
|
|
|
|
|
|
|
|
|
4. Копирование файла
журнала транзакций |
|
|
|
V
|
|
|
|
|
|
V |
|
|
|
|
|
|
|
|
|
|
|
|
Файл резервной копии
журнала транзакций |
|
|
|
|
V |
|
|
—> |
Скопированный файл
резервной копии журнала транзакций |
|
|
|
|
|
|
|
|
|
|
Monitor server |
|
|
|
|
|
|
|
|
—> |
MSDB |
<— |
|
|
|
|
|
|
|
|
|
|
|
|
|
Рисунок №1. Log Shipping в SQL Server 2000
Первые два шага являются дополнительными. Если Вы в начале
не синхронизировали базы данных основного и резервного
сервера, на шаге №1 будет сделана резервная копия исходной
базы данных. На шаге №2, визард копирует резервную копию на
secondary server и восстанавливает её поверх резервной базы
данных.
Визард всегда исполняет следующие три шага: На шаге
№3 он создаёт задачу для SQL AGENT на primary server. Эта
задача периодически выполняет резервное копирование в файл.
Этот визард также создает ориентированный на log shipping план
обслуживания (maintenance plan) для базы данных на secondary
server. Этот план состоит из двух заданий SQL AGENT: первое
для копирования журнала транзакций на secondary server (Шаг
№4), а второе для восстановления журнала регистрации
транзакций поверх резервной базы данных (Шаг №5).
Эти шаги
создают log shipping пару (то есть: две базы данных
участвующих в log shipping). Чтобы ещё больше повысить
избыточность или установить связанный сервер, Вы можете
сформировать дополнительные log shipping пары, установив log
shipping для primary server с другими, дополнительными
резервными серверами.
[Содержание]
Пошаговое
руководство
Чтобы воспользоваться услугами специализированного визарда,
выполните представленные ниже шаги. Откройте Enterprise
Manager и разверните в нём primary server, перейдите в папку
Management, и запустите Database Maintenance Plan Wizard. В
первом экране визарда нужно выбрать промышленную базу данных,
а затем поставить галочку в чекбоксе "Ship the transaction
logs to other SQL Servers (log shipping)" внизу экрана.
Создавать maintenance plan одновременно можно только для одной
промышленной базы данных. Указанный чекбокс будет доступен
только если для исходной базы данных выбрана full или
bulk_logged recovery model, потому что только эти модели
допускают резервирование журнала транзакций.
Следующие несколько экранов представляют параметры для
определения полной резервной копии базы данных в рамках
maintenance plan. Однако, планы несущие более одной
функциональной нагрузки могут оказаться сложными для
восприятия, так что автор статьи предлагает создать отдельный
план для log shipping.
В окне Specify Transaction Log
Backup Disk Directory, выберите чекбокс Use this directory, и
перейдите в папку журнала транзакций primary server.
Удостоверитесь в том, что указанная в Remove files older than
продолжительность хранения, достаточна для сохранения журнала
на primary server, пока не будут обеспечены все необходимые
требования вашей стратегии резервирования. Если Вы зададите
слишком короткую продолжительность, и если задача копирования
журнала на secondary server окончится сбоем, другая задача SQL
AGENT на primary server удалит резервную копию журнала
транзакций до того, как SQL Server скопирует её на secondary
server, что приведёт к сбою в работе механизма log shipping.
Определите в качестве значения по умолчанию для расширений
файлов журналов регистрации транзакций в виде ".trn", Эти
файлы план обслуживания будет именовать в соответствии с
форматом bname_tlog_yyyymmddhhmm.trn.
В следующем экране
задаётся Transaction Log Share, и этот экран появляется только
если определено, что план использует log shipping. В этом
экране нужно идентифицировать файловый ресурс для primary
server. Вы можете использовать кнопку с точками (...) для
перехода к этому файловому ресурсу.
В экране Log Shipping
Destinations можно добавить secondary server или несколько
таких серверов по одному. Щёлкните кнопку Add, чтобы открыть
диалоговое окно Add Destination Database, и в котором можно
ввести всю информацию о secondary server. Текстовое поле
Server Name показывает имя резервного сервера, такое, как оно
зарегистрировано в Enterprise Manager при предварительной
подготовке. В текстовом поле Directory, введите имя каталога
резервного сервера, в который будут помещаться копии журналов
транзакций исходной базы данных. Это имя - локальный путь к
файловому ресурсу. Вы можете выбирать опцию Create and
initialize new database на secondary server, что бы SQL Server
скопировал и восстановил первоначальную резервную копию базы
данных. Или Вы можете выбирать Use existing database (No
initialization) если Вы уже выполнили восстановление базы
данных. Если ваша база данных большая, может понадобиться
выполнить резервное копирование вручную и восстановить
резервную базу в удобное время.
Резервная база данных
должна быть в состоянии nonrecovered, что бы SQL Server мог
восстанавливать журналы транзакций. Вы имеете два параметра,
относящихся к состоянию загрузки базы данных: No recovery mode
или Standby mode. No recovery mode не означает, что
пользователи не смогут делать запросы к базе данных;
восстановление журнала транзакций будут единственным
выполняемым действием. Standby mode переводит базу данных в
режим read-only так, чтобы пользователи могут обращаться с
запросами к базе, когда не активно восстановление журнала
транзакций. Окно Add Destination Database также содержит опцию
Terminate users in database (Recommended) включение которой не
позволит работать пользователям, если осуществляется
восстановление базы данных или журнала транзакций. Во время
восстановления журнала транзакций, выполняющий эту работу
процесс будет единственным, которому разрешено работать с
базой данных. Поэтому Microsoft и рекомендует использовать эту
опцию, потому что присутствие других пользователей в базе
данных может замедлить восстановление.
Также Вы можете
выбрать опцию Allow database to assume primary role, которая
позволяет резервной базе данных переключаться на роль
основной, промышленной базы данных, являющейся первичным
источником для log shipping и, таким образом, получить
возможность в будущем аннулировать первоначальные роли между
промышленным и резервным серверами. Когда Вы выбираете эту
опцию, определите файловый ресурс для secondary server как
папку для резервной копии журнала транзакций для будущей
промышленной базы данных.
В следующем окне Initialize the
Destination Databases Вы можете выбирать использование уже
существующей резервной копии или сделать новую. Для больших
баз данных использование существующей резервной копии может
быть более удобно. Однако, все журналы транзакций, которые
были созданы с момента резервного копирования, должны уже
находиться в файловом ресурсе для журнала транзакций на
primary server, и иметь правильный порядок, чтобы визард мог
скопировать и восстановить их на secondary server. Для
небольших баз данных намного проще предоставить создание
резервных копий визарду.
В окне Log Shipping Schedules
устанавливается периодичность создания резервных копий для
исходной базы данных, а также для их копирования и загрузки в
заданиях для SQL AGENT, которые визард создаёт на secondary
server. Периодичность работы log shipping можно сделать
довольно частой, вплоть до одного раза в минуту, но задание
исполнения необходимых работ один раз каждые 5 минут является
более распространённым вариантом для больших баз
данных.
Параметры в окне Log Shipping Thresholds нужны для
того, чтобы установить приемлемые значения для времени
ожидания на резервное копирование журнала транзакций и
исполнение заданий на его копирование и восстановление. Если
эти пороговые значения будут превышены, диалоговое окно Log
Shipping Monitor на monitor server инициирует соответствующее
предупреждение.
Коль уж речь зашла о monitor server,
следующее окно Specify Log Shipping Monitor Server Information
позволяет определить сервер, который будет использоваться в
качестве monitor server. Будьте внимательны: Вы можете просто
принять значение по умолчанию, но часто значением по умолчанию
является primary server. Как правило, не является хорошей
практикой использование в качестве monitor server
промышленного или резервного сервера, потому что Вы не сможете
определять текущее состояние log shipping, если любой из этих
серверов станет недоступен.
После этого вы пройдёте ещё
несколько окон, содержащих другие параметры визарда, и в
последнем его окне нужно будет выбрать название для плана
обслуживания. Автор для ясности предлагает использовать в
названии фразу log shipping. Лучше не включать имя сервера в
названии плана, если Вы планируете в будущем изменять роли
серверов. Щёлкните Finish, и визард автоматически установит
log shipping для первичного - промышленного сервера, резервных
серверов и также установит Log Shipping Monitor на monitor
server.
[Содержание]
Изменение
конфигурации log shipping
Чтобы изменить конфигурацию log shipping, используют
диалоговое окно Properties maintenance plan. Вкладка
transaction log содержит параметры конфигурации резервного
копирования журнала транзакций. Вкладка log shipping
показывает log shipping пары, которые были созданы в рамках
этого плана, а также другие пары, которые были добавлены к
плану. Эта вкладка также содержит параметры, с помощью которых
можно добавить новую резервную базу данных (создав новую пару
log shipping) или удалить выбранную log shipping пару, а также
отредактировать свойства выбранной log shipping пары или
полностью удалить log shipping.
Когда Вы выбираете Edit во
вкладке log shipping, открывается диалоговое окно Edit
Destination Database. В диалоговом окне General tab, Вы можете
просматривать и изменять каталог журнала регистрации
транзакций резервного сервера и новое расположение файлового
ресурса основного сервера, которые были заданы при установке.
На вкладке Initialize можно изменить режим восстановления и
копирования на secondary server, а также периодичность
восстановления. На вкладке Thresholds можно установить
пороговые значения продолжительности операций. На Sync
Threshold устанавливают максимально разрешённую
продолжительность операции (между самой последней резервной
копией журнала транзакций промышленной базы данных и самым
последним восстановлением журнала), после чего Log Shipping
Monitor сгенерирует предупреждение (Вы можете установить этот
параметр и через Log Shipping Monitor). Значения Load Time
Delay, File Retention Period и History Retention Period
относятся к secondary server.
Monitor server играет важную
роль в этих параметрах конфигурации. Вкладка log shipping во
многом зависит от monitor server, так что Вы не можете
изменять эти значения конфигурации log shipping, когда monitor
server недоступен. Когда автор запустил на monitor server
утилиту SQL Server 2000 Profiler он обнаружил, что primary
server подсоединился к monitor server, чтобы получить
имеющуюся в таблицах monitor server информацию о планировании
log shipping. Поэтому, чтобы изменить параметры настройки
плана log shipping, Вы должны удостовериться, что monitor
server доступен в Enterprise Manager.
[Содержание]
Мониторинг log
shipping
Если Вы использовали log shipping в SQL Server 7.0 или
создавали свою собственную систему для log shipping, Вы,
вероятно, контролируете работу log shipping на secondary
server. Однако, SQL Server 2000 для поддержки log shipping
имеет специальную утилиту Log Shipping Monitor, которая обычно
размещаете на отдельном monitor server.
Где SQL Server 2000
хранит информацию о log shipping? Семь таблиц для log shipping
постоянно находятся в базе данных msdb. Для SQL Server 2000
Developer и Enterprise это: log_shipping_plans,
log_shipping_plan_databases, log_shipping_databases,
log_shipping_plan_history, log_shipping_monitor,
log_shipping_primaries, log_shipping_secondaries.
Каждая из
этих таблиц существует на промышленном и резервном и серверах,
а также на сервере для мониторинга. Каждый сервер использует
только некоторые из этих таблиц, чтобы хранить данные,
связанные с его ролью в log shipping.
Рассмотрим log
shipping для primary server. Из Enterprise Manager можно
подключиться к primary server и контролировать работу log
shipping. Если база данных включена в log shipping, на вкладке
General диалогового окна Properties базы данных будет указана
её роль (источник - source или адресат - destination), а также
будет отмечено, если этот сервер содержит Log Shipping
Monitor. Вы сможете контролировать состояние и хронологию
работы заданий на резервное копирование журнала транзакций для
log shipping в Enterprise Manager в разделе SQL Server Agent,
папка Jobs.
Primary server использует только две таблицы
для log shipping в базе msdb. В таблицу log_shipping_databases
сервер вставляет строку, привязывающую идентификатор (id)
соответствующего maintenance plan базы данных к базе данных,
играющей в log shipping роль промышленной, т.е. основной базы.
В таблицу log_shipping_monitor сервер вставляет строку,
содержащую имя для monitor server и тип его
логина.
Рассмотрим log shipping для secondary server. План
для log shipping постоянно находится на secondary server. С
этого сервера можно контролировать задания SQL AGENT, которые
копируют файлы журналов транзакций на сервер и восстанавливают
эти журналы поверх базы данных резервного сервера. Также можно
увидеть у базы данных резервного сервера в диалоговом окне
Properties отметку о её роли в log shipping.
В базе данных
msdb на secondary server для log shipping используются четыре
таблицы. После создания SQL сервером log shipping плана, будет
вставлена строка в таблицу log_shipping_plans, которая
фиксирует имена Primary server и Secondary server, а также
расположение файлов и идентификаторы (ID) заданий на
копирование и восстановление (который будут получены из
системной таблицы sysjobs на secondary server). В таблице
log_shipping_plan_databases сервер привязывает план к именам
промышленных и резервных баз данных и хранит информацию о
последних скопированных и загруженных файлах. Таблица
Log_shipping_plan_history содержит записи для каждого задания
на копирование и восстановление в рамках log shipping плана, а
также информацию о порядке исполнения этих задач. В таблицу
log_shipping_monitor сервер вставляет строку со ссылкой на
monitor server.
Если при установке с помощью Database
Maintenance Plan Wizard Вы выбрали возможность смены роли
резервного сервера на промышленный, Вы увидите одну важную
особенность у secondary server: появится дополнительный план
обслуживания (maintenance plan) с точно таким же именем, как у
плана, который Вы создали, но у него не будет инициализирован
log shipping. Также Вы увидите заблокированную задачу для SQL
AGENT, которая призвана создавать резервную копию журнала
транзакций локальной базы данных. Хотя на первый взгляд это и
вносит некоторую путаницу, имеющий такое же имя maintenance
plan является дополнительным планом, который зарезервирован на
тот случай, если роли серверов будут изменены.
Рассмотрим
контроль log shipping с помощью monitor server. После того,
как log shipping будет установлен, SQL Server запускает
утилиту Enterprise Manager Log Shipping Monitor на monitor
server. Кроме того, SQL Server создает два оповещения для SQL
AGENT: одно для резервного копирования, а второе для состояния
out-of-sync (отсутствует синхронизация).
Чтобы использовать
эту утилиту, откройте Enterprise Manager и подключитесь к
monitor server, перейдите в папку Management и выберите Log
Shipping Monitor. Вы увидите список log shipping пар. Щёлкните
правой кнопкой мыши по паре log shipping, чтобы увидеть
историю её резервного копирования, копирования файлов журналов
и их восстановления. История копирования и восстановления
особенно полезна, потому что она даёт быстрый доступ к
информации об ошибках и представляет о них более
детализированную информацию, чем Вы можете получить в истории
заданий SQL AGENT на secondary server.
Вкладка Status
диалогового окна Properties у пары показывает состояние её
резервного копирования и процессов копирования и
восстанавливать. Состояние может быть нормальным (Normal) или
Out-of-Sync. Если SQL Server Agent не скопировал или не
восстановил transaction log, диалоговое окно отобразит имя
журнала в виде first_file_000000000000.trn. Это не настоящее
имя реального файла, оно просто показывает (особенность
утилиты), что SQL Server Agent не обработал ни одного файла.
Вкладка Status также показывает текущие дельты в минутах для
Backup, Copy и Load (имеется ввиду восстановление журнала).
Информация на этой вкладке не обновляется автоматически, так
что Вы должны закрыть и повторно открыть это диалоговое окно,
чтобы обновить данные.
Для log shipping SQL Server использует только две таблицы в
базе msdb, чтобы хранить информацию о log shipping парах. В
каждой таблице, SQL Server генерирует идентификатор (id)
определяющий запись и ограничение внешнего ключа (foreign key
constrain) для ссылок в log_shipping_secondaries на primary_id
в log_shipping_primaries (только эти две таблицы в log
shipping содержат ограничение внешнего ключа). Таблица
log_shipping_primaries содержит строку для каждой промышленной
базы данных, состояние её задачи резервного копирования
журнала транзакций, а также информацию о плановых отключения
электропитания (которую Вы можете использовать для
предотвращения излишних оповещений). Таблица
Log_shipping_secondaries содержит строку для каждой резервной
базы данных, которая является подобием промышленной базы
данных log shipping. Связанные строки обоих таблиц и формируют
пары log shipping, которые Вы наблюдаете в Log Shipping
Monitor.
Каждая log shipping пара имеет в диалоговом окне
Log Shipping Pair Properties вкладки Source и Destination,
которые позволяют корректировать информацию о пороговых
значениях для генерации оповещений об отказах в резервном
копировании и для оповещений об Out-of-Sync. Эти
предупреждения относятся к двум заданиям для SQL AGENT,
выполняющимся на monitor server: Log Shipping Alert Job -
Backup и Log Shipping Alert Job - Restore. По умолчанию,
каждое из заданий выполняется один раз в минуту. Эти задания
генерируют ошибку для Windows 2000 или Windows NT Application
log, когда время исполнения резервного копирования для log
shipping пары превышает аварийный порог или когда процессы
копирования и восстановления превышают порог длительности для
Out-of-Sync.
[Содержание]
Удаление и повторная
установка log shipping
Чтобы удалять log shipping из плана обслуживания базы
данных, откройте у плана диалоговое окно Properties, перейдите
на вкладку log shipping, и затем щёлкните по Remove log
shipping. Это удалит задания для SQL AGENT на копирование и
восстановление на secondary server, очистит информацию в
таблицах для log shipping на этом сервере и удалит всё
связанную информацию из Log Shipping Monitor. Однако, после
удаления останется не тронутым задание на резервное
копирование журнала транзакций для primary server. Это задание
удаляется при удалении соответствующего maintenance plan для
базы данных. При удалении Log Shipping Monitor на monitor
server, удаляются соответствующие строки в таблицах
log_shipping_primaries и log_shipping_secondaries в базе
данных msdb, расположенной на monitor server.
Если при
установке log shipping с помощью Database Maintenance Plan
Wizard Вы предусмотрели возможность для резервной базы данных
принять роль промышленной базы данных, maintenance plan базы
данных на secondary server и его задача резервного копирования
журнала останутся на secondary server даже после того, как Вы
удаляете план на primary server. Чтобы их удалить, необходимо
удалить maintenance plan для log shipping у базы данных на
secondary server. Когда Вы экспериментируете с SQL Server 2000
log shipping, возможно, что Вы будет иногда прерывать процесс
инсталляции. Когда Вы это сделаете, некоторые данные могут
остаться в таблицах log shipping на каждом из серверов и могут
мешать при последующих попытках установки log shipping. (Для
дополнительной информации, см. статью Microsoft: "BUG:
All Changes May Not Be Rolled Back When Log Shipping
Maintenance Wizard Fails") Чтобы избежать подобной
ситуации, удалите все относящиеся к прошлым попыткам данные в
таблицах для log shipping в базах msdb на каждом из
серверов.
[Содержание]