Vous n'êtes pas identifié(e).
Après arrêt du postgresql sur les 5 serveurs abonnés ; j'ai retenté un start et stop.
Les logs ont disparus au moment du stop Fast.
2021-10-29 20:39:04.611 GMT [23722] LOG: processus en tâche de fond « logical replication launcher » (PID 23832) quitte avec le code de sortie 1
2021-10-29 20:39:04.613 GMT [23827] LOG: arrêt en cours
Hors ligne
Donc, je suppose que je dois trouver un paramètre pour dire aux serveurs abonnés de lâcher l'affaire quand le serveur de réplication s'arrête.
Hors ligne
En effet. Il serait donc intéressant de faire le test que j'ai indiqué plus haut, à savoir arrêter les cinq serveurs, puis arrêter le serveur publieur. Juste pour voir s'il s'arrête rapidement quand les 5 autres serveurs ne sont plus là.
Guillaume.
Hors ligne
OK, j'ai loupé les deux messages précédents. Ne pas prendre en compte mon dernier message.
Quant à un paramètre, j'ai cherché un peu mais je n'ai rien trouvé. Ou alors peut être dans l'ordre de création de la souscription ?
Guillaume.
Hors ligne
Merci Guillaume, je vais chercher aussi un peu. Il y a forcement une solution.
Hors ligne
J'ai mis en place une réplication entre deux serveurs de version 11. Une publication, une souscription. Et l'arrêt fast fonctionne immédiatement. Pour infos, il tente la reconnexion toutes les cinq secondes. Donc rien de méchant.
Combien avez-vous de souscriptions ?
Guillaume.
Hors ligne
Il y a 53 tables publiées sur le maitre (1 maître).
Et sur chaque serveur slave, il y a 53 souscriptions (les 53 tables).
Et 5 serveurs slaves.
Hors ligne
Les 5 serveurs slaves sont connectés au Master via un réseau IP MLS (Mélange de radio et fibre optique). géré par l'opérateur.
Hors ligne
temps de latence à cette heure :
PING 192.168.94.100 (192.168.94.100) 56(84) bytes of data.
64 bytes from 192.168.94.100: icmp_seq=1 ttl=61 time=26.7 ms
64 bytes from 192.168.94.100: icmp_seq=2 ttl=61 time=21.7 ms
64 bytes from 192.168.94.100: icmp_seq=3 ttl=61 time=25.9 ms
Hors ligne
Je suis en réplication logique. au niveau table.
Hors ligne
En fonction des tables, je gère les inserts, update, et certaines tables le delete.
Mais à cette heure y a pas d'activité sur les BDD.
Donc, c'est sûrement, un souci de connexion intempestive. Enfin, c'est une supposition...
Hors ligne
Je viens de démarrer un seul serveur, et ca recommence lors de l'arrêt du publieur :
2021-10-29 21:19:11.694 GMT [4413] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 21:19:11.694 GMT [4414] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 21:19:11.699 GMT [4402] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 21:19:11.717 GMT [4418] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 21:19:11.732 GMT [4407] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 21:19:11.732 GMT [4419] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 21:19:11.732 GMT [4420] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 21:19:11.733 GMT [4421] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 21:19:11.737 GMT [4405] logrepli@ppv FATAL: le système de base de données s'arrête
Hors ligne
C'est étonnant d'avoir fait une souscription par table. Pourquoi n'avez vous pas faire une souscription pour toutes les tables ? parce que chaque souscription va demander au minimum une connexion, donc 53 connexions pour un serveur, mais 260 et qq connexions pour les 5. C'est énorme et je ne comprends pas pourquoi vous faites ça.
Mais en soit, je ne pense pas que ce soit le problème. Le seul paramètre qui me semble avoir un lien avec votre souci est wal_retrieve_retry_interval. Quel est sa valeur ? (par défaut, c'est 5 secondes).
Guillaume.
Hors ligne
Je viens de faire un test rapide avec wal_retrieve_retry_interval à 1 ms (valeur totalement stupide, mais c'est un test). Et je reproduis exactement votre problème. Bref, regardez sa valeur, ça pourrait être intéressant.
Guillaume.
Hors ligne
Merci. Je vais tester. La raison est simple :
Le serveur Maître possède des tables communes (tarifs, clients etc...).
Les serveurs slaves n'ont pas les droits de modifier ces tables.
Donc, en gros, le Boss met à jour les tables communes au siège (exemple :un tarif qui change).
ET les slaves eux, se contentent de facturer sans pouvoir toucher aux prix.
Le Boss, lui facture les très gros clients sur son instance. Les filiales facturent les moyens et petits clients.
C'est un résumé, il y a bcp de table communes (client, sociétés, villes, prix, etc...)
Hors ligne
Ça, c'est une explication sur le "pourquoi la réplication". Pas sur le "pourquoi autant de souscriptions". En tout cas, avec autant de souscriptions, je vous prédis des problèmes de performances très très rapidement.
Guillaume.
Hors ligne
je teste dès que le serveur a cesser de logguer. Promis, je ferai un retour. Merci énormément pour les conseils prodigués.
Hors ligne
Guillaume ? c'est possible de grouper plusieurs table dans une souscription ?
Je peux pas faire sur toutes. Car l'instance maître facture de son côté, donc par exemple : la table purchase ne doit pas être synchronisée vers les slaves.
En revanche, s'il est possible de grouper les tables, je vais regarder de près.
Dernière modification par OlivierMans (29/10/2021 23:32:32)
Hors ligne
en fait, j'ai fait une publication par table, donc, une souscription par table. Peux-être que ma logique n'est pas la bonne.
Hors ligne
https://www.postgresql.org/docs/11/sql- … ation.html
Ah oui, il semble y avoir "FOR TABLE"
Hors ligne
Oui, c'est possible. Vous indiquez la liste de tables en les séparant par une virgule :
CREATE PUBLICATION mypublication FOR TABLE users, departments;Vous pouvez même les ajouter après :
ALTER PUBLICATION mypublication ADD TABLE users, departments;Je pense que, suivant les options que vous souhaitez, vous pouvez ne créer que quelques souscriptions. Ce sera beaucoup plus simple à administrer, et bien plus performant.
Guillaume.
Hors ligne
Bon, je vais m'occuper un peu des enfants, à très bientôt. Je vais revoir effectivement les publications et donc les souscriptions.
Je laisse ouvert le post, pour mettre à jour dès demain matin.
Hors ligne
Oui, en effet, ça se joue au niveau de la publication.
Bon, sur ce, moi, je vais me coucher, il se fait tard 
Bonne continuation, je regarderais demain ce que ça a donné.
Guillaume.
Hors ligne
Bonjour,
1ère étape.
J'ai supprimé toutes les souscriptions et toutes les publications sur maître et slaves.
A la place des 53 publications (une par table), j'ai créé 2 publications (PUB_IU et PUB_IUD).
J'ai fait une publication pour les tables en (Insert, Update) et une Publication pour les tables en (Insert, Update, Delete).
Déjà, le résultat du ps-ef :
root@lin01:~# ps -ef |grep postgres
postgres 4530 30279 0 08:06 ? 00:00:00 postgres: 11/main: postgres postgres 192.168.0.1(61591) idle
postgres 4532 30279 0 08:06 ? 00:00:04 postgres: 11/main: postgres ppv 192.168.0.1(62550) idle
postgres 12804 30279 0 09:08 ? 00:00:20 postgres: 11/main: postgres ppv 192.168.0.1(65167) idle
postgres 12872 30279 0 09:09 ? 00:00:00 postgres: 11/main: postgres postgres 192.168.0.1(49685) idle
postgres 15134 30279 0 09:27 ? 00:00:00 postgres: 11/main: postgres ppv 192.168.0.1(60806) idle
postgres 17775 30279 0 09:46 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.94.100(37490) idle
postgres 17788 30279 0 09:46 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.94.100(37496) idle
postgres 18192 30279 0 09:48 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.92.100(51666) idle
postgres 18199 30279 0 09:49 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.92.100(51670) idle
postgres 18357 30279 0 09:50 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.0.100(35172) idle
postgres 18363 30279 0 09:50 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.0.100(35176) idle
postgres 18405 30279 0 09:51 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.91.100(45268) idle
postgres 18416 30279 0 09:51 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.91.100(45292) idle
postgres 18464 30279 0 09:52 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.93.100(41762) idle
postgres 18600 30279 0 09:53 ? 00:00:00 postgres: 11/main: walsender logrepli 192.168.93.100(41778) idle
Comme l'a préconisé Guillaume, je passe de 265 connexions de réplications à la BDD à 10 connexions (sauf erreur de ma part).
Je vais maintenant tester l'arrêt en mode Fast...
Hors ligne
Résolu !
C'est good !! L'arrêt et le démarrage sont instantanés. A peine une seconde.
A noter que j'ai dû purger les anciens slots de réplications qui étaient conservés.
Visibles avec la commande : SELECT * FROM pg_replication_slots ;
Puis pour supprimer : SELECT pg_drop_replication_slot(slot_name) from pg_replication_slots where slot_name = 'ici le nom du slot' ;
J'ai réactivé le start et stop dans systemd via la commande service.
J'ai aussi changé le paramètre donné par Guillaume "wal_retrieve_retry_interval". Je l'ai mis à 30S. Mais je vais jouer avec pour observer les perfs.
Vraiment, merci à Guillaume, mais aussi à Julien pour l'aide.
Vous êtes au top !
Cdlt,
Olivier
Hors ligne