In questo articolo descriveremo il set minimo di azioni necessarie per un'installazione ottimale del DBMS Firebird versione 3.0 su nuove distribuzioni Linux. Come esempi sono state scelte CentOS 8 e Ubuntu 19.
Per «consegnare» la distribuzione di Firebird al sistema target, in questo tutorial è stata scelta l'opzione di scaricare l'archivio tar.gz dal link del sito ufficiale del progetto ().
Per i più impazienti — subito in azione:
Installazione rapida
Modifichiamo il file /etc/sysctl.conf, aggiungendo la riga:
vm.max_map_count = 256000
Salviamo il file e applichiamo la configurazione:
sudo sysctl -p /etc/sysctl.conf
Le istruzioni successive variano per CentOS 8 e Ubuntu 19, ma LINK e CARTELLO indicano il link del sito ufficiale del progetto Firebird per scaricare la distribuzione e la cartella in cui verrà estratta la distribuzione durante il download.
Attualmente (marzo 2020), è disponibile la release Firebird 3.0.5 ( per la versione a 64 bit).
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 LINK|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- LINK|tar -zxC /tmp
In realtà, l'installazione del DBMS Firebird:
cd /tmp/CARTELLO
sudo ./install.sh
Se vuoi capire meglio a cosa servono queste azioni, continua a leggere.
Parte principale
Una breve introduzione
Si presume che il sistema operativo sia già installato nella sua versione minima e che sia stato configurato l'accesso ai repository pubblici o alle loro copie locali.
Si presuppone che il lettore abbia conoscenze di base su Linux e sul database Firebird.
Pianificazione
Si consiglia di dedicare partizioni separate sul server del database per i file temporanei (/tmp), i file di database e i backup locali.
I file temporanei includono file di blocco, file di ordinamento, file di "materializzazione" delle tabelle temporanee globali (GTT) e dei tavoli di monitoraggio. I file di ordinamento e delle tabelle temporanee globali si trovano in /tmp, i file mon$-e i file di blocco si trovano in /tmp/firebird.
I file di ordinamento vengono "eliminati" (unlink) subito dopo la creazione, quindi non possono essere "visti" nell'elenco delle directory – solo nell'elenco dei descrittori (handles) del processo (contrassegnati come deleted):
sudo ls -lhF /proc/`pgrep firebird`/fd
Nell'elenco del pseudodirectory /proc/…/fd/ sono mostrati i collegamenti simbolici, e le informazioni effettive del file sono fornite da:
sudo stat -L /proc/`pgrep firebird`/fd/NUMERO
dove NUMERO – descrittore del file di interesse.
Invece di chiamare "pgrep eseguibile-file» è possibile inserire subito l'identificativo del processo di interesse.
I file temporanei possono essere molto grandi, quindi si /tmp raccomanda di allocare almeno 20-30 GB. Va considerato che la dimensione dei file di ordinamento dipende esclusivamente dal volume di dati ordinati esplicitamente o implicitamente nella query e un singolo utente può "creare" gigabyte di file temporanei.
La sezione per i file del database deve contenere i file di tutti i database, più, almeno, una copia del file del database più grande. È necessario considerare la crescita dei file dei database per i prossimi anni.
La sezione dei backup locali deve contenere, almeno, un archivio di backup di tutti i database più il backup del database più grande. È auspicabile che in questa sezione ci sia anche spazio per il ripristino del database più grande. È necessario considerare la crescita dei backup e degli archivi di backup per i prossimi anni.
Preparazione preliminare
Il server DBMS Firebird 3.0 assegna e libera dinamicamente la memoria di sistema, il che può portare a frammentazione. Ad esempio, dopo la disconnessione simultanea da superserver di un gran numero di utenti, possono verificarsi errori durante nuove connessioni.
La frammentazione della memoria è controllata dal parametro di sistema vm.max_map_count, di default – 64K. Si consiglia di aumentare il suo valore a quattro volte:
sudo sysctl vm.max_map_count=256000
Per garantire che il nuovo valore venga applicato al riavvio del sistema, aggiungiamo nel file /etc/sysctl.conf la riga:
vm.max_map_count = 256000
È utile fare un commento per chiarire il motivo della modifica di questo parametro. Si può prima modificare il file e poi applicare le impostazioni salvate:
sudo sysctl -p /etc/sysctl.conf
Installazione dei pacchetti necessari
I file eseguibili del DBMS Firebird 3.0 Linux dipendono dalle librerie ncurses (libncurses.so.5), ICU (senza legame a una versione e senza comparire nell'output ldd) e tommath (libtommath.so.0). Per scaricare e decomprimere l'archivio di compilazione saranno necessarie delle utility gzip, tar e curl o wget. Le versioni di ICU, gzip, tar e curl/wget non sono rilevanti.
Il lavoro con i pacchetti dipende dal sistema e dal gestore di pacchetti utilizzato nel sistema, quindi li consideriamo uno alla volta.
CentOS 8
CentOS 8 utilizza un nuovo gestore di pacchetti – dnf che viene chiamato 'trasparentemente' con il comando yum. Poiché per i nostri scopi non c'è differenza tra i due, negli esempi utilizzeremo yum.
Aggiorniamo la cache dei metadati: sudo yum makecache
Il pacchetto libtomath si trova in un repository separato E(xtra)P(ackages for)E(nterprise)L(inux), quindi verifichiamo che sia già attivato:
yum -C repolist
L'opzione «solo dal cache» (-C o --cache-only) viene utilizzata per escludere controlli e download non necessari, velocizzando il funzionamento di yum. Se il repository epel non è nell'elenco, installiamolo e aggiorniamo la cache dei metadati:
sudo yum install epel-release &&
sudo yum makecache
Confermiamo le richieste, confrontando se necessario i valori delle chiavi pgp con quelli già noti di una fonte fidata.
Se ci sono problemi nel download delle metainformazioni dal repository su risorse https, modifichiamo il file /etc/yum.repos.d/epel.repo, sostituendo https:// con http:// e ripetiamo il comando per aggiornare la cache.
Controlliamo lo stato dei pacchetti necessari (il comando è composto, nell'esempio l'output filtra il pacchetto a 32 bit):
yum -C list
ncurses libicu libtommath
gzip tar curl wget |
grep -v i686
Installed Packages
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
Available Packages
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
Vediamo che curl, gzip e ncurses si trovano nel repository pseudo di installazione (anaconda), e tar – escluso dall'installazione minima del sistema. Le versioni principali libncurses e libtommath più di quanto necessario: 6 e 1 invece di 5 e 0, rispettivamente. Se lo stesso pacchetto è installato e disponibile, è stata rilasciata un'aggiornamento per esso. Installiamo i pacchetti mancanti:
sudo yum install
libicu libtommath tar
Ubuntu 19
Per la gestione dei pacchetti sono previste utilità apt, apt‑get e apt‑cache. Il primo è concepito per un uso interattivo, mentre gli ultimi due sono destinati all'uso negli script. I nomi dei pacchetti sono leggermente diversi e comprendono la versione.
Controlliamo lo stato dei pacchetti necessari (il comando è composto, l'esempio di output è ridotto e sono stati filtrati i pacchetti a 32 bit):
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 [installed]
libncurses5 6.1
libncurses6 6.1 [installed,automatic]
libtommath1 1.1.0
tar 1.30 [installed]
wget 1.20.3 [installed]
Pacchetti per i quali è indicato tra parentesi quadre installato/upgradable – installati. Disponibile, ma non installato ncurses5, invece curl installato wget. Installiamo i pacchetti mancanti:
sudo apt‑get install
libncurses5 libtommath1
Creazione di symlink
Poiché libtommath.so.1 e libncurses.so.6 sono retrocompatibili con libtommath.so.0 e libncurses.so.5, quindi per Firebird è sufficiente creare symlink alle versioni esistenti delle librerie.
Troviamo libtommath.so.1 (libncurses.so.? si trovano nella stessa cartella):
find /usr -name libtommath.so.1
CentOS:
/usr/lib64/libtommath.so.1
Ubuntu:
/usr/lib/x86_64-linux-gnu/libtommath.so.1
Creiamo i symlink.
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
Controlliamo il risultato (il comando è composto, esempi di output abbreviati):
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
Download del pacchetto del DBMS Firebird.
Sul sito ufficiale del progetto Firebird (firebirdsql.org) vengono pubblicati i link ai pacchetti delle 'versioni ufficiali' (releases) e delle 'build quotidiane' (snapshot build).
Le versioni ufficiali per Linux sono disponibili in formato archivi (tar.gz) e pacchetti deb/rpm, mentre le build sono offerte solo come archivi. Considereremo l' 'installer generico' (generic installer da tar.gz).
L'archivio della build deve essere scaricato e estratto, ma gestiremo entrambi questi processi. L'estrazione avviene in /tmp, l'URL indica il link all'archivio da scaricare.
curl:
curl -L URL | tar -zxC /tmp
wget:
wget -O– URL | tar -zxC /tmp
Di default curl invia i dati scaricati all'output standard, ma non gestisce i reindirizzamenti e aggiungiamo '-L', wget, al contrario: gestisce i reindirizzamenti, ma registra i dati in un file e impostiamo «‑O‑». Per tar indicare l'uso di gzip-filtro e la cartella in cui verrà eseguita l'estrazione. Al termine del processo apparirà una cartella di tipo Firebird‑3.0.5.33220‑0.amd64 con tre file: install.sh, buildroot.tar.gz e manifest.txt.
Installazione di Firebird
Durante la fase di preparazione preliminare abbiamo regolato il valore del parametro di sistema vm.max_map_count, controllato la disponibilità e installato le librerie ICU, ncurses e tommath. Verificato che le versioni di ncurses e tommath siano corrette (libncures.so.5 e libtommath.so.0) e creato i link simbolici necessari.
L'installazione vera e propria è molto semplice. Ci spostiamo nella cartella in cui è stato estratto l'archivio del pacchetto Firebird, controlliamo e, se necessario, impostiamo il flag «eseguibile» sullo script install.sh:
chmod +x install.sh
eseguiamo lo script di installazione:
sudo ./install.sh
con la pressione del tasto Enter confermiamo l'inizio dell'installazione e, quando viene richiesto, inseriamo la password sysdba.
Lo script di installazione avvia automaticamente systemd-unit firebird-superserver (architettura Firebird 3.0 non divulgata). Il servizio Firebird funzionerà con i parametri predefiniti per il superserver: cache delle pagine di 2048 pagine (per database), buffer di ordinamento di 64 MB (totale) e connessione solo ai client della terza versione. Visualizza i parametri firebird.conf:
grep -v ^# firebird.conf | grep -v ^$
Si deve tenere presente che i nuovi valori da firebird.conf saranno attivati solo dopo il riavvio del servizio Firebird.
Nella selezione dei valori dei parametri si deve considerare che ci sono tre principali "consumatori": la cache delle pagine (per il database), il buffer di ordinamento (totale) e la memoria allocata dal server per le connessioni dei client. Si possono gestire solo i primi due – la quantità di memoria per le connessioni dei client dipende dal numero e dal tipo delle query memorizzate, dai loro piani e dagli oggetti del database coinvolti nelle query. La valutazione della memoria delle connessioni dei client è effettuata solo empiricamente e può variare con il cambiamento delle applicazioni dei client e/o degli oggetti del database.
Per il superserver su host con una piccola quantità di memoria (fino a 12-16 GB) non è consigliabile allocare per la cache delle pagine e il buffer di ordinamento più di un terzo-quarto dell'intero volume di RAM.
Se il numero di basi non è fisso e può variare, il volume totale della memoria della cache delle pagine deve essere diviso per il numero massimo di basi che possono essere presenti sul server. La dimensione della cache delle pagine è impostata in pagine e deve essere riconvertita in byte.
Per passare all'architettura classic è necessario specificare esplicitamente almeno ServerMode in firebird.conf, ridurre in quello stesso punto la cache delle pagine (non più di 2K), ridurre il buffer di ordinamento (il volume complessivo consentito di tutti gli ordinamenti diviso per il numero massimo di connessioni), vietare e fermare il'unità firebird-superserver, consentire e avviare l'unità firebird-classic.socket.
L'uso dell'architettura superclassic in Firebird 3.0 non ha particolarmente senso: 'affidabilità' – come nel superserver e lo stesso buffer di ordinamento comune. Non ci sono cache di pagine comuni e le 'perdite' nella sincronizzazione delle diverse connessioni sono le stesse del classic.
Si deve ricordare che in Firebird 3.0 alcune impostazioni (cache delle pagine, dimensioni del file lock, tabelle hash e alcune altre) possono essere impostate in databases.conf in modo individuale per ogni base. Per il superserver è utile, ad esempio, impostare un valore piccolo DefaultDbCachePages in firebird.conf e impostare cache di pagina personalizzate per le necessarie basi in databases.conf.
Per domande relative all'articolo, lasciate un commento o scrivete alla nostra email di supporto support@ibase.ru.
Fonte: habr.com
