Реалізація резервування сервера бази даних малою кров’ю на прикладі Oracle Standard Edition, Інші СУБД, Бази даних, статті

Ліричний вступ.


10 років тому на одній з моїх минулих робіт один користувач запустив “крутий дефрагментатор”, скачаний з Інтернету, на машині з найбільшим жорстким диском в конторі – 2.5ГБ. На цьому диску зберігалися документи, створені за останні 3 роки – майже всі документи невеликий організації. Повна псування кореневої директорії і обох копій таблиці FAT говорили, що документам кінець, але половину документів вдалося відновити завдяки недавно зробленій дефрагментації: ми за допомогою прямого редактора диска шукали блоки, схожі на директорії, знаходили розмір і початковий кластер файлу і потім зчитували дані прямо з фізичного диска. Якби в організації виконувалися елементарні процедури по резервуванню та збереження даних, то ці “танці з бубном” були б не потрібні і друга половина документів збереглася б.

Хороше доказ користі резервного копіювання?! Адже пропажа документів або бази даних може привести до серйозного збою в роботі організації і навіть до питання про її ліквідацію!

Добре, з резервним копіюванням більш-менш ясно. Що ще? Ще – резервування серверів!


Що тут може бути складно, скажете ви? – Робимо бекап даних, а при падінні сервера піднімаємо новий і відновлюємо дані з бекапа! Так, можливо це вихід, але поки ми будемо піднімати сервер, настроювати його і заливати дані (а їх може бути багато гігабайти), робота організації буде зупинена. Особливо це критично для баз даних. Скажімо, пропаденіе бази клієнтів дуже ускладнить роботу майже всім службам організації на ті години, які ви витратите на відновлення і запуск системи. Якщо клієнтів тисячі або того більше – це дуже критично. А якщо при цьому під рукою не знайшлося підходящого “заліза”? – Тоді починаємо бігати висолопивши язика: терміново шукати готівку (за безнал швидко не купиш – хіба що під гарантійний лист) і бігти в магазин за залізом, а заодно і за вазеліном (за такий прорахунок точно не нагорода). Чи не краще заздалегідь підготуватися до можливих катаклізмів? Крім того,

в резервної копії, природно, не буде останніх змін, зроблених після виконання останнього бекапу. Адже не робити ж бекап кожні п’ять хвилин …

Oracle для постійної підтримки живої копії бази має можливість об’єднувати сервера баз в групу. Один сервер є головним – з ним і працюють користувачі, а на решту йде онлайн копіювання змін основної бази. У разі виходу з ладу основного сервера один з резервних перейде в режим головного і робота організації може бути продовжена. Така можливість Oracle називається “Data Guard”. Для реалізації цього режиму необхідний Oracle Enterprise Edition. У документації добре описано, як це зробити. Складність може виявитися не в технічній реалізації, а у фінансах: Enterprise істотно дорожче Standard. Якщо ви можете дозволити собі придбати Enterprise або користуєтеся піратським софтом, то можете не забивати собі голову дурницями тієї, яку я зібрався вам розповісти, а робіть все по документації.

Описав я Data Guard дуже грубо – своїми словами. Я не фахівець з Oracle. Рік тому я не знав ще, що буду з ним працювати. Скажу більше: я його в очі не бачив. Я підкреслюю це, щоб показати, що щоб зробити описане нижче, не обов’язково бути крутим фахівцем – достатньо мати час і читати документацію. Правда, тлумачний порадник теж не завадив би (і він у мене був).

Далі я розповім, як зробити подобу Data Guard, маючи в розпорядженні тільки Oracle Standard Edition. Це не наш винахід. В Інтернеті було знайдено цікавий документ, в якому на кількох картинках і десятці рядків тексту (документ PowerPoint) було показано, як це зробити. Наша ж заслуга тільки в тому, що ми змогли це реалізувати і це стабільно працює вже півроку.


Створення та оновлення.


Для початку нам необхідно створити два однакових сервера. Бажано, щоб операційні системи, розташування файлів Oracle, табличних просторів і логів збігалися – це зробить перенос “холодної” копії бази легкою справою. На основному (primary) сервер створюємо необхідні instances і заливаємо дані. На резервному (standby) налаштовуємо Oracle, створюємо ті ж instances (потрібні лише імена – табличні простору і логи можна не створювати).

Після запуску та перевірки працездатності primary сервера необхідно зробити “холодну” копію кожного зарезервованого instance на standby сервері:

1. зупинити primary instance

ALTER DATABASE CLOSE;

або

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

2. створити standby controlfile

