Cada versão do Firebird possui sua própria versão do formato das estruturas de disco do banco de dados - O (n) D (isk) S (estrutura). Antes da versão 2.5, inclusive, o mecanismo Firebird podia trabalhar com o ODS das versões anteriores, ou seja, os bancos de dados de versões mais antigas eram abertos pela nova versão e funcionavam no modo de compatibilidade, mas o mecanismo Firebird 3.0 funciona apenas com um banco de dados em sua própria versão do ODS 12.0.
Para mudar para 3.0, o banco de dados da 2.5 deve ser convertido para um novo formato via backup / restauração. Obviamente, assumimos que o banco de dados foi preparado anteriormente para a conversão - ou seja, metadados e solicitações foram testados quanto à compatibilidade com o Firebird 3.0.
Se você seguir a abordagem padrão, isso significa que você precisa fazer backup na versão 2.5, instalar o 3.0 e fazer uma restauração. Este procedimento é aceitável se houver tempo suficiente, mas ao migrar bancos de dados grandes ou durante várias dezenas de bancos de dados, quando o tempo estiver se esgotando, você poderá usar a conversão de fluxo, que é 30 a 40% mais rápida. Como exatamente fazer isso (no Windows e no Linux), leia sob o gato.
A idéia geral é que, para a aceleração, usaremos o pipeline:
gbak -b … 25 stdout | gbak -c … stdin 30
O Gbak da 2.5 gera um backup em um formato linear e o envia ao stdout, que imediatamente pega o gbak do 3.0 via stdin e cria um novo banco de dados.
É necessário organizar esse pipeline usando o método de acesso local (arquivo), pois o acesso à rede (mesmo através do host local) atrasará significativamente o processo.
Abaixo, examinamos os detalhes para Windows e Linux.
WindowsNo caso do Windows, a maneira mais fácil é criar uma versão totalmente autônoma do Firebird. Para fazer isso, pegue o
arquivo incorporado do
Firebird 2.5 , renomeie fbemded.dll para fbclient.dll, adicione utilitários gbak.exe do arquivo 2.5 "usual" e (opcionalmente) isql.exe.
O Firebird 3.0 usa um
único conjunto e não requer nenhuma modificação.
A opção menor (que não requer a instalação de bibliotecas de tempo de execução VS2008 / VS2010 no sistema de destino) contém os seguintes arquivos:
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
Um administrador experiente pode perceber que intl / fbintl.dll e intl / fbintl.conf não estão incluídos no 2.5. Isso é verdade, já que o gbak não usa um caractere de conexão e não converte dados entre caracteres, mas no lado "de recebimento" do Firebird 3.0, esses arquivos são necessários ao criar índices.
No firebird.conf, o Firebird 3.0 recomenda adicionar:
MaxUnflushedWrites = -1 MaxUnflushedWriteTime = -1
Além disso, é aconselhável definir diferentes valores de IpcName para 2.5 e 3.0.
Ao escolher os valores de outros parâmetros, o firebird.conf procede de uma simples consideração: no estágio de transferência de dados, em um processo, o gbak executa 2.5, e no outro 3.0, o 2.5 termina e o 3.0 começa a criar índices.
Para acelerar o estágio de criação de índices no 3.0, é recomendável aumentar o tamanho do parâmetro TempCacheLimit para ~ 40% de RAM (se for um servidor dedicado, é claro).
Por exemplo, se o servidor tiver 16 GB de RAM, você poderá colocar
TempCacheLimit=6G
Obviamente, esse valor só pode ser definido para o Firebird 3 de 64 bits, pois qualquer processo de 32 bits não poderá alocar mais de 2 gigabytes de memória.Em 2.5, esse parâmetro não precisa ser alterado - ele já não pode ter mais de 2 gigabytes e não afeta a velocidade durante o backup.
Antes de executar a operação, é necessário verificar se o cache da página no cabeçalho do banco de dados está definido como 0 (comando
gstat -h databasename , consulte a linha de buffers de página).
Se o cache for especificado explicitamente no cabeçalho do banco de dados, ele substituirá os valores do firebird.conf (e database.conf no 3.0) e, no caso de valores inadequadamente grandes, pode levar ao consumo excessivo de memória e passar para a troca.
Em seguida, copie os arquivos para o sistema de destino.
A conversão é realizada após a interrupção do serviço Firebird 2.5 do “sistema”, na linha de comando com privilégios crescentes 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 30
Este exemplo usa “oblíquo reto” entre aspas (válido “estilo unix”) e “hat” (caractere “^”) escapa ao caractere de avanço de linha, o que é conveniente ao digitar comandos longos. A opção -st (atus) apareceu no Firebird 2.5.8 e permite gravar dados sobre o tempo de operação do processo gbak no protocolo (consulte a documentação para obter detalhes).
LinuxNo Linux, o Firebird 3 depende da biblioteca de tommath. No CentOS (RHEL), esta biblioteca está no repositório epel, no Ubuntu (Debian) está no sistema.
Para o CentOS, você deve primeiro conectar o repositório epel e só depois
yum install libtommath
O Ubuntu não precisa conectar repositórios adicionais, mas versões diferentes de pacotes estão instaladas no Ubuntu 16 e Ubuntu 18 - libtommath0 e libtommath1, respectivamente.
O Firebird 3.0 está procurando por tommath.so.0 e, para o Ubuntu 18, é necessário criar um link (link simbólico) de tommath.so.0 para tommath.so.1. Para fazer isso, primeiro você precisa encontrar tommath.so.1.
O caminho de busca no Ubuntu é
/usr/lib/x86_64-linux-gnu/ , mas em outras distribuições baseadas no Debian, pode ser diferente.
O segundo problema é que, antes do Firebird 3.0.1, inclusive, não havia uma maneira fácil de instalar duas versões diferentes do servidor. Não consideramos a opção "compilar a partir da fonte com o prefixo desejado" devido à sua relativa complexidade.
Para o Firebird 3.0.2 e superior, uma
compilação com –enable-binreloc e uma opção de instalador separada (-path path) são implementadas.
Supondo que a biblioteca tommath e, se necessário, o link simbólico para tommath.so.0 tenham sido adicionados ao sistema, você pode adicionar a distribuição real (no momento da redação deste documento) do Firebird 3.0.4 a distribuição, por exemplo, / opt / fb3:
./install.sh -path /opt/fb3
Depois disso, você pode interromper o serviço do sistema Firebird e iniciar a conversão de streaming.
Ao parar o Firebird, deve-se ter em mente que os processos do Firebid 2.5 no modo Clássico geralmente iniciam o xinetd - portanto, é necessário desativar o serviço do firebird para o xinetd ou parar completamente o xinetd.No firebird.conf para 3.0 no Linux, você não precisa definir os parâmetros MaxUnflushed (eles funcionam apenas no Windows) e alterar as configurações do Firebird 2.5.
No Linux, o acesso local (arquivo) do Firebird 2.5 não é equivalente à versão incorporada para Windows - o servidor 2.5 funcionará no processo gbak (sem a parte da rede), mas os direitos de acesso serão verificados na base de usuários, o que significa que não apenas um login, mas também uma senha será necessária :
export ISC_USER=username ISC_PASSWORD=password /opt/firebird/bin/gbak -b … 25 stdout\ |/opt/fb3/bin/gbak -c … stdin 30
Após a conversão bem-sucedida, você deve primeiro remover o Firebird 3.0 "adicional", depois o Firebird 2.5 "principal" e somente depois executar uma instalação limpa do Firebird 3.0 - o melhor de tudo, desde o instalador regular tar.gz, e não pelos repositórios, porque a versão nos repositórios pode demorar.
Além disso, após restaurar o banco de dados Linux e reinstalá-lo, é necessário verificar se o novo banco de dados possui o proprietário do usuário firebird.
Se não for assim, será necessário corrigir
chown firebird.firebird database
SumárioAlém de economizar tempo e espaço em disco, a conversão de fluxo tem outra vantagem importante - a conversão do banco de dados é feita sem a exclusão do Firebird 2.5 existente, o que simplifica bastante a reversão se a conversão for malsucedida (geralmente devido à falta de espaço ou uma reinicialização inesperada durante o processo de migração).
A economia de tempo se deve ao fato de a conversão "clássica" ser "tempo de backup" mais "tempo de recuperação". A recuperação consiste em duas partes: lendo dados de um arquivo de backup e construindo um índice.
Na conversão de streaming, o tempo total é obtido como "tempo de backup mais cinco a dez por cento" e "tempo de criação do índice".
Os resultados específicos dependem da estrutura do banco de dados, mas, em média, o tempo de recuperação é aproximadamente igual ao tempo de backup duplo. Portanto, se tomarmos o tempo de backup por unidade, a “conversão clássica” - três unidades de tempo, fluxo - duas unidades de tempo. Um aumento no TempCacheLimit também ajuda a reduzir o tempo.
Em geral, na prática, a conversão de fluxo permite economizar 30 a 40% do tempo de um backup e restaurante alternativos.
Perguntas?Escreva todas as perguntas nos comentários ou envie para o autor da metodologia e co-autor deste artigo - Vasily Sidorov, engenheiro de sistemas líder do iBase, na bs no ibase ru.