Cada versão do Firebird tem sua própria versão do formato de estruturas de disco do banco de dados – O(n)D(isk)S(tructure). Até a versão 2.5 inclusive, o mecanismo Firebird podia trabalhar com ODS de versões anteriores, ou seja, bancos de dados de versões mais antigas eram abertos pela nova versão e funcionavam em modo de compatibilidade, mas o mecanismo Firebird 3.0 só funciona com bancos de dados em sua própria versão ODS 12.0.
Para migrar para 3.0, o banco de dados da versão 2.5 deve ser convertido para o novo formato através de backup/restauração. Naturalmente, supomos que o banco de dados tenha sido preparado previamente para a conversão - ou seja, os metadados e consultas foram verificados quanto à compatibilidade com o Firebird 3.0.
Se seguirmos a abordagem padrão, isso significa que é necessário fazer um backup na versão 2.5, depois instalar a 3.0 e realizar a restauração. Esse procedimento é viável se houver tempo suficiente, mas na migração de grandes bancos de dados, ou na migração simultânea de várias dezenas de bancos de dados, quando o tempo é crítico, pode-se usar a conversão em stream, que é de 30-40% mais rápida. Como fazer isso (no Windows e no Linux) pode ser lido abaixo.
A ideia geral é que, para acelerar, utilizaremos um pipeline:
gbak -b … banco25 stdout | gbak -c … stdin banco30O gbak da versão 2.5 gera um backup em formato linear e o direciona para stdout, que é imediatamente capturado através de stdin pelo gbak da versão 3.0, criando um novo banco de dados.
Esse pipeline deve ser organizado utilizando o método de acesso local (de arquivos), pois o acesso de rede (mesmo através de localhost) diminuirá significativamente o processo.
Abaixo, examinamos os detalhes para Windows e Linux.
Windows
No caso do Windows, a maneira mais simples de fazer isso é criar uma montagem totalmente autônoma do Firebird. Para isso, pegamos , renomeamos fbembedded.dll para fbclient.dll, adicionamos do arquivo "normal" 2.5 as utilitários gbak.exe e (opcionalmente) – isql.exe.
O Firebird 3.0 utiliza e não requer nenhum ajuste.
A opção mais mínima (que não exige a instalação de bibliotecas de tempo de execução do VS2008/VS2010 no sistema alvo) 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.dllUm administrador experiente pode notar que na versão 2.5 não estão incluídos os arquivos intl/fbintl.dll e intl/fbintl.conf. Isso é verdade, pois o gbak não utiliza o charset da conexão e não converte dados entre charsets, mas do lado de 'recepção' do Firebird 3.0 esses arquivos são necessários para a criação de índices.
No firebird.conf, recomenda-se adicionar para o Firebird 3.0:
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1Além disso, é desejável configurar um valor diferente para IpcName para 2.5 e 3.0.
Ao escolher os valores de outros parâmetros no firebird.conf, partimos da simples consideração de que, no estágio de migração de dados, um processo utiliza o gbak 2.5, enquanto o outro utiliza o 3.0; em seguida, o 2.5 encerra sua execução e o 3.0 inicia a construção de índices.
Para acelerar o estágio de construção de índices no 3.0, recomenda-se aumentar o tamanho do parâmetro TempCacheLimit para cerca de 40% da RAM (se este for um servidor dedicado, claro).
Por exemplo, se o servidor tiver 16 GB de RAM, pode-se definir
TempCacheLimit=6GÉ claro que tal valor só pode ser definido no Firebird 3 de 64 bits, pois qualquer processo de 32 bits não conseguirá alocar mais de 2 gigabytes de memória.
No 2.5, não é necessário alterar esse parâmetro – ele já não pode ser superior a 2 gigabytes e, durante o backup, não afeta a velocidade.
Antes de executar a operação, é necessário verificar se o cache de páginas no cabeçalho do banco de dados está definido como 0 (comando gstat -h databasename, verifique a linha Page buffers).
Se o cache for definido explicitamente no cabeçalho do banco de dados, isso sobrescreve os valores do firebird.conf (e databases.conf no 3.0) e, caso os valores sejam inadequadamente altos, isso pode levar a um consumo excessivo de memória e swap.
Em seguida, copiamos os arquivos para o sistema de destino.
A conversão é realizada após a parada do serviço 'sistema' do Firebird 2.5, na linha de comando com privilégios elevados para administrador local (exemplo):
set ISC_USER=proprietário
"25/gbak" -z -b -g -v -st t -y 25.log banco25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin banco30Neste exemplo, é utilizada a 'barra inclinada direta' entre aspas (o 'estilo unix' permitido), enquanto o 'caret' (símbolo '^') escapa o símbolo de nova linha, o que é conveniente ao digitar comandos longos. A opção -st(atus) foi introduzida no Firebird 2.5.8 e permite registrar no log dados sobre o tempo de execução do processo gbak (detalhes – na documentação).
Linux
No Linux, o Firebird 3 depende da biblioteca tommath. No CentOS (RHEL), essa biblioteca está no repositório epel, enquanto no Ubuntu (Debian), ela está no sistema.
Para o CentOS, primeiro é necessário conectar-se ao repositório epel e depois executar
yum install libtommathNo Ubuntu, não é necessário conectar repositórios adicionais, mas no Ubuntu 16 e no Ubuntu 18, diferentes versões de pacotes são instaladas - libtommath0 e libtommath1, respectivamente.
O Firebird 3.0 procura por tommath.so.0 e, para o Ubuntu 18, é necessário criar um link simbólico (symlink) de tommath.so.0 para tommath.so.1. Para isso, primeiro é necessário encontrar tommath.so.1.
O caminho procurado no Ubuntu é /usr/lib/x86_64-linux-gnu/, mas em outras distribuições baseadas em Debian pode ser diferente.
O segundo problema está relacionado ao fato de que até o Firebird 3.0.1, inclusive, não havia uma maneira fácil de instalar duas versões diferentes do servidor. A opção "compilar a partir do código-fonte com o prefixo necessário" não é considerada devido à sua relativa complexidade.
Para o Firebird 3.0.2 e superior, foi implementada e uma opção separada do instalador (-path caminho).
Assumindo que a biblioteca tommath e, se necessário, o symlink para tommath.so.0 foram adicionados ao sistema, pode-se instalar a distribuição atual (no momento da redação deste artigo) do Firebird 3.0.4 em, por exemplo, /opt/fb3:
./install.sh -path /opt/fb3Depois disso, pode-se parar o serviço do sistema Firebird e iniciar a conversão contínua.
Ao parar o Firebird, é importante considerar que os processos do Firebird 2.5 em modo Classic geralmente são iniciados pelo xinetd - portanto, é necessário ou desativar o serviço firebird para o xinetd ou parar totalmente o xinetd.
No firebird.conf para 3.0 no Linux, não é necessário definir os parâmetros MaxUnflushed (eles funcionam apenas no Windows) e alterar as configurações do Firebird 2.5.
No Linux, o acesso local (baseado em arquivos) ao Firebird 2.5 não é equivalente à versão embutida do Windows - o servidor 2.5 funcionará no processo gbak (sem parte de rede), mas os direitos de acesso serão verificados com base no banco de usuários, ou seja, serão necessários não apenas o login, mas também a senha:
export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30Após a conversão bem-sucedida, é necessário remover primeiro o Firebird 3.0 "adicional", depois o Firebird 2.5 "principal" e só então executar uma instalação limpa do Firebird 2.5 - sendo preferível fazer isso a partir do instalador padrão tar.gz, e não através dos repositórios, já que a versão nos repositórios pode estar desatualizada.
Além disso, após restaurar o BD no Linux e reinstalar, deve-se verificar se o novo BD tem o usuário firebird como proprietário.
Se não for o caso, será necessário corrigir
chown firebird.firebird databaseResultado
Além da economia de tempo e espaço em disco, a conversão em tempo real possui outra vantagem importante – a transformação do banco de dados é feita sem a remoção do Firebird 2.5 existente, o que simplifica consideravelmente o retorno em caso de conversão malsucedida (geralmente devido à falta de espaço ou uma reinicialização inesperada durante o processo de migração).
A economia de tempo está relacionada ao fato de que a conversão "clássica" leva em conta o "tempo de backup" mais o "tempo de restauração". A restauração consiste em duas partes: ler dados do arquivo de backup e construir o índice.
Na conversão em tempo real, o tempo total é calculado como "tempo de backup mais cinco a dez por cento" e o "tempo de construção de índices".
Os resultados específicos dependem da estrutura do banco de dados, mas, em média, o tempo de restauração é aproximadamente o dobro do tempo de backup. Portanto, se considerarmos o tempo de backup como uma unidade, a "conversão clássica" leva três unidades de tempo, enquanto a conversão em tempo real leva duas unidades de tempo. Um aumento no TempCacheLimit também ajuda a reduzir o tempo adicionalmente.
No geral, a conversão em tempo real permite economizar entre 30% a 40% do tempo necessário para backups sequenciais e restaurações.
Dúvidas?
Por favor, envie todas as perguntas nos comentários ou entre em contato com o autor da metodologia e coautor deste artigo – Vasily Sidorov, engenheiro de sistemas sênior da empresa "iBase", pelo e-mail bs at ibase ru.
Apenas usuários registrados podem participar da pesquisa. , por favor.
Qual versão do Firebird você está usando?
Firebird 3.x
Firebird 2.5
Firebird 2.1
Firebird 2.0, 1.5 ou 1.0
16 usuários votaram. 1 usuário se absteve.
Fonte: habr.com
