Ressuscitar Replicação Assíncrona: O Desfibrilador do DBA

"Código Vermelho: A Replicação Parou!"

Às vezes, a vida de um DBA não é fácil. Uma queda de luz, um disco cheio ou um cabo de rede mastigado pelo gato pode fazer com que a replicação perca o compasso. Quando isso acontece, o replication.log começa a gritar e a sua réplica fica lá, parada no tempo, enquanto o mundo (o Publicador) continua girando.

Se as notas acumuladas ficaram confusas demais ou se o "delay" ficou maior que a paciência do seu chefe, é hora de aplicar o protocolo de Ressincronização Total. Pense nisso como um "reset" de fábrica para alinhar os dois servidores novamente.

AVISO DE EMERGÊNCIA: Este processo vai substituir a base de dados do Leitor por uma nova. Se você tinha dados lá que não estavam no Publicador (o que não deveria acontecer numa réplica), eles vão para o limbo dos dados esquecidos.

Protocolo de Ressuscitação (Passo a Passo)

Este processo é uma coreografia entre dois servidores. Siga a ordem rigorosamente, intercalando as ações entre o Publicador e o Leitor como descrito abaixo. Pular um passo aqui é como esquecer de ligar o oxigênio antes da cirurgia.

1. O Grande Botão de Pausa (No Leitor)

O primeiro passo é silenciar o servidor LEITOR (Linux). Não podemos trocar as rodas de um carro em movimento. Pare o serviço do Firebird:

sudo systemctl stop firebird

2. Desativando a Publicação (No Publicador)

Agora, conecte-se a cada um dos bancos de dados e desative a publicação via SQL:

-- Execute via isql ou sua ferramenta SQL favorita
      ALTER DATABASE DISABLE PUBLICATION;
      COMMIT;

Agora que desativamos a replicação no lado PUBLICADOR (Windows), pare o serviço no Windows (pelo CMD ou services.msc):

net stop FirebirdServerDefaultInstance

3. Limpando os Rastros (Clean Slate)

Apague todos os arquivos de journal e archive. Isso garante que a réplica não tente processar notas do "passado" que não batem com o novo banco que vamos copiar, então usando o Explorer ou o terminal no lado Publicador (Windows), execute a limpeza dessas pastas:

# No Windows (Publicador) - Limpe as subpastas de cada banco:
del /q c:\fdb-repl\journal\acme\*
del /q c:\fdb-repl\archive\acme\*
del /q c:\fdb-repl\journal\correios\*
del /q c:\fdb-repl\archive\correios\*

Só prossiga se as pastas indicadas acima estiverem vazias.

4. O Transplante (A Cópia "Fresquinha")

Para copiar os arquivos de dados do lado publicador para o lado leitor, a pasta c:\fdb do publicador deve estar compartilhada com o nome fdb para Administradores e também o usuário firebird cujas credenciais serão usadas para montar a unidade de rede no Linux.

Se você seguiu o artigo Configurando Replicação Assíncrona, você já deve ter um arquivo /etc/cifs-credentials.agente_firebird no lado leitor, vamos agora usá-lo para montar a unidade de rede do Windows temporariamente:

sudo mkdir -p /mnt/publicador
sudo mount -t cifs //IP_DO_WINDOWS/fdb /mnt/publicador -o credentials=/etc/cifs-credentials.agente_firebird,iocharset=utf8,vers=2.0,uid=firebird,gid=firebird,file_mode=0660,dir_mode=0770

Agora, realize a cópia dos novos arquivos "mestre":

cp /mnt/publicador/acme.fdb /var/fdb/acme.fdb
cp /mnt/publicador/correios.fdb /var/fdb/correios.fdb

Após a cópia, desmonte a unidade e ajuste o dono dos arquivos no Linux:

