Vous n'êtes pas identifié(e).
Bonjour,
Je rencontre un soucis sur mon serveur postgres de production (version : 9.6).
Pour info, ce serveur est master dans une architecture master/slave avec streaming des logs de transactions
Le soucis est que le filesystem des wal redo logs archivés (archive_logs) se remplit trop rapidement tandis que le FS des wal redo logs (pg_xlog) stagne.
Actuellement, mes FS sont utilisés comme suit :
/dev/mapper/vg_apps-lv_pgsql96_backup 208G 9.1G 190G 5% /applis/24140-tdgg/artifactory/postgres/backup/9.6
xxxxxx.fr.net.intra:/vol_SVM_DMZ_MULTI_PROD_063/yyyy_qtree 260G 216G 45G 83% /applis/24140-tdgg/artifactory/postgres/backup/9.6/archive_logs
Comme vous pouvez le voir le FS des archive_logs est surutilisé (216/260G) tandis que le FS des pg_xlog est sous-utilisé (9.1/208G)
Sauriez-vous comment faire ne sorte que les logs soient conservés plus longtemps ds le FS des pg_xlog afin d'éviter la saturation permanente du FS des archive logs ?
Merci d'avance pour votre réponse.
Cordialement.
Hors ligne
Bonjour,
Ces 2 répertoires ont des buts totalement différents, et leur utilisation est donc totalement différente également. Cela dit, il est impossible de vous aider sans avoir plus de détails sur la configuration, notamment comment les wal sont archivés et comment ils sont purgés.
Julien.
https://rjuju.github.io/
En ligne
Bonjour,
Voici la configuration des WAL redo logs extraite du fichier de configuration postgresql.conf :
------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------
# - Settings -
wal_level = replica # minimal, replica, or logical
# (change requires restart)
fsync = on # flush data to disk for crash safety
# (turning this off can cause
# unrecoverable data corruption)
synchronous_commit = local # synchronization level;
# off, local, remote_write, remote_apply, or on
#wal_sync_method = fsync # the default is the first option
# supported by the operating system:
# open_datasync
# fdatasync (default on Linux)
# fsync
# fsync_writethrough
# open_sync
#full_page_writes = on # recover from partial page writes
#wal_compression = off # enable compression of full-page writes
#wal_log_hints = off # also do full page writes of non-critical updates
# (change requires restart)
wal_buffers = 16MB # min 32kB, -1 sets based on shared_buffers
# (change requires restart)
#wal_writer_delay = 200ms # 1-10000 milliseconds
#wal_writer_flush_after = 1MB # measured in pages, 0 disables
#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000
# - Checkpoints -
checkpoint_timeout = 5min # range 30s-1d
max_wal_size = 4GB
min_wal_size = 2GB
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
#checkpoint_flush_after = 256kB # measured in pages, 0 disables
#checkpoint_warning = 30s # 0 disables
# - Archiving -
archive_mode = on # enables archiving; off, on, or always
# (change requires restart)
archive_command = 'cp %p /applis/24140-tdgg/artifactory/postgres/backup/9.6/archive_logs/%f' # command to use to archive a logfile segment
# placeholders: %p = path of file to archive
# %f = file name only
# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
archive_timeout = 3600 # force a logfile segment switch after this
# number of seconds; 0 disables
------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------
# - Sending Server(s) -
# Set these on the master and on any standby that will send replication data.
max_wal_senders = 10 # max number of walsender processes
# (change requires restart)
wal_keep_segments = 500
#wal_keep_segments = 25 # in logfile segments, 16MB each; 0 disables
#wal_sender_timeout = 60s # in milliseconds; 0 disables
max_replication_slots = 1 # max number of replication slots
# (change requires restart)
#track_commit_timestamp = off # collect timestamp of transaction commit
# (change requires restart)
# - Master Server -
# These settings are ignored on a standby server.
synchronous_standby_names = 'walreceiver' # standby servers that provide sync rep
# number of sync standbys and comma-separated list of application_name
# from standby(s); '*' = all
#vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
# - Standby Servers -
# These settings are ignored on a master server.
hot_standby = on # "on" allows queries during recovery
# (change requires restart)
#max_standby_archive_delay = 30s # max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
#max_standby_streaming_delay = 30s # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
#wal_receiver_status_interval = 10s # send replies at least this often
# 0 disables
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts
#wal_receiver_timeout = 60s # time that receiver waits for
# communication from master
# in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s # time to wait before retrying to
# retrieve WAL after a failed attempt
#------------------------------------------------------------------------------Cordialement.
Hors ligne
Sauriez-vous comment faire ne sorte que les logs soient conservés plus longtemps ds le FS des pg_xlog afin d'éviter la saturation permanente du FS des archive logs ?
C'est impossible. Le but de l'archivage, c'est d'archiver dès que possible. Donc dès que le journal est plein, il est archivé. Il n'y a aucun moyen de changer cela. Vous avez simplement mal configuré vos systèmes de fichiers. Celui des WAL en cours doit être suffisamment grand pour conserver les journaux avant leur archivage, et celui des WAL archivés doit être suffisamment grand pour conserver les journaux d'après votre politique de sauvegarde (et notamment la rétention souhaitée). Si vous archivez uniquement pour la réplication, vous devez utiliser l'outil pg_archivecleanup à partir du secondaire pour supprimer les journaux archivés devenus inutiles (ce qui devrait supprimer pratiquement tout).
Guillaume.
Hors ligne
Et en relisant ma réponse, je me dis que si vous voulez éviter la saturation du systèmes de fichiers des archives, c'est que vous avez certainement oublié de mettre en place pg_archivecleanup sur le secondaire pour qu'il supprime les archives devenues inutiles, et non pas conserver les journaux sur le primaire.
Guillaume.
Hors ligne
De plus:
archive_command = 'cp %p /applis/24140-tdgg/artifactory/postgres/backup/9.6/archive_logs/%f'
Cette commande est une très mauvaise idée. Par exemple:
* la copie n'est pas atomique
* le fichier n'est pas synchronisé sur disue une fois la copie terminée
Vous pouvez utiliser rsync plutôt que cp pour le premier problème, pour le second c'est relativement impossible sans utiliser un langage plus adapté permettant d'exécuter un fsync.
Julien.
https://rjuju.github.io/
En ligne
Bonjour,
Merci pour vos retours
Pour info, le FS des archive logs est monté sur un partage NFS partagé par le serveur primaire et secondaire.
xxxxxx.fr.net.intra:/vol_SVM_DMZ_MULTI_PROD_063/yyyy_qtree 260G 216G 45G 83% /applis/24140-tdgg/artifactory/postgres/backup/9.6/archive_logs
Je ne comprends pas ce concept de journal "plein". Pourriez-vous SVP m'expliquer les critères possibles de déclenchement de la copie des logs ds pg_xlog vers le répertoire d'archive logs ?
Nous avons essayé d'augmenter la valeur de "wal_keep_segments" afin de garder les pg_xlog plus longtemps avant copie vers le répertoire d'archive logs, sans succés.
Concernant l'utilisation de pg_archivecleanup, je me suis renseigné sur le lien officiel et je ne suis pas sûr qu'il réponde à notre besoin.
Nous souhaitons conserver les archive logs sur plusieurs jours pour répondre au cas par exemple où le serveur secondaire est indisponible pendant plusieurs jours (crash de la VM, soucis de réplication etc.) afin de pouvoir faire une restauration des transactions jouées sur le noeud primaire en l'absence du noeud secondaire une fois que celui-ci est de nouveau rendu disponible.
Nous avons mis en place un script de purge ds le contab qui purge les archives logs de plus de 4 jours.
Merci.
Cdt.
Hors ligne
Je ne comprends pas ce concept de journal "plein". Pourriez-vous SVP m'expliquer les critères possibles de déclenchement de la copie des logs ds pg_xlog vers le répertoire d'archive logs ?
Un journal de transactions fait 16 Mo. Il est rempli au fur et à mesure des écritures dans la base. Une fois que les 16 Mo sont remplis, PostgreSQL passe au journal de transaction suivant, et archive le journal de transaction qu'il vient de terminer de remplir. On peut forcer PostgreSQL à archiver un journal de transaction avant qu'il ne soit rempli. Par contre, on ne peut pas le forcer à ne pas archiver un journal rempli (enfin, si, on peut, avec un script d'archivage qui renvoie une erreur d'archivage, mais c'est ridicule).
Nous avons essayé d'augmenter la valeur de "wal_keep_segments" afin de garder les pg_xlog plus longtemps avant copie vers le répertoire d'archive logs, sans succés.
Normal, wal_keep_segments n'a pas pour but de repousser l'archivage, mais de conserver un certain nombre de journaux en local alors qu'ils ont été archivés. Donc ce que vous observez est normal et conforme à votre configuration (500*16 Mo = 8 Go, et comme votre répertoire pg_xlog contient 9 Go, les 1 Go restant doivent être l'activité en cours).
Concernant l'utilisation de pg_archivecleanup, je me suis renseigné sur le lien officiel et je ne suis pas sûr qu'il réponde à notre besoin.
Nous souhaitons conserver les archive logs sur plusieurs jours pour répondre au cas par exemple où le serveur secondaire est indisponible pendant plusieurs jours (crash de la VM, soucis de réplication etc.) afin de pouvoir faire une restauration des transactions jouées sur le noeud primaire en l'absence du noeud secondaire une fois que celui-ci est de nouveau rendu disponible.
Nous avons mis en place un script de purge ds le contab qui purge les archives logs de plus de 4 jours.
Votre script ne prend pas en compte le fait que le secondaire ait besoin ou non des archives. Il supprime sans distinction ceux de plus de 4 jours, donc en reprenant votre exemple, si votre secondaire est indisponible pendant plus de 4 jours, il sera impossible de le resynchroniser automatiquement. Par contre, l'intérêt de pg_archivecleanup est justement d'éviter ça. Quand il est exécuté par le secondaire, ce dernier lui indique la première archive dont il a encore besoin, et pg_archivecleanup supprimera toutes les archives plus anciennes que cette archive. pg_archivecleanup est exactement ce dont vous avez besoin, et votre script est exactement ce que vous devez éviter.
Guillaume.
Hors ligne
Désolé pour la réponse tardive.
En relisant le code de notre script de purge, je me rends compte qu'il utilisait déjà la commande pg_archivecleanup.
Le script est schedulé pour être lancé deux fois par jour par le crontab Linux.
Ci-dessous les lignes correspondantes du script :
OUTPUT=`find ${DIR_BACKUP} -type f -name "0000000*" -mtime ${RETENTION} -print | tail -n1`
# Purge des anciens WALs
WAL=`basename ${OUTPUT}`
# PATH de pg_archivecleanup
ARCHIVECLEANUP=$(locate pg_archivecleanup | head -1)
eval ${ARCHIVECLEANUP} -d ${DIR_BACKUP} ${WAL} >${LOG_ARCH_CLEAN} 2>&1J'ai l'impression que cela revient au même que faire une purge des fichiers plus vieux qu'une durée de rétention donnée.
Pourriez-vous SVP m'indiquer quelle commande lancer pour que le secondaire ne garde que les logs "dont il a besoin" (à savoir non écrites en base si j'ai bien compris) ?
Merci d'avance.
Hors ligne
En effet, la façon dont vous l'utilisez n'est pas très bonne. Vous supprimez les fichiers qui sont plus anciens que votre durée de rétention.
Une meilleure configuration serait de laisser le serveur secondaire faire en configurant le paramètre archive_cleanup_command du fichier recovery.conf comme indiqué dans l'exemple de la page de man de pg_archivecleanup (https://docs.postgresql.fr/13/pgarchive … -1.9.5.4.9).
Guillaume.
Hors ligne
@gleu :
Je vais suivre ton conseil et ajouter cette config ds le fichier recovery.conf :
archive_cleanup_command = 'pg_archivecleanup emplacementarchive %r'Je surveille la purge et les métriques sur l'occupation du filesystem et vous tiens au courant.
Merci.
@rjuju :
Désolé de répondre seulement maintenant à ta réponse du 29/07 mais je n'avais pas compris.
Que veux tu dire par "copie pas atomique" ? Est-ce que tu veux dire qu'il est possible de manquer des fichiers lors de la copie (d'où l'intérêt d'utiliser rsync qui fait une copie incrémentale du contenu des répertoires) ?
Ps compris non plus la nécessité de forcer un fsync, c'est fait à fréquence régulière par l'OS de mémoire
Hors ligne
Que veux tu dire par "copie pas atomique" ? Est-ce que tu veux dire qu'il est possible de manquer des fichiers lors de la copie (d'où l'intérêt d'utiliser rsync qui fait une copie incrémentale du contenu des répertoires) ?
Non, plutôt l'inverse. Par exemple si un WAL est en cours de copie et que seulement 8Mo surl es 16Mo sont présent dans le fichier de destination et qu'un serveur secondaire (ou tout autre consommateur) essaye de récupérer le fichier, il ne verra qu'une partie des données. Le résultat peut aller d'un serveur secondaire bloqué à une corruption en passant par une fin de restauration trop précoce.
Ps compris non plus la nécessité de forcer un fsync, c'est fait à fréquence régulière par l'OS de mémoire
Oui, l'OS le fera de manière régulière. Un autre façon de dire ça est qu'en cas d'arrêt brutal du serveur une partie de votre sauvegarde sera définitivement perdue. C'est à priori l'inverse de ce qui est attendu d'une sauvegarde.
Julien.
https://rjuju.github.io/
En ligne