Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je travaille sur un moteur 9.5.3 sous Cent-OS 7.2.
J'ai mis en place un warm-standby (log_shipping+streaming replication).
Sur mon maître, j'ai un shell pour mon ARCHIVE_COMMAND qui fait un CP en local et un RSYNC vers mon esclave.
J'ai un shell pour faire une sauvegarde de base toutes les 12 heures :
pg_basebackup -D ${BACKUP_DIR}/HOT_BACKUP -F t -R -x -z -c fast -l ${LABEL} -P -v -U replic
Cela génére un fichier .backup qui se "propage" dans mon répertoire d'archive local et dans celui de l'esclave.
Sur mon esclave, dans mon recovery.conf, j'ai indiqué :
ARCHIVE_CLEANUP_COMMAND='pg_archivecleanup /home/postgres/PG_ARC %r'
Les WAL archivés devenus inutiles sont bien supprimés au fil de l'eau, mais pas les .backup
Est-ce normal ? à moi de gérer ?
Hors ligne
Bonjour,
Si vous utilisez des WAL dans le cadre de la réplication et de la sauvegarde, il ne faut pas utiliser d'archive_cleanup_command. L'option -x dans votre appel à pg_basebackup ne récupère que les WAL nécessaire pour atteindre un point de cohérence, mais pas plus. Si vous demandez à votre standby de supprimer les WAL, en cas d'incident vous pourrez perdre jusqu'à 12 heures de données.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour Julien,
Merci pour la réponse.
Pour confirmer, je viens de reconstruire mon esclave, avec la sauvegarde de minuit et :
2016-06-01 07:29:40 CEST [17869]: [1-1] user= 2016-06-01 07:29:40 CEST LOG: database system was interrupted; last known up at 2016-06-01 00:10:01 CEST
2016-06-01 07:29:40 CEST [17869]: [2-1] user= 2016-06-01 07:29:40 CEST LOG: entering standby mode
cp: impossible d'évaluer « /home/postgres/PG_ARC_MASTER/000000010000000300000087 »: Aucun fichier ou dossier de ce type
2016-06-01 07:29:40 CEST [17871]: [1-1] user= 2016-06-01 07:29:40 CEST LOG: started streaming WAL from primary at 3/87000000 on timeline 1
2016-06-01 07:29:40 CEST [17871]: [2-1] user= 2016-06-01 07:29:40 CEST FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000300000087 has already been removed
cp: impossible d'évaluer « /home/postgres/PG_ARC_MASTER/000000010000000300000087 »: Aucun fichier ou dossier de ce type
2016-06-01 07:29:40 CEST [17873]: [1-1] user= 2016-06-01 07:29:40 CEST LOG: started streaming WAL from primary at 3/87000000 on timeline 1
2016-06-01 07:29:40 CEST [17873]: [2-1] user= 2016-06-01 07:29:40 CEST FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000300000087 has already been removed
Je vais donc retirer la commande ARCHIVE_CLEANUP_COMMAND du recovery.conf.
J'ai déjà un shell sur le maître qui nettoie les WAL archivés de plus de 2 jours. Je vais donc rajouter le nettoyage des mêmes fichiers sur l'esclave.
Est-ce une bonne pratique ?
Dernière modification par mortimer.pw (01/06/2016 08:19:50)
Hors ligne
La bonne pratique est effectivement de supprimer les fichiers archivés ainsi que les sauvegarde pg_basebackup en fonction de la rétention voulue.
Par contre, il n'y a pas de fichiers à supprimer sur le secondaire. Celui-ci va récupérer les WAL dont il a besoin et les purger comme le fait le primaire, sauf si votre restaure_command les copie en local avant de les restaurer ?
Julien.
https://rjuju.github.io/
Hors ligne
Re,
Sur le Maître, j'ai :
- les fichiers WAL "courants", dans /home/postgres/PG_XLOG,
- les fichiers WAL archivés, dans /home/postgres/PG_ARC.
Sur l'Esclave, j'ai :
- les fichiers WAL archivés du Maître, dans /home/postgres/PG_ARC
Ces fichiers archivés, le sont par ARCHIVE_COMMAND sur le maître (cp en local et rsync sur l'Esclave).
J'ai enlevé ARCHIVE_CLEANUP_COMMAND du recovery.conf sur l'Esclave.
Si l'Esclave a besoin de fichiers WAL, il va les copier de /home/postgres/PG_ARC vers /home/postgres/PG_XLOG grace à la RESTORE_COMMAND.
Sur l'esclave, les fichiers vont donc s'accumuler dans /home/postgres/PG_ARC. Il y a donc bien des fichiers à supprimer sur le secondaire ?
Hors ligne
Au final vous archivez sur 2 serveurs (copie locale + rsync, comme indiqué dans le premier message désolé j'avais raté cette information), donc oui il faut bien supprimer ces fichiers (et ceux là uniquement) sur les deux serveurs.
Julien.
https://rjuju.github.io/
Hors ligne
Super, merci Julien.
Hors ligne
Pages : 1
