"VAROVÁNÍ:Byla zjištěna neshoda mezi sl_table a pg

VAROVÁNÍ:Byla zjištěna neshoda mezi sl_table a pg_class. K nápravě může být užitečný příkaz Slonik REPAIR CONFIG.
2014-04-26 07:32:54 PDT FATAL slon_node_health_check() vrátilo hodnotu false – fatální zdravotní problém!
REPAIR CONFIG může pomoci tento problém napravit

Pokud Slony zpozoroval nesoulad pg_class.oid a sl_table.tabreloid replikující se tabulky v uzlu, uvidíte tuto VAROVÁNÍ v protokolech a okamžitě zastavíte replikaci. Protože podle architektury má slony všechny replikující se objekty OID informace ve svých katalozích zachycené v čase konfigurace z pg_class.oid.

V jakém případě pg_class.oid !=sl_table.tabreloid ?

Ve většině případů se uzel přesunul na své místo pomocí pg_dump/pg_restore tím, že způsobil změnu OID objektů.

K napodobení výše uvedené VAROVÁNÍ jsem použil nastavení replikace dvou uzlů mezi dvěma databázemi ve stejném clusteru[5432] pro několik tabulek. (Zde se dozvíte, jak nastavit replikaci Slony). Zde jsou aktuální informace OID na slave uzlu (demodatabáze) pro jeden z objektů „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)

Dobře, ‚dtest‘ OID 26119 uloženo v katalogu slony v sl_table.tabreloid. (schema Slony _rf). Proveďte logické zálohování a obnovení stejné demo databáze jednoduše pro změnu OID objektu, jak je uvedeno níže:(Pamatujte si, že proces Slon je v tuto chvíli zastaven)

-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)

Nyní se pg_class.oid z 'dtest' změnil na 26640, zatímco sl_table.tab_reloid stále odráží staré OID 26119. V této fázi, pokud spustíme proces slon, se v podstatě zastaví se zprávou VAROVÁNÍ o neshodě OID spuštěním dotazu pg_class.oid =sl_table.tabreloid. Po vrácení falešného výsledku se nepohne vpřed, dokud nebude opraven. Můžeme také zavolat funkci slon_node_health_check() explicitně pro ověření:

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)

Můžeme to opravit dvěma způsoby.

Použití nástroje příkazového řádku Slonik se skriptem preambule REPAIR CONFIG nebo
Použití funkce katalogu Slony updatereloid() v terminálu psql.

Metoda 1: Vytvořte skript preambule, jak je uvedeno níže, a proveďte jej příkazem slonik. Použil bych druhou metodu, je to jen pro informaci.

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

Metoda 2: Předejte ID tabulky a informace o uzlu funkci:

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

Skvělé, pojďme nyní zkontrolovat informace OID na slave uzlu (demodatabáze) z pg_class a _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)

Po aktualizaci se slony začnou bez problémů synchronizovat.
Děkujeme týmu Slony-I.

"VAROVÁNÍ:Byla zjištěna neshoda mezi sl_table a pg_class." v Slony-I