Cada versión de Firebird tiene su propia versión del formato de estructuras de disco de la base de datos – O(n)D(is)S(tructure). Hasta la versión 2.5 inclusive, el motor Firebird podía trabajar con ODS de versiones anteriores, es decir, las bases de datos de versiones antiguas se abrían con la nueva versión y operaban en modo de compatibilidad, pero el motor Firebird 3.0 solo trabaja con bases de datos en su propia versión ODS 12.0.
Para actualizar a 3.0, la base de datos de 2.5 debe convertirse al nuevo formato a través de backup/restauración. Por supuesto, asumimos que la base de datos ha sido preparada previamente para la conversión, es decir, que los metadatos y las consultas han sido verificadas por su compatibilidad con Firebird 3.0.
Siguiendo el enfoque estándar, esto significa que se debe realizar un backup en la versión 2.5, luego instalar la 3.0 y hacer la restauración. Este procedimiento es aceptable si hay suficiente tiempo, pero al migrar grandes bases de datos, o al migrar simultáneamente varias decenas de bases de datos, cuando el tiempo es limitado, se puede optar por la conversión continua, que es un 30-40% más rápida. Cómo hacerlo exactamente (en Windows y en Linux), léelo a continuación.
La idea general es que para acelerar, utilizaremos una tubería:
gbak -b … base25 stdout | gbak -c … stdin base30Gbak de 2.5 genera un backup en formato lineal y lo envía a stdout, que inmediatamente es capturado a través de stdin por gbak de 3.0 y crea una nueva base de datos.
Es necesario organizar esta tubería utilizando necesariamente el método de acceso local (a archivos), ya que el acceso por red (incluso a través de localhost) ralentizará considerablemente el proceso.
A continuación, examinamos los detalles para Windows y Linux.
Windows
En el caso de Windows, lo más fácil es hacer una compilación completamente autónoma de Firebird. Para ello, tomamos , renombramos fbembed.dll a fbclient.dll, añadimos desde el archivo 'normal' 2.5 la utilidad gbak.exe y (opcionalmente) – isql.exe.
Firebird 3.0 utiliza y no requiere ninguna modificación.
La opción más mínima (que no requiere instalación de bibliotecas de tiempo de ejecución VS2008/VS2010 en el sistema de destino) contiene los siguientes archivos:
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 puede notar que en 2.5 no se incluyen los archivos intl/fbintl.dll e intl/fbintl.conf. Esto es cierto, ya que gbak no utiliza el juego de caracteres de conexión y no convierte datos entre conjuntos de caracteres, pero en el lado de 'recepción' de Firebird 3.0, esos archivos son necesarios al crear índices.
En firebird.conf se recomienda agregar lo siguiente para Firebird 3.0:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Además, es deseable establecer un valor diferente para IpcName para 2.5 y 3.0.
Al elegir los valores de otros parámetros en firebird.conf, partimos de una consideración simple: en la etapa de migración de datos, un proceso utiliza gbak 2.5 y el otro 3.0, luego 2.5 finaliza su trabajo y 3.0 comienza a construir índices.
Para acelerar la etapa de construcción de índices en 3.0, se recomienda aumentar el tamaño del parámetro TempCacheLimit a aproximadamente un 40% de RAM (si es un servidor dedicado, por supuesto).
Por ejemplo, si el servidor tiene 16 GB de RAM, se puede establecer
TempCacheLimit=6GPor supuesto, este valor solo se puede establecer en Firebird 3 de 64 bits, ya que cualquier proceso de 32 bits no podrá asignar más de 2 gigabytes de memoria.
Para 2.5, este parámetro no necesita ser modificado, ya que no puede ser mayor de 2 gigabytes y tampoco afecta la velocidad durante la copia de seguridad.
Antes de realizar la operación, es necesario verificar que el caché de páginas en la cabecera de la base de datos esté establecido en 0 (orden gstat -h databasename, ver la línea de buffers de página).
Si el caché se establece explícitamente en la cabecera de la base de datos, anula los valores de firebird.conf (y databases.conf en 3.0), y en caso de valores excesivamente grandes puede llevar a un consumo excesivo de memoria y al uso de swap.
Luego, copiamos los archivos al sistema objetivo.
La conversión se realiza después de detener el servicio 'sistema' de Firebird 2.5, en la línea de comandos con privilegios elevados hasta administrador local (ejemplo):
set ISC_USER=propietario
"25/gbak" -z -b -g -v -st t -y 25.log base25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin base30En este ejemplo se utiliza la 'barra diagonal' entre comillas (estilo 'unix-style' permitido), y el 'caret' (símbolo '^') escapa el símbolo de salto de línea, lo cual es útil para teclear comandos largos. La opción -st(atus) apareció en Firebird 2.5.8 y permite registrar en el protocolo los datos sobre el tiempo de funcionamiento del proceso gbak (detalles en la documentación).
Linux
En Linux, Firebird 3 depende de la biblioteca tommath. En CentOS (RHEL), esta biblioteca se encuentra en el repositorio epel, en Ubuntu (Debian) en – el sistema.
Para CentOS, primero es necesario conectar el repositorio epel y solo después hacer
yum install libtommathEn Ubuntu no es necesario conectar repositorios adicionales, pero en Ubuntu 16 y en Ubuntu 18 se instalan diferentes versiones de paquetes: libtommath0 y libtommath1, respectivamente.
Firebird 3.0 busca tommath.so.0 y para Ubuntu 18 adicionalmente es necesario crear un enlace (symlink) de tommath.so.0 a tommath.so.1. Para esto, primero hay que localizar tommath.so.1.
La ruta buscada en Ubuntu es /usr/lib/x86_64-linux-gnu/, pero en otras distribuciones basadas en Debian puede ser diferente.
El segundo problema está relacionado con que hasta Firebird 3.0.1, inclusive, no había una forma sencilla de instalar dos versiones diferentes del servidor. La opción de "compilar desde los fuentes con el prefijo correcto" no la consideramos debido a su relativa complejidad.
Para Firebird 3.0.2 y versiones superiores se implementó y una opción separada en el instalador (-path ruta).
Asumiendo que la biblioteca tommath y, si es necesario, el symlink para tommath.so.0 se han agregado al sistema, se puede instalar la distribución actual (en el momento de escribir este artículo) de Firebird 3.0.4 en, por ejemplo, \/opt\/fb3:
./install.sh -path \/opt\/fb3Después de esto, se puede detener el servicio del sistema Firebird y comenzar la conversión en lote.
Al detener Firebird, hay que tener en cuenta que los procesos de Firebird 2.5 en modo Classic generalmente los inicia xinetd, por lo que es necesario o prohibir el servicio firebird para xinetd o detener xinetd completamente.
En firebird.conf para 3.0 en Linux no es necesario establecer los parámetros MaxUnflushed (solo funcionan en Windows) y cambiar la configuración de Firebird 2.5.
En Linux, el acceso local (a archivos) de Firebird 2.5 no es equivalente a la variante embebida en Windows: el servidor 2.5 funcionará en el proceso gbak (sin parte de red), pero los derechos de acceso se verificarán según la base de usuarios, por lo que se requerirán tanto el login como la contraseña:
export ISC_USER=username ISC_PASSWORD=password
\/opt\/firebird\/bin\/gbak -b … base25 stdout
|\/opt\/fb3\/bin\/gbak -c … stdin base30Después de una conversión exitosa, primero hay que eliminar el "Firebird 3.0 adicional", luego el "Firebird 2.5 principal" y después hacer una instalación limpia de Firebird 2.5, preferiblemente desde el instalador tar.gz y no a través de repositorios, ya que la versión en los repositorios puede estar desactualizada.
Además, después de restaurar la BD en Linux y reinstalar, se debe verificar que la nueva BD tenga como propietario al usuario firebird.
Si no es así, habrá que corregirlo
chown firebird.firebird databaseSummary
Además del ahorro de tiempo y espacio en disco, la conversión en línea tiene otra ventaja importante: la conversión de la base se realiza sin eliminar el Firebird 2.5 existente, lo que facilita notablemente la reversión en caso de una conversión fallida (más comúnmente, debido a la falta de espacio o un reinicio inesperado durante el proceso de migración).
El ahorro de tiempo está relacionado con el hecho de que la conversión 'clásica' es 'tiempo de respaldo' más 'tiempo de recuperación'. La recuperación consta de dos partes: lectura de datos desde el archivo de respaldo y construcción del índice.
En la conversión en línea, el tiempo total se calcula como 'tiempo de respaldo más cinco a diez por ciento' y 'tiempo de construcción de índices'.
Los resultados específicos dependen de la estructura de la base, pero en promedio, el tiempo de recuperación es aproximadamente el doble del tiempo de respaldo. Por lo tanto, si tomamos como unidad el tiempo de respaldo, la 'conversión clásica' toma tres unidades de tiempo, mientras que la conversión en línea toma dos unidades de tiempo. Aumentar el TempCacheLimit ayuda a reducir aún más el tiempo.
En general, la conversión en línea permite ahorrar entre un 30% y un 40% del tiempo necesario para un respaldo y restauración secuencial.
¿Preguntas?
Por favor, envía todas tus preguntas en los comentarios, o dirígete al autor de la metodología y coautor de este artículo — Vasily Sidorov, ingeniero de sistemas líder de la compañía 'iBase', a la dirección bs at ibase ru.
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Qué versión de Firebird utilizas?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 o 1.0
16 usuarios votaron. 1 usuario se abstuvo.
Fuente: habr.com
