{"id":30280,"date":"2019-10-31T21:34:38","date_gmt":"2019-10-31T18:34:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0\/"},"modified":"2019-10-31T21:34:38","modified_gmt":"2019-10-31T18:34:38","slug":"potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0","title":{"rendered":"Conversione in streaming dei database Firebird 2.5 nel formato ODS12 (Firebird 3.0)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ogni versione di Firebird ha una propria versione del formato delle strutture delle disco delle basi di dati \u2013 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\u00e0 compatibile, ma il motore Firebird 3.0 lavora solo con i DB nella propria versione ODS 12.0.<\/p>\n

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\u00e8 che i metadati e le query siano stati controllati per la compatibilit\u00e0 con Firebird 3.0.<\/p>\n

Seguendo l'approccio standard, questo significa che \u00e8 necessario eseguire un backup sulla versione 2.5, poi installare la 3.0 e fare il ripristino. Questa procedura \u00e8 accettabile se si ha abbastanza tempo, ma nella migrazione di grandi database, o nella migrazione contemporanea di decine di DB, quando il tempo \u00e8 un fattore critico, si pu\u00f2 utilizzare la conversione in streaming, che \u00e8 dal 30 al 40% pi\u00f9 veloce. Come fare ci\u00f2 (su Windows e Linux), leggi di seguito.
\n<\/a><\/noindex>
\nL'idea generale \u00e8 che per accelerare utilizzeremo una pipeline:<\/p>\n

gbak -b \u2026 database25 stdout | gbak -c \u2026 stdin database30<\/code><\/pre>\n
\nGbak 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.<\/p>\n
\u00c8 necessario organizzare tale pipeline utilizzando obbligatoriamente il metodo di accesso locale (file), poich\u00e9 l'accesso rete (anche tramite localhost) rallenterebbe notevolmente il processo.<\/p>\n
Di seguito consideriamo i dettagli per Windows e Linux.<\/p>\n
Windows<\/b><\/p>\n
Nel caso di Windows, \u00e8 pi\u00f9 semplice creare un'installazione completamente autonoma di Firebird. Per fare questo, prendiamo l'archivio embed di Firebird 2.5<\/a><\/noindex>, rinominando fbemded.dll in fbclient.dll, aggiungendo dall'archivio \"normale\" 2.5 gli strumenti gbak.exe e (facoltativo) \u2013 isql.exe. <\/p>\n
Firebird 3.0 utilizza un'unica build<\/a><\/noindex> e non richiede alcuna modifica.<\/p>\n
La versione minima (che non richiede l'installazione delle librerie runtime VS2008\/VS2010 sul sistema di destinazione) contiene i seguenti file:<\/p>\n
25\/gbak.exe\n25\/fbclient.dll\n25\/firebird.conf\n25\/firebird.log\n25\/firebird.msg\n25\/ib_util.dll\n25\/icudt30.dll\n25\/icuin30.dll\n25\/icuuc30.dll\n25\/Microsoft.VC80.CRT.manifest\n25\/msvcp80.dll\n25\/msvcr80.dll\n\n30\/fbclient.dll\n30\/firebird.conf\n30\/firebird.msg\n30\/gbak.exe\n30\/ib_util.dll\n30\/icudt52.dll\n30\/icudt52l.dat\n30\/icuin52.dll\n30\/icuuc52.dll\n30\/msvcp100.dll\n30\/msvcr100.dll\n30\/intl\/fbintl.conf\n30\/intl\/fbintl.dll\n30\/plugins\/engine12.dll<\/code><\/pre>\n
\nUn amministratore esperto pu\u00f2 notare che in 2.5 non sono inclusi i file intl\/fbintl.dll e intl\/fbintl.conf. \u00c8 proprio cos\u00ec, poich\u00e9 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.<\/p>\n
In firebird.conf si consiglia di aggiungere in Firebird 3.0:<\/p>\n
MaxUnflushedWrites = -1\nMaxUnflushedWriteTime = -1<\/code><\/pre>\n
\nInoltre, \u00e8 desiderabile impostare un valore diverso per IpcName per le versioni 2.5 e 3.0. <\/p>\n
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 \u2013 in 3.0, poi 2.5 termina e 3.0 inizia a costruire gli indici.<\/p>\n
Per accelerare la fase di costruzione degli indici in 3.0, \u00e8 consigliabile aumentare la dimensione del parametro TempCacheLimit a circa il 40% della RAM (se si tratta di un server dedicato, ovviamente).<\/p>\n
Ad esempio, se sul server ci sono 16 GB di RAM, si pu\u00f2 impostare <\/p>\n
TempCacheLimit=6G<\/code><\/pre>\n
\nNaturalmente, tale valore pu\u00f2 essere impostato solo su Firebird 3 a 64 bit, poich\u00e9 qualsiasi processo a 32 bit non pu\u00f2 allocare pi\u00f9 di 2 gigabyte di memoria.<\/i><\/p>\n
Per 2.5 non \u00e8 necessario modificare questo parametro: \u00e8 gi\u00e0 limitato a 2 gigabyte e non influisce sulla velocit\u00e0 durante il backup.<\/p>\n
Prima di eseguire l'operazione, \u00e8 necessario controllare che la cache delle pagine nell'intestazione del database sia impostata su 0 (comando gstat -h databasename<\/code>, controllare la riga Page buffers). <\/p>\n
Se la cache \u00e8 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\u00f2 portare a un uso eccessivo della memoria e a uno scambio.<\/p>\n
Successivamente, copiamo i file nel sistema di destinazione. <\/p>\n
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):<\/p>\n
set ISC_USER=proprietario\n\"25\/gbak\" -z -b -g -v -st t -y 25.log database25 stdout|^\n\"30\/gbak\" -z -c -v -st t -y 30.log stdin database30<\/code><\/pre>\n
\nIn 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 \u00e8 utile per digitare comandi lunghi. L'opzione -st(atus) \u00e8 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).<\/p>\n
Linux<\/b><\/p>\n
Su Linux Firebird 3 dipende dalla libreria tommath. Su CentOS (RHEL) questa libreria si trova nel repository epel, su Ubuntu (Debian) nel sistema.<\/p>\n
Per CentOS \u00e8 necessario prima collegare il repository EPEL e solo dopo fare <\/p>\n
yum install libtommath<\/code><\/pre>\n
\nIn Ubuntu non \u00e8 necessario collegare repository aggiuntivi, ma in Ubuntu 16 e in Ubuntu 18 si installano versioni diverse dei pacchetti \u2013 libtommath0 e libtommath1, rispettivamente.<\/p>\n
Firebird 3.0 cerca tommath.so.0 e per Ubuntu 18 \u00e8 necessario creare un collegamento (symlink) da tommath.so.0 a tommath.so.1. Per questo, prima bisogna trovare tommath.so.1. <\/p>\n
Il percorso cercato in Ubuntu \u00e8 \/usr\/lib\/x86_64-linux-gnu\/<\/code>, ma in altre distribuzioni basate su Debian potrebbe essere diverso.<\/p>\n
Il secondo problema \u00e8 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\u00e0.<\/p>\n
Per Firebird 3.0.2 e versioni superiori \u00e8 implementata la compilazione con \u2013enable-binreloc<\/a><\/noindex> e un'opzione separata per l'installatore (-path percorso).<\/p>\n
Supponendo che la libreria tommath e, se necessario, il symlink per tommath.so.0 siano stati aggiunti al sistema, \u00e8 possibile installare l'attuale (al momento della scrittura di questo articolo) pacchetto Firebird 3.0.4 in, ad esempio, \/opt\/fb3:<\/p>\n
.\/install.sh -path \/opt\/fb3<\/code><\/pre>\n
\nDopo ci\u00f2, \u00e8 possibile fermare il servizio di sistema Firebird e avviare la conversione in streaming. <\/p>\n
Quando si ferma Firebird, bisogna tenere conto che i processi di Firebird 2.5 in modalit\u00e0 Classic vengono solitamente avviati da xinetd \u2013 quindi \u00e8 necessario o disabilitare il servizio firebird per xinetd o fermare completamente xinetd.<\/i><\/p>\n
Nel file firebird.conf per 3.0 su Linux non \u00e8 necessario impostare i parametri MaxUnflushed (funzionano solo su Windows) e modificare le impostazioni di Firebird 2.5. <\/p>\n
In Linux l'accesso locale (file-based) di Firebird 2.5 non \u00e8 equivalente alla variante embedded su Windows \u2013 il server 2.5 funzioner\u00e0 nel processo gbak (senza parte di rete), ma i diritti di accesso saranno controllati sulla base degli utenti, il che significa che sar\u00e0 necessario non solo il login, ma anche la password: <\/p>\n
export ISC_USER=username ISC_PASSWORD=password\n\/opt\/firebird\/bin\/gbak -b \u2026 database25 stdout\n|\/opt\/fb3\/bin\/gbak -c \u2026 stdin database30<\/code><\/pre>\n
\nDopo 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 \u2013 anzi, \u00e8 meglio farlo dall'installatore tar.gz standard, e non tramite repository, poich\u00e9 la versione nei repository potrebbe essere obsoleta.<\/p>\n
Inoltre, dopo il ripristino del database su Linux e la reinstallazione bisogna controllare che il nuovo database abbia come proprietario l'utente firebird.<\/p>\n
Se non \u00e8 cos\u00ec, sar\u00e0 necessario correggere<\/p>\n
chown firebird.firebird database<\/code><\/pre>\n
\nRisultato<\/b><\/p>\n
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).<\/p>\n
Il risparmio di tempo \u00e8 legato al fatto che la conversione \"classica\" \u00e8 pari a \"tempo di backup\" pi\u00f9 \"tempo di ripristino\". Il ripristino \u00e8 composto da due parti: lettura dei dati dal file di backup e creazione dell'indice.<\/p>\n
Con la conversione in streaming, il tempo totale risulta come \"tempo di backup pi\u00f9 cinque-dieci percento\" e \"tempo di creazione degli indici\".<\/p>\n
I risultati specifici dipendono dalla struttura del database, ma mediamente il tempo di ripristino \u00e8 circa il doppio del tempo di backup. Pertanto, se consideriamo come unit\u00e0 di misura il tempo di backup, la \"conversione classica\" richiede tre unit\u00e0 di tempo, mentre quella in streaming ne richiede due. Inoltre, l'aumento di TempCacheLimit aiuta a ridurre ulteriormente il tempo.<\/p>\n
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.<\/p>\n
Domande?<\/b><\/p>\n
Per favore, scrivi tutte le domande nei commenti oppure inviale all'autore della metodologia e coautore di questo articolo \u2014 Vasiliy Sidorov, ingegnere sistemista senior della compagnia \"iBase\", all'indirizzo bs at ibase ru.<\/p>\n
Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n
Quale versione di Firebird stai utilizzando?<\/h2>\n