sudo umount /mnt/publicador
sudo chown -v firebird:firebird /var/fdb/*.fdb
sudo chmod -v 660 /var/fdb/*.fdb

5. Resetando o Coração (gfix)

Os bancos que foram copiados precisam ser marcados como réplica somente leitura. No lado Leitor (Linux), execute:

sudo /opt/firebird/bin/gfix -replica read_only /var/fdb/acme.fdb
sudo /opt/firebird/bin/gfix -replica read_only /var/fdb/correios.fdb

6. Choque de Vida (Religando Tudo)

Primeiro, inicie o serviço no PUBLICADOR (Windows), use o services.msc ou execute pelo cmd:

net start FirebirdServerDefaultInstance

Use uma ferramenta de acesso SQL (como IbExpert, FlameRobin ou isql) apenas no servidor Publicador. Conecte-se a cada um dos seus bancos de dados individualmente e execute estes comandos para despertar a replicação:

-- Execute para cada banco (ex: acme.fdb)
ALTER DATABASE ENABLE PUBLICATION;
ALTER DATABASE INCLUDE ALL TO PUBLICATION;
COMMIT;

Se precisar remover algumas tabelas da replicação, acrescente também o comando(exemplo):

ALTER DATABASE EXCLUDE TABLE PLG$PROF_SESSIONS, PLG$PROF_STATEMENTS, PLG$PROF_CURSORS, PLG$PROF_RECORD_SOURCES, PLG$PROF_REQUESTS, PLG$PROF_PSQL_STATS, PLG$PROF_RECORD_SOURCE_STATS FROM PUBLICATION;

7. Reiniciando os logs do lado leitor

No lado LEITOR (Linux), renomeie o arquivo de log atual e crie um novo:

sudo mv /opt/firebird/replication.log /opt/firebird/replication.log.$(date +%Y%m%d_%H%M%S)
sudo touch /opt/firebird/replication.log
sudo chown firebird:firebird /opt/firebird/replication.log

Quando o servidor do lado leitor for iniciado, nosso log estará vazio e com isso, qualquer erro de replicação será facilmente identificado.

8. Iniciando o lado leitor

No lado LEITOR (Linux), inicie o serviço do Firebird:

sudo systemctl start firebird

9. A Prova dos Nove (Verificação)

Como saber se a replicação está realmente funcionando? Vamos criar um rastro deliberado no lado do Publicador. Via qualquer programa de acesso a banco de dados, como FlameRobin ou IBExpert, execute:

CREATE TABLE TESTE_REPLICA (ID INT PRIMARY KEY);
COMMIT;

Este comando cria uma tabela chamada TESTE_REPLICA com uma coluna ID do tipo INT e define ela como a chave primária. Mas apenas a criação da tabela não é suficiente para que a replicação funcione. O Firebird precisa saber que essa tabela deve ser publicada na lista de replicação, então execute o seguinte comando SQL no banco do Publicador:

ALTER DATABASE INCLUDE TABLE TESTE_REPLICA TO PUBLICATION;

Feche o gerenciador de banco de dados, abra o Explorer e aponte-o para a pasta c:\fdb-repl\journal\acme e veja se surgem novos arquivos de journaling a medida que alterações são feitas no banco de dados. Notará que alguns deles, depois de 60 segundos vão sumindo, na realidade, estão sendo processados e seguindo para nossa área de expedição c:\fdb-repl\archive\acme que você também poderá observar usando o Explorer. Conseguindo enxergar essa movimentação de arquivos de lá para cá, você entenderá que o processo de replicação já está funcionando no lado PUBLICADOR.

Mas se você precisa de mais provas, poderá usar um gerenciador de banco de dados de sua preferência e conectá-lo a base acme no lado do Leitor e observar se a tabela TESTE_REPLICA apareceu por lá, se sim, parabéns: seu motor de replicação está em perfeito estado!

Mas e se não apareceu? Calma, vamos verificar o que está acontecendo. Execute no lado Leitor (Linux) o comando:

tail -f /opt/firebird/replication.log

Observe o log da replicação, pois mostrará o que está acontecendo.

Se mostrar algo como:

Database: /var/fdb/acme.fdb
VERBOSE: No new segments found, suspending

Significa que o Leitor não encontrou novos segmentos para processar, portanto ele suspende a operação e tentará novamente em 60 segundos. Falhas de manipulação de arquivos também aparecem no log. Se você tem a certeza que o banco do lado PUBLICADOR está sendo modificado, mas o LEITOR não está recebendo as modificações(No new segments found, suspending), então o problema provavelmente está no lado PUBLICADOR, que não está fazendo o journaling corretamente. No lado Publicador, verifique se o serviço do Firebird está rodando, se o usuário que está executando o serviço tem permissão de escrita na pasta de journaling e se o arquivo replication.conf está configurado corretamente. O arquivo c:\fb5\replication.log do lado PUBLICADOR deve conter mensagens de erro que indicarão o problema.

Lembre-se de que no replication.conf você configurou o parametro apply_idle_timeout que define o tempo de espera quando ocioso e o parametro apply_error_timeout que define o tempo de espera após um erro. Portanto, você deve aguardar o tempo configurado (em nosso exemplo, 60 segundos) para depois testar se a replicação está funcionando.

← Voltar para Firebird