В тази статия ще опишем минималния набор от действия, необходими за оптимална инсталация на СУБД Firebird версия 3.0 върху новите дистрибуции на Linux. За примери са избрани CentOS 8 и Ubuntu 19.
За „доставянето“ на дистрибутива Firebird на целевата система, в това ръководство е избран вариантът за изтегляне на tar.gz архив от линка на официалния сайт на проекта ().
За най-нетърпеливите — веднага на работа:
Бърза инсталация
Редактираме файла /etc/sysctl.conf, добавяйки реда:
vm.max_map_count = 256000
Запазете файла и приложете настройката:
sudo sysctl -p ／etc／sysctl.conf
Следващите инструкции се различават за CentOS 8 и Ubuntu 19, но ССЫЛКА и КАТАЛОГ означават линк от официалния сайт на проекта Firebird за изтегляне на дистрибутива и каталога, в който дистрибутивът ще бъде разпакован по време на изтеглянето.
В момента (март 2020) актуален е релизът Firebird 3.0.5 ( към 64-битовата версия).
CentOS 8
sudo yum -y install epel-release
sudo yum -y makecache
sudo yum -y install libicu libtommath tar
ln -s libncurses.so.5
／usr／lib64／libncurses.so.5
ln -s libtommath.so.1
／usr／lib64／libtommath.so.0
curl -L ССЫЛКА|tar -zxC ／tmp
Ubuntu 19
sudo apt-get -y install libncurses5 libtommath1
ln -s libtommath.so.1
／usr／lib／x86_64-linux-gnu／libtommath.so.0
wget -O- ССЫЛКА|tar -zxC ／tmp
Съществува инсталация на СУБД Firebird:
cd ／tmp／КАТАЛОГ
sudo .／install.sh
Ако искате да разберете по-добре какво означават тези действия – четете нататък.
Основна част
Небольшая преамбула
Предполага се, че ОС вече е инсталирана в минимален вариант и е настроен достъп до публични репозитории или до техните локални копия.
Предполага се, че читателят има основни знания за Linux и СУБД Firebird.
Планиране
На сървъра СУБД е препоръчително да се отделят отделни дялове за временни файлове (/tmp), файлове на бази данни и локални резервни копия.
Временните файлове включват lock-файлове, сортировъчни файлове, файлове за „материализация“ на глобални временни таблици (GTT) и таблици за мониторинг. Сортировъчните файлове и глобалните временни таблици са разположени в /tmp, файлове на mon$-таблици и lock-файлове – в /tmp/firebird.
Сортировъчните файлове „се изтриват“ (unlink) веднага след създаването, така че те не могат да се „видят“ в списъка с каталози – само в списъка на дескрипторите (handles) на процеса (пометени като deleted):
sudo ls -lhF ／proc／`pgrep firebird`／fd
В списъка на псевдокаталога /proc/…/fd/ се показват симлинкове, а фактическата информация за файла дава:
sudo stat -L ／proc／`pgrep firebird`／fd／НОМЕР
където НОМЕР – дескриптор на целевия файл.
Вместо извикване на „pgrep изпълняемия-файл“ можете директно да подставите идентификатора на интересуващия процес.
Временните файлове могат да са много големи, затова е /tmp препоръчително да осигурите поне 20-30 ГБ. Трябва да се вземе под внимание, че размерът на файловете с подредби зависи само от обема на данните, явно или неявно подредени в запитването, и един-единствен потребител може да "създаде" гигабайти временни файлове.
Секцията за файлове на бази данни трябва да съдържа файлове за всички бази, плюс поне копие на файла на най-голямата база. Необходимо е да се прогнозира нарастващият обем на файловете на базите в перспектива за няколко години напред.
Секцията за локални бекъпи трябва да съхранява, поне по един архив на бекъпа за всички бази плюс бекъп на най-голямата база. Желателно е да има място за възстановяване на най-голямата база. Необходимо е да се предвиди нарастващият обем на бекъпите и архивите на бекъпите за следващите няколко години.
Предварителна подготовка
Серверът на СУБД Firebird 3.0 динамично разпределя и освобождава системна памет, което може да доведе до фрагментация. Например, след едновременно изключване на голям брой потребители от суперсервера, могат да възникнат грешки при нови свързвания.
Фрагментацията на паметта се контролира от системния параметър vm.max_map_count, по подразбиране – 64K. Препоръчително е да увеличите стойността му четири пъти:
sudo sysctl vm.max_map_count=256000
За да новата стойност бъде зададена при рестартиране на системата, добавете в файла /etc/sysctl.conf ред:
vm.max_map_count = 256000
Желателно е да направите коментар, за да е ясна причината за промяната на този параметър. Можете първо да редактирате файла и след това да приложите запазените в него настройки:
sudo sysctl -p ／etc／sysctl.conf
Инсталиране на необходимите пакети
Изпълнимите файлове на СУБД Firebird 3.0 Linux зависят от библиотеките ncurses (libncurses.so.5), ICU (без зададена версия и без показване в изхода ldd) и tommath (libtommath.so.0). За разархивиране на архива от сборката ще са необходими утилити. gzip, tar и curl или wget. Версиите на ICU не са значими. gzip, tar и curl/wget Работата с пакетите зависи от системата и от използвания пакетен мениджър, затова ще ги разгледаме последователно.
CentOS 8 използва нов пакетен мениджър –
CentOS 8
dnf и той също "прозрачно" се извиква с командата yum. Тъй като за нашите цели няма разлика между тях – в примерите ще бъдеАктуализиране на кеша на метаданните: Тъй като за нашите цели няма разлика между тях – в примерите ще бъде.
sudo yum makecache Пакетът libtomath се намира в отделен E(xtra)P(ackages for)E(nterprise)L(inux) репозиториум, затова проверяваме дали е вече включен:
yum -C repolist
Опцията "само от кеша" (
--cache-only-C или --cache-only) се използва, за да се изключат ненужните проверки и зареждания, ускорявайки работата на yum. Ако в списъка няма epel-репозиторий – инсталираме го и обновяваме кеша на метаданни:
sudo yum install epel-release &&
sudo yum makecache
Потвърдете запитванията, като при необходимост сверите стойностите на pgp-ключовете с вече известните от доверен източник.
Ако възникнат проблеми при зареждането на метаинформация от репозитория с https-ресурси, редактирайте файла /etc/yum.repos.d/epel.repo, заменяйки https:// на http:// и повторете командата за обновяване на кеша.
Проверете статуса на необходимите пакети (командата е комбинирана, в примерния изход е филтриран 32-битовият пакет):
yum -C list
ncurses libicu libtommath
gzip tar curl wget |
grep -v i686
Инсталирани пакети
curl.x86_64 7.61.1-11.el8 @anaconda
gzip.x86_64 1.9-9.el8 @anaconda
ncurses.x86_64 6.1-7.20180224.el8 @anaconda
Налично пакети
libicu.x86_64 60.3-1.el8 BaseOS
libtommath.x86_64 1.1.0-1.el8 epel
tar.x86_64 2:1.30-4.el8 BaseOS
wget.x86_64 1.19.5-8.el8_1.1 AppStream
Виждаме, че curl, gzip и ncurses разположени в псевдорепозитория на инсталатора (anaconda), а tar – изключен от минималната инсталация на системата. Основните версии libncurses и libtommath са повече, отколкото е необходимо: 6 и 1 вместо 5 и 0, съответно. Ако един и същ пакет е инсталиран и наличен – за него е издадено обновление. Инсталираме липсващите пакети:
sudo yum install
libicu libtommath tar
Ubuntu 19
За управление на пакетите се използват утилити apt, apt‑get и apt‑cache. Първото е предназначено за интерактивна работа, а последните две – за използване в скриптове. Имената на пакетите са малко различни и включват версия.
Проверете статуса на необходимите пакети (командата е комбинирана, примерният изход е съкратен и е филтриран 32-битовите пакети):
apt list libncurses? libicu?? libtommath?
gzip tar curl wget |
grep -v i386
curl 7.65.3-1
gzip 1.10-0 [upgradable…]
libicu63 63.2-2 [инсталиран]
libncurses5 6.1
libncurses6 6.1 [инсталиран, автоматично]
libtommath1 1.1.0
tar 1.30 [инсталиран]
wget 1.20.3 [инсталиран]
Пакетите, за които в квадратни скобки е посочено инсталиран/upgradable – са инсталирани. Наличен, но не инсталиран ncurses5, вместо curl е инсталиран wget. Инсталираме липсващите пакети:
sudo apt‑get install
libncurses5 libtommath1
Създаване на симлинкове
Тъй като libtommath.so.1 и libncurses.so.6 обратно съвместими с libtommath.so.0 и libncurses.so.5, за Firebird е достатъчно да се създадат симлинкове на наличните версии на библиотеките.
Намираме libtommath.so.1 (libncurses.so.? се намират в тази съща директория):
find /usr -name libtommath.so.1
CentOS:
/usr/lib64/libtommath.so.1
Ubuntu:
/usr/lib/x86_64-linux-gnu/libtommath.so.1
Създайте симлинкове.
CentOS:
sudo ln -s libtommath.so.1
/usr/lib64/libtommath.so.0
sudo ln -s libncurses.so.6
/usr/lib64/libncurses.so.5
Ubuntu:
sudo ln -s libtommath.so.1
/usr/lib/x86_64-linux-gnu/libtommath.so.0
Проверете резултата (командата е комбинирана, примерите на изхода са съкратени):
ls -lhF
$(dirname `find /usr -name libtommath.so.1`) |
grep "lib(ncurses|tommath).so."
CentOS:
libncurses.so.5 -> libncurses.so.6*
libncurses.so.6 -> libncurses.so.6.1*
libncurses.so.6.1*
libtommath.so.0 -> libtommath.so.1*
libtommath.so.1 -> libtommath.so.1.1.0*
libtommath.so.1.1.0*
Ubuntu:
libncurses.so.5 -> libncurses.so.5.9
libncurses.so.5.9
libncurses.so.6 -> libncurses.so.6.1
libncurses.so.6.1
libtommath.so.0 -> libtommath.so.1
libtommath.so.1 -> libtommath.so.1.1.0
libtommath.so.1.1.0
Изтегляне на дистрибуцията на СУБД Firebird.
На официалния сайт на проекта Firebird (firebirdsql.org) се публикуват връзки към дистрибуции на "официални" версии (releases) и "ежедневни" сборки (snapshot build).
Официалните версии за линукс са налични под формата на архиви (tar.gz) и пакети deb/rpm, докато сборките – само под формата на архиви. Ще разгледаме "общия инсталатор" (generic installer от tar.gz).
Архивът на сборката трябва да бъде изтеглен и разархивиран, но можем да съчетаем и двата процеса. Разархивирането се извършва в /tmp, URL означава връзка към изтегления архив.
curl:
curl -L URL | tar -zxC /tmp
wget:
wget -O– URL | tar -zxC /tmp
По подразбиране curl изпраща изтегляните данни на стандартния изход, но не обработва пренасочвания и добавяме "-L", а wget, обратно: обработва пренасочвания, но записва данните в файл и поставяме "-O-". За tar указваме използването на gzip-филтрите и директорията, в която ще се извърши разархивирането. След приключване на процеса ще се появи директория на име Firebird-3.0.5.33220-0.amd64 с три файла: install.sh, buildroot.tar.gz и manifest.txt.
Инсталация на Firebird
В хода на предварителната подготовка сме регулирали стойността на системния параметър vm.max_map_count, проверили сме наличността и сме инсталирали библиотеките ICU, ncurses и tommath. Уверихме се в правилността на версиите на ncurses и tommath (libncures.so.5 и libtommath.so.0) и създадохме необходимите симлинкове.
Собствено инсталирането е много просто. Преминаваме в директорията, в която е разархивиран архивът на дистрибуцията на Firebird, проверяваме и, ако е необходимо, задаваме флага "изпълним" на скрипта install.sh:
chmod +x install.sh
стартираме инсталационния скрипт:
sudo ./install.sh
чрез натискане на клавиша Enter потвърждаваме началото на инсталацията, а при получаване на запитване – въвеждаме паролата sysdba.
Инсталационният скрипт автоматично стартира systemd-юнита firebird-superserver (по подразбиране архитектура на Firebird 3.0). Сервизът Firebird ще работи с параметрите по подразбиране за суперсервера: страничен кеш от 2048 страници (на база), буфер за сортиране от 64 MB (общ) и връзка само с клиенти от трета версия. Преглед на параметрите firebird.conf:
grep -v ^# firebird.conf | grep -v ^$
Следва да се има предвид, че новите стойности от firebird.conf ще бъдат активирани само след рестартиране на сервиза Firebird.
При избиране на стойности на параметрите следва да се вземе предвид, че има три основни „потребители“: страничния кеш (за базата), буфера за сортиране (общ) и паметта, предоставена от сървъра за клиентските връзки. Управляват се само първите два – обемът на паметта за клиентските връзки зависи от броя и текста на кешираните запитвания, техните планове и използваните в запитванията обекти на базата. Оценката на паметта за клиентските връзки се прави само емпирично и може да се променя при промяна на клиентските приложения и/или обектите на базата.
За суперсървера на хостове с малък обем памет (до 12-16 GB) не трябва да се отделя за страничния кеш и буфера за сортиране повече от една трета-четвърт от общия обем на RAM.
Ако броят на базите не е фиксиран и може да се променя – общият обем на паметта на страничния кеш следва да се разделя на максималния брой бази, които могат да бъдат на сървера. Размерът на страничния кеш се задава в страници и трябва да се преизчислява отделно в байтове.
За да се премине към архитектурата на класиката, е необходимо най-малко да се посочи явно ServerMode в firebird.conf, да се намали там също страничния кеш (не повече от 2K), да се намали буфера за сортиране (общият допустим обем на всички сортирания, разделен на максималния брой връзки), да се забрани и спре модулът firebird-superserver, да се разреши и стартира модулът firebird-classic.socket.
Използването на архитектурата супер-класик в Firebird 3.0 няма особен смисъл: „надеждността“ е както при суперсървера и същият общ буфер за сортиране. Няма общ страничен кеш и „загубите“ от синхронизация между различните връзки са същите, както при класиката.
Трябва да се помни, че в Firebird 3.0 част от параметрите (страничния кеш, размера на лок-файла, хеш-таблиците и някои други) могат да се задават в databases.conf индивидуално за всяка база. За суперсървера е полезно, например, да се зададе малка стойност DefaultDbCachePages в firebird.conf и да се установят индивидуални странични кешове за нужните бази в databases.conf.
Въпроси по статията задавайте в коментарите или пишете на нашия адрес за поддръжка support@ibase.ru.
Източник: habr.com
