„ВНИМАНИЕ:Намерено несъответствие между sl_table и pg

ПРЕДУПРЕЖДЕНИЕ:Открито несъответствие между sl_table и pg_class. Командата на Slonik REPAIR CONFIG може да бъде полезна за коригиране на това.
2014-04-26 07:32:54 PDT FATAL slon_node_health_check() върна false – фатален здравословен проблем!
REPAIR CONFIG може да бъде полезен за отстраняване на този проблем

Виждате това ПРЕДУПРЕЖДЕНИЕ съобщение в регистрационните файлове и незабавно спиране на репликацията, ако Slony е забелязал несъответствие на pg_class.oid и sl_table.tabreloid на реплицираща таблица в възел. Тъй като по архитектура slony държи цялата информация за OID на реплицирани обекти в своите каталози, заснета по време на конфигуриране от pg_class.oid.

В какъв случай pg_class.oid !=sl_table.tabreloid?

В повечето случаи възелът премества мястото си с помощта на pg_dump/pg_restore, като предизвиква промяна на OID на обектите.

За да имитирам горното ПРЕДУПРЕЖДЕНИЕ, използвах настройка за репликация на два възела между две бази данни в един и същ клъстер[5432] за няколко таблици. (Вижте тук как да настроите Slony репликация). Ето текущата информация за OID на подчинен възел (демо база данни) за един от обектите „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)

Добре, „dtest“ OID 26119 се съхранява в slony каталог в sl_table.tabreloid. (Slony schema _rf). Вземете логическото архивиране и възстановяване на същата демонстрационна база данни, просто за да промените OID на обекта, както е по-долу:(Не забравяйте, процесът Slon е спрян в този момент)

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

Сега pg_class.oid от 'dtest' се промени на 26640, докато sl_table.tab_reloid все още отразява стария OID 26119. На този етап, ако започнем slon процес, той по същество спира с ПРЕДУПРЕЖДЕНИЕ съобщение при несъответствие на OID чрез изпълнение на заявка pg_class.oid =sl_table.tabreloid. При връщане на фалшив резултат няма да се движи напред, докато не бъде фиксиран. Можем също да извикаме функцията slon_node_health_check() изрично за проверка:

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)

Можем да поправим това по два начина.

Използване на помощната програма на командния ред Slonik със скрипт на преамбюла REPAIR CONFIG или
Използване на функцията за каталог на Slony updatereloid() в psql терминал.

Метод 1: Създайте скрипт за преамбюла, както е по-долу и го изпълнете с командата slonik. Бих използвал втория метод, той е само за справка.

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

Метод 2: Предайте идентификатора на набора от таблица и информацията за възел на функция:

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

Чудесно, нека проверим информацията за OID сега на подчинен възел (демо база данни) от pg_class и _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)

След актуализацията, slony ще започне да се синхронизира без проблеми.
Благодаря на екипа на Slony-I.

„ВНИМАНИЕ:Намерено несъответствие между sl_table и pg_class.“ в Слони-I