Quels sont les postgresql utilisés ? Ce sont ceux de CentOS des deux côtés ?? Et des canaux/dépôts par défaut ? Sur chaque système (7 & 8) on peut installer différentes versions (celle de base, celle via des canaux particuliers centos, voir des canaux externes, ou bien une compilation). Connaitre les versions est un élément important pour une aide éventuelle.
PostgreSQL vient des dépôts PostgreSQL et non ceux de CentOS.
Les versions :
- serveur : PostgreSQL 10.11 sur CentOS 7.6
- client quand on est sur CentOS 7 : PostgreSQL 10.11 sur CentOS 7.6
- client quand on est sur CentOS 8 : PostgreSQL 10.11 sur CentOS 8.1 puis on a mis à jour en PostgreSQL 10.12 pour essayer (depuis la 10.13 est sortie mais nous n'avons pas essayé)
Avez vous décomposé les phases du scripts pour les faire une à une à la main ? C'est long, OK, mais cela permet de mettre de côté ce script lui même et d'avoir une présomption supplémentaire sur le périmètre exact à l'origine du problème. A moins qu'aucun problème ne surgisse lors de l'exécution à la main des phases essentielles, alors là, il faudra voir le script, mais c'est à priori peu probable, cependant mérite de transformer le peu probable en certitude.
Oui des tests manuels ont été réalisés et nous ont permis d'écarter la piste du script Python : nous avons testé le pg_restore sans les fameux scripts SQL et le problème est le même.
En gros, quand on test un scénario, on se mets dans une boucle de minimum 4 itérations et on lance les pg_restore.
A quel moment exact cela "time out" ? Une durée n'est pas suffisante, il faudrait préciser si cela se produit toujours à la même étape, et quelle est cette étape. Si c'est toujours à la même étape, alors le point précédent peut se concentrer là dessus uniquement.
C'est toujours sur la même table mais les valeurs du "TOC" (Error from TOC entry 31721; 2606 45850 FK CONSTRAINT mytable1 key_1 myowner) que j'ai donné sont pas forcément les même : on est plus ou moins loin dans la table.
Le truc c'est qu'on est toujours plus ou moins au même endroit du restore après un même temps d'exécution car nous avons globalement des performances constantes.
Enfin, toutes les opérations réussissent à tout les coups lorsque le pare-feu de centos8 est désactivé ? Ce point n'est pas bien clair or il semble primordial, car si c'est le cas, les précédents points sont inutiles : il faut se concentrer sur ça et éventuellement le pg_hba. à priori je ne pense pas, car sinon il n'y aurait pas ce long texte, mais n'étant pas sûr d'avoir bien compris ce point je préfère demander
C'est bien ça : avec le pare-feu désactivé, tout est ok.
Niveau pare-feu nous avons essayé :
- en conservant notre iptables historique (ça limitait nos changements déjà au combien nombreux pour ce projet)
- en utilisant le frontend firewalld
- en utilisant le frontend nft
-> même soucis : si un pare-feu est activé sur le CLIENT CentOS 8, alors le pg_restore échoue.
[^] # Re: idées ?
Posté par kortex . En réponse au message CentOS 8 - Problème difficile à dépanner - probablement au niveau du réseau. Évalué à 3.
PostgreSQL vient des dépôts PostgreSQL et non ceux de CentOS.
Les versions :
- serveur : PostgreSQL 10.11 sur CentOS 7.6
- client quand on est sur CentOS 7 : PostgreSQL 10.11 sur CentOS 7.6
- client quand on est sur CentOS 8 : PostgreSQL 10.11 sur CentOS 8.1 puis on a mis à jour en PostgreSQL 10.12 pour essayer (depuis la 10.13 est sortie mais nous n'avons pas essayé)
Oui des tests manuels ont été réalisés et nous ont permis d'écarter la piste du script Python : nous avons testé le pg_restore sans les fameux scripts SQL et le problème est le même.
En gros, quand on test un scénario, on se mets dans une boucle de minimum 4 itérations et on lance les pg_restore.
C'est toujours sur la même table mais les valeurs du "TOC" (Error from TOC entry 31721; 2606 45850 FK CONSTRAINT mytable1 key_1 myowner) que j'ai donné sont pas forcément les même : on est plus ou moins loin dans la table.
Le truc c'est qu'on est toujours plus ou moins au même endroit du restore après un même temps d'exécution car nous avons globalement des performances constantes.
C'est bien ça : avec le pare-feu désactivé, tout est ok.
Niveau pare-feu nous avons essayé :
- en conservant notre iptables historique (ça limitait nos changements déjà au combien nombreux pour ce projet)
- en utilisant le frontend firewalld
- en utilisant le frontend nft
-> même soucis : si un pare-feu est activé sur le CLIENT CentOS 8, alors le pg_restore échoue.