Ajout Troubleshoting erreur could not map filenode to relation OID
This commit is contained in:
parent
c93df7994c
commit
7db614e36f
|
@ -282,4 +282,91 @@ ma_base=# DROP SUBSCRIPTION s_upgrade;
|
|||
|
||||
~~~
|
||||
# systemctl restart postgresql@13-prim.service
|
||||
~~~
|
||||
~~~
|
||||
|
||||
# Troubleshooting
|
||||
|
||||
## ERREUR: could not map filenode "base/\*/\*" to relation OID
|
||||
|
||||
Si une erreur dans la réplication logique du type :
|
||||
|
||||
~~~
|
||||
2022-08-29 10:12:57.380 CEST [12525] LOG: le processus apply de réplication logique pour la souscription « mysub_sql10 » a démarré
|
||||
|
||||
2022-08-29 10:12:57.628 CEST [12525] ERREUR: n'a pas pu recevoir des données du flux de WAL : ERREUR: could not map filenode "base/16385/107076665" to relation OID
|
||||
|
||||
2022-08-29 10:12:57.632 CEST [27621] LOG: processus en tâche de fond « logical replication worker » (PID 12525) a quitté avec le code de sortie 1
|
||||
~~~
|
||||
|
||||
Il est possible que ce soit un conflit d'**OID** soit de **relfilenode**
|
||||
|
||||
Il faut regarder l'OID et le relfilenode qui est mentionner dans l'erreur sur le secondaire et sur le primaire.
|
||||
|
||||
On peux listé les OID, le nom de la table (relname) et le relfilenode avec la requête suivante sur la base où l'on a créer la SUBSCRIPTION :
|
||||
|
||||
~~~sql
|
||||
bar2=# select oid,relname,relfilenode from pg_class;
|
||||
~~~
|
||||
|
||||
Exemple de sortie :
|
||||
|
||||
~~~sql
|
||||
bar2=# select oid,relname,relfilenode from pg_class;
|
||||
oid | relname | relfilenode
|
||||
---------+-----------------------------------------------------------------+-------------
|
||||
101181 | primary_keys | 0
|
||||
101186 | tables | 0
|
||||
101851 | dblink_pkey_results | 0
|
||||
101965 | tablefunc_crosstab_2 | 0
|
||||
101968 | tablefunc_crosstab_3 | 0
|
||||
101971 | tablefunc_crosstab_4 | 0
|
||||
101990 | pgstattuple_type | 0
|
||||
101993 | statenbjourmax | 0
|
||||
101996 | statinfo | 0
|
||||
101999 | tokenout | 0
|
||||
102002 | tokentype | 0
|
||||
102837 | bbk_contents | 102837
|
||||
102814 | aerien_contrat_to_gesto_periode_id_seq | 102814
|
||||
102828 | aerien_contrat_to_gesto_tarif_id_seq | 102828
|
||||
102819 | pg_toast_102815 | 102819
|
||||
102820 | pg_toast_102815_index | 102820
|
||||
102821 | aerien_contrat_to_gesto_saison_id_seq | 102821
|
||||
102864 | yalago_produit_chambre | 2976661
|
||||
102826 | pg_toast_102822 | 102826
|
||||
102827 | pg_toast_102822_index | 102827
|
||||
102815 | aerien_contrat_to_gesto_saison | 102815
|
||||
2619 | pg_statistic | 2619
|
||||
1247 | pg_type | 0
|
||||
102835 | pg_toast_102829 | 102835
|
||||
102836 | pg_toast_102829_index | 102836
|
||||
102829 | bbk_api_id_mapping_produit | 102829
|
||||
102841 | pg_toast_102837 | 102841
|
||||
102842 | pg_toast_102837_index | 102842
|
||||
102871 | all_exist_chambre | 0
|
||||
102880 | pg_toast_102876 | 102880
|
||||
114983 | zztemp_retro_except_alofvl1_pkey | 3031858
|
||||
111282 | zztemp_mise_a_jour_all_status_retro | 3031864
|
||||
111331 | zztemp_stock_except_gesto | 3031867
|
||||
111335 | pg_toast_111331 | 3031868
|
||||
102876 | bbk_reservation_hotel_externe | 102876
|
||||
102881 | pg_toast_102876_index | 102881
|
||||
|
||||
...
|
||||
~~~
|
||||
|
||||
Dans le message d'erreur que l'on a précédemment, il nous retournes l'OID et le relfilenode suivant :
|
||||
|
||||
~~~
|
||||
ERREUR: could not map filenode "base/16385/107076665" to relation OID
|
||||
~~~
|
||||
|
||||
Dans ce cas là, si on cherche le 107076665 dans la sortie de la requête *select oid,relname,relfilenode from pg_class;* on trouve le relfilenode de cette table, **sur le serveur primaire** :
|
||||
|
||||
~~~sql
|
||||
bar2=# select oid,relname,relfilenode from pg_class where relfilenode = '107076665';
|
||||
oid | relname | relfilenode
|
||||
---------+-----------------------------------------------------------------+-------------
|
||||
23135 | zztemp_stock_chambre | 107076665
|
||||
~~~
|
||||
|
||||
Une solution peut être de supprimer et recréer cette table sur le primaire, qui fait que ça réassigne un autre numéro de **relfilenode** a cette table, et ça peut débloquer la réplication sur le secondaire impacté.
|
Loading…
Reference in a new issue