„OSTRZEŻENIE:znaleziono niezgodność między sl_table a pg

OSTRZEŻENIE:Znaleziono niezgodność między sl_table i pg_class. Polecenie Slonik KONFIG NAPRAW może być przydatne do naprawienia tego.
2014-04-26 07:32:54 PDT KRYTYCZNY slon_node_health_check() zwrócił false – fatalny problem zdrowotny!
KONFIG NAPRAW może być pomocny w naprawie tego problemu

Widzisz ten komunikat ostrzegawczy w dziennikach i natychmiastowe zatrzymanie replikacji, jeśli Slony zaobserwował niezgodność pg_class.oid i sl_table.tabreloid z replikującej się tabeli w węźle. Ponieważ przez architekturę slony przechowuje wszystkie informacje OID obiektów replikujących się w swoich katalogach przechwycone w czasie konfiguracji z pg_class.oid.

W jakim przypadku pg_class.oid !=sl_table.tabreloid ?

W większości przypadków węzeł przeniósł swoje miejsce za pomocą pg_dump/pg_restore, powodując zmianę OID obiektów.

Aby naśladować powyższy komunikat ostrzegawczy, użyłem konfiguracji replikacji dwóch węzłów między dwiema bazami danych w tym samym klastrze [5432] dla kilku tabel. (Zapoznaj się tutaj, jak skonfigurować replikację Slony). Oto aktualne informacje OID w węźle podrzędnym (baza danych demo) dla jednego z obiektów „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 przechowywany w katalogu slony w sl_table.tabreloid.(Slony schema _rf). Wykonaj logiczną kopię zapasową i przywróć tę samą bazę danych demonstracyjnych, aby zmienić OID obiektu, jak poniżej:(Pamiętaj, że proces Slon jest w tym momencie zatrzymany)

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

Teraz pg_class.oid z 'dtest' zmienił się na 26640, podczas gdy sl_table.tab_reloid nadal odzwierciedla stary OID 26119. Na tym etapie, jeśli zaczniemy proces slon, zasadniczo zatrzymuje się komunikatem OSTRZEŻENIE o niezgodności OID, uruchamiając zapytanie pg_class.oid =sl_table.tabreloid. Po zwróceniu fałszywego wyniku nie ruszy do przodu, dopóki nie zostanie naprawiony. Możemy również wywołać funkcję slon_node_health_check() jawnie w celu weryfikacji :

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)

Możemy to naprawić na dwa sposoby.

Korzystanie z narzędzia wiersza poleceń Slonik ze skryptem preambuły REPAIR CONFIG lub
Używanie funkcji katalogu Slony updatereloid() w terminalu psql.

Metoda 1: Utwórz skrypt preambuły jak poniżej i wykonaj poleceniem slonik. Używałbym drugiej metody, to tylko w celach informacyjnych.

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: Przekaż identyfikator zestawu tabel i informacje o węźle do funkcji:

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

Super, sprawdźmy teraz informacje OID w węźle podrzędnym (baza danych demo) z pg_class i _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 aktualizacji slony rozpocznie synchronizację bez żadnych problemów.
Dzięki zespołowi Slony-I.

„OSTRZEŻENIE:znaleziono niezgodność między sl_table a pg_class”. w Słonym-I