Ogni versione di Firebird ha la propria versione del formato delle strutture dei dischi del database – O(n)D(isk)S(tructure). Fino alla versione 2.5 inclusa, il motore Firebird poteva lavorare con ODS delle versioni precedenti, cioè i database di versioni più vecchie potevano essere aperti dalla nuova versione e funzionare in modalità compatibilità, ma il motore Firebird 3.0 funziona solo con database nella propria versione ODS 12.0.
Per passare a 3.0, il database da 2.5 deve essere convertito nel nuovo formato tramite backup/ripristino. Naturalmente, supponiamo che il database sia stato preparato in anticipo per la conversione, ovvero che i metadati e le query siano stati controllati per la compatibilità con Firebird 3.0.
Se si segue l'approccio standard, ciò significa che è necessario eseguire un backup sulla versione 2.5, quindi installare 3.0 e ripristinare. Questa procedura è accettabile se c'è tempo a disposizione, ma durante la migrazione di grandi database, o durante la migrazione simultanea di diverse decine di database, quando il tempo è ristretto, è possibile utilizzare la conversione in tempo reale, che è dal 30% al 40% più veloce. Come fare ciò (su Windows e Linux), leggi più avanti.
L'idea generale è che per accelerare utilizzeremo una pipeline:
gbak -b … database25 stdout | gbak -c … stdin database30Gbak 2.5 genera un backup in formato lineare e lo invia a stdout, che viene immediatamente acquisito tramite stdin da gbak 3.0, creando un nuovo database.
È necessario organizzare questa pipeline utilizzando il metodo di accesso locale (file), poiché l'accesso di rete (anche tramite localhost) rallenta notevolmente il processo.
Di seguito esaminiamo i dettagli per Windows e Linux.
Windows
Nel caso di Windows, il modo più semplice è creare una build completamente autonoma di Firebird. Per questo prendiamo , rinominiamo fbemded.dll in fbclient.dll, aggiungiamo dall'archivio gli strumenti gbak.exe e (facoltativo) – isql.exe della versione normale 2.5.
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. È effettivamente così, poiché gbak non utilizza il charset di connessione e non converte i dati tra i charset, ma sul lato di 'ricezione' di Firebird 3.0 questi file sono necessari durante la creazione degli indici.
In firebird.conf si raccomanda di aggiungere per Firebird 3.0:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1È inoltre consigliabile impostare valori diversi per IpcName per 2.5 e 3.0.
Nella scelta dei valori per altre impostazioni di firebird.conf, partiamo da un semplice ragionamento: durante il processo di caricamento dei dati un'istanza di gbak opera in 2.5, mentre un'altra in 3.0; successivamente, 2.5 termina la sua operazione e 3.0 inizia a costruire gli indici.
Per accelerare la fase di costruzione degli indici in 3.0, si consiglia di aumentare la dimensione del parametro TempCacheLimit fino a circa il 40% della RAM (se ovviamente si tratta di un server dedicato).
Ad esempio, se il server ha 16 GB di RAM, è possibile 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: non può già superare i 2 gigabyte e non influisce sulla velocità durante il backup.
Prima di eseguire l'operazione, controlla che la cache della pagina nell'intestazione del database sia impostata a 0 (comando gstat -h databasename, guarda la riga Page buffers).
Se la cache è esplicitamente impostata nell'intestazione del database, sovrascrive i valori di firebird.conf (e databases.conf in 3.0) e, in caso di valori eccessivamente grandi, può portare a un uso eccessivo della memoria e a uno swappaggio.
Successivamente, copiamo i file nel sistema di destinazione.
La conversione avviene dopo aver fermato il servizio "system" di Firebird 2.5, nella riga di comando con privilegi elevati a quelli di 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" tra virgolette (stile unix consentito), e il "cappello" (simbolo "^") esegue l'escape del carattere di newline, utile per digitare comandi lunghi. L'opzione -st(atus) è stata introdotta in Firebird 2.5.8 e consente di registrare nel log i dati sul tempo di esecuzione del processo gbak (dettagli nella documentazione).
Linux
Su Linux, Firebird 3 dipende dalla libreria tommath. In CentOS (RHEL) questa libreria si trova nel repository epel, in Ubuntu (Debian) nel sistema.
Per CentOS, è necessario prima abilitare il repository epel e solo dopo procedere con
yum install libtommathPer Ubuntu non è necessario abilitare repository aggiuntivi, ma su Ubuntu 16 e Ubuntu 18 vengono installate versioni diverse dei pacchetti: libtommath0 e libtommath1, rispettivamente.
Firebird 3.0 cerca tommath.so.0 e per Ubuntu 18 è necessario creare un link (symlink) da tommath.so.0 a tommath.so.1. Prima è necessario 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, compreso, non c'era un modo semplice per installare due versioni diverse del server. L'opzione "compilare dai sorgenti con il prefisso desiderato" non viene considerata a causa della sua relativa complessità.
Per Firebird 3.0.2 e versioni superiori è stata implementata e un'opzione separata per l'installer (-path percorso).
Supponendo che la libreria tommath e, se necessario, il symlink per tommath.so.0 siano stati aggiunti al sistema, è possibile installare la distribuzione attuale (al momento della scrittura di questo articolo) di Firebird 3.0.4 in, ad esempio, /opt/fb3:
./install.sh -path /opt/fb3Dopo di che, è possibile fermare il servizio di sistema Firebird e avviare la conversione in streaming.
Quando si arresta Firebird, è importante considerare che i processi Firebid 2.5 in modalità Classic vengono solitamente avviati da xinetd: pertanto, è necessario disabilitare il servizio firebird per xinetd o arrestare completamente xinetd.
Nel file firebird.conf per la versione 3.0 su Linux non è necessario impostare i parametri MaxUnflushed (funzionano solo su Windows) e modificare le impostazioni di Firebird 2.5.
Su Linux, l'accesso locale (file-based) a 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 verranno verificati in base al database degli utenti, il che significa che saranno necessari sia il login che la password:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … database25 stdout
|/opt/fb3/bin/gbak -c … stdin database30Dopo una conversione riuscita, prima è necessario rimuovere 'l'ulteriore' Firebird 3.0, poi 'il principale' Firebird 2.5 e solo dopo eseguire un'installazione pulita di Firebird 2.5 — ed è meglio farlo utilizzando l'installer standard tar.gz, piuttosto che attraverso i repository, poiché la versione nei repository potrebbe essere obsoleta.
Inoltre, dopo il ripristino del DB su Linux e la reinstallazione, è necessario verificare che il nuovo DB abbia come proprietario l'utente firebird.
Se non è così, dovrà essere corretto.
chown firebird.firebird databaseRisultato
Oltre al risparmio di tempo e spazio su disco, la conversione in streaming presenta un altro importante vantaggio: la trasformazione del database avviene senza rimuovere il Firebird 2.5 esistente, il che semplifica notevolmente il ripristino in caso di conversione non riuscita (di solito a causa di spazio insufficiente o di un'improvvisa riavvio durante il processo di migrazione).
Il risparmio di tempo è legato al fatto che la conversione "classica" comporta il "tempo di backup" più il "tempo di ripristino". Il ripristino è composto da due parti: lettura dei dati dal file di backup e costruzione dell'indice.
Con la conversione in streaming, il tempo totale risulta essere "tempo di backup più cinque-dieci percento" e "tempo di costruzione 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à il tempo di backup, la "conversione classica" richiede tre unità di tempo, mentre quella in streaming due unità di tempo. Aumentare il TempCacheLimit aiuta ulteriormente a ridurre il tempo.
In generale, la conversione in streaming consente di risparmiare circa il 30-40% del tempo rispetto al backup e ripristino sequenziale.
Domande?
Per favore, inviate tutte le domande nei commenti, o contattate l'autore del metodo e co-autore di questo articolo — Vasily Sidorov, ingegnere di sistema senior dell'azienda «iBase», all'indirizzo bs at ibase ru.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Quale versione di Firebird utilizzi?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 o 1.0
16 utenti hanno votato. 1 utente ha scelto di astenersi.
Fonte: habr.com