ALTER DATABASE CREATE STANDBY CONTROLFILE AS “filepath”;

3. Скопіювати всі файли, пов’язані з Вашим instance (табличні простору, redo, pfile та / або spfile, orapw), на місце, де буде розташований майбутній standby instance.

4. Замінити всі controlfile в standby instance на створений standby controlfile (тобто скопіювати його в N місць і перейменувати, як зазначено в параметрі control_files).

5. Якщо не був скопійований spfile, створити його з pfile, не стартуючи instance:

$ ORACLE_SID=….

$ sqlplus “/ as sysdba”

CREATE SPFILE FROM PFILE = “filepath”;

6. Запустити standby instance в режимі MOUNT:

STARTUP MOUNT;

7. Запустити primary instance в режимі READ-WRITE:

STARTUP;

або, якщо база вже була подмонтіровать,

ALTER DATABASE OPEN;

8. Налаштувати механізм періодичного копіювання archivelogs primary instance в директорію standby instance, визначену параметром log_archive_dest_1. Після завершення копіювання підключитися до standby instance і виконати наступні команди:

ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE UNTIL CANCEL;

ALTER DATABASE RECOVER CANCEL;

Для отримання найсвіжіших змін, перед копіюванням archivelogs слід примусово переключити redolog на primary instance:

ALTER SYSTEM SWITCH LOGFILE;

Для того, щоб перемикання redo-логів і скидання archive-логів відбувалося максимально швидко, був обраний мінімальний розмір файла для redo-логів і достатня їх кількість (я зробив 10 штук). Це і переключення призводить до створення величезної кількості archive-логів. При щотижневому бекап мені доводиться видаляти багато тисяч цих файлів.

Сам процес у нас повністю автоматизований з використанням cron і shell-скриптів. Копіювання логів і керування standby базою здійснюється через ssh. Рекомендую для авторизації використовувати RSA ключі.


Самих скриптів не викладаю. У них, власне, нічого

складного немає: треба лише передбачити збереження номера останнього скопійованого archive-лога і блокування для заборони копіювання та застосування archivelogs на час проведення робіт з зупиненим primary або standby instance та виконання гарячого бекапу.

Скрипт у нас запускається кожні п’ять хвилин. Це означає, що, в разі падіння primary сервера, можлива втрата даних не більше ніж за останні п’ять хвилин роботи – решта archive-логи уже скопійовані.


Перемикання standby instance в режим read only.


У порівнянні з Data Guard у описаної схеми є ще один недолік – не можна виконувати запити до standby серверу для зниження навантаження на primary – адже база закрита. Так, користувачам це буде недоступно, але адміністратор може тимчасово перевести standby instance в режим read only:


1. підключитися до standby instance і виконати наступну команду: ALTER DATABASE OPEN;


В цьому режимі підкачка змін з archivelogs неможлива!


2. щоб повернутися в закритий режим, потрібно виконати наступну команду:


ALTER DATABASE CLOSE;

Відключати на цей час механізм переносу archive-логів не обов’язково, тому що необроблені archive-логи будуть підкачати системою пізніше.


Переклад standby instance в режим primary instance.


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


1. підключитися до standby instance і виконати наступну команду:


ALTER DATABASE ACTIVATE STANDBY DATABASE;

Після цього повернення в режим standby неможливий – тепер це активна база!


2. відкрити instance в режимі read-write:

ALTER DATABASE OPEN;


Щоб користувачі змогли виявити новий сервер, слід адресувати його по доменному імені, але не по IP: після зміни IP в відповідного запису на DNS-сервер і повного відключення primary сервера (по харчуванню або з локальної мережі) клієнтське ПО звертатиметься вже до нового серверу. Рекомендую не прописувати IP сервера в

hosts на клієнтських машинах.

Перед впровадженням системи ми провели випробування з перемиканням і DNS. Експеримент показав, що на все про все, включаючи перезавантаження клієнтського ПЗ, яке не вміє відновлювати розірване подкюченіе до бази, потрібно не більше 5 хвилин.


Про недоліки.



Два нестачі я вже описав вище – можлива втрата останніх змін (в нашому випадку – максимум за останні п’ять хвилин) і неможливість роботи користувачів з standby instance в режимі READ ONLY. Я знайшов ще одну ваду: не можна змінювати розміри табличних просторів standby instance. Потрібно визначати розміри з запасом і дозволяти подальше зростання файлів.


Скрипт збору статистики наведено у файлі за наступним посиланням (http://www.realcoding.net/dn/oracle_scripts/scripts/stats_sample.sql).

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


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

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

Ваш отзыв

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

*

*