Поточна конвертація баз Firebird 2.5 у формат ODS12 (Firebird 3.0)

Кожна версія Firebird має власну версію формату дискових структур бази даних – O(n)D(isk)S(tructure). До версії 2.5 включно, двигун Firebird міг працювати з ODS попередніх версій, тобто бази від старих версій відкривалися новою версією і працювали в режимі сумісності, але двигун Firebird 3.0 працює тільки з БД у власній ODS версії 12.0.

Щоб перейти на 3.0, базу даних від 2.5 необхідно перетворювати на новий формат через backup/restore. Зрозуміло, ми припускаємо, що БД була попередньо підготовлена ​​конвертації — тобто. метадані та запити були перевірені на сумісність із Firebird 3.0.

Якщо слідувати стандартному підходу, це означає, що потрібно зробити бекап на версії 2.5, потім встановити 3.0 і зробити рестор. Така процедура є прийнятною, якщо є достатньо часу, але при міграції великих баз даних, або при одночасної міграції кількох десятків БД, коли час підтискає, можна скористатися потоковою конвертацією, яка на 30-40% швидше. Як саме це зробити (під Windows та під Linux), читайте під катом.

Загальна ідея полягає в тому, що для прискорення ми скористаємося конвеєром:

gbak -b … база25 stdout | gbak -c … stdin база30

Gbak від 2.5 генерує бекап у лінійному форматі і направляє його в stdout, який відразу через stdin підхоплює gbak від 3.0 і створює нову БД.

Організовувати такий конвеєр потрібно обов'язково локальним (файловим) методом доступу, оскільки мережевий доступ (навіть через localhost) суттєво уповільнить процес.

Нижче ми розглядаємо деталі для Windows та Linux.

Windows

