En este artículo, describiremos el conjunto mínimo de acciones necesarias para la instalación óptima de la base de datos Firebird versión 3.0 en nuevas distribuciones de Linux. Para los ejemplos, se han seleccionado CentOS 8 y Ubuntu 19.
Para la "entrega" de la distribución de Firebird al sistema objetivo, en esta guía, se ha elegido la opción de descargar el archivo tar.gz desde el enlace del sitio oficial del proyecto ().
Para los más impacientes — ¡al grano!
Instalación rápida
Editando el archivo /etc/sysctl.conf, añadiendo la línea:
vm.max_map_count = 256000
Guardamos el archivo y aplicamos la configuración:
sudo sysctl -p /etc/sysctl.conf
Las siguientes instrucciones difieren para CentOS 8 y Ubuntu 19, pero ENLACE y CATÁLOGO indican el enlace del sitio oficial del proyecto Firebird para descargar la distribución y el directorio en el que se descomprimirá la distribución durante la descarga.
En este momento (marzo de 2020), la versión vigente es Firebird 3.0.5 ( para la versión de 64 bits).
CentOS 8
sudo yum -y install epel-release
sudo yum -y makecache
sudo yum -y install libicu libtommath tar
ln -s libncurses.so.5
/usr/lib64/libncurses.so.5
ln -s libtommath.so.1
/usr/lib64/libtommath.so.0
curl -L ENLACE|tar -zxC /tmp
Ubuntu 19
sudo apt-get -y install libncurses5 libtommath1
ln -s libtommath.so.1
/usr/lib/x86_64-linux-gnu/libtommath.so.0
wget -O- ENLACE|tar -zxC /tmp
Realmente la instalación de la base de datos Firebird:
cd /tmp/CATÁLOGO
sudo ./install.sh
Si quieres entender mejor para qué sirven estas acciones, sigue leyendo.
Parte principal
Una pequeña introducción
Se asume que ya se ha instalado el sistema operativo en una versión mínima y que se ha configurado el acceso a los repositorios públicos o a sus copias locales.
Se asume que el lector tiene conocimientos básicos de Linux y de la base de datos Firebird.
Planificación
En el servidor de la base de datos, se recomienda dedicar particiones separadas para archivos temporales (/tmp), archivos de bases de datos y copias de seguridad locales.
Los temporales incluyen archivos de bloqueo, archivos de ordenación, archivos de "materialización" de tablas temporales globales (GTT) y tablas de monitoreo. Los archivos de ordenación y las tablas temporales globales se encuentran en /tmp, los archivos de tablas mon$ y los archivos de bloqueo se encuentran en /tmp/firebird.
Los archivos de ordenación se "eliminan" (unlink) inmediatamente después de ser creados, por lo que no se pueden "ver" en el listado del directorio — solo en la lista de descriptores (handles) de proceso (marcados como deleted):
sudo ls -lhF /proc/`pgrep firebird`/fd
En el listado del pseudo-directorio /proc/…/fd/ se muestran enlaces simbólicos, y la información real sobre el archivo la proporciona:
sudo stat -L /proc/`pgrep firebird`/fd/NÚMERO
donde NÚMERO – es el descriptor del archivo de interés.
En lugar de llamar a “pgrep archivo-ejecutable” se puede poner directamente el identificador del proceso de interés.
Los archivos temporales pueden ser muy grandes, por lo que se /tmp recomienda asignar al menos 20-30 GB. Se debe tener en cuenta que el tamaño de los archivos de ordenación depende únicamente del volumen de datos que se ordenan explícita o implícitamente en la consulta, y un solo usuario puede "crear" gigabytes de archivos temporales.
La partición para los archivos de bases de datos debe albergar archivos de todas las bases. además, al menos, una copia del archivo de la base más grande. Se debe considerar el crecimiento de los archivos de base en el futuro a varios años.
La partición de copias de seguridad locales debe albergar, al menos, un archivo de respaldo de todas las bases más una copia de la base más grande. Es deseable que en esta partición también haya espacio para la restauración de la base más grande. Se debe considerar el crecimiento de las copias de seguridad y archivos de copias de seguridad en el futuro a varios años.
Preparación previa
El servidor de base de datos Firebird 3.0 asigna y libera dinámicamente la memoria del sistema, lo que puede llevar a su fragmentación. Por ejemplo, después de que un gran número de usuarios se desconecte del superservidor al mismo tiempo, pueden surgir errores en nuevas conexiones.
La fragmentación de la memoria es controlada por el parámetro del sistema vm.max_map_count, por defecto – 64K. Se recomienda aumentar su valor cuatro veces:
sudo sysctl vm.max_map_count=256000
Para que el nuevo valor se establezca al reiniciar el sistema, se añade en el archivo /etc/sysctl.conf la línea:
vm.max_map_count = 256000
Es preferable incluir un comentario para que se entienda la razón del cambio de este parámetro. Se puede editar el archivo primero y luego aplicar la configuración guardada en él:
sudo sysctl -p /etc/sysctl.conf
Instalación de los paquetes necesarios
Los archivos ejecutables de Firebird 3.0 Linux dependen de las bibliotecas ncurses (libncurses.so.5), ICU (sin vinculación a la versión y sin mostrar en la salida ldd) y tommath (libtommath.so.0). Para descargar y descomprimir el archivo de compilación se requerirán utilidades. gzip, tar y curl o wget. Las versiones de ICU, gzip, tar y curl/wget son irrelevantes.
El trabajo con paquetes depende del sistema y del gestor de paquetes utilizado en el sistema, por lo que los examinaremos secuencialmente.
CentOS 8
CentOS 8 utiliza un nuevo gestor de paquetes – dnf y también es "transparentemente" invocado con el comando yum. Dado que para nuestros propósitos no hay diferencia entre ellos, en los ejemplos se utilizará yum.
Actualizar la caché de metadatos: sudo yum makecache
El paquete libtomath se encuentra en un repositorio separado E(xtra)P(ackages for)E(nterprise)L(inux), así que verificamos que ya esté conectado:
yum -C repolist
La opción "solo desde caché" (-C o --cache-only) se utiliza para evitar verificaciones y descargas innecesarias, acelerando el funcionamiento de yum. Si el repositorio epel no está en la lista, lo instalamos y actualizamos el caché de metadatos:
sudo yum install epel-release &&
sudo yum makecache
Confirmamos las solicitudes, comprobando los valores de las claves pgp con los ya conocidos de una fuente confiable, si es necesario.
Si hay problemas al cargar la metainformación del repositorio desde recursos https, editamos el archivo /etc/yum.repos.d/epel.repo, reemplazando https:// en http:// y repetimos el comando de actualización del caché.
Verificamos el estado de los paquetes necesarios (el comando está compuesto, en el ejemplo se filtra el paquete de 32 bits):
yum -C list
ncurses libicu libtommath
gzip tar curl wget |
grep -v i686
Paquetes instalados
curl.x86_64 7.61.1-11.el8 @anaconda
gzip.x86_64 1.9-9.el8 @anaconda
ncurses.x86_64 6.1-7.20180224.el8 @anaconda
Paquetes disponibles
libicu.x86_64 60.3-1.el8 BaseOS
libtommath.x86_64 1.1.0-1.el8 epel
tar.x86_64 2:1.30-4.el8 BaseOS
wget.x86_64 1.19.5-8.el8_1.1 AppStream
Vemos que curl, gzip y ncurses están alojados en el pseudorepositorio del instalador (anaconda), y tar – excluido de la instalación mínima del sistema. Las versiones principales libncurses y libtommath son mayores de lo que se requiere: 6 y 1 en lugar de 5 y 0, respectivamente. Si el mismo paquete está instalado y disponible, se ha lanzado una actualización. Instalamos los paquetes faltantes:
sudo yum install
libicu libtommath tar
Ubuntu 19
Las utilidades destinadas a la gestión de paquetes son apt, apt‑get y apt‑cache. El primero está diseñado para un trabajo interactivo, mientras que los dos últimos están destinados para usarse en scripts. Los nombres de los paquetes son un poco diferentes e incluyen la versión.
Verificamos el estado de los paquetes necesarios (el comando está compuesto, el ejemplo de salida está abreviado y se filtran los paquetes de 32 bits):
apt list libncurses? libicu?? libtommath?
gzip tar curl wget |
grep -v i386
curl 7.65.3-1
gzip 1.10-0 [actualizable…]
libicu63 63.2-2 [instalado]
libncurses5 6.1
libncurses6 6.1 [instalado, automático]
libtommath1 1.1.0
tar 1.30 [instalado]
wget 1.20.3 [instalado]
Los paquetes para los cuales en los corchetes se indica installed/actualizable – están instalados. Disponible, pero no instalado ncurses5, en lugar de curl está instalado wget. Instalamos los paquetes faltantes:
sudo apt‑get install
libncurses5 libtommath1
Creando enlaces simbólicos
Dado que libtommath.so.1 y libncurses.so.6 son compatibles con la versión anterior, por lo que para Firebird es suficiente crear enlaces simbólicos a las versiones existentes de las bibliotecas. libtommath.so.0 y libncurses.so.5libncurses.so.?
Buscamos libtommath.so.1 (se encuentran en este mismo directorio): find /usr -name libtommath.so.1
Ubuntu:
CentOS:
/usr/lib64/libtommath.so.1
Creamos enlaces simbólicos.
/usr/lib/x86_64-linux-gnu/libtommath.so.1
sudo ln -s libtommath.so.1 /usr/lib64/libtommath.so.0 sudo ln -s libncurses.so.6 /usr/lib64/libncurses.so.5
CentOS:
sudo ln -s libtommath.so.1
/usr/lib/x86_64-linux-gnu/libtommath.so.0
Creamos enlaces simbólicos.
Verificamos el resultado (el comando está compuesto, ejemplos de salida están abreviados):
ls -lhF $(dirname `find /usr -name libtommath.so.1`) | grep "lib(ncurses|tommath).so."
ls -lhF
$(dirname `find /usr -name libtommath.so.1`) |
grep "lib(ncurses|tommath).so."
CentOS:
libncurses.so.5 -> libncurses.so.6*
libncurses.so.6 -> libncurses.so.6.1*
libncurses.so.6.1*
libtommath.so.0 -> libtommath.so.1*
libtommath.so.1 -> libtommath.so.1.1.0*
libtommath.so.1.1.0*
Creamos enlaces simbólicos.
libncurses.so.5 -> libncurses.so.5.9
libncurses.so.5.9
libncurses.so.6 -> libncurses.so.6.1
libncurses.so.6.1
libtommath.so.0 -> libtommath.so.1
libtommath.so.1 -> libtommath.so.1.1.0
libtommath.so.1.1.0
Descargando el distribuidor de la base de datos Firebird.
En el sitio web oficial del proyecto Firebird (firebirdsql.org) se publican enlaces a los distribuciones de "versiones oficiales" (releases) y "builds diarios" (snapshot build).
Las versiones oficiales para Linux están disponibles en forma de archivos comprimidos (tar.gz) y paquetes deb/rpm, y las construcciones sólo están disponibles en forma de archivos comprimidos. Consideraremos el "instalador genérico" (generic installer de tar.gz).
El archivo comprimido de la construcción debe ser descargado y descomprimido, pero podemos combinar ambos procesos. La descompresión se realiza en /tmp, URL designa el enlace al archivo comprimido que se descarga.
curl:
curl -L URL | tar -zxC /tmp
wget:
wget -O– URL | tar -zxC /tmp
funciona hasta que se finalice manualmente. Por lo tanto, puede ser útil la opción curl envía los datos descargados a la salida estándar, pero no procesa redirecciones y añadimos "‑L", mientras que wget, por el contrario: procesa redirecciones, pero escribe los datos en un archivo y usamos "‑O‑". Para tar estamos especificando el uso de gzip-filtro y el directorio en el que se realizará la descompresión. Al finalizar el proceso, aparecerá un directorio del tipo Firebird‑3.0.5.33220‑0.amd64 con tres archivos: install.sh, buildroot.tar.gz y manifest.txt.
Instalación de Firebird
Durante la preparación previa, ajustamos el valor del parámetro del sistema vm.max_map_count, verificamos la existencia e instalamos las bibliotecas ICU, ncurses y tommath. Aseguramos que las versiones de ncurses y tommath son correctas (libncurses.so.5 y libtommath.so.0) y creamos los enlaces simbólicos necesarios.
La instalación propiamente dicha es muy sencilla. Accedemos al directorio donde se descomprimió el archivo distribuidor de Firebird, verificamos y, si es necesario, establecemos el flag de "ejecutable" al script install.sh:
chmod +x install.sh
ejecutamos el script de instalación:
sudo ./install.sh
presionando la tecla Enter confirmamos el inicio de la instalación, y al recibir la solicitud – introducimos la contraseña sysdba.
El script de instalación inicia automáticamente systemd-unidad firebird-superserver (arquitectura predeterminada de Firebird 3.0). El servicio Firebird funcionará con los parámetros por defecto para el superservidor: caché de páginas de 2048 páginas (por base), búfer de ordenamientos de 64 MB (general) y conexión solo con clientes de la tercera versión. Visualizar parámetros firebird.conf:
grep -v ^# firebird.conf | grep -v ^$
Se debe considerar que los nuevos valores de firebird.conf se activarán solo después de reiniciar el servicio Firebird.
Al seleccionar los valores de los parámetros, es importante tener en cuenta que hay tres «consumidores» principales: el caché de página (para la base), el búfer de ordenación (general) y la memoria asignada por el servidor para las conexiones de los clientes. Solo se puede gestionar los dos primeros: el volumen de memoria de las conexiones de los clientes depende de la cantidad y el texto de las consultas en caché, sus planes y los objetos de la base involucrados en las consultas. La evaluación de la memoria de las conexiones de los clientes se hace únicamente empíricamente y puede cambiar con los cambios en las aplicaciones clientes y/o objetos de la base.
Para el superservidor en hosts con poca memoria (hasta 12-16 GB), no se debe asignar al caché de página y al búfer de ordenación más de un tercio o cuatro quintas partes del volumen total de RAM.
Si la cantidad de bases no es fija y puede cambiar, el volumen total de memoria del caché de página debe dividirse por el número máximo de bases que pueden estar en el servidor. El tamaño del caché de página se establece en páginas y debe convertirse por separado a bytes.
Para cambiar a la arquitectura clásica, es necesario especificar, al menos, explícitamente ServerMode en firebird.conf, reducir también allí el caché de página (no más de 2K), disminuir el búfer de ordenación (el volumen total permitido de todas las ordenaciones, dividido por el número máximo de conexiones), prohibir y detener la unidad firebird-superserver, permitir y ejecutar la unidad firebird-classic.socket.
El uso de la arquitectura superclásica en Firebird 3.0 no tiene mucho sentido: la «fiabilidad» es la misma que la del superservidor y el mismo búfer de ordenación general. No hay caché de página general y las «pérdidas» por sincronización de diferentes conexiones son las mismas que en la clásica.
Es importante recordar que en Firebird 3.0, parte de los parámetros (caché de página, tamaños del archivo de bloqueo, tablas hash y algunos otros) se pueden establecer en databases.conf individualmente para cada base. Para el superservidor, es útil, por ejemplo, establecer un valor pequeño para DefaultDbCachePages en firebird.conf y establecer cachés de página individuales para las bases necesarias en databases.conf.
Si tienes preguntas sobre el artículo, hazlas en los comentarios, o envíanos un correo a nuestra dirección de soporte support@ibase.ru.
Fuente: habr.com
