diff --git a/HowtoPostgreSQL/ReplicationLogique.md b/HowtoPostgreSQL/ReplicationLogique.md index ccc22b54..e44d92c0 100644 --- a/HowtoPostgreSQL/ReplicationLogique.md +++ b/HowtoPostgreSQL/ReplicationLogique.md @@ -282,4 +282,91 @@ ma_base=# DROP SUBSCRIPTION s_upgrade; ~~~ # systemctl restart postgresql@13-prim.service -~~~ \ No newline at end of file +~~~ + +# 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é. \ No newline at end of file