Ogni versione di Firebird ha una propria versione del formato delle strutture delle disco delle basi di dati – O(n)D(isk)S(tructure). Fino alla versione 2.5 inclusa, il motore Firebird poteva lavorare con ODS delle versioni precedenti, il che significa che i database delle vecchie versioni venivano aperti dalla nuova versione e funzionavano in modalità compatibile, ma il motore Firebird 3.0 lavora solo con i DB nella propria versione ODS 12.0.
Per passare alla 3.0, il database dalla 2.5 deve essere convertito nel nuovo formato tramite backup/restoration. Naturalmente, presupponiamo che il DB sia stato preparato in anticipo per la conversione, cioè che i metadati e le query siano stati controllati per la compatibilità con Firebird 3.0.
Seguendo l'approccio standard, questo significa che è necessario eseguire un backup sulla versione 2.5, poi installare la 3.0 e fare il ripristino. Questa procedura è accettabile se si ha abbastanza tempo, ma nella migrazione di grandi database, o nella migrazione contemporanea di decine di DB, quando il tempo è un fattore critico, si può utilizzare la conversione in streaming, che è dal 30 al 40% più veloce. Come fare ciò (su Windows e Linux), leggi di seguito.
L'idea generale è che per accelerare utilizzeremo una pipeline:
gbak -b … database25 stdout | gbak -c … stdin database30Gbak dalla 2.5 genera un backup in formato lineare e lo invia a stdout, che subito dopo viene catturato tramite stdin da gbak della 3.0, creando un nuovo DB.
È necessario organizzare tale pipeline utilizzando obbligatoriamente il metodo di accesso locale (file), poiché l'accesso rete (anche tramite localhost) rallenterebbe notevolmente il processo.
Di seguito consideriamo i dettagli per Windows e Linux.
Windows
Nel caso di Windows, è più semplice creare un'installazione completamente autonoma di Firebird. Per fare questo, prendiamo , rinominando fbemded.dll in fbclient.dll, aggiungendo dall'archivio "normale" 2.5 gli strumenti gbak.exe e (facoltativo) – isql.exe.
Firebird 3.0 utilizza e non richiede alcuna modifica.
La versione minima (che non richiede l'installazione delle librerie runtime VS2008/VS2010 sul sistema di destinazione) contiene i seguenti file:
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.dllUn amministratore esperto può notare che in 2.5 non sono inclusi i file intl/fbintl.dll e intl/fbintl.conf. È proprio così, poiché gbak non utilizza il charset di connessione e non converte i dati tra i charset, ma sul lato "ricevente" di Firebird 3.0 questi file sono necessari durante la creazione degli indici.
In firebird.conf si consiglia di aggiungere in Firebird 3.0:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Inoltre, è desiderabile impostare un valore diverso per IpcName per le versioni 2.5 e 3.0.
Quando si scelgono i valori di altri parametri in firebird.conf, ci basiamo su una semplice considerazione: durante il passaggio dei dati, in un processo gbak funziona in 2.5, mentre in un altro – in 3.0, poi 2.5 termina e 3.0 inizia a costruire gli indici.
Per accelerare la fase di costruzione degli indici in 3.0, è consigliabile aumentare la dimensione del parametro TempCacheLimit a circa il 40% della RAM (se si tratta di un server dedicato, ovviamente).
Ad esempio, se sul server ci sono 16 GB di RAM, si può impostare
TempCacheLimit=6GNaturalmente, tale valore può essere impostato solo su Firebird 3 a 64 bit, poiché qualsiasi processo a 32 bit non può allocare più di 2 gigabyte di memoria.
Per 2.5 non è necessario modificare questo parametro: è già limitato a 2 gigabyte e non influisce sulla velocità durante il backup.
Prima di eseguire l'operazione, è necessario controllare che la cache delle pagine nell'intestazione del database sia impostata su 0 (comando gstat -h databasename, controllare la riga Page buffers).
Se la cache è impostata esplicitamente nell'intestazione del database, essa sovrascrive i valori di firebird.conf (e databases.conf in 3.0) e, in caso di valori eccessivamente alti, può portare a un uso eccessivo della memoria e a uno scambio.
Successivamente, copiamo i file nel sistema di destinazione.
La conversione avviene dopo aver fermato il servizio "sistematico" di Firebird 2.5, nella riga di comando con diritti elevati fino ad amministratore locale (esempio):
set ISC_USER=proprietario
"25/gbak" -z -b -g -v -st t -y 25.log database25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin database30In questo esempio viene utilizzata la "barra obliqua diretta" tra virgolette (consentita "in stile unix"), mentre il "cappello" (simbolo "^") fa da escape per il carattere di invio, il che è utile per digitare comandi lunghi. L'opzione -st(atus) è apparsa in Firebird 2.5.8 e consente di registrare nel protocollo i dati sul tempo di esecuzione del processo gbak (maggiori dettagli nella documentazione).
Linux
Su Linux Firebird 3 dipende dalla libreria tommath. Su CentOS (RHEL) questa libreria si trova nel repository epel, su Ubuntu (Debian) nel sistema.
Per CentOS è necessario prima collegare il repository EPEL e solo dopo fare
yum install libtommathIn Ubuntu non è necessario collegare repository aggiuntivi, ma in Ubuntu 16 e in Ubuntu 18 si installano versioni diverse dei pacchetti – libtommath0 e libtommath1, rispettivamente.
Firebird 3.0 cerca tommath.so.0 e per Ubuntu 18 è necessario creare un collegamento (symlink) da tommath.so.0 a tommath.so.1. Per questo, prima bisogna trovare tommath.so.1.
Il percorso cercato in Ubuntu è /usr/lib/x86_64-linux-gnu/, ma in altre distribuzioni basate su Debian potrebbe essere diverso.
Il secondo problema è che fino a Firebird 3.0.1, inclusa, non c'era un modo semplice per installare due diverse versioni del server. Non consideriamo l'opzione "compilare dai sorgenti con il prefisso desiderato" a causa della sua relativa complessità.
Per Firebird 3.0.2 e versioni superiori è implementata e un'opzione separata per l'installatore (-path percorso).
Supponendo che la libreria tommath e, se necessario, il symlink per tommath.so.0 siano stati aggiunti al sistema, è possibile installare l'attuale (al momento della scrittura di questo articolo) pacchetto Firebird 3.0.4 in, ad esempio, /opt/fb3:
./install.sh -path /opt/fb3Dopo ciò, è possibile fermare il servizio di sistema Firebird e avviare la conversione in streaming.
Quando si ferma Firebird, bisogna tenere conto che i processi di Firebird 2.5 in modalità Classic vengono solitamente avviati da xinetd – quindi è necessario o disabilitare il servizio firebird per xinetd o fermare completamente xinetd.
Nel file firebird.conf per 3.0 su Linux non è necessario impostare i parametri MaxUnflushed (funzionano solo su Windows) e modificare le impostazioni di Firebird 2.5.
In Linux l'accesso locale (file-based) di Firebird 2.5 non è equivalente alla variante embedded su Windows – il server 2.5 funzionerà nel processo gbak (senza parte di rete), ma i diritti di accesso saranno controllati sulla base degli utenti, il che significa che sarà necessario non solo il login, ma anche la password:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … database25 stdout
|/opt/fb3/bin/gbak -c … stdin database30Dopo la conversione riuscita, bisogna prima rimuovere il "Firebird 3.0" "aggiuntivo", poi il "Firebird 2.5" "principale" e solo dopo eseguire una nuova installazione di Firebird 2.5 – anzi, è meglio farlo dall'installatore tar.gz standard, e non tramite repository, poiché la versione nei repository potrebbe essere obsoleta.
Inoltre, dopo il ripristino del database su Linux e la reinstallazione bisogna controllare che il nuovo database abbia come proprietario l'utente firebird.
Se non è così, sarà necessario correggere
chown firebird.firebird databaseRisultato
Oltre al risparmio di tempo e spazio su disco, la conversione in streaming ha un altro importante vantaggio: la trasformazione del database avviene senza rimuovere l'esistente Firebird 2.5, il che semplifica notevolmente il ripristino in caso di conversione non riuscita (di solito a causa di spazio insufficiente o di un riavvio imprevisto durante il processo di migrazione).
Il risparmio di tempo è legato al fatto che la conversione "classica" è pari a "tempo di backup" più "tempo di ripristino". Il ripristino è composto da due parti: lettura dei dati dal file di backup e creazione dell'indice.
Con la conversione in streaming, il tempo totale risulta come "tempo di backup più cinque-dieci percento" e "tempo di creazione degli indici".
I risultati specifici dipendono dalla struttura del database, ma mediamente il tempo di ripristino è circa il doppio del tempo di backup. Pertanto, se consideriamo come unità di misura il tempo di backup, la "conversione classica" richiede tre unità di tempo, mentre quella in streaming ne richiede due. Inoltre, l'aumento di TempCacheLimit aiuta a ridurre ulteriormente il tempo.
In generale, la conversione in streaming consente di risparmiare nella pratica dal 30 al 40% del tempo necessario per il backup e il ripristino sequenziale.
Domande?
Per favore, scrivi tutte le domande nei commenti oppure inviale all'autore della metodologia e coautore di questo articolo — Vasiliy Sidorov, ingegnere sistemista senior della compagnia "iBase", all'indirizzo bs at ibase ru.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Quale versione di Firebird stai utilizzando?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 o 1.0
Hanno votato 16 utenti. Un utente si è astenuto.
Fonte: habr.com
