Installation de Firebird 3 sur les versions modernes de Linux : CentOS 8 et Ubuntu 19

Dans cet article, nous décrirons le minimum d'actions nécessaires pour une installation optimale de la base de données Firebird version 3.0 sur les nouvelles distributions Linux. Pour les exemples, nous avons choisi CentOS 8 et Ubuntu 19.

Pour "livrer" le distributeur Firebird au système cible, ce guide choisit l'option de téléchargement de l'archive tar.gz à partir du lien du site officiel du projet (firebirdsql.org).

Pour les plus impatients — au travail :

Installation rapide

Nous éditons le fichier /etc/sysctl.conf, en ajoutant la ligne :

vm.max_map_count = 256000

Nous enregistrons le fichier et appliquons la configuration :

sudo sysctl -p /etc/sysctl.conf

Les instructions suivantes varient pour CentOS 8 et Ubuntu 19, mais LIEN et CATALOGUE désignent le lien du site officiel du projet Firebird pour télécharger le distributeur et le répertoire dans lequel le distributeur sera décompressé lors du téléchargement.
À l'heure actuelle (mars 2020), la version actuelle est Firebird 3.0.5 (voici le lien pour la version 64 bits).

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 LIEN|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- LIEN|tar -zxC /tmp

L'installation de la base de données Firebird en elle-même :

cd /tmp/CATALOGUE
sudo ./install.sh

Si vous souhaitez mieux comprendre à quoi servent ces actions – lisez la suite.

Partie principale

Petite préface

On suppose que le système d'exploitation est déjà installé dans sa version minimale et que l'accès aux dépôts publics ou à leurs copies locales est configuré.

Il est présumé que le lecteur a des connaissances de base sur Linux et sur la base de données Firebird.

Planification

Sur le serveur de la base de données, il est recommandé de prévoir des partitions distinctes pour les fichiers temporaires (/tmp), les fichiers de base de données et les sauvegardes locales.

Les fichiers temporaires comprennent des fichiers de verrouillage, des fichiers de tri, des fichiers de "matérialisation" des tables temporaires globales (GTT) et des tables de surveillance. Les fichiers de tri et les tables temporaires globales se trouvent dans /tmp, les fichiers de mon$-tables et les fichiers de verrouillage se trouvent dans /tmp/firebird.

Les fichiers de tri sont "supprimés" (unlink) immédiatement après leur création, donc ils ne peuvent pas être "vus" dans le listing du répertoire – seulement dans la liste des descripteurs (handles) du processus (marqués comme supprimé):

sudo ls -lhF /proc/`pgrep firebird`/fd

Dans le listing du pseudo-répertoire /proc/…/fd/ s'affichent des symlinks, et les informations réelles sur le fichier sont données par :

sudo stat -L /proc/`pgrep firebird`/fd/NOMBRE

où NOMBRE – est le descripteur du fichier en question.

Au lieu d'appeler "pgrep fichier-exécutable", vous pouvez directement substituer l'identifiant du processus d'intérêt.

Les fichiers temporaires peuvent être très volumineux, il est donc recommandé de prévoir au moins 20 à 30 Go. Il convient de noter que la taille des fichiers de tri dépend uniquement du volume des données, triées explicitement ou implicitement dans la requête, et qu'un seul utilisateur peut "créer" des gigaoctets de fichiers temporaires. /tmp Le répertoire pour les fichiers de base de données doit contenir les fichiers de toutes les bases, plus, au minimum, une copie du fichier de la plus grande base. Il faut prendre en compte la croissance des fichiers de base sur plusieurs années à venir.

Le répertoire des sauvegardes locales doit contenir, au minimum, une archive de sauvegarde de toutes les bases ainsi qu'une sauvegarde de la plus grande base. Idéalement, il devrait également y avoir de la place pour la restauration de la plus grande base. Il faut tenir compte de la croissance des sauvegardes et des archives de sauvegarde sur plusieurs années à venir.

Préparation préalable

Préparation préalable

Le serveur SGBD Firebird 3.0 alloue et libère dynamiquement la mémoire système, ce qui peut conduire à sa fragmentation. Par exemple, après la déconnexion simultanée d'un grand nombre d'utilisateurs du super serveur, des erreurs peuvent survenir lors de nouvelles connexions.

La fragmentation de la mémoire est contrôlée par le paramètre système vm.max_map_count, par défaut – 64K. Il est recommandé d'augmenter sa valeur par quatre :

sudo sysctl vm.max_map_count=256000

Pour que cette nouvelle valeur soit appliquée au redémarrage du système, il faut l'ajouter au fichier /etc/sysctl.conf en ajoutant la ligne :

