Cada versión de Firebird tiene su propia versión del formato de las estructuras de la base de datos del disco: O (n) D (isk) S (tructure). Antes de la versión 2.5 inclusive, el motor Firebird podía funcionar con ODS de versiones anteriores, es decir, las bases de datos de versiones anteriores fueron abiertas por la nueva versión y funcionaban en modo de compatibilidad, pero el motor Firebird 3.0 solo funciona con una base de datos en su propia versión ODS 12.0.
Para cambiar a 3.0, la base de datos de 2.5 debe convertirse a un nuevo formato a través de copia de seguridad / restauración. Por supuesto, suponemos que la base de datos se preparó previamente para la conversión, es decir Se ha probado la compatibilidad de metadatos y solicitudes con Firebird 3.0.
Si sigue el enfoque estándar, esto significa que necesita hacer una copia de seguridad a la versión 2.5, luego instalar 3.0 y realizar una restauración. Este procedimiento es aceptable si hay suficiente tiempo, pero al migrar grandes bases de datos, o al migrar varias docenas de bases de datos, cuando se agota el tiempo, puede usar la conversión de flujo, que es 30-40% más rápido. Cómo exactamente hacer esto (bajo Windows y bajo Linux), lea bajo el gato.
La idea general es que para la aceleración usaremos la tubería:
gbak -b … 25 stdout | gbak -c … stdin 30
Gbak desde 2.5 genera una copia de seguridad en formato lineal y la envía a stdout, que recoge inmediatamente gbak desde 3.0 a través de stdin y crea una nueva base de datos.
Es necesario organizar dicha canalización utilizando el método de acceso local (archivo), ya que el acceso a la red (incluso a través de localhost) ralentizará significativamente el proceso.
A continuación miramos los detalles para Windows y Linux.
VentanasEn el caso de Windows, la forma más fácil es hacer una compilación totalmente autónoma de Firebird. Para hacer esto, tome el
archivo de incrustación Firebird 2.5 , cambie el nombre de fbemded.dll a fbclient.dll, agregue las utilidades gbak.exe del archivo "habitual" 2.5 y (opcionalmente) isql.exe.
Firebird 3.0 usa un
solo ensamblaje y no requiere ninguna modificación.
La opción más pequeña (que no requiere la instalación de las 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.dll
Un administrador experimentado puede notar que intl / fbintl.dll e intl / fbintl.conf no están incluidos en 2.5. Esto es cierto porque gbak no utiliza una conexión de caracteres ni convierte datos entre caracteres, pero en el lado "receptor" de Firebird 3.0 estos archivos son necesarios al crear índices.
En firebird.conf, Firebird 3.0 recomienda agregar:
MaxUnflushedWrites = -1 MaxUnflushedWriteTime = -1
Además, es aconsejable establecer diferentes valores de IpcName para 2.5 y 3.0.
Al elegir los valores de otros parámetros, firebird.conf procede de una simple consideración: en la etapa de transferencia de datos, en un proceso, gbak ejecuta 2.5 y en el otro 3.0, luego termina 2.5 y 3.0 comienza a construir índices.
Para acelerar la etapa de creación de índices en 3.0, se recomienda aumentar el tamaño del parámetro TempCacheLimit a ~ 40% de RAM (si es un servidor dedicado, por supuesto).
Por ejemplo, si el servidor tiene 16 GB de RAM, puede poner
TempCacheLimit=6G
Por supuesto, este valor solo se puede establecer para Firebird 3 de 64 bits, ya que cualquier proceso de 32 bits no podrá asignar más de 2 gigabytes de memoria.En 2.5, este parámetro no necesita ser cambiado: ya no puede tener más de 2 gigabytes y no afecta la velocidad durante la copia de seguridad.
Antes de realizar la operación, debe verificar que el caché de la página en el encabezado de la base de datos esté establecido en 0 (
gstat -h databasename , consulte la línea de búferes de página).
Si la memoria caché se especifica explícitamente en el encabezado de la base de datos, anula los valores de firebird.conf (y database.conf en 3.0), y en caso de valores inadecuadamente grandes, puede conducir a un consumo excesivo de memoria e ir al intercambio.
Luego, copie los archivos al sistema de destino.
La conversión se lleva a cabo después de detener el servicio "sistema" de Firebird 2.5, en la línea de comando con mayores privilegios para el administrador local (ejemplo):
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
Este ejemplo utiliza un "oblicuo recto" entre comillas (un "estilo unix" válido), y un sombrero (un carácter "^") escapa al carácter de avance de línea, lo cual es conveniente al escribir comandos largos. La opción -st (atus) apareció en Firebird 2.5.8 y le permite escribir datos sobre el tiempo de funcionamiento del proceso gbak en el protocolo (consulte la documentación para más detalles).
LinuxEn Linux, Firebird 3 depende de la biblioteca tommath. En CentOS (RHEL), esta biblioteca está en el repositorio de epel, en Ubuntu (Debian) está en el sistema.
Para CentOS, primero debe conectar el repositorio de epel y solo luego
yum install libtommath
Ubuntu no necesita conectar repositorios adicionales, pero se instalan diferentes versiones de paquetes en Ubuntu 16 y Ubuntu 18: libtommath0 y libtommath1, respectivamente.
Firebird 3.0 está buscando tommath.so.0 y para Ubuntu 18 también se requiere crear un enlace (enlace simbólico) de tommath.so.0 a tommath.so.1. Para hacer esto, primero necesita encontrar tommath.so.1.
La ruta de búsqueda en Ubuntu es
/usr/lib/x86_64-linux-gnu/ , pero en otras distribuciones basadas en Debian puede ser diferente.
El segundo problema es que antes de Firebird 3.0.1, inclusive, no había una manera fácil de instalar dos versiones diferentes del servidor. No consideramos la opción "compilar desde la fuente con el prefijo deseado" debido a su relativa complejidad.
Para Firebird 3.0.2 y superior, se implementa una
compilación con –enable-binreloc y una opción de instalador separada (ruta de ruta).
Suponiendo que la biblioteca tommath y, si es necesario, el enlace simbólico para tommath.so.0 se han agregado al sistema, puede agregar la distribución real (en el momento de escribir este artículo) Firebird 3.0.4 a, por ejemplo, / opt / fb3:
./install.sh -path /opt/fb3
Después de eso, puede detener el servicio del sistema Firebird y comenzar la conversión de transmisión.
Al detener Firebird, debe tenerse en cuenta que los procesos Firebid 2.5 en modo clásico generalmente inician xinetd, por lo tanto, es necesario deshabilitar el servicio firebird para xinetd o detener xinetd por completo.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 versión incorporada para Windows: el servidor 2.5 funcionará en el proceso gbak (sin la parte de red), pero los derechos de acceso se verificará en la base de usuarios, lo que significa que no solo se requerirá un inicio de sesión, sino también una contraseña :
export ISC_USER=username ISC_PASSWORD=password /opt/firebird/bin/gbak -b … 25 stdout\ |/opt/fb3/bin/gbak -c … stdin 30
Después de una conversión exitosa, primero debe eliminar el Firebird 3.0 "adicional", luego el Firebird 2.5 "principal", y solo después de eso realice una instalación limpia de Firebird 3.0, lo mejor de todo desde el instalador tar.gz regular, y no a través de los repositorios, porque la versión en los repositorios puede retrasarse.
Además, después de restaurar la base de datos de Linux y reinstalarla, debe verificar que la nueva base de datos tenga el propietario del usuario de firebird.
Si esto no es así, entonces será necesario arreglar
chown firebird.firebird database
ResumenAdemás de ahorrar tiempo y espacio en disco, la conversión de flujo tiene otra ventaja importante: la conversión de la base de datos se realiza sin eliminar el Firebird 2.5 existente, lo que simplifica enormemente la reversión si la conversión no tiene éxito (a menudo debido a la falta de espacio o un reinicio inesperado durante el proceso de migración).
El ahorro de tiempo se debe al 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: leer datos de un archivo de copia de seguridad y crear un índice.
En la conversión de transmisión, el tiempo total se obtiene como "tiempo de respaldo más cinco a diez por ciento" y "tiempo de creación de índice".
Los resultados específicos dependen de la estructura de la base de datos, pero en promedio, el tiempo de recuperación es aproximadamente igual al tiempo de copia de seguridad doble. Por lo tanto, si tomamos tiempo de respaldo por unidad, entonces "conversión clásica" - tres unidades de tiempo, flujo - dos unidades de tiempo. Un aumento en TempCacheLimit también ayuda a reducir el tiempo.
En general, la conversión de transmisión en la práctica le permite ahorrar entre un 30 y un 40% del tiempo de una copia de seguridad alternativa y un restaurante.
Preguntas?Escriba todas las preguntas en los comentarios o envíelas al autor de la metodología y coautor de este artículo: Vasily Sidorov, ingeniero de sistemas líder en iBase, en bs at ibase ru.