Тестування доступності

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

“Гаряча заміна

Поняття гарячої заміни відноситься до бази даних, копія якої підтримується на окремому компютері Підтримка гарячої заміни реалізується за допомогою методу, званого доставкою журналу Доставка журналу- це періодичне відновлення резервної копії журналу транзакцій з первинного сервера на сервері гарячої заміни Таким чином, підтримується постійна готовність до роботи резервного сервера У разі збою до роботи миттєво підключаються сервер гарячої заміни і найостанніша резервна копія журналу транзакцій Ця проста схема дозволяє реалізувати доставку журналу без покупки дорогого обладнання і при малих додаткових витратах Однак доставка журналу має і ряд недоліків

■ При збої первинного сервера всі транзакції, виконані з моменту останньої доставки журналу на резервний сервер, виявляться втраченими З цієї причини доставку журналу зазвичай організовують кожні кілька хвилин

■ Перемикання відбувається не зовсім непомітно для користувачів На сервері гарячої заміни повинен бути виконаний певний програмний код, а клієнтське додаток повинен перевизначити джерело даних і підключитися до резервного сервера Далі в цій главі буде наведено приклад такого програмного коду

■ Мають бути створені і періодично виконуватися завдання служби інтеграції, що переміщують реєстраційні записи користувачів з первинного сервера на резервний

■ Коли первинний сервер буде відновлений, повернення до вихідної конфігурації зажадає ручного втручання адміністратора бази даних

Якщо всі ці питання не суперечать організаційним вимогам, то доставка журналу на сервер гарячої заміни може виявитися відмінною альтернативою недоступності бази даних

В ідеальному випадку первинний і резервний сервери повинні перебувати в різних географічних місцях, щоб катаклізми в одному місці не чинили вплив на роботу іншого сервера До того ж доставка журналу накладає додаткове навантаження на мережу, по якій кожні кілька хвилин буде переміщатися журнал транзакцій Якщо два сервера можуть бути обєднані в одну високошвидкісну приватну мережу, то доставка журналу може не позначатися на роботі інших користувачів та необхідної для них смузі пропускання мережі

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

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

Сервери

Доставка журналу звичайно охоплює три екземпляри SQL Server: первинний, сервер гарячої заміни і сервер моніторингу

■ Первинним є головний сервер, до якого зазвичай підключаються клієнти Цей сервер повинен бути дуже якісним і містити надлишкову дискову підсистему

■ Сервером гарячої заміни є резервний сервер, також званий вторинним Якщо головний сервер дає збій, то він стає первинним Цей сервер повинен задовольняти мінімальним вимогам, достатнім для підтримки роботи користувачів під час відновлення головного сервера

■ Сервер моніторингу відстежує роботу первинного та резервного серверів Він знає, коли і які файли були переміщені, і генерує попередження, коли синхронізація цих серверів порушується Один сервер моніторингу може контролювати безліч конфігурацій доставки журналу

Сервер моніторингу може представляти собою екземпляр сервера призначення У той же час розміщення сервера моніторингу на сервері джерела є явною реалізацією плану самознищення Якщо сервер джерела фізично вийде з ладу, то сервер моніторингу також стане непрацездатним і сервер призначення не отримає сигнал на включення в роботу Найкращим рішенням є приміщення сервера моніторингу на окремий компютер

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

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

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

дисковий простір Як первинний, так і всі вторинні сервери повинні мати можливість зчитувати і записувати в цей каталог У Management Studio конфігурування доставки журналу здійснюється наступним чином

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp У вікні Object Explorer утиліти Management Studio первинного сервера клацніть правою кнопкою миші на базі даних, журнал якої повинен доставлятися, і виберіть у контекстному меню пункт Properties

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp На сторінці Transaction Log Shipping діалогового вікна встановіть прапорець Enable transaction log shipping

3&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Конфігуруйте резервування, клацнувши на кнопці Backup Setting Введіть імя загального каталогу на локальному або мережевому сервері Саме в цей каталог буде міститися журнал транзакцій і зберігатися до моменту копіювання на вторинний сервер

Мережевий спільно використовуваний ресурс, що не розміщений на первинному серве-Рада ре, краще захистить бази даних у разі збою обладнання головного сервера

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

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

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

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

6&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Створіть розклад завдань, які будуть резервувати журнал транзакцій Для цього введіть імя завдання, час і частоту Нетривалий час між копіюванням журналу транзакцій мінімізує обсяг даних, втрачених в разі збою

Переконайтеся, що на сторінці Transaction Log Shipping створене тільки одне рас-Рада писання резервування журналу транзакцій В іншому випадку не всі з

менения в даних будуть поширені на вторинні сервери

7&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Додайте вторинні сервери в конфігурацію журналу транзакцій, клацнувши на кнопці Add у вікні другого примірника Повторюючи дії пп 7-14, ви можете створити безліч вторинних примірників

8&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp На екрані вторинної бази даних підключіться до сервера, який виступатиме в ролі резервного, і введіть імя вторинної бази даних Якщо цієї бази даних поки не існує, її слід створити

