sql >> Database teknologi >  >> RDS >> PostgreSQL

"ADVARSEL:Uoverensstemmelse fundet mellem sl_table og pg_class." i Slony-I

ADVARSEL:Uoverensstemmelse fundet mellem sl_table og pg_class. Slonik-kommandoen REPAIR CONFIG kan være nyttig til at rette op på dette.
2014-04-26 07:32:54 PDT FATAL slon_node_health_check() returnerede falsk – fatalt sundhedsproblem!
REPAIR CONFIG kan være nyttigt til at rette op på dette problem

Du ser denne ADVARSEL-meddelelse i logfiler og øjeblikkeligt stop af replikering, hvis Slony har observeret en uoverensstemmelse mellem pg_class.oid og sl_table.tabreloid i en replikerende tabel i en node. Fordi slony af arkitektur holder alle replikerende objekter OID-oplysninger i sine kataloger, som er fanget på konfigureringstidspunktet fra pg_class.oid.

I hvilket tilfælde pg_class.oid !=sl_table.tabreloid ?

I de fleste tilfælde flyttede en node sin plads ved hjælp af pg_dump/pg_restore ved at få objekters OID til at ændre sig.

For at efterligne ovenstående ADVARSEL-meddelelse har jeg brugt to noder replikeringsopsætning mellem to databaser på samme klynge[5432] til få tabeller. (Se her, hvordan du opsætter Slony-replikering). Her er den aktuelle OID information om slave node (demo database) for et af objekterne '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 gemt i slony katalog i sl_table.tabreloid.(Slony schema _rf). Tag den logiske sikkerhedskopiering og gendannelse af samme demodatabase for blot at ændre objektets OID som nedenfor:(Husk, Slon-processen er stoppet i dette øjeblik)

-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 er pg_class.oid af 'dtest' ændret til 26640, hvorimod sl_table.tab_reloid stadig afspejler den gamle OID 26119. På dette stadium, hvis vi starter slon-processen, stopper den i det væsentlige med ADVARSEL-meddelelse om uoverensstemmelse mellem OID ved at køre en forespørgsel pg_class.oid =sl_table.tabreloid. Ved at returnere et falsk resultat vil det ikke komme videre, før det er rettet. Vi kan også kalde funktionen slon_node_health_check() eksplicit for verifikation:

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 løse dette på to måder.

  1. Brug af Slonik kommandolinjeværktøj med præamble script REPAIR CONFIG eller
  2. Brug af Slony-katalogfunktionen updatereloid() i psql-terminalen.

Metode 1: Opret præamble script som nedenfor og udfør med slonik kommando. Jeg ville bruge den anden metode, det er kun til reference.

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

Metode 2: Send table-set id og node information til en funktion:

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

Cool, lad os tjekke OID-oplysningerne nu på slaveknude (demodatabase) fra pg_class og _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 opdateringen begynder slony at synkronisere uden problemer.
Tak til Slony-I-teamet.


  1. 8 måder at tilføje mikrosekunder til en Datetime-værdi i MariaDB

  2. MySQL LIMIT-klausul svarer til SQL SERVER

  3. Hvorfor er usigneret heltal ikke tilgængelig i PostgreSQL?

  4. Hvordan laver man en sikkerhedskopi af en enkelt tabel i en postgres-database?