7.2.3. Настройка доставки журналов

Доставка журналов (log shiiping) в SQL Server 2005: настройка, режим доставки журналов без восстановления работоспособности (NoRecovery mode), режим доставки журналов в режиме горячей готовности (standby mode)

Настроить доставку журналов можно как при помощи графического интерфейса Management Studio, так и при помощи команд Transact-SQL. Команды Transact-SQL здесь рассматриваться не будут, поскольку, во-первых, это заняло бы много места и времени, а, во-вторых, необходимый код можно легко сгенерировать автоматически при помощи кнопки Script Configuration (Отскриптовать конфигурацию) на графическом экране Management Studio.

В предыдущей версии SQL Server для настройки доставки журналов использовался Database Maintenance Plan Wizard — мастер настройки планов обслуживания баз данных. В SQL Server 2005 планы обслуживания баз данных не имеют к доставке журналов никакого отношения. Настройка доставки журналов производится из вкладки Transaction Log Shipping (Доставка журналов транзакций) свойств базы данных (рис. 7.1). Эту вкладку можно открыть также из контекстного меню базы данных при помощи команды Tasks | Ship Transaction Logs (Задачи | Доставлять журналы транзакций).

Рис. 7.1. Экран настройки доставки журналов

Остановимся на возможностях настройки доставки журналов:

q      флажок Enable this as a primary database in a log shipping configuration (Включить как основную базу данных в конфигурации доставки журналов) фактически включает доставку журналов для данной базы данных. Если база данных работает в режиме восстановления Simple (см. разд. 4.5), то попытка установить это флажок приведет к появлению предупреждающего сообщения. Использование доставки журналов для баз данных, которые работают в режиме восстановления Bulk-logged, также не рекомендуется. Лучше всего использовать доставку журналов только с режимом Full;

q      нажатие на кнопку Backup Settings (Настройки резервного копирования) приведет к открытию еще одного диалогового окна Transaction Log Backup Settings (Настройки резервного копирования журнала транзакций), в котором вы сможете настроить параметры резервного копирования журнала транзакций основной базы данных. Следующие параметры настраиваются именно из этого окна;

q      Network path to backup folder (Сетевой путь к каталогу резервного копирования) и Local path to the folder (Локальный путь к каталогу) — соответственно, сетевой и локальный пути к каталогу, в который будут помещаться резервные копии журналов транзакций. Служба SQL Server Agent вторичного сервера будет забирать файлы резервных копий из этого каталога. Если вы решили помещать резервные копии сразу на сетевой сервер, то поле с локальным путем можно оставить пустым.

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

q      Delete files older than (Удалять файлы, старше чем) — этот параметр позволяет указать срок (дату), по истечении которого файлы журналов транзакций будут удалены (по умолчанию 3 дня). Даже успешно скопированные и восстановленные файлы журналов транзакций все равно будут оставаться в исходном каталоге в течение указанного времени. То, что они не удаляются сразу, связано с тем, что для одного первичного сервера можно настроить доставку журналов на несколько вторичных;

q      Alert if no backup occurs within (Оповещать, если резервное копирование не происходит в течение) — для этого параметра по умолчанию используется значение 1 час. Он используется для создания предупреждения Log Shipping Primary Server Alert (Предупреждение основного сервера поставки журналов), которое можно увидеть под контейнером Alerts (Предупреждения) в контейнере SQL Server Agent. По умолчанию это предупреждение не назначается ни одному оператору, а, следовательно, увидеть, что оно сработало, можно только при просмотре логов SQL Server Agent (или таблиц истории доставки журналов). Подробно про работу с предупреждениями и операторами будет рассказываться в разд. 8.1.7;

q      Backup job (Задание резервного копирования) — при помощи этой группы элементов управления можно просмотреть параметры создаваемого задания SQL Server Agent, которое и будет выполнять резервное копирование журналов транзакций. При помощи кнопки Edit job (Изменить задание) можно изменить параметры этого задания, а при помощи флажка Disable this job (Отключить это задание) — на время отключить задание. Подробно про работу с заданиями будет рассказываться в разд. 8.1.3.

После того, как вы закончите настройку параметров резервного копирования журналов транзакций и нажмете кнопку OK на вкладке Transaction Log Shipping окна свойств базы данных, вам потребуется настроить параметры восстановления резервных копий на сервере-получателе. Для этого надо нажать кнопку Add (Добавить) под списком Secondary server instances and databases (Вторичные экземпляры серверов и базы данных) на той же вкладке. В открывшемся окне Secondary database settings (Параметры вторичных баз данных) вам потребуется определить следующие параметры:

q      Secondary server instance (Вторичный экземпляр сервера) — тот сервер, на котором будут восстанавливаться резервные копии журнала транзакций;

q      Secondary database (Вторичная база данных) — та база данных, для которой будет производиться восстановление копий журналов транзакций. Можно не только выбрать имя существующей базы данных, но и вписать новое имя. В этом случае базу данных можно будет создать автоматически.

В том же окне при помощи вкладки Initialize Secondary Database (Инициализировать вторичную базу данных) вам придется определиться, как именно будет создана вторичная база данных. В вашем распоряжении три варианта:

q      Yes, generate a full backup of the primary database (Да, сгенерировать полную резервную копию основной базы данных) — будет автоматически проведено полное резервное копирование исходной базы данных, и эта резервная копия будет восстановлена на указанном вами сервере под указанным именем. При помощи кнопки Restore options (Восстановить параметры) можно будет определить местонахождение файлов базы данных и журналов транзакций создаваемой базы данных;

