ADVERTENCIA:Desajuste encontrado entre sl_table y pg_class. El comando Slonik REPAIR CONFIG puede ser útil para rectificar esto.
2014-04-26 07:32:54 PDT FATAL slon_node_health_check() devolvió falso:¡problema de salud fatal!
REPAIR CONFIG puede ser útil para rectificar este problema
Verá este mensaje de ADVERTENCIA en los registros y la detención inmediata de la replicación, si Slony ha observado una falta de coincidencia de pg_class.oid y sl_table.tabreloid de una tabla de replicación en un nodo. Porque, por arquitectura, slony mantiene toda la información OID de los objetos replicados en sus catálogos capturados en el momento de la configuración desde pg_class.oid.
¿En qué caso pg_class.oid !=sl_table.tabreloid ?
En la mayoría de los casos, un nodo movió su lugar usando pg_dump/pg_restore haciendo que los objetos OID cambiaran.
Para imitar el mensaje de ADVERTENCIA anterior, he usado la configuración de replicación de dos nodos entre dos bases de datos en el mismo clúster [5432] para algunas tablas. (Consulte aquí cómo configurar la replicación de Slony). Aquí está la información OID actual en el nodo esclavo (base de datos de demostración) para uno de los 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 almacenado en el catálogo slony en sl_table.tabreloid.(Slony schema _rf). Tome la copia de seguridad lógica y la restauración de la misma base de datos de demostración simplemente para cambiar el OID del objeto como se muestra a continuación:(Recuerde, el proceso Slon se detiene en este 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)
Ahora, pg_class.oid de 'dtest' ha cambiado a 26640, mientras que sl_table.tab_reloid aún refleja el antiguo OID 26119. En esta etapa, si comenzamos el proceso slon, esencialmente se detiene con un mensaje de ADVERTENCIA en caso de discrepancia de OID al ejecutar una consulta pg_class.oid =sl_table.tabreloid. Al devolver un resultado falso, no avanzará hasta que se solucione. También podemos llamar a la función slon_node_health_check() explícitamente para verificación:
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 arreglar esto de dos maneras.
- Uso de la utilidad de línea de comandos de Slonik con el script de preámbulo REPAIR CONFIG o
- Uso de la función de catálogo de Slony updatereloid() dentro de la terminal psql.
Método 1: Cree un script de preámbulo como se muestra a continuación y ejecútelo con el comando slonik. Estaría usando el segundo método, es solo como referencia.
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: Pase la identificación del conjunto de tablas y la información del nodo a una función:
demo=# select _rf.updatereloid(tab_set,2) from _rf.sl_table ;
updatereloid
--------------
1
1
1
(3 rows)
Genial, revisemos la información OID ahora en el nodo esclavo (base de datos de demostración) de pg_class y _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)
Después de la actualización, slony comenzará a sincronizarse sin problemas.
Gracias al equipo de Slony-I.
