Cada versión de Firebird ten a súa propia versión do formato da estrutura do disco da base de datos, O(n)D(isk)S(tructure). Ata a versión 2.5 inclusive, o motor Firebird podía funcionar con ODS de versións anteriores, é dicir, as bases de datos de versións antigas abríanse pola nova versión e funcionaban en modo de compatibilidade, pero o motor Firebird 3.0 só funciona con bases de datos na súa propia versión ODS. 12.0.
Para migrar a 3.0, a base de datos de 2.5 debe converterse ao novo formato mediante copia de seguridade/restauración. Por suposto, asumimos que a base de datos estaba preparada previamente para a conversión, é dicir. Comprobouse a compatibilidade de metadatos e consultas con Firebird 3.0.
Se segues o enfoque estándar, isto significa que cómpre facer unha copia de seguridade na versión 2.5, instalar a 3.0 e restaurar. Este procedemento é aceptable se hai tempo suficiente, pero ao migrar grandes bases de datos ou ao migrar varias ducias de bases de datos ao mesmo tempo, cando o tempo se esgota, pode utilizar a conversión de transmisión, que é un 30-40% máis rápida. Como facelo exactamente (en Windows e en Linux), lea baixo o corte.
A idea xeral é que usaremos unha canalización para acelerar as cousas:
gbak -b … база25 stdout | gbak -c … stdin база30Gbak desde 2.5 xera unha copia de seguridade nun formato lineal e envíaa a stdout, que inmediatamente recolle gbak da 3.0 a través de stdin e crea unha nova base de datos.
É necesario organizar tal pipeline cun método de acceso local (arquivo), xa que o acceso á rede (mesmo a través de localhost) ralentizará significativamente o proceso.
A continuación repasamos os detalles de Windows e Linux.
Windows
No caso de Windows, o xeito máis sinxelo é facer unha compilación completamente autónoma de Firebird. Para iso levamos , cambie o nome de fbemded.dll a fbclient.dll, engada as utilidades gbak.exe e (opcionalmente) isql.exe do arquivo 2.5 "normal".
Usos de Firebird 3.0 e non require ningunha modificación.
A versión máis mínima (que non require a instalación das bibliotecas de execución VS2008/VS2010 no sistema de destino) contén os seguintes ficheiros:
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 administrador experimentado pode notar que 2.5 non inclúe os ficheiros intl/fbintl.dll e intl/fbintl.conf. Isto é certo, xa que gbak non usa un conxunto de caracteres de conexión e non converte datos entre conxuntos de caracteres, pero no lado "receptor" de Firebird 3.0, estes ficheiros son necesarios cando se crean índices.
En firebird.conf, Firebird 3.0 recoméndase engadir:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Ademais, é desexable establecer diferentes valores de IpcName para 2.5 e 3.0.
Ao elixir os valores doutros parámetros de firebird.conf, procedemos dunha consideración simple: na fase de transfusión de datos, gbak executa 2.5 nun proceso e 3.0 no outro, despois 2.5 sae e 3.0 comeza a construírse. índices.
Para acelerar a fase de creación de índices en 3.0, recoméndase aumentar o tamaño do parámetro TempCacheLimit a ~40% de RAM (se é un servidor dedicado, por suposto).
Por exemplo, se o servidor ten 16 GB de RAM, entón podes poñer
TempCacheLimit=6GPor suposto, este valor só se pode establecer para o Firebird 64 de 3 bits, xa que calquera proceso de 32 bits non pode asignar máis de 2 gigabytes de memoria.
Na versión 2.5, este parámetro non é necesario cambiar; non pode ser superior a 2 gigabytes de todos os xeitos e non afecta a velocidade durante a copia de seguridade.
Antes de realizar a operación, cómpre comprobar que a caché da páxina na cabeceira da base de datos estea configurada como 0 (comando gstat -h databasename, consulte a liña Buffers de páxina).
Se a caché está definida explícitamente na cabeceira da base de datos, entón anula os valores de firebird.conf (e databases.conf en 3.0) e, en caso de valores inadecuadamente grandes, pode provocar un consumo e intercambio de memoria excesivos.
A continuación, copie os ficheiros no sistema de destino.
A conversión realízase despois de deter o servizo Firebird 2.5 do "sistema", na liña de comandos con dereitos elevados para o administrador local (exemplo):
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 база30Este exemplo usa unha "barra diagonal" entre comiñas (válido "estilo Unix") e un "sombreiro" (o carácter "^") escapa ao carácter de nova liña, o que é útil cando se escriben comandos longos. A opción -st(atus) apareceu en Firebird 2.5.8 e permítelle rexistrar datos sobre a hora en que se estaba a executar o proceso gbak (para máis detalles, consulte a documentación).
Linux
En Linux Firebird 3 depende da biblioteca Tommath. En CentOS (RHEL) esta biblioteca está situada no repositorio epel, en Ubuntu (Debian) no repositorio do sistema.
Para CentOS, primeiro debes conectar o repositorio epel e só despois facelo
yum install libtommathUbuntu non precisa incluír repositorios adicionais, pero Ubuntu 16 e Ubuntu 18 instalan versións diferentes dos paquetes: libtommath0 e libtommath1, respectivamente.
Firebird 3.0 busca tommath.so.0 e para Ubuntu 18 tamén é necesario crear unha ligazón (ligazón simbólica) de tommath.so.0 a tommath.so.1. Para iso, primeiro cómpre atopar tommath.so.1.
Ruta buscada en Ubuntu - /usr/lib/x86_64-linux-gnu/, pero outras distribucións baseadas en Debian poden ser diferentes.
O segundo problema está relacionado co feito de que ata Firebird 3.0.1 incluído, non había un xeito sinxelo de instalar dúas versións de servidor diferentes. Non consideramos a opción "compilar desde a fonte co prefixo necesario" pola súa relativa complexidade.
Para Firebird 3.0.2 e superior implementado e unha opción de instalación separada (ruta da ruta).
Asumindo que se engadiron ao sistema a biblioteca tommath e, se é necesario, unha ligazón simbólica para tommath.so.0, pode instalar a distribución actual de Firebird 3.0.4 (no momento de escribir este artigo), por exemplo, /opt. /fb3:
./install.sh -path /opt/fb3Despois diso, podes deter o servizo do sistema Firebird e comezar a conversión por streaming.
Ao deter Firebird, teña en conta que os procesos de Firebid 2.5 no modo Clásico adoitan ser iniciados por xinetd, polo que cómpre desactivar o servizo firebird para xinetd ou deter o xinetd por completo.
En firebird.conf para 3.0 en Linux, non precisa configurar os parámetros MaxUnflushed (só funcionan en Windows) e cambiar a configuración de Firebird 2.5.
En Linux, o acceso local (arquivo) de Firebird 2.5 non é equivalente á versión integrada en Windows; o servidor 2.5 funcionará no proceso gbak (sen a parte da rede), pero os dereitos de acceso comprobaranse coa base de usuarios, o que significa que non só será necesario un inicio de sesión, senón tamén un contrasinal:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30Despois dunha conversión exitosa, primeiro debes desinstalar o Firebird 3.0 "adicional", despois o Firebird 2.5 "principal", e despois realizar unha instalación limpa de Firebird 2.5 - e é mellor desde o instalador tar.gz normal, e non a través do repositorios, porque. a versión nos repositorios pode quedar atrás.
Ademais, despois de restaurar a base de datos en Linux e reinstalala, cómpre comprobar que a nova base de datos é propiedade do usuario de firebird.
Se este non é o caso, entón haberá que corrixilo.
chown firebird.firebird databaseTotal
Ademais de aforrar tempo e espazo no disco, a conversión por streaming ten outra vantaxe importante: a conversión da base de datos realízase sen eliminar o Firebird 2.5 existente, o que simplifica moito a recuperación en caso de conversión non exitosa (a maioría das veces debido á falta de espazo ou ao reinicio inesperado durante a migración). proceso).
O aforro de tempo débese ao feito de que a conversión "clásica" é "tempo de copia de seguridade" máis "tempo de restauración". A recuperación consta de dúas partes: ler datos dun ficheiro de copia de seguridade e construír un índice.
Coa conversión en streaming, o tempo total obtense como "tempo de copia de seguranza máis cinco a dez por cento" e "tempo de construción do índice".
Os resultados específicos dependen da estrutura da base de datos, pero, de media, o tempo de recuperación é aproximadamente o dobre do tempo de copia de seguridade. Polo tanto, se tomamos o tempo de copia de seguridade como unha unidade, entón a "conversión clásica" é de tres unidades de tempo, a transmisión é dúas unidades de tempo. Aumentar TempCacheLimit axuda a reducir aínda máis o tempo.
En xeral, a conversión por streaming na práctica permítelle aforrar un 30-40% do tempo de copia de seguridade e restauración alternativas.
Preguntas?
Escribe todas as preguntas nos comentarios ou envíallas ao autor da metodoloxía e co-autor deste artigo - Vasily Sidorov, enxeñeiro de sistemas líder de iBase, en bs at ibase ru.
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Que versión de Firebird estás usando?
-
Firebird 3.x
-
Firebird 2.5
-
Firebird 2.1
-
Firebird 2.0, 1.5 ou 1.0
Votaron 16 usuarios. 1 usuario abstívose.
Fonte: www.habr.com