Як реалізувати резервне копіювання за допомогою онлайн-дампа InterBase XE7
Dmitry Kuzmenko, 08-SEP-2016
InterBase, починаючи з версії 2007, підтримує онлайн-дамп - онлайн-копіювання файлу бази даних. Замість gbak -b/-c це дозволяє отримати готову до використання базу даних після копіювання, і вам не потрібно «відновлювати» її з резервної копії (щось, що не є базою даних). Онлайн-дамп дуже швидкий, майже як копіювання файлу операційною системою.
Використовуйте наступну команду для створення онлайн-дампа бази даних
gbak -d [options] database target
(Повний опис дампу можна знайти в документації, Doc\OpGuide.pdf, або тут)
Так само, як і для файлу бази даних, цільовий файл може мати будь-яку назву та розширення, які вам подобаються. Результатом команди буде файл дампу, еквівалентний оригінальній базі даних, але в режимі лише для читання.
Час першого запуску цієї команди - це час сканування (читання) вихідної бази даних та час запису цільового файлу.
Поки цільовий файл перебуває в режимі лише для читання, він пов’язаний із файлом бази даних. При першому дампі буде прочитано та скопійовано весь файл бази даних у цільовий файл. При другому та наступних - лише змінені сторінки будуть записані в цільовий файл. Це називається «інкрементальним дампом».
Важливо! InterBase XE7 при кожній повторній команді дампу (з тими самими іменами файлів, звісно) читає лише змінені сторінки бази даних і записує їх у цільовий файл. Інші версії до XE7 читають повну вихідну базу даних. Отже, продуктивність різна, і XE7 набагато швидший. Якщо у вихідній базі даних не було змінено жодної сторінки, інкрементальний дамп XE7 займе ~1 секунду, тоді як InterBase2007-XE3 витратить час, необхідний для читання всього файлу бази даних. Час залежить від розміру вихідної бази даних та швидкості зберігання. Наприклад, якщо швидкість зберігання становить близько 400 МБ/с, то база даних об’ємом 100 ГБ буде сканована за 250 секунд (4 хв 10 с).
Примітка. InterBase XE7 підтримує формати файлів баз даних XE7 (ODS 16), XE/XE3 (ODS 15) та 2009 (ODS 13). Функція розумного сканування, згадана вище, працюватиме лише з форматом бази даних XE7 (ODS 16).
Якщо вам потрібно перевести цільовий файл у режим читання-запису (звичайний режим), використовуйте команду
gfix target -mode read_write
Але після цього цільовий файл втрачає зв’язок із базою даних, і подальший запуск gbak -d database target стає неможливим, оскільки цільовий файл вважається «іншою» базою даних.
Якщо ви хочете повністю перезаписати цільовий файл замість інкрементального дампу, використовуйте опцію -ov
gbak -d -ov database target
Дамп дампу
Перший дамп дампу працюватиме, але наступні інкременти - ні. Наприклад, спочатку
gbak -d database target1
тут ми отримуємо target1 як повну дамповану базу даних у режимі лише для читання
Далі,
gbak -d target1 target2
Як бачите, ми створюємо дамп дампу. І так, ця команда скопіює target1 у target2. Обидва цільові файли будуть у режимі лише для читання. Але якщо ми повторимо ці дві команди знову, зміни, які перейшли з бази даних у target1, не будуть скопійовані в target2. Отже, target2 залишається в стані після першого, початкового копіювання. І не буде жодних повідомлень про помилки чи попередження.
Отже, якщо ви коли-небудь захочете зробити дамп дампу, ви повинні використовувати лише повний дамп
gbak -d -ov target1 target2
Опція -ov є обов’язковою, щоб гарантувати, що target2 буде записаний (і перезаписаний) із джерела target1.
Схема резервного копіювання 1
Приклад дампів у різні часові інтервали
gbak -d database target
Запускається, наприклад, щогодини. Тут ми маємо робочу вихідну базу даних і «резервну» копію target, яка відстає на одну годину.
Крім того, додатково кожні 24 години ми можемо запускати
gbak -d database target2
Тут ми маємо робочу базу даних, копію target, що відстає на 1 годину, і копію target2, що відстає на 24 години.
Ви можете створювати будь-яку кількість дампів з однієї бази даних.
Зрозуміло, що цільові дампи можна використовувати як бази даних лише для читання для будь-яких цілей - звітності, аналітики тощо, для завдань, які не потребують перегляду актуальної бази даних.
Плюси: Кожен дамп можна планувати незалежно.
Мінуси: Затримки між найновішим і найстарішим дампом.
Схема резервного копіювання 2
Послідовний дамп у різні цільові файли. У цьому випадку вам потрібно налаштувати планувальник (ОС або власний) для запуску наступних команд по одній за вказаний часовий інтервал
gbak -d database target1
gbak -d database target2
gbak -d database target3
Якщо ви використовуєте 1-годинний інтервал між цими командами, ви отримаєте дампи (резервні копії) таким чином:
target1 о 12:00, target2 о 13:00, target3 о 14:00. Наступний запуск дампу target1 буде оновлено о 15:00 і так далі. У результаті ми матимемо копії баз даних за останні 3 години.
Плюси: ми маємо дампи за кілька годин, які близькі до оригінальної бази даних
Мінуси: трохи складно планувати ці команди. Тобто в цьому прикладі команди дампу потрібно планувати за точним часом:
Дамп у target1 о 00:00, 03:00, 06:00…
Дамп у target2 о 01:00, 04:00, 07:00…
Дамп у target3 о 02:00, 05:00, 08:00…
Підсумок
Gbak -d можна використовувати для дампу в локальне сховище та для дампу через мережу - оскільки інкрементальний дамп надсилає в цільовий файл лише змінені сторінки. Отже, цільовий файл можна розмістити на віддаленому мережевому сховищі. Але, звісно, мережа повинна мати хорошу пропускну здатність, щоб бути сумісною з локальним сховищем. Інакше запис у цільовий файл буде повільним.
Онлайн-дамп можна використовувати не лише як інструмент для створення онлайн-резервної копії бази даних, але і як інструмент для «горизонтального масштабування» системи, для балансування навантаження робочих, звітних та аналітичних застосунків.
Хоча ви бачите, що онлайн-дамп є найшвидшим способом отримати онлайн-копію бази даних (замість gbak -b/-c), оскільки дамп працює зі сторінками, він може пропустити деякі пошкодження сторінок, якщо база даних пошкоджена. Таким чином, вам все одно потрібно перевіряти узгодженість бази даних за допомогою старого доброго gbak -b/-c, але ви можете робити це рідше, ніж раніше.