ATTENZIONE:trovata mancata corrispondenza tra sl_table e pg_class. Il comando Slonik REPAIR CONFIG può essere utile per correggere questo problema.
2014-04-26 07:32:54 PDT FATAL slon_node_health_check() ha restituito false – problema di salute fatale!
REPAIR CONFIG può essere utile per correggere questo problema
Viene visualizzato questo messaggio di AVVISO nei registri e l'arresto immediato della replica, se Slony ha osservato una mancata corrispondenza di pg_class.oid e sl_table.tabreloid di una tabella di replica in un nodo. Perché, per architettura, slony conserva tutte le informazioni OID degli oggetti replicati nei suoi cataloghi catturati in fase di configurazione da pg_class.oid.
In tal caso pg_class.oid !=sl_table.tabreloid ?
Nella maggior parte dei casi, un nodo ha spostato la sua posizione utilizzando pg_dump/pg_restore causando la modifica dell'OID degli oggetti.
Per imitare il messaggio di AVVISO sopra, ho utilizzato la configurazione della replica di due nodi tra due database sullo stesso cluster[5432] per alcune tabelle. (Fare riferimento qui su come impostare la replica Slony). Ecco le informazioni OID attuali sul nodo slave (database demo) per uno degli oggetti '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 memorizzato nel catalogo slony in sl_table.tabreloid.(Slony schema _rf). Esegui il backup logico e il ripristino dello stesso database demo semplicemente per modificare l'OID dell'oggetto come di seguito:(Ricorda, il processo Slon è interrotto in questo 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)
Ora, pg_class.oid di 'dtest' è cambiato in 26640 mentre sl_table.tab_reloid riflette ancora il vecchio OID 26119. A questo punto, se avviamo il processo slon, essenzialmente si interrompe con il messaggio di AVVISO in caso di mancata corrispondenza di OID eseguendo una query pg_class.oid =sl_table.tabreloid. Alla restituzione di un risultato falso, non andrà avanti fino a quando non verrà risolto. Possiamo anche chiamare esplicitamente la funzione slon_node_health_check() per la verifica :
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)
Possiamo risolvere il problema in due modi.
- Utilizzo dell'utilità della riga di comando Slonik con lo script di preambolo REPAIR CONFIG o
- Utilizzo della funzione di catalogo Slony updatereloid() all'interno del terminale psql.
Metodo 1: Crea uno script di preambolo come di seguito ed esegui con il comando slonik. Userei il secondo metodo, è solo per riferimento.
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
Metodo 2: Passa l'ID del set di tabelle e le informazioni sul nodo a una funzione:
demo=# select _rf.updatereloid(tab_set,2) from _rf.sl_table ;
updatereloid
--------------
1
1
1
(3 rows)
Fantastico, controlliamo ora le informazioni OID sul nodo slave (database demo) da 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)
Dopo l'aggiornamento, slony inizierà a sincronizzarsi senza problemi.
Grazie al team Slony-I.
