Conversione in streaming dei database Firebird 2.5 nel formato ODS12 (Firebird 3.0)

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 si segue l'approccio standard, ciò significa che è necessario eseguire un backup della versione 2.5, quindi installare la 3.0 ed eseguire un ripristino. Tale procedura è accettabile se c'è abbastanza tempo, ma durante la migrazione di database di grandi dimensioni o durante la migrazione di diverse dozzine di database contemporaneamente, quando il tempo sta per scadere, è possibile utilizzare la conversione in streaming, che è più veloce del 30-40%. Come farlo esattamente (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 база30

Gbak 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 e Linux.

Windows

Nel caso di Windows, il modo più semplice è realizzare una build completamente autonoma di Firebird. Per questo prendiamo archivio incorporato Firebird 2.5, rinominare fbemded.dll in fbclient.dll, aggiungere le utility gbak.exe e (facoltativamente) isql.exe dall'archivio "normale" 2.5.

Firebird 3.0 utilizza unico assemblaggio 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.dll

Un 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 = -1

Inoltre, è 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=6G

Naturalmente, 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 база30

Questo 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. Su CentOS (RHEL) questa libreria si trova nel repository epel, su Ubuntu (Debian) nel repository di sistema.

Per CentOS, devi prima connettere il repository epel e solo dopo farlo

yum install libtommath

Ubuntu non ha bisogno di includere repository aggiuntivi, ma Ubuntu 16 e Ubuntu 18 installano versioni diverse dei pacchetti, rispettivamente libtommath0 e libtommath1.

Firebird 3.0 cerca tommath.so.0 e per Ubuntu 18 è inoltre necessario creare un collegamento (link simbolico) da tommath.so.0 a tommath.so.1. Per fare ciò, devi prima trovare tommath.so.1.

Percorso cercato in Ubuntu - /usr/lib/x86_64-linux-gnu/, ma altre distribuzioni basate su Debian potrebbero 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 costruire con --enable-binreloc 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/fb3

Successivamente, 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 (file) di Firebird 2.5 non è equivalente alla versione incorporata in Windows: il server 2.5 verrà eseguito nel processo gbak (senza la parte di rete), ma i diritti di accesso verranno controllati rispetto alla base utenti, il che significa che sarà richiesto non solo il login, ma anche la password:

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30

Dopo 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 aver ripristinato il database su Linux e averlo reinstallato, è necessario verificare che il nuovo database sia di proprietà dell'utente firebird.

Se questo non è il caso, allora dovrà essere corretto.

chown firebird.firebird database

risultato

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. AccediPer 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