vm.max_map_count = 256000

Il est conseillé d'ajouter un commentaire afin de clarifier la raison de ce changement de paramètre. On peut d'abord éditer le fichier, puis appliquer les paramètres enregistrés :

sudo sysctl -p /etc/sysctl.conf

Installation des paquets nécessaires

Les fichiers exécutables du SGBD Firebird 3.0 sur Linux dépendent des bibliothèques ncurses (libncurses.so.5), ICU (sans version liée et sans affichage dans la sortie ldd) et tommath (libtommath.so.0). Pour télécharger et décompresser l'archive de compilation, on aura besoin des utilitaires gzip, tar et curl ou wget. Les versions d'ICU gzip, tar et curl/wget – ne sont pas significatives.

Le travail avec les paquets dépend du système et du gestionnaire de paquets utilisé dans le système, nous allons donc les examiner un par un.

CentOS 8

CentOS 8 utilise un nouveau gestionnaire de paquets – dnf et il est également "transparent" sous le commandement yum. Étant donné qu'il n'y a pas de différence entre eux pour nos besoins – dans les exemples, ce sera yum.

Mise à jour du cache des métadonnées : sudo yum makecache

Le paquet libtomath se trouve dans un dépôt E(xtra)P(ackages for)E(nterprise)L(inux) distinct, donc vérifions s'il est déjà connecté :

yum -C repolist

L'option «cache uniquement» (-C ou --cache-only) est utilisée pour exclure les vérifications et téléchargements inutiles, accélérant ainsi le fonctionnement de yum. Si le dépôt epel n'est pas dans la liste, installons-le et mettons à jour le cache des métadonnées :

sudo yum install epel-release &&
sudo yum makecache

Confirmer les demandes, en vérifiant si nécessaire les valeurs des clés pgp avec celles déjà connues d'une source de confiance.

Si des problèmes surviennent lors du téléchargement des métadonnées du dépôt à partir de ressources https, modifions le fichier /etc/yum.repos.d/epel.repo, en remplaçant https:// sur http:// et répétant la commande de mise à jour du cache.

Vérifions l'état des paquets requis (la commande est concaténée, dans l'exemple la sortie filtre un paquet 32 bits) :

yum -C list 
ncurses libicu libtommath 
gzip tar curl wget |
grep -v i686
Paquets installés
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
Paquets disponibles
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

Nous voyons que curl, gzip et ncurses sont placés dans le dépôts pseudo du programme d'installation (anaconda), tandis que tar est exclu de l'installation minimale du système. Les versions majeures libncurses et libtommath sont supérieures à celles requises : 6 et 1 au lieu de 5 et 0, respectivement. Si le même paquet est à la fois installé et disponible, une mise à jour a été publiée. Installons les paquets manquants :

sudo yum install 
libicu libtommath tar

Ubuntu 19

Pour gérer les paquets, des utilitaires sont prévus apt, apt‑get et apt‑cache. Le premier est conçu pour une utilisation interactive, tandis que les deux derniers sont destinés à être utilisés dans des scripts. Les noms des paquets sont légèrement différents et incluent la version.

Vérifions l'état des paquets requis (la commande est concaténée, l'exemple de sortie est raccourci et les paquets 32 bits sont filtrés) :

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 [installé]
libncurses5 6.1
libncurses6 6.1 [installé, automatique]
libtommath1 1.1.0
tar 1.30 [installé]
wget 1.20.3 [installé]

Les paquets pour lesquels il est indiqué entre crochets installé/upgradable sont installés. Disponible mais non installé ncurses5, à la place de curl est installé wget. Installons les paquets manquants :

sudo apt‑get install 
libncurses5 libtommath1

Création de liens symboliques

Puisque libtommath.so.1 et libncurses.so.6 sont rétrocompatibles avec libtommath.so.0 et libncurses.so.5, il suffit de créer des liens symboliques vers les versions existantes des bibliothèques pour Firebird.

