WAARSCHUWING:Mismatch gevonden tussen sl_table en pg_class. Het Slonik-commando REPAIR CONFIG kan nuttig zijn om dit te verhelpen.
2014-04-26 07:32:54 PDT FATAL slon_node_health_check() heeft false geretourneerd - fataal gezondheidsprobleem!
REPAIR CONFIG kan nuttig zijn om dit probleem te verhelpen
U ziet dit WAARSCHUWINGsbericht in logboeken en onmiddellijke stopzetting van de replicatie, als Slony een niet-overeenstemming heeft waargenomen van pg_class.oid en sl_table.tabreloid van een replicatietabel in een knooppunt. Omdat slony volgens de architectuur alle OID-informatie van replicerende objecten in zijn catalogi bevat die tijdens de configuratie van pg_class.oid zijn vastgelegd.
In welk geval pg_class.oid !=sl_table.tabreloid ?
In de meeste gevallen heeft een knooppunt zijn plaats verplaatst met behulp van pg_dump/pg_restore door ervoor te zorgen dat de OID van objecten verandert.
Om het bovenstaande WAARSCHUWINGsbericht na te bootsen, heb ik twee knooppuntenreplicatie-instellingen gebruikt tussen twee databases op hetzelfde cluster [5432] voor enkele tabellen. (Zie hier hoe u Slony-replicatie instelt). Hier is de huidige OID-informatie over slave-knooppunt (demo-database) voor een van de objecten '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 opgeslagen in slony-catalogus in sl_table.tabreloid. (Slony-schema _rf). Neem de logische back-up en herstel van dezelfde demo-database om de object-OID te wijzigen, zoals hieronder:(Vergeet niet dat het Slon-proces op dit moment is gestopt)
-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)
Nu is pg_class.oid van 'dtest' gewijzigd in 26640, terwijl sl_table.tab_reloid nog steeds de oude OID 26119 weerspiegelt. Als we in dit stadium het slon-proces starten, stopt het in wezen met een WAARSCHUWING-bericht bij niet-overeenkomende OID door een query uit te voeren pg_class.oid =sl_table.tabreloid. Bij het retourneren van een vals resultaat zal het niet verder gaan totdat het is opgelost. We kunnen ook de functie slon_node_health_check() expliciet aanroepen voor verificatie:
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)
We kunnen dit op twee manieren oplossen.
- Slonik-opdrachtregelhulpprogramma gebruiken met preambulescript REPAIR CONFIG of
- De Slony-catalogusfunctie updatereloid() gebruiken in de psql-terminal.
Methode 1: Maak een preambule-script zoals hieronder en voer het uit met de opdracht slonik. Ik zou de tweede methode gebruiken, het is alleen ter referentie.
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
Methode 2: Geef de tabelset-id en knooppuntinformatie door aan een functie:
demo=# select _rf.updatereloid(tab_set,2) from _rf.sl_table ;
updatereloid
--------------
1
1
1
(3 rows)
Cool, laten we de OID-informatie nu controleren op slave-knooppunt (demo-database) van pg_class en _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)
Na de update begint slony zonder problemen te synchroniseren.
Met dank aan het Slony-I-team.