{"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 tempo reale delle database Firebird 2.5 nel formato ODS12 (Firebird 3.0)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ogni versione di Firebird ha la propria versione del formato delle strutture dei dischi del database \u2013 O(n)D(isk)S(tructure). Fino alla versione 2.5 inclusa, il motore Firebird poteva lavorare con ODS delle versioni precedenti, cio\u00e8 i database di versioni pi\u00f9 vecchie potevano essere aperti dalla nuova versione e funzionare in modalit\u00e0 compatibilit\u00e0, ma il motore Firebird 3.0 funziona solo con database nella propria versione ODS 12.0.<\/p>\n

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\u00e0 con Firebird 3.0.<\/p>\n

Se si segue l'approccio standard, ci\u00f2 significa che \u00e8 necessario eseguire un backup sulla versione 2.5, quindi installare 3.0 e ripristinare. Questa procedura \u00e8 accettabile se c'\u00e8 tempo a disposizione, ma durante la migrazione di grandi database, o durante la migrazione simultanea di diverse decine di database, quando il tempo \u00e8 ristretto, \u00e8 possibile utilizzare la conversione in tempo reale, che \u00e8 dal 30% al 40% pi\u00f9 veloce. Come fare ci\u00f2 (su Windows e Linux), leggi pi\u00f9 avanti.
\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 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.<\/p>\n
\u00c8 necessario organizzare questa pipeline utilizzando il metodo di accesso locale (file), poich\u00e9 l'accesso di rete (anche tramite localhost) rallenta notevolmente il processo.<\/p>\n
Di seguito esaminiamo i dettagli per Windows e Linux.<\/p>\n
Windows<\/b><\/p>\n
Nel caso di Windows, il modo pi\u00f9 semplice \u00e8 creare una build completamente autonoma di Firebird. Per questo prendiamo l'archivio embed di Firebird 2.5<\/a><\/noindex>, rinominiamo fbemded.dll in fbclient.dll, aggiungiamo dall'archivio gli strumenti gbak.exe e (facoltativo) \u2013 isql.exe della versione normale 2.5. <\/p>\n
Firebird 3.0 utilizza una build unica<\/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 effettivamente cos\u00ec, poich\u00e9 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.<\/p>\n
In firebird.conf si raccomanda di aggiungere per Firebird 3.0:<\/p>\n
MaxUnflushedWrites = -1\nMaxUnflushedWriteTime = -1<\/code><\/pre>\n
\n\u00c8 inoltre consigliabile impostare valori diversi per IpcName per 2.5 e 3.0. <\/p>\n
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.<\/p>\n
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).<\/p>\n
Ad esempio, se il server ha 16 GB di RAM, \u00e8 possibile 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: non pu\u00f2 gi\u00e0 superare i 2 gigabyte e non influisce sulla velocit\u00e0 durante il backup.<\/p>\n
Prima di eseguire l'operazione, controlla che la cache della pagina nell'intestazione del database sia impostata a 0 (comando gstat -h databasename<\/code>, guarda la riga Page buffers). <\/p>\n
Se la cache \u00e8 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\u00f2 portare a un uso eccessivo della memoria e a uno swappaggio.<\/p>\n
Successivamente, copiamo i file nel sistema di destinazione. <\/p>\n
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):<\/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\" 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) \u00e8 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).<\/p>\n
Linux<\/b><\/p>\n
Su Linux, Firebird 3 dipende dalla libreria tommath. In CentOS (RHEL) questa libreria si trova nel repository epel, in Ubuntu (Debian) nel sistema.<\/p>\n
Per CentOS, \u00e8 necessario prima abilitare il repository epel e solo dopo procedere con <\/p>\n
yum install libtommath<\/code><\/pre>\n
\nPer Ubuntu non \u00e8 necessario abilitare repository aggiuntivi, ma su Ubuntu 16 e Ubuntu 18 vengono installate versioni diverse dei pacchetti: libtommath0 e libtommath1, rispettivamente.<\/p>\n
Firebird 3.0 cerca tommath.so.0 e per Ubuntu 18 \u00e8 necessario creare un link (symlink) da tommath.so.0 a tommath.so.1. Prima \u00e8 necessario 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, 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\u00e0.<\/p>\n
Per Firebird 3.0.2 e versioni superiori \u00e8 stata implementata una build con \u2013enable-binreloc<\/a><\/noindex> e un'opzione separata per l'installer (-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 la distribuzione attuale (al momento della scrittura di questo articolo) di Firebird 3.0.4 in, ad esempio, \/opt\/fb3:<\/p>\n
.\/install.sh -path \/opt\/fb3<\/code><\/pre>\n
\nDopo di che, \u00e8 possibile fermare il servizio di sistema Firebird e avviare la conversione in streaming. <\/p>\n
Quando si arresta Firebird, \u00e8 importante considerare che i processi Firebid 2.5 in modalit\u00e0 Classic vengono solitamente avviati da xinetd: pertanto, \u00e8 necessario disabilitare il servizio firebird per xinetd o arrestare completamente xinetd.<\/i><\/p>\n
Nel file firebird.conf per la versione 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
Su Linux, l'accesso locale (file-based) a Firebird 2.5 non \u00e8 equivalente alla variante embedded su Windows: il server 2.5 funzioner\u00e0 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: <\/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 una conversione riuscita, prima \u00e8 necessario rimuovere 'l'ulteriore' Firebird 3.0, poi 'il principale' Firebird 2.5 e solo dopo eseguire un'installazione pulita di Firebird 2.5 \u2014 ed \u00e8 meglio farlo utilizzando l'installer standard tar.gz, piuttosto che attraverso i repository, poich\u00e9 la versione nei repository potrebbe essere obsoleta.<\/p>\n
Inoltre, dopo il ripristino del DB su Linux e la reinstallazione, \u00e8 necessario verificare che il nuovo DB abbia come proprietario l'utente firebird.<\/p>\n
Se non \u00e8 cos\u00ec, dovr\u00e0 essere corretto.<\/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 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).<\/p>\n
Il risparmio di tempo \u00e8 legato al fatto che la conversione \"classica\" comporta il \"tempo di backup\" pi\u00f9 il \"tempo di ripristino\". Il ripristino \u00e8 composto da due parti: lettura dei dati dal file di backup e costruzione dell'indice.<\/p>\n
Con la conversione in streaming, il tempo totale risulta essere \"tempo di backup pi\u00f9 cinque-dieci percento\" e \"tempo di costruzione 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 il tempo di backup, la \"conversione classica\" richiede tre unit\u00e0 di tempo, mentre quella in streaming due unit\u00e0 di tempo. Aumentare il TempCacheLimit aiuta ulteriormente a ridurre il tempo.<\/p>\n
In generale, la conversione in streaming consente di risparmiare circa il 30-40% del tempo rispetto al backup e ripristino sequenziale.<\/p>\n
Domande?<\/b><\/p>\n
Per favore, inviate tutte le domande nei commenti, o contattate l'autore del metodo e co-autore di questo articolo \u2014 Vasily Sidorov, ingegnere di sistema senior dell'azienda \u00abiBase\u00bb, 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 utilizzi?<\/h2>\n