AVISO:Incompatibilidade encontrada entre sl_table e pg_class. O comando Slonik REPAIR CONFIG pode ser útil para corrigir isso.
2014-04-26 07:32:54 PDT FATAL slon_node_health_check() retornou falso – problema de saúde fatal!
REPAIR CONFIG pode ser útil para corrigir este problema
Você vê esta mensagem de AVISO nos logs e parada imediata da replicação, se o Slony tiver observado uma incompatibilidade de pg_class.oid e sl_table.tabreloid de uma tabela de replicação em um nó. Porque, pela arquitetura, o slony contém todas as informações de OID de objetos replicantes em seus catálogos capturadas no momento da configuração de pg_class.oid.
Em que caso pg_class.oid !=sl_table.tabreloid ?
Na maioria dos casos, um nó mudou de lugar usando pg_dump/pg_restore, fazendo com que o OID dos objetos mudasse.
Para imitar a mensagem de AVISO acima, usei a configuração de replicação de dois nós entre dois bancos de dados no mesmo cluster [5432] para algumas tabelas. (Consulte aqui como configurar a replicação Slony). Aqui estão as informações atuais do OID no nó escravo (banco de dados demo) para um dos objetos 'dtest':
demo=# select oid,relfilenode,relname from pg_class where relname='dtest';
oid | relfilenode | relname
-------+-------------+---------
26119 | 26119 | detest
(1 row)
demo=# select tab_id,tab_reloid,tab_relname from _rf.sl_table where tab_relname='dtest';
tab_id | tab_reloid | tab_relname
--------+------------+-------------
2 | 26119 | dtest
(1 row)
Ok, 'dtest' OID 26119 armazenado no catálogo slony em sl_table.tabreloid.(Slony schema _rf). Faça o backup lógico e a restauração do mesmo banco de dados de demonstração simplesmente para alterar o OID do objeto como abaixo:(Lembre-se, o processo Slon está parado neste momento)
-bash-4.1$ pg_dump -Fc -p 5432 -U postgres demo >/tmp/demo93.dmp
-bash-4.1$ psql -c "alter database demo rename to demo_bk;"
-bash-4.1$ psql -c "create database demo;"
-bash-4.1$ pg_restore -Fc -p 5432 -U postgres -d demo /tmp/demo93.dmp
-bash-4.1$ psql -c "select oid,relfilenode,relname from pg_class where relname='dtest';"
oid | relfilenode | relname
-------+-------------+---------
26640 | 26640 | dtest
(1 row)
-bash-4.1$ psql -c "select tab_id,tab_reloid,tab_relname from _rf.sl_table where tab_relname='dtest';"
tab_id | tab_reloid | tab_relname
--------+------------+-------------
2 | 26119 | dtest
(1 row)
Agora, pg_class.oid de 'dtest' mudou para 26640 enquanto sl_table.tab_reloid ainda reflete o antigo OID 26119. Neste estágio, se iniciarmos o processo slon, ele essencialmente para com uma mensagem de AVISO na incompatibilidade de OID executando uma consulta pg_class.oid =sl_table.tabreloid. Ao retornar um resultado falso, ele não avançará até que seja corrigido. Também podemos chamar a função slon_node_health_check() explicitamente para verificação:
demo=# select _rf.slon_node_health_check();
WARNING: table [id,nsp,name]=[1,a,public] - sl_table does not match pg_class/pg_namespace
WARNING: table [id,nsp,name]=[2,dtest,public] - sl_table does not match pg_class/pg_namespace
WARNING: table [id,nsp,name]=[3,movepage,public] - sl_table does not match pg_class/pg_namespace
WARNING: Mismatch found between sl_table and pg_class. Slonik command REPAIR CONFIG may be useful to rectify this.
slon_node_health_check
------------------------
f
(1 row)
Podemos corrigir isso de duas maneiras.
- Usando o utilitário de linha de comando Slonik com script de preâmbulo REPAIR CONFIG ou
- Usando a função de catálogo Slony updatereloid() no terminal psql.
Método 1: Crie o script de preâmbulo como abaixo e execute com o comando slonik. Eu estaria usando o segundo método, é apenas para referência.
demo=# o /tmp/repair_conf.slonik
demo=# select 'REPAIR CONFIG ( SET ID = '||set_id||', EVENT NODE = 1 );' FROM _rf.sl_set;
demo=# o
Add nodes information at the beginning of the file "/tmp/repair_conf.slonik"
cluster name = rf;
node 1 admin conninfo = 'host=localhost dbname=postgres user=postgres port=5432 password=postgres';
node 2 admin conninfo = 'host=localhost dbname=demo user=postgres port=5432 password=postgres';
REPAIR CONFIG ( SET ID = 1, EVENT NODE = 2 );
REPAIR CONFIG ( SET ID = 2, EVENT NODE = 2 );
REPAIR CONFIG ( SET ID = 3, EVENT NODE = 2 );
-bash-4.1$ slonik /tmp/repair_conf.slonik
Método 2: Passe o ID do conjunto de tabelas e as informações do nó para uma função:
demo=# select _rf.updatereloid(tab_set,2) from _rf.sl_table ;
updatereloid
--------------
1
1
1
(3 rows)
Legal, vamos verificar as informações de OID agora no nó escravo (banco de dados de demonstração) de pg_class e _slonycatalog.sl_table
-bash-4.1$ psql -d demo -c "select oid,relfilenode,relname from pg_class where relname='dtest';"
oid | relfilenode | relname
-------+-------------+---------
26119 | 26119 | dtest
(1 row)
-bash-4.1$ psql -d demo -c "select tab_id,tab_reloid,tab_relname from _rf.sl_table where tab_relname='dtest';"
tab_id | tab_reloid | tab_relname
--------+------------+-------------
2 | 26119 | dtest
(1 row)
Após a atualização, o slony começará a sincronizar sem problemas.
Graças à equipe Slony-I.
