sql >> Databasteknik >  >> RDS >> PostgreSQL

"VARNING:Felmatchning hittades mellan sl_table och pg_class." i Slony-I

VARNING:Felmatchning hittades mellan sl_table och pg_class. Slonik-kommandot REPAIR CONFIG kan vara användbart för att rätta till detta.
2014-04-26 07:32:54 PDT FATAL slon_node_health_check() returnerade falskt – dödligt hälsoproblem!
REPAIR CONFIG kan vara till hjälp för att åtgärda detta problem

Du ser detta VARNING-meddelande i loggar och omedelbart stopp av replikering, om Slony har observerat en oöverensstämmelse mellan pg_class.oid och sl_table.tabreloid för en replikerande tabell i en nod. Eftersom slony av arkitektur håller alla replikerande objekt OID-information i sina kataloger fångad vid konfigureringstiden från pg_class.oid.

I vilket fall pg_class.oid !=sl_table.tabreloid ?

I de flesta fall flyttade en nod sin plats med pg_dump/pg_restore genom att få objektens OID att ändras.

För att efterlikna ovanstående VARNINGSmeddelande, har jag använt två noder replikeringsinställningar mellan två databaser på samma kluster[5432] för några tabeller. (Se här om hur du ställer in Slony-replikering). Här är den aktuella OID-informationen om slavnoden (demodatabas) för ett av objekten '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 lagrad i slony-katalogen i sl_table.tabreloid.(Slony-schema _rf). Ta den logiska säkerhetskopieringen och återställningen av samma demodatabas helt enkelt för att ändra objektets OID enligt nedan:(Kom ihåg att Slon-processen stoppas just nu)

-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 har pg_class.oid av 'dtest' ändrats till 26640 medan sl_table.tab_reloid fortfarande återspeglar det gamla OID 26119. I det här skedet, om vi startar slon-processen, slutar den i huvudsak med VARNING-meddelande om OID-felmatchning genom att köra en fråga pg_class.oid =sl_table.tabreloid. När ett falskt resultat returneras kommer det inte att gå vidare förrän det är fixat. Vi kan också anropa funktionen slon_node_health_check() uttryckligen för verifiering :

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)

Vi kan fixa detta på två sätt.

  1. Använda Slonik kommandoradsverktyg med preambelskriptet REPAIR CONFIG eller
  2. Använder Slony-katalogfunktionen updatereloid() i psql-terminalen.

Metod 1: Skapa inledningsskript enligt nedan och kör med slonik-kommandot. Jag skulle använda den andra metoden, det är bara för referens.

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

Metod 2: Skicka tabelluppsättnings-id och nodinformation till en funktion:

demo=# select _rf.updatereloid(tab_set,2) from _rf.sl_table ;   
updatereloid
--------------
1
1
1
(3 rows)

Coolt, låt oss kontrollera OID-informationen nu på slavnoden (demodatabas) från pg_class och _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)

Efter uppdateringen kommer slony att börja synkronisera utan några problem.
Tack till Slony-I-teamet.


  1. Django och postgresql-scheman

  2. PDO + MySQL och trasig UTF-8-kodning

  3. WordPress – Bakom kulisserna, del 1

  4. Bevisa SQL-fråga likvärdighet