Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nous travaillons avec un postgresql-9.6 sur un environnement linux.
J'ai monté une base replique sur un autre serveur en mode streaming en utilisant les paramètres de postgres de façon à ce que le slave joue les WAL directement depuis l'emplacement pg_xlog de serveur maitre. C'est bon, la réplication marche, mais, le problème étant que les fichiers dans pg_xlog du serveur maitre ne sont pas effacés et s'accumulent, ce qui bouffent beaucoup d'espace disque. Le contenu du fichier recovery.conf est comme ceci:
standby_mode = 'on'
primary_conninfo = 'host=host_maitre port=port_maitre user=rep password=reppassword'
trigger_file = '/tmp/postgresql.port.trigger.5434'
Est ce normal que ces fichiers wal dans pg_xlog ne sont pas supprimés, comment fait on pour y remédier car on commence à manquer d'espace disque.
J'ai pensé à utiliser pg_archivecleanup et insérer cette commande dans le recovery.conf. Mais je ne crois pas que pg_archivecleanup dispose d'option pour se connecter au serveur maitre depuis le slave ?
Pouvez vous nous aider sur ces points ?
Merci d'avance.
Hors ligne
J'ai monté une base replique sur un autre serveur en mode streaming en utilisant les paramètres de postgres de façon à ce que le slave joue les WAL directement depuis l'emplacement pg_xlog de serveur maitre.
C'est-à-dire ? Parce que dit comme ça ça ressemble à une très très mauvaise idée. Les WALs doivent être archivés avant d'être rejoué.
Est ce normal que ces fichiers wal dans pg_xlog ne sont pas supprimés, comment fait on pour y remédier car on commence à manquer d'espace disque.
Non, vous avez quelque chose qui les retient. Ça peut être l'une de ces raisons :
- l'archivage ne fonctionne pas (voir dans pg_stat_archiver)
- un slot de réplication inutilisé (voir dans pg_replication_slots)
- un wal_keep_segments trop haut
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour cette réponse.
C'est-à-dire ? Parce que dit comme ça ça ressemble à une très très mauvaise idée. Les WALs doivent être archivés avant d'être rejoué.
>>>C'est à dire que le système actuel n'utilise pas d'archive command dans postgresql.conf.
Pour les autres information:
select * from pg_stat_archiver >>
archived_count last_archived_wal last_archived_time failed_count last_failed_wal last_failed_time stats_reset
0 0 2017-07-15 12:41:24.872644+00
select * from pg_replication_slots >> Aucun resultat
wal_keep_segments = 100
Effectivement, je crois que vous aviez raison. Faudrait peut être diminuer wal_keep_segments ? Justement puisque le système n'utilise pas archive_command on a préféré définir wal_keep_segments à 100.
Pouvez vous conseiller sur la bonne solution à prendre ?
Hors ligne
select * from pg_stat_archiver >>
archived_count last_archived_wal last_archived_time failed_count last_failed_wal last_failed_time stats_reset
0 0 2017-07-15 12:41:24.872644+00
Hors ligne
>>>C'est à dire que le système actuel n'utilise pas d'archive command dans postgresql.conf.
Comment effectuez-vous la réplication exactement ?
Julien.
https://rjuju.github.io/
Hors ligne
MASTER SETUP
Step1: paramétrage postgresql.conf
wal_level = replica
max_wal_senders = 8
max_wal_size = 1GB
hot_standby = on
Step2: Creation de l'utilisateur pour la replication
Step3: Parametrage de pg_dba.conf
SLAVE SETUP
Step4: Arrêt de l'instance
Step5: Restauration du master pour créer la replique avec >>> pg_basebackup
Step6: Copie/coller du postgresql.conf du master vers le slave
Step7: Creation du recovery.conf
standby_mode = on
primary_conninfo = 'host=masterhost user=userrepl'
Step8: Démarrage du slave
>>>> Je précise ici qu'on a mis archive_command = '' sur le maitre
Je pense que le problème vient d'ici, on a désactivé l'archive_command sans pour autant mis archive_mode = 'off' donc archive_mode toujours activé les fichiers dans pg_xlog/archive_status sont tous mit en .ready et en attente de copie par archive_command, du coup les wal dans pg_xlog s'accumulent et prennent de l'espace.
Pour solutionner nous pensons à mettre archive_mode = 'off' puis redémarrer le master. Monter pg_xlog dans le serveur de replique et inserrer pg_archivecleanup dans recovery.conf pour supprimer les wal qui ne sont plus utiles dans le repertoire pg_xlog monté.
Qu'en pensez vous ? Nous allons faire un jeu de test.
Hors ligne
J'ai l'impression que vous essayez de vous en sortir sans faire d'archivage. C'est une très mauvaise idée et ça va vous péter à la figure. Configurez l'archivage, et ça ira beaucoup mieux.
Guillaume.
Hors ligne
Vous pouvez soit positionner archive_mode à off et redémarrer, soit positionner archive_command à 'false' et recharger la configuration.
Il ne faut surtout pas utiliser pg_archivecleanup sur le répertoire pg_xlog du serveur primaire.
Dans votre configuration, si vous arrêter votre serveur secondaire suffisamment longtemps (le temps que plus de 100 journaux de transactions soient écrits), il sera nécessaire de le recréer de zéro. Ce n'est pas une mauvaise choise en soit, tout dépend de ce que vous voulez.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
J'ai l'impression que vous essayez de vous en sortir sans faire d'archivage. C'est une très mauvaise idée et ça va vous péter à la figure. Configurez l'archivage, et ça ira beaucoup mieux
>>> Vous voulez sans doute parler si la réplication s'arrête durant un certain laps de temps et qu'il faudra la reconstruire pour la redémarrer n'ayant plus les jeux de wal nécessaires pour rattraper le master non ? Ou quels autres inconvénients signalez vous ?
Il ne faut surtout pas utiliser pg_archivecleanup sur le répertoire pg_xlog du serveur primaire
Pourquoi ? On a fait un jeu de test sur pg_archivecleanup hier soir et çà à marcher pourtant !!! Mais j'aimerai quand même savoir la raison pour que vous déconseillez cette méthode.
Auparavant, on avait déjà désactive archive_mode durant un certain laps de temps mais les wal dans pg_xlog ne diminuaient pas, et engager toujours l'espace disque. Puis on a monté le répertoire dans la réplique, qu'on a ensuite purgé les pgxlog avec pg_arhivecleanup command, et çà marchait.
Hors ligne
Parce qu'il ne faut jamais toucher au contenu du répertoire pg_xlog manuellement. Vous risquez par exemple d'empêcher le maître de pouvoir redémarrer suite à un arrêt brutal, et donc de corrompre l'instance. Après vous faites comme vous voulez.
Julien.
https://rjuju.github.io/
Hors ligne
Je ne comprends pas, comment çà manuel?
L'option %r de pg_acrchivecleanup est manuel vous dites ?
Hors ligne
Vous ne devez jamais toucher au contenu du répertoire pg_xlog. pg_archivecleanup, comme son nom l'indique, sert à nettoyer les archives, pas pg_xlog.
Guillaume.
Hors ligne
Je met un bilan de résultat pour ceux qui sont intéressés:
gleu> normalement si je comprends bien, si archive_mode=on et la commande archive_command est renseignée avec une copie , les wal seront transmis vers l'emplacement définis dans archive_command. Par conséquent, si l'on ne met rien dans archive_command les wal ainsi seront entassés dans pg_xlog et seront toujours en attente de copie (wal.ready). Avec un test, j'ai utilisé archivecleanup commande depuis la réplique vu que la réplique connait quel est le wal déjà joué donc déjà mise en .done qu'on peut supprimer. Je rappelle que l'objectif ici est de seulement supprimer les wal déjà joués pour réduire et éviter le gonflement d'espace occupé par les wal en attentes de copie. Une fois les wal déjà joué supprimés, on désactive archive_mode. Et ainsi postgresql reprend son jeu normal sans mode d'archivage. Cette opération à été testé sur une base de test avec un résultat positif
Peut être avez vous des objections à ceux ci ?
rjuju> Mettre archive_command à false, je viens de tester, çà ne résolu pas le problème, d'ailleurs je ne comprends pas pourquoi.
Par contre, je pense que l'idée est assez la même ou presque, une autre astuce (plus bas) vérifiée et mise en application résolu bien le problème.
Puisque dans le cas où l'on ne dispose pas de serveur de réplique et/ou que l'on aime pas trop utiliser la commande archivecleanup, pour supprimer les wal supprimables on peut utiliser la méthode suivante. Tout simplement, on ne désactive pas archive_mode mais cependant on met archive_command = '/bin/true'. Cela conduira en quelque sorte à une illusion de copie, qui va entrainer ainsi de mettre les wal.ready en wal.done sur le master qui effacera les wal pouvant être supprimé. Postgresql gardera ensuite dans pg_xlog les wal nécessaires à son mode de vie normal selon vos paramétrages.
En tout cas, merci beaucoup aux aides et conseils que vous avez apporter pour ce sujet.
Hors ligne
Pas d'objection particulière, je ne comprends pas ce que vous faites.
Guillaume.
Hors ligne
Pareil, je ne comprends pas trop le problème que vous cherchez à résoudre. Dans tous les cas si les journaux s'entassent c'est qu'il y a un problème. Et il faut résoudre ce problème à la source, plutôt que supprimer des journaux de transaction dans le répertorie pg_xlog (et oui utiliser pg_archivecleanup, faire des rm revient au même, il s'agit d'une suppression qui n'est pas effectuée nativement et c'est le meilleur moyen de corrompre votre instance).
Julien.
https://rjuju.github.io/
Hors ligne
erreur ne pas ternir compte
Dernière modification par stephane.lorek (11/05/2021 10:36:51)
Hors ligne
Pages : 1
