Главная » Microsoft SQL Server, Базы данных » Тестирование доступности

0

Недоступную базу данных нельзя назвать полезной. представляет собой имитацию процесса восстановления базы данных в самом пессимистическом сценарии. Мерой доступности является время, необходимое для восстановления самых свежих производственных данных на тестовом сервере, и доказательство работоспособности клиентских приложений.

“Горячая” замена

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

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

?               Переключение происходит не совсем незаметно для пользователей. На сервере “горячей” замены должен быть выполнен некоторый программный код, а клиентское приложение должно переопределить источник данных и подключиться к резервному серверу. Далее в этой главе будет приведен пример такого программного кода.

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

?               Когда первичный сервер будет восстановлен, возвращение к исходной конфигурации потребует ручного вмешательства администратора базы данных.

Если все эти вопросы не противоречат организационным требованиям, то доставка журнала на сервер “горячей” замены может оказаться отличной альтернативой недоступности базы данных.

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

Доставка журнала

Корпоративная редакция SQL Server включает в себя мастер доставки журнала (Log Shipping Wizard), интегрированный в мастер обслуживания базы данных, который создает план обслуживания, резервирующий, копирующий и восстанавливающий журнал транзакций с первичного сервера на резервный каждый несколько минут.

Серверы

Доставка журнала обычно охватывает три экземпляра SQL Server: первичный, сервер “горячей” замены и сервер мониторинга.

?               Первичным является главный сервер, к которому обычно подключаются клиенты. Этот сервер должен быть очень качественным и содержать избыточную дисковую подсистему.

?               Сервером “горячей” замены является резервный сервер, также называемый вторичным. Если главный сервер дает сбой, то он становится первичным. Этот сервер должен удовлетворять минимальным требованиям, достаточным для поддержания работы пользователей во время восстановления главного сервера.

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

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

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

Конфигурирование доставки журнала в Management Studio

Доставку журнала можно сконфигурировать с использованием двух методов: с помощью Management Studio и с помощью системных хранимых процедур. При использовании любого из этих методов должно быть создано и сконфигурировано для совместного использования

дисковое пространство. Как первичный, так и все вторичные серверы должны иметь возможность считывать и записывать в этот каталог. В Management Studio конфигурирование доставки журнала осуществляется следующим образом.

1.              В окне Object Explorer утилиты Management Studio первичного сервера щелкните правой кнопкой мыши на базе данных, журнал которой должен доставляться, и выберите в контекстном меню пункт Properties.

2.              На странице Transaction Log Shipping открывшегося диалогового окна установите флажок Enable transaction log shipping.

3.              Сконфигурируйте резервирование, щелкнув на кнопке Backup Setting. Введите имя общего каталога на локальном или сетевом сервере. Именно в этот каталог будет помещаться журнал транзакций и храниться до момента копирования на вторичный сервер.

Сетевой совместно используемый ресурс, не размещенный на первичном серве- Совет   ре, лучше защитит базы данных в случае сбоя оборудования главного сервера.

4.              Введите такое значение времени, по истечении которого файлы журнала транзакций должны удаляться. Например, если файлы должны удаляться через день, введите в поле Delete Files Older Than интервал в один день.

5.              Введите такое значение времени в поле If No Backup Occurs Within, по истечении которого в случае отсутствия нового журнала транзакций сервер должен отправлять предупреждение.

Чем больше промежуток времени до отправки предупреждения, тем большему

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

6.              Создайте расписание заданий, которые будут резервировать журнал транзакций. Для этого введите имя задания, время и частоту. Непродолжительное время между копированием журнала транзакций минимизирует объем данных, утраченных в случае сбоя.

Убедитесь, что на странице Transaction Log Shipping создано только одно рас- Совет          писание резервирования журнала транзакций. В противном случае не все из

менения в данных будут распространены на вторичные серверы.

7.              Добавьте вторичные серверы в конфигурацию журнала транзакций, щелкнув на кнопке Add в окне второго экземпляра. Повторяя действия пп. 7-14, вы можете создать множество вторичных экземпляров.

8.              На экране вторичной базы данных подключитесь к серверу, который будет выступать в роли резервного, и введите имя вторичной базы данных. Если этой базы данных пока не существует, ее следует создать.

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

10.           Во вкладке Copy Files установите, куда должны копироваться файлы резервной копии и журнала транзакций. В этой же вкладке можно определить, через какое время файлы резервных копий должны удаляться.

Неплохая идея заключается в том, чтобы копировать файлы на резервный сторонний сервер. Это гарантирует то, что в случае сбоя оборудования первичного сервера файлы останутся доступными.

11.           Во вкладке Copy Files укажите, когда файлы должны копироваться заданием.

12.           Во вкладке Restore Тransaction Logs выберите режим ожидания (standby) либо отмену восстановления. Режим ожидания обеспечит доступ к вторичному серверу только для операций чтения. Если вы выберете именно этот вариант, то подключения пользователей будут удаляться во время доступности копии журнала транзакций. Режим отмены восстановления не откроет доступ к вторичной базе данных никакой другой базе данных.

