Vous n'êtes pas identifié(e).
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
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...
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.
https://www.postgresql.org/docs/11/sql- … ation.html
Ah oui, il semble y avoir "FOR TABLE"
en fait, j'ai fait une publication par table, donc, une souscription par table. Peux-être que ma logique n'est pas la bonne.
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.
je teste dès que le serveur a cesser de logguer. Promis, je ferai un retour. Merci énormément pour les conseils prodigués.
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...)
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
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...
Je suis en réplication logique. au niveau table.
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
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.
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.
Merci Guillaume, je vais chercher aussi un peu. Il y a forcement une solution.
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.
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
sur tous en fait :
2021-10-29 20:27:08.462 GMT [2151] ERREUR: n'a pas pu se connecter au publieur : FATAL: le système de base de données s'arrête
FATAL: le système de base de données s'arrête
2021-10-29 20:27:08.465 GMT [623] LOG: processus en tâche de fond « logical replication worker » (PID 2150) quitte avec le code de sortie 1
2021-10-29 20:27:08.465 GMT [623] LOG: processus en tâche de fond « logical replication worker » (PID 2151) quitte avec le code de sortie 1
2021-10-29 20:27:08.465 GMT [623] LOG: processus en tâche de fond « logical replication worker » (PID 2149) quitte avec le code de sortie 1
2021-10-29 20:27:08.467 GMT [2152] ERREUR: n'a pas pu se connecter au publieur : FATAL: le système de base de données s'arrête
FATAL: le système de base de données s'arrête
2021-10-29 20:27:08.468 GMT [2153] ERREUR: n'a pas pu se connecter au publieur : FATAL: le système de base de données s'arrête
FATAL: le système de base de données s'arrête
2021-10-29 20:27:08.470 GMT [623] LOG: processus en tâche de fond « logical replication worker » (PID 2152) quitte avec le code de sortie 1
2021-10-29 20:27:08.471 GMT [623] LOG: processus en tâche de fond « logical replication worker » (PID 2153) quitte avec le code de sortie 1
sur un serveur distant :
2021-10-29 20:25:37.863 GMT [652] LOG: processus en tâche de fond « logical replication worker » (PID 28741) quitte avec le code de sortie 1
2021-10-29 20:25:37.863 GMT [28735] ERREUR: n'a pas pu se connecter au publieur : FATAL: le système de base de données s'arrête
FATAL: le système de base de données s'arrête
2021-10-29 20:25:37.863 GMT [28742] ERREUR: n'a pas pu se connecter au publieur : FATAL: le système de base de données s'arrête
FATAL: le système de base de données s'arrête
2021-10-29 20:25:37.863 GMT [28743] ERREUR: n'a pas pu se connecter au publieur : FATAL: le système de base de données s'arrête
FATAL: le système de base de données s'arrête
2021-10-29 20:25:37.863 GMT [28740] ERREUR: n'a pas pu se connecter au publieur : FATAL: le système de base de données s'arrête
FATAL: le système de base de données s'arrête
ok je regarde
@Guillume : Si, si j'ai 5 serveurs synchronisés avec des souscriptions sur 53 tables.
Donc : 265 tables qui cherchent à se connecter aux abonnements ...
Est-ce une piste ?
ET toujours :
2021-10-29 20:14:22.829 GMT [12477] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 20:14:22.852 GMT [12478] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 20:14:22.853 GMT [12479] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 20:14:22.869 GMT [12480] logrepli@ppv FATAL: le système de base de données s'arrête
etc...
@Guillaume :
root@lin01:~# ps -ef |grep postgres
root 838 1773 0 20:12 pts/0 00:00:00 grep postgres
postgres 27165 1 2 20:10 ? 00:00:02 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
postgres 29215 27165 1 20:10 ? 00:00:00 postgres: 11/main: checkpointer
postgres 29219 27165 0 20:10 ? 00:00:00 postgres: 11/main: stats collector
root 29516 29514 0 20:11 pts/1 00:00:00 systemctl stop postgresql@11-main
postgres 29518 1 0 20:11 ? 00:00:00 /usr/bin/perl -wT /usr/bin/pg_ctlcluster --skip-systemctl-redirect -m fast 11-main stop
postgres 29520 29518 0 20:11 ? 00:00:00 /usr/lib/postgresql/11/bin/pg_ctl stop -s -w -D /var/lib/postgresql/11/main -m fast
root@lin01:~#
Ok il est arrêté. Donc : 30 minutes pour s'arrêter.
2021-10-29 20:05:50.268 GMT [26440] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 20:05:50.268 GMT [26438] logrepli@ppv FATAL: le système de base de données s'arrête
2021-10-29 20:05:50.305 GMT [1809] LOG: le système de base de données est arrêté
@Guillaume : Je relance re-stoppe et fait le ps -ef.
Merci pour la suggestion.
@GLEU : Bonjour Guillaume,
Voici le retour du ps -aux
root@lin01:~# ps -aux |grep postgres
postgres 1809 3.7 0.6 628896 50528 ? S 19:34 0:43 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
postgres 4125 2.9 0.0 628896 5704 ? Ds 19:35 0:34 postgres: 11/main: checkpointer
postgres 4129 0.0 0.0 59164 4044 ? Ss 19:35 0:00 postgres: 11/main: stats collector
root 4723 0.0 0.0 8688 1984 pts/1 S+ 19:36 0:00 systemctl stop postgresql@11-main
root 31046 0.0 0.0 4724 792 pts/0 S+ 19:54 0:00 grep postgres
postgres 31062 0.0 0.0 628896 6240 ? Ss 19:54 0:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
postgres 31063 0.0 0.0 628896 6240 ? Ss 19:54 0:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
postgres 31064 0.0 0.0 628896 6240 ? Ss 19:54 0:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
postgres 31065 0.0 0.0 628896 6240 ? Ss 19:54 0:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
postgres 31066 0.0 0.0 628896 6240 ? Ss 19:54 0:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
postgres 31067 0.0 0.0 628896 6240 ? Ss 19:54 0:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
postgres 31068 0.0 0.0 628896 6240 ? Rs 19:54 0:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