9&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Ініціалізується вторинну базу даних Для цього можете встановити створення її з резервної копії, створюваної відразу після завершення операції конфігурування доставки журналу, або використовувати для цього вже існуючу резервну копію В останньому випадку вам слід також вказати імя каталогу, в якому знаходиться резервна копія бази даних При бажанні ви можете не ініціалізувати вторинну базу даних

10&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp У вкладці Copy Files встановіть, куди повинні копіюватися файли резервної копії та журналу транзакцій У цій же вкладці можна визначити, через який час файли резервних копій повинні видалятися

Непогана ідея полягає в тому, щоб копіювати файли на резервний сторонній сервер Це гарантує те, що у разі збою обладнання первинного сервера файли залишаться доступними

11&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp У вкладці Copy Files вкажіть, коли файли повинні копіюватися завданням

12&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp У вкладці Restore Тransaction Logs виберіть режим очікування (standby) або скасування відновлення Режим очікування забезпечить доступ до вторинного сервера тільки для операцій читання Якщо ви виберете саме цей варіант, то підключення користувачів будуть видалятися під час доступності копії журналу транзакцій Режим скасування відновлення не відкриє доступ до вторинної базі даних ніякий інший базі даних

13&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp У вкладці Restore Тransaction Log також доступні варіанти відкладеного відновлення та відправки попередження Ці варіанти дозволяють зберегти всі журнали транзакцій до закінчення робочого дня або застосувати їх негайно по отриманні

14&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Для завдання у вкладці Restore Transaction Logs доступні також параметри підвищення гранулярності і часу їх застосування

15&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Клацніть на кнопці ОК, щоб завершити настройку вторинної бази даних і повернутися на сторінку параметрів бази даних

16&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Коли настройка вторинної бази даних буде завершена, сервер моніторингу може бути налаштований у вкладці Properties бази даних Тут же доступний варіант створення сценарію установки

Якщо доставка журналу має безліч параметрів, не передбачених по Советзамовчуванням, то створення сценарію буде гарантувати, що всі виконані

вами зміни конфігурації будуть кожного разу залишатися тими ж

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

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

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

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

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

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp log_shipping_monitor_alert

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

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp log_shipping_monitor_history_detail

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp log_shipping_monitor_primary

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp log_shipping_monitor_secondary

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

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

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp sp_help_log_shipping_monitor_primary

■ s p_he1p_log_shipp ing_moni t оr_s eсondary

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp sp_help_log_shipping_alert_job

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp sp_help_log_shipping_primary_database

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp sp_help_log_shipping_primary_secondary

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp sp_help_log_shipping_secondary_database

■ s p_he lp_log_shippi ng_s e з onda ry_jp ri ma ry

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

Перемикання ролей

Доставка журналу дозволяє вручну перемикати ролі Цю дію можна здійснювати для обслуговування баз даних, а також у разі збою сервера Залежно від причини збоїв та їх частоти краще спочатку виконати резервування журналу транзакцій на первинному сервері Якщо збій призвів до пошкодження даних, то ви можете не виконувати цю дію, щоб пошкоджені дані не потрапили на резервний сервер

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

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

У SQL Server 2005 змінити конфігурацію доставки журналу набагато легше, ніж у більш ранніх версіях SQL Server Змінити вторинну базу даних, доступну тільки для читання, щоб дозволити читання, достатньо просто База даних доставки журналу здатна зменшити навантаження на первинний сервер, переносячи операції читання на вторинний сервер Для цього виконайте такі дії

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp У SQL Server Management Studio клацніть правою кнопкою миші на базі даних, щоб отримати доступ до її параметрами

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Клацніть на сторінці Transaction Log Shipping, щоб отримати доступ до інформації про доставку журналу транзакцій

3&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Відредагуйте властивості другого вузла доставки журналу, клацнувши на еліпсі з трьома крапками

4&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Змініть параметри відновлення у вкладці Restore журналу транзакцій і клацніть на кнопці ОК

5&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Клацніть на кнопці ОК на сторінці Transaction Log, і зміни конфігурації доставки журналу будуть застосовані

З даного моменту всі операції доступу до даних, яким потрібно читання, але не потрібна запис, отримають доступ до другого вузла, а первинний сервер баз даних буде звільнений від операцій читання

Доставка облікових записів користувачів

Ні доставка журналів, організована за допомогою Management Studio, ні збережені процедури не синхронізують реєстраційні записи первинного сервера на сервері гарячої заміни Якщо резервний сервер стає поточним, то він повинен мати ті ж реєстраційні записи, що й основний в іншому випадку користувачі не зможуть отримати до нього доступ Таким чином, одним із важливих завдань стає переміщення реєстраційних записів користувачів з первинного сервера на сервер гарячої заміни Найкраще для виконання цього завдання використовувати завдання служби інтеграції, яке виконує підключення до кожного з серверів і переміщує облікові записи користувачів Якщо ви постійно додаєте облікові записи користувачів сервера, то завдання їх переміщення також потрібно виконувати кілька разів на день в іншому випадку одного рази на день буде цілком достатньо

Повернення до вихідного первинного сервера

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

1 Використовуйте завдання служби інтеграції для переміщення всіх реєстраційних записів користувачів з сервера гарячої заміни на первинний

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

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*