13.           Во вкладке Restore Тransaction Log также доступны варианты отложенного восстановления и отправки предупреждения. Эти варианты позволяют сохранить все журналы транзакций до окончания рабочего дня либо применить их немедленно по получении.

14.           Для задания во вкладке Restore Transaction Logs доступны также параметры повышения гранулярности и времени их применения.

15.           Щелкните на кнопке ОК, чтобы завершить настройку вторичной базы данных и вернуться на страницу параметров базы данных.

16.           Когда настройка вторичной базы данных будет завершена, сервер мониторинга может быть сконфигурирован во вкладке Properties базы данных. Здесь же доступен вариант создания сценария установки.

Если доставка журнала имеет множество параметров, не предусмотренных по Совет       умолчанию, то создание сценария будет гарантировать, что все выполненные

вами изменения конфигурации будут каждый раз оставаться теми же.

17. После щелчка на кнопке ОК на странице параметров базы данных откроется диалоговое окно сохранения конфигурации, после чего настройку доставки журнала можно считать завершенной.

Чтобы удалить доставку журнала, откройте страницу параметров базы данных, перейдите к вкладке Transaction Log Shipping, снимите флажок Log Shipping и щелкните на кнопке ОК.

Мониторинг доставки журнала

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

Ниже приведен список таблиц, которые можно использовать для мониторинга доставки журнала.

?               log_shipping_monitor_alert

?               1og_shiрр ing_moni tоr_e ггоr_detail

?               log_shipping_monitor_history_detail

?               log_shipping_monitor_primary

?               log_shipping_monitor_secondary

Все эти таблицы находятся в базе данных msdb (так как доставка журнала по своей сути представляет набор заданий) всех серверов, вовлеченных в конфигурацию доставки журнала.

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

?               sp_help_log_shipping_monitor_primary

?               s p_he1p_log_shipp ing_moni t оr_s eсondary

?               sp_help_log_shipping_alert_job

?               sp_help_log_shipping_primary_database

?               sp_help_log_shipping_primary_secondary

?               sp_help_log_shipping_secondary_database

?               s p_he lp_log_shippi ng_s e с onda ry_jp r i ma ry

Для мониторинга доставки журнала также может пригодиться отчет Transaction log shipping, который находится в узле Reports страницы Summary сервера.

Переключение ролей

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

Для того чтобы переключиться на резервный сервер, на него следует либо вручную скопировать файлы журнала транзакций, либо с помощью задания SQL Server Agent. После копирования файлы журнала транзакций должны быть восстановлены в правильном порядке на вторичном сервере. Последний журнал транзакций восстанавливается с параметром WITH RECOVERY, позволяющим закрыть все открытые транзакции и привести SQL Server в обновляемое состояние. В идеальном случае все эти действия лучше выполнить и задокументировать прежде, чем переключиться на вторичный сервер.

Конфигурирование ожидающего сервера запросов, доступного только для чтения

В SQL Server 2005 изменить конфигурацию доставки журнала гораздо легче, чем в более ранних версиях SQL Server. Изменить вторичную базу данных, доступную только для чтения, чтобы разрешить чтение, достаточно просто. База данных доставки журнала способна уменьшить нагрузку на первичный сервер, перенося операции чтения на вторичный сервер. Для этого выполните следующие действия.

1.              В SQL Server Management Studio щелкните правой кнопкой мыши на базе данных, чтобы получить доступ к ее параметрам.

2.              Щелкните на странице Transaction Log Shipping, чтобы получить доступ к информации о доставке журнала транзакций.

3.              Отредактируйте свойства второго узла доставки журнала, щелкнув на эллипсе с тремя точками.

4.              Измените параметры восстановления во вкладке Restore журнала транзакций и щелкните на кнопке ОК.

5.              Щелкните на кнопке ОК на странице Transaction Log, и изменения конфигурации доставки журнала будут применены.

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

Доставка учетных записей пользователей

Ни доставка журналов, организованная с помощью Management Studio, ни хранимые процедуры не синхронизируют регистрационные записи первичного сервера на сервере “горячей” замены. Если резервный сервер становится текущим, то он должен иметь те же регистрационные записи, что и основной; в противном случае пользователи не смогут получить к нему доступ. Таким образом, одной из важных задач становится перемещение регистрационных записей пользователей с первичного сервера на сервер “горячей” замены. Лучше всего для выполнения этой задачи использовать задание службы интеграции, которое выполняет подключение к каждому из серверов и перемещает учетные записи пользователей. Если вы постоянно добавляете учетные записи пользователей сервера, то задание их перемещения также нужно выполнять несколько раз в день; в противном случае одного раза в день будет вполне достаточно.

Возвращение к исходному первичному серверу

После того как первичный сервер был восстановлен и приведен в полную готовность, следующие действия позволят реинициализировать его в период, когда пользователи не подключены.

1.              Используйте задание службы интеграции для перемещения всех регистрационных записей пользователей с сервера горячей замены на первичный.

2.              Переместите базу данных со вторичного сервера на первичный, используя для этого либо полное резервное копирование и восстановление, либо отключение и подключение базы данных.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии