1. Короткий вступ в ON-Bar Утиліта ON-Bar надає надійне і масштабується, для резервного копрованія баз...
2. Паралельне резервне копіювання
3. Послідовність виконання паралельного резервного копіювання
4. Малюнок 2. Процеси-нащадки On-Bar
5. Малюнок 3. Блок-схема роботи On-Bar
6. Послідовність виконання паралельного відновлення з резервної копії
7. Малюнок 4. Блок схема відновлення з резервної копії
8. Увага:
9. параметри конфігурації
10. Розрахунок розмірів просторів баз даних для паралельної роботи ON-Bar
11. Малюнок 5. Паралельне резервне копіювання.
12. висновок
13. Подяки
14. Ресурси для скачування

Короткий вступ в ON-Bar

Наше деловое партнерство www.banwar.org

Утиліта ON-Bar надає надійне і масштабується, для резервного копрованія баз даних Informix Dynamic Server. Утиліта читає дані з бази даних і потім спілкується безпосередньо з Storage Manager для запису даних на стрічку, як показано на малюнку 1 . Storage manager відстежує розміщення даних і час, протягом яких дані повинні храніться.В якості storage manager можуть використовуватися наприклад NetWorker від EMC і NetBackup від VERITAS.

Малюнок 1. Архітектура On-Bar

ON-Bar пропонує три різних рівня резервного копіювання:

• Рівень 0 - створює резервну копію всіх даних системи.
• Рівень 1 - створює резервну копію всіх даних, які змінилися з моменту створення резервної копії рівня 0.
• Рівень 2 - створює резервну копію всіх даних, які змінилися з моменту створення резервної копії рівня 1.

Ці три різних рівня можуть бути використані в комбінації один з одним, щоб скоротити тривалість процесу архівації даних.

Паралельне резервне копіювання

Паралельне резервне копіювання дозволяє архівувати дані з декількох просторів баз даних (dbspace) одночасно (кількість одночасно оброблюваних просторів визначається параметром BAR_MAX_BACKUP в файлі конфігурації $ ONCONFIG). Завдяки цьому зменшує загальна тривалість резервного копіювання, за умови що інфраструктура забезпечує оптимальне функціонування. Слід пам'ятати, що при відновленні On-Bar використовує логічні журнали для досягнення точки консистентності даних.

Якщо Ви збираєтеся використовувати паралельне резервне копіювання, то дуже важливо переконатися в тому, що у Вас регулярно створюються резервні копії логічних журналів. У більш ранніх версіях Informix (до v10) дозволялось використовувати паралельне резервне копіювання без збереження логічних журналів. Але в разі відновлення екземпляра Informix з такого архіву (без логічних журналів) повністю відновити всі дані не представлялося можливим.

Переконайтеся, що параметр LTAPEDEV в файлі конфігурації $ ONCONFIG встановлений в значення, відмінне від / dev / null, а також, що скрипт ALARMPROGRAM дозволяє створювати резервні копії логічних журналів з використанням On-Bar. Якщо LTAPEDEV встановлений в / dev / null, то файл логічного журналу буде позначений як збережений, як тільки трапиться перемикання з одного файлу журналу на інший. В цьому випадку журнал не буде збережений.

Послідовність виконання паралельного резервного копіювання

Якщо Ви запускаєте паралельне резервне копіювання або відновлення, драйвер onbar (onbar_d) породжує процеси-нащадки onbar_d (див. малюнок 2 ), Які безпосередньо виконують операції копіювання або відновлення. Кожен процес-нащадок обробляє один простір зберігання даних. ON-Bar обробляє файли логічних журналів послідовно. Якщо Ви запускаєте послідовне резервне копіювання або відновлення, то драйвер onbar виконує операції тільки над одним об'єктом одноразово. Процеси onbar_d записують повідомлення про стан і помилки в журнал активності ON-Bar. Також вони записують інформацію в файл аварійної завантаження, який використовується при "холодному" відновленні.

Малюнок 2. Процеси-нащадки On-Bar

Блок-схема на малюнку 3 описує процес резервного копіювання, що виконується OnBar. При виклику команди резервного копіювання, драйвер onbar будує список просторів зберігання даних і створює сесію резервного копіювання.

Малюнок 3. Блок-схема роботи On-Bar

При паралельному резервному копіюванні (якщо значення параметра BAR_MAX_BACKUP не дорівнює 1), драйвер onbar запускає один або кілька процесів-нащадків onbar_d і призначає завдання для виконання кожного з них. Кожен такий процес-нащадок створює резервну копію одного простору зберігання даних. Процес-нащадок завершує свою роботу після того, як створення резервної копії завершено. Драйвер onbar продовжує створювати нові процес-нащадки, поки не будуть створені копії всіх просторів зберігання. Потім драйвер onbar копіює файли логічних журналів. Якщо Ви створюєте повну резервну копію примірника Informix (whole system backup) або ж у Вас встановлено значення параметра BAR_MAX_BACKUP, рівне 1, то драйвер onbar буде створювати резервні копії просторів зберігання і логічних журналів поледовательності, породивши тільки один процес-нащадок onbar_d.

Після закінчення резервного копіювання драйвер onbar перевіряє чи відбулася помилка. Якщо помилка мала місце бути, то драйвер записує відповідний статус в журнал активності ON-Bar. Інформація про кожного збереженому об'єкті поміщається в файл аварійної завантаження і в базу даних sysutils.

Послідовність виконання паралельного відновлення з резервної копії

Якщо параметр конфігурації BAR_MAX_BACKUP дорівнює 1, ON-Bar відновлює простору зберігання послідовно. Якщо Ви не створювали повну резеврную копію примірника Informix (whole system backup), то Ви повинні використовувати команду 'onbar -r' для відновлення даних. При використанні даної команди ON-Bar відновлює простору зберігання даних в паралельному режимі і потім застосовує зміни з логічних журналів.

Малюнок 4. Блок схема відновлення з резервної копії

При паралельному відновленні (якщо BAR_MAX_BACKUP НЕ дорівнює 1), драйвер onbar запускає кілька процесів-нащадків - onbar_d. Процеси onbar_d переміщують дані між storage manager і сервером баз даних, поки "тепле" відновлення не завершено. Кожен процес onbar_d обробляє один простір зберігання даних.

Увага:

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

Після відновлення кожного об'єкта інформація про це записується в базу даних sysutils. Для кожного простору зберігання ON-Bar відновлює останню копію рівня 0, потім рівня 1 (якщо така існує), потім рівня 2 (якщо існує). Після завершення фізичного відновлення ON-Bar створює резервну копію поточних логічних журналів, щоб зберегти точку консистентності (checkpoint), а потім відновлює дані з логічних журналів. Це дозволяє відновити дані аж до моменту, коли виникла непередбачена ситуація.

Якщо Ви встановили BAR_MAX_BACKUP рівним 0, то система створює стільки процесів ON-Bar, скільки необхідно. Кількість процесів ON-Bar обмежена тільки числом просторів зберігання даних і / або кількістю пам'яті, доступної для використання. Обсяг вільної пам'яті визначається величиною параметра конфігурації SHMTOTAL.

On-Bar визначає максимальне число процесів-нащадків (N) виходячи з наступної формули:

N = SHMTOTAL / (число траспортних буффер * розмір транспортного буфера / тисяча двадцять чотири)

Якщо значення SHMTOTAL дорівнює 0, BAR_MAX_BACKUP заново в 1. Якщо N більше, ніж BAR_MAX_BACKUP, то On-Bar використовує значення BAR_MAX_BACKUP. В іншому випадку запускається N процесів-нащадків.

параметри конфігурації

На додаток стандартним параметрам конфігурації ON-Bar, при паралельному резервного копіювання та відновлення Informix Dynamic server використовує такі параметри конфігурації:

Значення Значення в onconfig.std Ефект BAR_MAX_BACKUP 0 = максимальному числу процесів, що допускаються системою
1 = послідовне резервне копіювання або відновлення
n = встановлює кількість паралельних процесів, рівне n 0 Визначає число паралельних процесів для кожної команди onbar BAR_NB_XPORT_COUNT від 3 і вище 10 Визначає кількість буффер даних, які кожен процес onbar_d може використовувати для обміну даними з сервером баз даних. Значення даного параметра впливає на продуктивність onbar BAR_RETRY BAR_ABORT (0), BAR_CONT (1), або n 1 Якщо встановити в значення BAR_ABORT, то onbar буде переривати копіювання або відновлення при виникненні помилки, пов'язаної з простором зберігання даних або з логічним журналом.
Якщо встановити в значення BAR_CONT, то onbar перерве процес копіювання або відновлення для конкретного простору зберігання даних.
Якщо вказати конкретну цифру (n), то onbar зробить n спроб копіювання або відновлення простору зберігання або логічного журналу перш, ніж перейти до следуещее.

Розрахунок розмірів просторів баз даних для паралельної роботи ON-Bar

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

Припустимо, що потрібно створити екземпляр Informix з об'ємом даних 200 Гб. Є следущий список просторів баз даних:

• rootdbs
• llogdbs
• plogdbs
• tempdbs1
• tempdbs2
• database1dbs
• userdbs1
• userdbs2
• ....
• ....
• userdbsN

Простору якого розміру необхідно організувати?

1. 1. Приклад з великими розмірами просторів баз даних:
   userdbs1 40 Гб userdbs2 40 Гб userdbs3 20 Гб При схемі зберігання даних, аналогічної зазначеної вище, для резервного копіювання usrdbs1 буде виділена одна нитка, в той час, як інші нитки ON-Bar будуть простоювати без роботи.
2. 2. Схема зберігання даних, при якій розкриваються переваги паралельної роботи ON-Bar: userdbs1a 8 Гб userdbs1b 8 Гб userdbs1c 8 Гб userdbs1d 8 Гб userdbs1e 8 Гб userdbs2a 8 Гб userdbs2b 8 Гб userdbs2c 8 Гб userdbs2d 8 Гб userdbs2e 8 Гб userdbs3a 8 Гб userdbs3b 8 Гб userdbs3c 8 Гб userdbs3d 8 Гб userdbs3e 8 Гб

У цьому випадку, як показано на малюнку 5 , Простір розміром 40 Гб розбите на п'ять окремих просторів баз даних. У такій конфігурації On-Bar може використовувати до п'яти паралельних ниток для резервного копіювання даних. Таким чином ми отримали перевагу над першою схемою зберігання даних. В даному випадку вузьке місце буде на стороні програмного забезпечення.

Малюнок 5. Паралельне резервне копіювання.

Аналогічно, буде явна перевага і при відновленні даних з архіву.

висновок

Ми побачили, що продуктивність On-Bar безпосередньо залежить від розмірів і кількість просторів баз даних. При правильному розподілі даних, On-Bar буде виконувати резервне копіювання швидше завдяки паралельним ниткам. У разі, якщо дані переважно знаходяться в одному великому просторі, тільки одна нитка буде забезпечувати архівацію даних, в той час, як інші нитки будуть простоювати.

Подяки

Я хочу подякувати Срінівасахар Прасад і Удей Кейл за їх підтримку, поради та ідеї.

Ресурси для скачування

Схожі теми

Підпишіть мене на повідомлення до коментарів