У випадку Windows найпростіше зробити повністю автономне складання Firebird. Для цього беремо embed-архів Firebird 2.5, перейменовуємо fbemded.dll на fbclient.dll, додаємо з архіву «звичайного» 2.5 утиліти gbak.exe і (необов'язково) – isql.exe.

Firebird 3.0 використовує єдине складання і не вимагає жодного доопрацювання.

Мінімальний варіант (не вимагає установки рантайм-бібліотек VS2008/VS2010 на цільовій системі) містить наступні файли:

25/gbak.exe
25/fbclient.dll
25/firebird.conf
25/firebird.log
25/firebird.msg
25/ib_util.dll
25/icudt30.dll
25/icuin30.dll
25/icuuc30.dll
25/Microsoft.VC80.CRT.manifest
25/msvcp80.dll
25/msvcr80.dll

30/fbclient.dll
30/firebird.conf
30/firebird.msg
30/gbak.exe
30/ib_util.dll
30/icudt52.dll
30/icudt52l.dat
30/icuin52.dll
30/icuuc52.dll
30/msvcp100.dll
30/msvcr100.dll
30/intl/fbintl.conf
30/intl/fbintl.dll
30/plugins/engine12.dll

Досвідчений адміністратор може помітити, що 2.5 не включені файли intl/fbintl.dll і intl/fbintl.conf. Це дійсно так, оскільки gbak не використовує чарсет коннекта і не конвертує дані між чарсетами, але на "приймальній" стороні Firebird 3.0 ці файли необхідні для створення індексів.

У firebird.conf Firebird 3.0 рекомендується додати:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Також, бажано встановити різні значення IpcName для 2.5 і 3.0.

При виборі значень інших параметрів firebird.conf виходимо з простого міркування: на етапі переливання даних в одному процесі gbak працює 2.5, а в іншому – 3.0, потім 2.5 завершує роботу, а 3.0 починає побудова індексів.

Щоб прискорити етап побудови індексів 3.0, рекомендується збільшити розмір параметра TempCacheLimit до ~40% RAM (якщо це виділений сервер, звичайно).

Наприклад, якщо на сервері 16 Гб RAM, можна поставити

TempCacheLimit=6G

Зрозуміло, таке значення можна ставити тільки у 64-бітного Firebird 3, оскільки будь-який 32-бітовий процес не зможе аллокувати більше 2х гігабайт пам'яті.

У 2.5 цей параметр міняти не потрібно - він і так не може бути більше 2х гігабайт, та й при бекапі на швидкість не впливає.

Перед виконанням операції потрібно перевірити, чи сторінковий кеш у заголовку бази даних встановлений у 0 (команда gstat -h databasename, дивитися рядок Page buffers).

Якщо кеш заданий явно в хидер БД, то він перевизначає значення з firebird.conf (і databases.conf в 3.0), і в разі неадекватно великих значень може призвести до зайвого споживання пам'яті та догляду у своп.

Далі копіюємо файли на цільову систему.

Конвертація проводиться після зупинки «системної» служби Firebird 2.5 у командному рядку з підвищенням прав до локального адміністратора (приклад):

set ISC_USER=владелец
"25/gbak" -z -b -g -v -st t -y 25.log база25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin база30

У цьому прикладі використовується "пряма коса" в лапках (допустимий "unix-style"), а "капелюшок" (символ "^") екранує символ перекладу рядка, що зручно при наборі довгих команд. Опція -st(atus) з'явилася Firebird 2.5.8 і дозволяє записати в протокол дані про час роботи процесу gbak (подробиці – в документації).

Linux

Linux Firebird 3 залежить від бібліотеки Tommath. У CentOS (RHEL) ця бібліотека знаходиться в epel-репозиторії, в Ubuntu (Debian) - системному.

Для CentOS потрібно спочатку підключити epel-репозиторій і лише потім робити

yum install libtommath

Ubuntu не потрібно підключати додаткові репозиторії, але в Ubuntu 16 і Ubuntu 18 встановлюються різні версії пакетів - libtommath0 і libtommath1, відповідно.

Firebird 3.0 шукає tommath.so.0 і для Ubuntu 18 додатково потрібно створити посилання (symlink) з tommath.so.0 на tommath.so.1. Для цього спочатку потрібно знайти tommath.so.1.

Шуканий шлях у Ubuntu – /usr/lib/x86_64-linux-gnu/, але в інших Debian-based дистрибутивах може бути інакше.

Друга проблема пов'язана з тим, що Firebird 3.0.1, включно, не було простого способу встановити дві різні версії сервера. Варіант «компілюємо з вихідних джерел з потрібним префіксом» ми не розглядаємо через його відносну трудомісткість.

Для Firebird 3.0.2 та вище реалізована складання з –enable-binreloc та окрема опція інсталятора (-path шлях).

Припускаючи, що бібліотека tommath і, при необхідності, симлінк для tommath.so.0 додані в систему, можна доустановити актуальний (на момент написання цієї статті) дистрибутив Firebird 3.0.4, наприклад, /opt/fb3:

./install.sh -path /opt/fb3

Після цього можна зупиняти системний сервіс Firebird та запускати потокову конвертацію.

При зупинці Firebird треба враховувати, що процеси Firebid 2.5 в режимі Classic зазвичай запускає xinetd - тому потрібно заборонити сервіс firebird для xinetd або зупинити xinetd повністю.

У firebird.conf для 3.0 на Linux не потрібно задавати MaxUnflushed-параметри (вони працюють лише на Windows) та змінювати налаштування Firebird 2.5.

У лінуксі локальний (файловий) доступ Firebird 2.5 не еквівалентний embeded-варіанту під Windows - сервер 2.5 працюватиме в процесі gbak (без мережної частини), але права доступу перевірятимуться по базі користувачів, а отже, знадобиться не тільки логін, а й пароль :

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30

Після успішної конвертації треба видалити спочатку «додатковий» Firebird 3.0, потім «основний» Firebird 2.5 і після цього виконати чисту установку Firebird 2.5 — причому найкраще зі штатного установника tar.gz, а чи не через репозиторії, т.к. версія у репозиторіях може відставати.

Також, після рестора БД на Linux та переустановки треба перевірити, щоб нова БД мала власником користувача firebird.

Якщо це не так, то треба буде виправити

chown firebird.firebird database

Підсумок

Окрім економії часу та місця на диску у потокової конвертації є ще одна важлива перевага – перетворення бази робиться без видалення існуючого Firebird 2.5, що помітно спрощує відкат при невдалій конвертації (найчастіше через брак місця або несподіване перезавантаження під час процесу міграції).

Економія часу пов'язана з тим, що «класична» конвертація – це «час бекапу» плюс «час відновлення». Відновлення складається з двох частин: читання даних із файлу бекапу та побудова індексу.

При поточній конвертації сумарний час виходить як час бекапу плюс п'ять-десять відсотків і час побудови індексів.

Конкретні результати залежить від структури бази, але у середньому час відновлення приблизно дорівнює подвійному часу бэкапа. Тому якщо брати за одиницю час бекапу, то «класична конвертація» — три одиниці часу, потокова — дві одиниці часу. Додатково скоротити час допомагає збільшити TempCacheLimit.

Загалом, потокова конвертація практично дозволяє заощадити 30-40% відсотків часу почергового бэкапа і рестора.

Питання?

Будь ласка, всі питання пишіть у коментарях, або направляйте автору методики та співавтору цієї статті — Василю Сидорову, провідному системному інженеру компанії iBase, за адресою bs at ibase ru.

Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.

Якою версією Firebird користуєтесь?

• Firebird 3.x

• Firebird 2.5

• Firebird 2.1

• Firebird 2.0, 1.5 або 1.0

Проголосували 16 користувачів. Утримався 1 користувач.

Джерело: habr.com