Trouvons libtommath.so.1 (libncurses.so.? situés dans ce même répertoire :

find /usr -name libtommath.so.1

CentOS :

/usr/lib64/libtommath.so.1

Ubuntu :

/usr/lib/x86_64-linux-gnu/libtommath.so.1

Créons des liens symboliques.

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

Vérifions le résultat (la commande est concaténée, les exemples de sortie sont raccourcis) :

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

Téléchargement de la distribution de la base de données Firebird.

Sur le site officiel du projet Firebird (firebirdsql.org), vous trouverez des liens vers les distributions des versions "officielles" (releases) et des builds "quotidiens" (snapshot build).

Les versions officielles pour Linux sont disponibles sous forme d'archives (tar.gz) et de paquets deb/rpm, tandis que les builds ne sont disponibles que sous forme d'archives. Nous allons examiner le « programme d'installation générique » (generic installer de tar.gz).

L'archive de la build doit être téléchargée et décompressée, mais nous combinerons ces deux processus. La décompression se fait dans /tmp, l'URL désigne le lien vers l'archive téléchargée.

curl:

curl -L URL | tar -zxC /tmp

wget:

wget -O– URL | tar -zxC /tmp

Par défaut curl envoie les données téléchargées vers la sortie standard, mais ne gère pas les redirections, et nous ajoutons «‑L», tandis que wget, à l'inverse : gère les redirections, mais enregistre les données dans un fichier, et nous mettons «‑O‑». Pour tar nous spécifions l'utilisation gzip-filtre et le répertoire dans lequel la décompression sera effectuée. À la fin du processus, un répertoire apparaîtra de type Firebird‑3.0.5.33220‑0.amd64 avec trois fichiers : install.sh, buildroot.tar.gz et manifest.txt.

Installation de Firebird

Lors de la préparation préliminaire, nous avons ajusté la valeur du paramètre système vm.max_map_count, vérifié la présence et installé les bibliothèques ICU, ncurses et tommath. Nous avons vérifié la validité des versions de ncurses et tommath (libncurses.so.5 et libtommath.so.0) et créé les liens symboliques nécessaires.

L'installation elle-même est très simple. Nous allons dans le répertoire où l'archive de la distribution Firebird a été décompressée, nous vérifions et, si nécessaire, nous établissons le drapeau « exécutable » pour le script install.sh:

chmod +x install.sh

nous exécutons le script d'installation :

sudo ./install.sh

en appuyant sur la touche Enter pour confirmer le début de l'installation, et en cas de demande, nous saisissons le mot de passe sysdba.

Le script d'installation lance automatiquement systemd-unité firebird-superserver (architecture par défaut de Firebird 3.0). Le service Firebird fonctionnera avec les paramètres par défaut du super serveur : cache de pages de 2048 pages (par base), tampon de tri de 64 Mo (global) et connexion uniquement pour les clients de la troisième version. Consultez les paramètres firebird.conf:

grep -v ^# firebird.conf | grep -v ^$

Il convient de noter que les nouvelles valeurs de firebird.conf seront activés uniquement après le redémarrage du service Firebird.

Lors de la sélection des valeurs des paramètres, il convient de tenir compte du fait qu'il existe trois principaux « consommateurs » : le cache de pages (pour la base), le tampon de tri (partagé) et la mémoire allouée par le serveur pour les connexions client. On ne peut gérer que les deux premiers — le volume de mémoire des connexions client dépend du nombre et du texte des requêtes mises en cache, de leurs plans et des objets de base de données impliqués dans les requêtes. L'évaluation de la mémoire des connexions client se fait uniquement empiriquement et peut varier en fonction des applications clientes et/ou des objets de base.

Pour un super serveur sur des hôtes avec une petite quantité de mémoire (jusqu'à 12-16 Go), il ne faut pas allouer plus d'un tiers à trois quarts de la mémoire vive totale pour le cache de pages et le tampon de tri.

Si le nombre de bases n'est pas fixe et peut changer, le volume total de mémoire du cache de pages doit être divisé par le nombre maximum de bases pouvant être sur le serveur. La taille du cache de pages est définie en pages et doit être convertie séparément en octets.

Pour passer à l'architecture classique, il est nécessaire de spécifier explicitement au minimum ServerMode dans firebird.conf, de réduire également le cache de pages (pas plus de 2K), de diminuer le tampon de tri (volume total autorisé de tous les tris divisé par le nombre maximum de connexions), d'interdire et d'arrêter l'unité firebird-superserver, d'autoriser et de démarrer l'unité firebird-classic.socket.

L'utilisation de l'architecture superclassique dans Firebird 3.0 n'a pas beaucoup de sens : la « fiabilité » est celle du super serveur et le tampon de tri est le même. Il n'y a pas de cache de pages commun et les « pertes » dues à la synchronisation des différentes connexions sont les mêmes que pour le classique.

Il convient de se rappeler que dans Firebird 3.0, certains paramètres (cache de pages, tailles de fichier local, tables de hachage et quelques autres) peuvent être définis dans databases.conf individuellement pour chaque base. Pour le super serveur, il est utile, par exemple, de définir une petite valeur DefaultDbCachePages dans firebird.conf et de définir des caches de pages individuels pour les bases nécessaires dans databases.conf.

Pour toute question sur l'article, n'hésitez pas à laisser des commentaires ou à écrire à notre adresse de support support@ibase.ru.

Source : habr.com