Ogni versione di Firebird ha la propria versione del formato della struttura del disco del database, O(n)D(isk)S(tructure). Fino alla versione 2.5 inclusa, il motore Firebird poteva funzionare con ODS delle versioni precedenti, ovvero i database delle vecchie versioni venivano aperti dalla nuova versione e funzionavano in modalità compatibilità, ma il motore Firebird 3.0 funziona solo con i database nella propria versione ODS 12.0.
Per migrare a 3.0, il database da 2.5 deve essere convertito nel nuovo formato tramite backup/ripristino. Naturalmente, supponiamo che il database sia stato precedentemente preparato per la conversione, ad es. i metadati e le query sono stati verificati per la compatibilità con Firebird 3.0.
Se segui l'approccio standard, questo significa eseguire il backup alla versione 2.5, quindi installare la 3.0 e ripristinare. Questa procedura è accettabile se hai abbastanza tempo, ma quando si migrano database di grandi dimensioni o quando si migrano diverse decine di database contemporaneamente e il tempo è essenziale, è possibile utilizzare la conversione in streaming, che è il 30-40% più veloce. Come fare esattamente questo (sotto Windows e sotto Linux), leggi sotto il taglio.
L'idea generale è che useremo una pipeline per accelerare le cose:
gbak -b … база25 stdout | gbak -c … stdin база30Gbak da 2.5 genera un backup in un formato lineare e lo invia a stdout, che preleva immediatamente gbak da 3.0 tramite stdin e crea un nuovo database.
È necessario organizzare tale pipeline con un metodo di accesso locale (file), poiché l'accesso alla rete (anche tramite localhost) rallenterà notevolmente il processo.
Di seguito esaminiamo i dettagli per Windows и Linux.
Windows
Nel caso di Windows Il modo più semplice è creare una build completamente autonoma di Firebird. Per fare ciò, prendi , rinominare fbemded.dll in fbclient.dll, aggiungere le utility gbak.exe e (facoltativamente) isql.exe dall'archivio "normale" 2.5.
Firebird 3.0 utilizza e non richiede alcuna modifica.
La versione minima (che non richiede l'installazione delle librerie di 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 potrebbe notare che la versione 2.5 non include i file intl/fbintl.dll e intl/fbintl.conf. Questo è vero, poiché gbak non usa un set di caratteri di connessione e non converte i dati tra i set di caratteri, ma sul lato "ricevente" di Firebird 3.0, questi file sono necessari quando si creano gli indici.
In firebird.conf Firebird 3.0 si consiglia di aggiungere:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Inoltre, è consigliabile impostare valori IpcName diversi per 2.5 e 3.0.
Nella scelta dei valori degli altri parametri di firebird.conf, procediamo da una semplice considerazione: nella fase di trasfusione dei dati, gbak esegue 2.5 in un processo e 3.0 nell'altro, quindi 2.5 esce e 3.0 inizia a costruire indici.
Per velocizzare la fase di creazione dell'indice nella versione 3.0, si consiglia di aumentare la dimensione del parametro TempCacheLimit a ~40% RAM (se si tratta di un server dedicato, ovviamente).
Ad esempio, se il server ha 16 GB di RAM, puoi inserire
TempCacheLimit=6GNaturalmente, questo valore può essere impostato solo per Firebird 64 a 3 bit, poiché qualsiasi processo a 32 bit non può allocare più di 2 gigabyte di memoria.
In 2.5, questo parametro non deve essere modificato: non può comunque essere superiore a 2 gigabyte e non influisce sulla velocità durante il backup.
Prima di eseguire l'operazione, è necessario verificare che la cache della pagina nell'intestazione del database sia impostata su 0 (command gstat -h databasename, vedere la riga Buffer di pagina).
Se la cache è impostata in modo esplicito nell'intestazione del database, sovrascrive i valori di firebird.conf (e databases.conf in 3.0) e, in caso di valori inadeguatamente grandi, può portare a un consumo eccessivo di memoria e allo scambio.
Successivamente, copia i file nel sistema di destinazione.
La conversione viene effettuata dopo aver fermato il servizio Firebird 2.5 di "sistema", da riga di comando con diritti elevati all'amministratore locale (esempio):
set ISC_USER=владелец
"25/gbak" -z -b -g -v -st t -y 25.log база25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin база30Questo esempio utilizza una "barra" tra virgolette (valido "stile unix") e un "cappello" (il carattere "^") esegue l'escape del carattere di nuova riga, utile quando si digitano comandi lunghi. L'opzione -st(atus) è apparsa in Firebird 2.5.8 e consente di registrare i dati sull'ora in cui il processo gbak era in esecuzione (per i dettagli, vedere la documentazione).
Linux
Su Linux Firebird 3 dipende dalla libreria tommath. CentOS (RHEL) questa libreria si trova nel repository epel, in Ubuntu (Debian) in – sistemico.
per CentOS Devi prima connetterti al repository EPEL e solo dopo farlo
yum install libtommathUbuntu non c'è bisogno di collegare repository aggiuntivi, ma in Ubuntu 16 e in Ubuntu Sono installate 18 diverse versioni di pacchetti: libtommath0 e libtommath1, rispettivamente.
Firebird 3.0 cerca tommath.so.0 e Ubuntu 18 Inoltre, è necessario creare un collegamento simbolico da tommath.so.0 a tommath.so.1. Per fare ciò, è necessario prima trovare tommath.so.1.
Il percorso ricercato in Ubuntu - /usr/lib/x86_64-linux-gnu/ma in altri DebianLe distribuzioni basate su possono essere diverse.
Il secondo problema è legato al fatto che fino a Firebird 3.0.1 incluso non esisteva un modo semplice per installare due diverse versioni del server. Non consideriamo l'opzione "compila dal sorgente con il prefisso richiesto" a causa della sua relativa complessità.
Per Firebird 3.0.2 e versioni successive implementato e un'opzione di installazione separata (-path path).
Supponendo che la libreria tommath e, se necessario, un collegamento simbolico per tommath.so.0 siano stati aggiunti al sistema, è possibile installare la distribuzione Firebird 3.0.4 corrente (al momento della stesura di questo documento) in, ad esempio, /opt /fb3:
./install.sh -path /opt/fb3Successivamente, puoi interrompere il servizio di sistema Firebird e avviare la conversione dello streaming.
Quando si arresta Firebird, tenere presente che i processi di Firebid 2.5 in modalità Classica vengono generalmente avviati da xinetd, quindi è necessario disabilitare il servizio firebird per xinetd o arrestare completamente xinetd.
In 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 (ai file) di Firebird 2.5 non è equivalente alla versione incorporata sotto Windows – Il server 2.5 verrà eseguito nel processo gbak (senza la parte di rete), ma i diritti di accesso verranno verificati rispetto al database degli utenti, il che significa che saranno richiesti non solo un nome utente ma anche una password:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30Dopo una conversione riuscita, devi prima disinstallare Firebird 3.0 "aggiuntivo", quindi Firebird 2.5 "principale", quindi eseguire un'installazione pulita di Firebird 2.5 - ed è meglio dal normale programma di installazione tar.gz, e non attraverso il repository, perché. la versione nei repository potrebbe essere in ritardo.
Inoltre, dopo il restauro del BD su Linux e la reinstallazione deve essere verificata per assicurarsi che il nuovo database sia di proprietà dell'utente firebird.
Se questo non è il caso, allora dovrà essere corretto.
chown firebird.firebird databaserisultato
Oltre a risparmiare tempo e spazio su disco, la conversione in streaming ha un altro importante vantaggio: la conversione del database viene eseguita senza eliminare il Firebird 2.5 esistente, il che semplifica enormemente il rollback in caso di conversione non riuscita (il più delle volte a causa della mancanza di spazio o di un riavvio imprevisto durante la migrazione processi).
Il risparmio di tempo è dovuto al fatto che la conversione "classica" è "tempo di backup" più "tempo di ripristino". Il ripristino è costituito da due parti: lettura dei dati da un file di backup e creazione di un indice.
Con la conversione in streaming, il tempo totale viene ottenuto come "tempo di backup più il cinque-dieci percento" e "tempo di costruzione dell'indice".
I risultati specifici dipendono dalla struttura del database, ma in media il tempo di ripristino è circa il doppio del tempo di backup. Pertanto, se consideriamo il tempo di backup come un'unità, la "conversione classica" è di tre unità di tempo, mentre lo streaming è di due unità di tempo. L'aumento di TempCacheLimit aiuta a ridurre ulteriormente il tempo.
In generale, la conversione in streaming in pratica consente di risparmiare il 30-40% del tempo di backup e ripristino alternati.
Domande?
Scrivi tutte le domande nei commenti o inviale all'autore della metodologia e coautore di questo articolo: Vasily Sidorov, iBase Leading System Engineer, presso bs at ibase ru.
Solo gli utenti registrati possono partecipare al sondaggio. Per favore.
Che versione di Firebird stai usando?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 o 1.0
16 utenti hanno votato. 1 utente si è astenuto.
Fonte: habr.com
