Neste artigo, descreveremos o conjunto mínimo de ações necessárias para a instalação ideal do SGBD Firebird versão 3.0 em novas distribuições Linux. Para os exemplos, foram escolhidos CentOS 8 e Ubuntu 19.
Para a "entrega" da distribuição Firebird ao sistema alvo, neste guia, escolhemos a opção de download do arquivo tar.gz através do link do site oficial do projeto ().
Para os mais impacientes — vamos direto ao ponto:
Instalação rápida
Editando o arquivo /etc/sysctl.conf, adicionando a linha:
vm.max_map_count = 256000
Salve o arquivo e aplique a configuração:
sudo sysctl -p /etc/sysctl.conf
As instruções subsequentes variam para CentOS 8 e Ubuntu 19, mas LINK e DIRETÓRIO indicam o link do site oficial do projeto Firebird para download da distribuição e o diretório onde a distribuição será descompactada durante o download.
Atualmente (março de 2020), a versão estável é o Firebird 3.0.5 ( para a versão 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 LINK|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- LINK|tar -zxC /tmp
A instalação do SGBD Firebird propriamente dita:
cd /tmp/DIRETÓRIO
sudo ./install.sh
Se você deseja entender melhor o que essas ações representam, continue lendo.
Parte principal
Uma pequena introdução
Presume-se que o sistema operacional já esteja instalado em uma versão mínima e que o acesso aos repositórios públicos ou suas cópias locais esteja configurado.
Presume-se que o leitor tenha conhecimentos básicos sobre Linux e sobre o SGBD Firebird.
Planejamento
No servidor SGBD, recomenda-se alocar partições separadas para arquivos temporários (/tmp), arquivos de bancos de dados e backups locais.
Arquivos temporários incluem arquivos de bloqueio, arquivos de classificação, arquivos de "materialização" de tabelas temporárias globais (GTT) e tabelas de monitoramento. Os arquivos de classificação e tabelas temporárias globais estão localizados em /tmp, arquivos mon$-tabelas e arquivos de bloqueio – em /tmp/firebird.
Os arquivos de classificação são "removidos" (unlink) imediatamente após serem criados, portanto não podem ser "vistos" na listagem do diretório – apenas na lista de descritores do processo (marcados como deleted):
sudo ls -lhF /proc/`pgrep firebird`/fd
Na listagem do pseudodiretório /proc/…/fd/ são exibidos links simbólicos, e a informação real sobre o arquivo é fornecida por:
sudo stat -L /proc/`pgrep firebird`/fd/NÚMERO
onde NÚMERO – o descritor do arquivo de interesse.
Em vez de chamar "pgrep executável-arquivo" você pode inserir diretamente o identificador do processo de interesse.
Os arquivos temporários podem ser bastante grandes, por isso é /tmp recomendado alocar pelo menos 20-30 GB. Deve-se considerar que o tamanho dos arquivos de ordenação depende apenas do volume de dados que estão sendo ordenados, explícita ou implicitamente, na consulta e um único usuário pode "criar" gigabytes de arquivos temporários.
A partição para arquivos de banco de dados deve acomodar arquivos de todos os bancos, além de, no mínimo, uma cópia do arquivo do maior banco. Deve-se levar em conta o crescimento dos arquivos de banco nos próximos anos.
A partição de backups locais deve conter, no mínimo, um arquivo de backup de todos os bancos, além do backup do maior banco. É desejável que nesta partição haja espaço para recuperação do maior banco. Deve-se considerar o crescimento dos backups e dos arquivos de backup nos próximos anos.
Preparação preliminar
O servidor de banco de dados Firebird 3.0 aloca e libera dinamicamente a memória do sistema, o que pode levar à sua fragmentação. Por exemplo, após a desconexão de um grande número de usuários do superservidor, podem ocorrer erros em novas conexões.
A fragmentação da memória é controlada pelo parâmetro do sistema vm.max_map_count, por padrão – 64K. É recomendável aumentar seu valor em quatro vezes:
sudo sysctl vm.max_map_count=256000
Para que o novo valor seja aplicado após a reinicialização do sistema, adicionamos ao arquivo /etc/sysctl.conf a linha:
vm.max_map_count = 256000
É desejável fazer um comentário para que a razão da alteração desse parâmetro seja clara. Pode-se editar o arquivo primeiro e depois aplicar as configurações salvas nele:
sudo sysctl -p /etc/sysctl.conf
Instalação dos pacotes necessários
Os arquivos executáveis do banco de dados Firebird 3.0 Linux dependem das bibliotecas ncurses (libncurses.so.5), ICU (sem referência à versão e sem exibição na saída ldd) e tommath (libtommath.so.0). Para baixar e descompactar o arquivo de montagem, serão necessárias utilidades gzip, tar e curl ou wget. As versões do ICU, gzip, tar e curl/wget não são significativas.
O trabalho com pacotes depende do sistema e do gerenciador de pacotes utilizado, portanto, vamos analisá-los um a um.
CentOS 8
O CentOS 8 utiliza um novo gerenciador de pacotes – dnf e ele é "transparentemente" chamado pelo comando yum. Como para nossos objetivos não há diferença entre eles – nos exemplos será yum.
Atualizamos o cache de metadados: sudo yum makecache
O pacote libtommath está em um repositório separado E(xtra)P(ackages for)E(nterprise)L(inux), portanto, verificamos se ele já está conectado:
yum -C repolist
A opção "somente do cache" (-C ou --cache-only) é usado para excluir verificações e downloads desnecessários, acelerando o funcionamento do yum. Se o repositório epel não estiver na lista – vamos instalá-lo e atualizar o cache de metadados:
sudo yum install epel-release &&
sudo yum makecache
Confirmamos as solicitações, verificando, se necessário, os valores das chaves pgp com os já conhecidos de uma fonte confiável.
Se houver problemas ao carregar as metainformações do repositório de fontes https, edite o arquivo /etc/yum.repos.d/epel.repo, substituindo https:// para http:// e repetimos o comando de atualização do cache.
Verificamos o status dos pacotes necessários (o comando está encadeado, no exemplo a saída filtrou o pacote de 32 bits):
yum -C list
ncurses libicu libtommath
gzip tar curl wget |
grep -v i686
Pacotes 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
Pacotes Disponíveis
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 e ncurses estão presentes no pseudo-repositório do instalador (anaconda), e tar – excluído da instalação mínima do sistema. As versões principais libncurses e libtommath são superiores ao necessário: 6 e 1 em vez de 5 e 0, respectivamente. Se um mesmo pacote está instalado e disponível – uma atualização foi lançada para ele. Vamos instalar os pacotes ausentes:
sudo yum install
libicu libtommath tar
Ubuntu 19
As utilidades destinadas ao gerenciamento de pacotes são apt, apt‑get e apt‑cache. O primeiro é destinado a trabalho interativo, enquanto os dois últimos são para uso em scripts. Os nomes dos pacotes são um pouco diferentes e incluem a versão.
Verificamos o status dos pacotes necessários (o comando está encadeado, o exemplo de saída foi reduzido e os pacotes de 32 bits foram filtrados):
apt list libncurses? libicu?? libtommath?
gzip tar curl wget |
grep -v i386
curl 7.65.3-1
gzip 1.10-0 [atualizável…]
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]
Pacotes para os quais está indicado entre colchetes installed/atualizável – estão instalados. Disponível, mas não instalado ncurses5, ao invés de curl instalado wget. Vamos instalar os pacotes ausentes:
sudo apt‑get install
libncurses5 libtommath1
Criação de links simbólicos
Como libtommath.so.1 e libncurses.so.6 são retrocompatíveis com libtommath.so.0 e libncurses.so.5, então para o Firebird basta criar links simbólicos para as versões de bibliotecas já existentes.
Encontramos libtommath.so.1 (libncurses.so.? estão localizados no mesmo diretório):
find /usr -name libtommath.so.1
CentOS:
/usr/lib64/libtommath.so.1
Ubuntu:
/usr/lib/x86_64-linux-gnu/libtommath.so.1
Vamos criar links simbólicos.
CentOS:
sudo ln -s libtommath.so.1
/usr/lib64/libtommath.so.0
sudo ln -s libncurses.so.6
/usr/lib64/libncurses.so.5
Ubuntu:
sudo ln -s libtommath.so.1
/usr/lib/x86_64-linux-gnu/libtommath.so.0
Verificamos o resultado (o comando está encadeado, exemplos de saída foram reduzidos):
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*
Ubuntu:
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
Carregando o distribuidor do SGBD Firebird.
No site oficial do projeto Firebird (firebirdsql.org) são publicadas links para distribuições de versões 'oficiais' (releases) e construções 'diárias' (snapshot build).
As versões oficiais para Linux estão disponíveis em forma de arquivos compactados (tar.gz) e pacotes deb/rpm, enquanto as compilações estão disponíveis apenas como arquivos compactados. Vamos considerar o 'instalador genérico' (generic installer de tar.gz).
O arquivo da construção precisa ser baixado e descompactado, mas podemos combinar esses dois processos. A descompactação é feita em /tmp, a URL representa o link para o arquivo compactado a ser baixado.
curl:
curl -L URL | tar -zxC /tmp
wget:
wget -O– URL | tar -zxC /tmp
Por padrão curl envia os dados baixados para a saída padrão, mas não processa redirecionamentos, e adicionamos '‑L', enquanto wget, ao contrário: processa redirecionamentos, mas grava os dados em um arquivo e usamos '‑O‑'. Para tar especificar o uso gzip-filtro e o diretório onde a descompactação será realizada. Após a conclusão do processo, aparecerá um diretório do tipo Firebird‑3.0.5.33220‑0.amd64 com três arquivos: install.sh, buildroot.tar.gz e manifest.txt.
Instalação do Firebird
Durante a preparação, ajustamos o valor do parâmetro do sistema vm.max_map_count, verificamos a presença e instalamos as bibliotecas ICU, ncurses e tommath. Confirmamos a correção das versões de ncurses e tommath (libncures.so.5 e libtommath.so.0) e criamos os links simbólicos necessários.
A instalação em si é muito simples. Acessamos o diretório onde o arquivo do distribuidor Firebird foi descompactado, verificamos e, se necessário, configuramos o script como 'executável' install.sh:
chmod +x install.sh
executamos o script de instalação:
sudo ./install.sh
pressione a tecla Enter para confirmar o início da instalação e, ao receber o prompt, insira a senha sysdba.
O script de instalação inicia automaticamente systemd-unidade firebird-superserver (arquitetura padrão do Firebird 3.0). O serviço Firebird funcionará com configurações padrão para o superserver: cache de página de 2048 páginas (por banco de dados), buffer de classificação de 64 MB (geral) e conexão apenas com clientes de terceira versão. Para ver as configurações firebird.conf:
grep -v ^# firebird.conf | grep -v ^$
Deve-se considerar que novos valores de firebird.conf serão ativados somente após a reinicialização do serviço Firebird.
Ao selecionar os valores dos parâmetros, deve-se considerar que existem três principais "consumidores": cache de página (para o banco), buffer de ordenação (geral) e a memória alocada pelo servidor para conexões de clientes. Somente os dois primeiros podem ser gerenciados - o volume de memória das conexões de clientes depende do número e do texto das consultas em cache, seus planos e dos objetos do banco envolvidos nas consultas. A avaliação da memória das conexões de clientes é feita apenas empiricamente e pode mudar com alterações nos aplicativos dos clientes e/ou nos objetos do banco.
Para superclientes em hosts com pouca memória (até 12-16 GB), não se deve alocar para o cache de página e o buffer de ordenação mais de um terço a um quarto do volume total da RAM.
Se o número de bancos não é fixo e pode mudar, o volume total de memória do cache de página deve ser dividido pelo número máximo de bancos que podem estar no servidor. O tamanho do cache de página é definido em páginas e deve ser recalculado separadamente em bytes.
Para alternar para a arquitetura classic, é necessário, no mínimo, especificar claramente ServerMode em firebird.conf, diminuir o cache de página lá mesmo (não mais que 2K), reduzir o buffer de ordenação (o volume total aceitável de todas as ordenações, dividido pelo número máximo de conexões), proibir e parar a unidade firebird-superserver, permitir e iniciar a unidade firebird-classic.socket.
O uso da arquitetura superclassic no Firebird 3.0 não faz muito sentido: a "reliabilidade" é a mesma que a do supercliente e o mesmo buffer de ordenação geral. Não há cache de página geral e as "perdas" na sincronização de diferentes conexões são as mesmas que as do classic.
Deve-se lembrar que no Firebird 3.0, parte dos parâmetros (cache de página, tamanhos de arquivos locais, tabelas hash e alguns outros) podem ser definidos em databases.conf individualmente para cada banco. Para o supercliente, é útil, por exemplo, definir um pequeno valor DefaultDbCachePages em firebird.conf e estabelecer caches de página individuais para os bancos necessários em databases.conf.
Se tiver perguntas sobre o artigo, deixe nos comentários ou envie um email para o nosso suporte support@ibase.ru.
Fonte: habr.com