q      Yes, restore an existing backup of the primary database (Да, восстановить существующую резервную копию основной базы данных) — этот вариант используется в ситуации, когда у вас уже есть полная резервная копия основной базы данных и нет необходимости производить ее резервное копирование заново. В этом случае вам потребуется указать сетевой путь к файлу с полной копией;

q      No, the secondary database is initialized (Нет, вторичная база данных уже инициализирована) — при выборе этого варианта вам потребуется самостоятельно позаботиться о создании вторичной базы данных и ее исходной синхронизации с основной.

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

На вкладке Copy Files (Копирование файлов) вы определяете параметры копирования файлов резервных копий журналов транзакций:

q      Destination folder to copied files (Каталог назначения для скопированных файлов) — удобнее всего здесь указать просто локальный каталог на вторичном сервере. Но если это противоречит каким-то правилам безопасности, можно указать и сетевой каталог на файл-сервере;

q      Delete copied files after (Удалять скопированные файлы после) — скопированные файлы будут удалены только через указанное здесь количество часов (даже если восстановление этих резервных копий прошло успешно). По умолчанию задано также 3 суток (72 часа);

q      Copy job (Задание копирования) — при помощи этого параметра можно узнать имя создаваемого задания SQL Server Agent, которое будет заниматься копированием файлов резервных копий журналов транзакций, настроить расписание резервного копирования, а также при необходимости отключить это задание.

На вкладке Restore Transaction Log (Восстановление журналов транзакций) вы можете настроить параметры восстановления резервных копий журналов транзакций:

q      Database state when restoring databases (Состояние базы данных при восстановлении) — это очень важный параметр, который определяет, будет ли база данных открываться для пользователей. В вашем распоряжении два варианта:

·                No recovery mode (Режим без восстановления работоспособности) — база данных открываться для пользователей не будет;

·                Standby mode (Режим "горячей готовности") — база данных будет открыта в режиме "только чтение". Однако понятно, что если к базе данных подключены пользователи, восстановление журналов транзакций производиться не будет. Поэтому вы можете или смириться с задержками при восстановлении, или принудительно отключать пользователей при восстановлении, установив флажок Disconnect users in the database when restoring backups (Отсоединять пользователей от базы данных при восстановлении резервных копий).

Оба варианта достаточно неудобны. Возможно, в некоторых ситуациях имеет смысл открывать доступ к пользователям в режиме STANDBY, настроив расписание для восстановления таким образом, чтобы восстановление происходило только во внерабочее время. Однако при использовании такого решения мы теряем главное преимущество доставки журналов — быструю синхронизацию основной и вторичной баз данных;

q      Delay restoring backups at least (Отложить восстановление базы данных по крайней мере на) — этот параметр дает возможность определить задержку перед восстановлением резервной копии. По умолчанию задано без задержки;

q      Alert if no restore occurs within (Предупредить, если восстановления не производятся в течение) — при помощи этого параметра можно указать пороговое время ожидания для восстановления резервных копий. Если в течение указанного времени (по умолчанию оно равно 45 минутам) восстановление по каким-то причинам произведено не будет, сработает предупреждение. Как и предупреждение резервного копирования, это предупреждение можно найти в контейнере SQL Server Agent | Alerts. Оно называется Log shipping Secondary Server Alert (Предупреждение вторичного сервера доставки журналов). Для того чтобы оно действительно оповещало администратора (например, при помощи сетевого сообщения или письма по электронной почте) ему нужно будет назначить оператора;

q      Restore Job (Задание восстановления) — можно выбрать имя и расписание для задания, которое будет заниматься восстановлением резервных копий журналов транзакций.

После того, как настройка вторичного сервера будет завершена, вам останется только вернуться в окно свойств основной базы данных и настроить параметры сервера мониторинга. В принципе, можно обойтись и без сервера мониторинга, но производить диагностику поставок журналов без информации, которая накапливается в таблицах этого сервера, намного сложнее. Включить такой сервер можно при помощи флажка Use a monitor server instance (Использовать экземпляр сервера мониторинга). Затем при помощи кнопки Settings (Параметры) вам потребуется настроить дополнительные параметры сервера мониторинга:

q      Monitor server instance (Экземпляр сервера мониторинга) — этот параметр позволяет выбрать сервер, который будет отслеживать доставку журналов;

q      Monitor connections (Отслеживать соединения) — определяет, как именно задания, которые выполняют резервное копирование, копирование по сети и восстановление, будут "отчитываться" перед сервером мониторинга (т. е. заносить информацию в его таблицы):

·                By impersonating the proxy account of the job (При помощи имперсонации учетной записи-прокси задания) — подключение будет производиться от имени специальной учетной записи-прокси. Ее можно определить из вкладки Job system (Система заданий) свойств SQL Server Agent на том сервере, на котором выполняется задание. По умолчанию используется учетная запись, от имени которой работает служба SQL Server Agent.

Если переключатель Monitor connections установлен в это положение, то этой учетной записи нужно предоставить права на запись информации в таблицы на сервере мониторинга;

·                Using the following SQL Server login (Использование следующего логина SQL Server) — можно явно указать логин SQL Server, который будет использоваться для подключения к серверу мониторинга. Конечно, вам потребуется создать соответствующий логин на сервере мониторинга и предоставить ему соответствующие права;

q      Delete history after (Удалять историю после) — через сколько дней будут удаляться старые записи из таблиц мониторинга. По умолчанию определено, что через четыре дня;

q      Alert job (Задание для оповещения) — этот параметр позволяет настроить задание, которое будет выполняться на сервере мониторинга и опрашивать основной и резервный сервера на предмет появления каких-либо проблем с доставкой журналов. Обратите внимание, что опрос по умолчанию производится каждые две минуты, что может повлиять на производительность работы сервера мониторинга.

Получить учебные материалы по этому курсу