18
0
Fork 0

Ajout Troubleshoting erreur could not map filenode to relation OID

This commit is contained in:
emorino 2022-08-30 14:56:26 +02:00
parent c93df7994c
commit 7db614e36f
1 changed files with 88 additions and 1 deletions

View File

@ -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é.