Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Je souhaite mettre en place un script de sauvegarde avec pg_basebackup en cron.
Ma configuration de la sauvegarde est en réplication. Les fichiers WAL sont enregistrés sur la même machine de ma bdd mais sauvegardé grâce à Rclone sur une autre serveur tous les jours en cron.
Au préalable j'ai déjà fait une sauvegarde complète de la base, sauf que je souhaite sauvegarder tous les mois la base complète automatiquement.
J'ai crée le fichier .pgpass.
localhost:5432:maBDD:postgres:monMotDePassequi se trouve dans /var/lib/postgresql avec les droits 600 et user et groupe = postgres
Le problème étant lors de l’exécution du script celui-ci me demande toujours le mot de passe.
Voici ma commande que je lance:
pg_basebackup -h localhost -p 5432 -U postgres -D /home/svgSavez-vous où est le problème ?
Faut il utiliser pg_basebackup ou un autre moyen pour une sauvegarde en cron ?
Cordialement.
Hors ligne
S'agit-t-il du cron pour l'utilisateur postgres, et êtes-vous sûr que les variables d'envrionnement sont positionnées avec votre implémentation de cron?
Peut-être qu'une version comme cela marcherait :
PGPASSFILE=/var/lib/postgresql/.pgpass pg_basebackup -h localhost -p 5432 -U postgres -D /home/svgJulien.
https://rjuju.github.io/
Hors ligne
Dans le 3eme champ de .pgpass, il faut mettre replication au lieu d'un nom de base de données.
Si ça échoue toujours après ça, consulter le fichier de log du serveur pour avoir des détails sur l'erreur.
Dernière modification par dverite (06/07/2022 14:13:05)
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Dans le 3eme champ de .pgpass, il faut mettre replication au lieu d'un nom de base de données.
Si ça échoue toujours après ça, consulter le fichier de log du serveur pour avoir des détails sur l'erreur.
Merci dverite. Le problème venait bien de la. Ça fonctionne nickel.
J'en profite pour poser une autre question sans devoir refaire un sujet.
Concernant les WAL à t'il un paramètre à mettre pour enregistrer que ce qui est utile ? Car en l'ouvrant on s’aperçoit qu'il y a énormément de donnée NUL
Hors ligne
Vous voulez dire les fichiers dans le répertoire pg_wal / pg_xlog? Ce sont des fichiers binaires, le seul levier est le paramètre wal_level, et concrètement il y a peu d'intérêt à avoir un niveau "minimal". Notamment, vous ne pourrez pas faire de sauvegardes type pg_basebackup.
Peut être que vous avez des checkpoints un peu trop fréquents, ce qui augmente le nombre de full page writes? Vous pouvez utiliser pg_waldump / pg_xlogdump pour avoir quelques chiffres, ou pg_stat_statements si vous êtes en version 13 ou supérieure.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Quand vous parlez de checkpoint vous faites référence à archive_timeout? Si oui, actuellement la valeur est sur 60 c'est peut être trop court
Voici ce que j'ai avec la commande pg_waldump :
/usr/lib/postgresql/13/bin/pg_waldump 00000001000000000000001C
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/1C000028, prev 0/1B000100, desc: RUNNING_XACTS nextXid 703 latestCompletedXid 702 oldestRunningXid 703
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/1C000060, prev 0/1C000028, desc: RUNNING_XACTS nextXid 703 latestCompletedXid 702 oldestRunningXid 703
rmgr: XLOG len (rec/tot): 114/ 114, tx: 0, lsn: 0/1C000098, prev 0/1C000060, desc: CHECKPOINT_ONLINE redo 0/1C000060; tli 1; prev tli 1; fpw true; xid 0:703; oid 16434; multi 1; offset 0; oldest xid 478 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 0/0; oldest running xid 703; online
rmgr: XLOG len (rec/tot): 24/ 24, tx: 0, lsn: 0/1C000110, prev 0/1C000098, desc: SWITCHMais je ne comprend pas du tout les données
Hors ligne
Quand vous parlez de checkpoint vous faites référence à archive_timeout?
Non, je faisais référence à checkpoint_timeout et/ou max_wal_size, cf https://www.postgresql.org/docs/current … ation.html.
Concernant votre paramétrage d'archive_timeout, il est censé correspondre à votre besoin en terme de RPO / RTO. Vous pouvez consulter la documentation pour voir comment le paramétrer, et/ou voir si potentiellement utiliser pg_receivewal et/ou des slots de réplication seraient mieux adapté.
Pour pg_waldump, il faudrait utiliser l'option --stat. Mais je ne comprends toujours pas ce que vous entendez par "contient beaucoup de données NUL", ni en quoi vous en déduisez que ces données sont inutiles.
Julien.
https://rjuju.github.io/
Hors ligne
Actuellement checkpoint_timeout est commenté dans le fichier postgresql.conf
Pour pg_waldump avec l'option --stat voici le retour
Type N (%) Record size (%) FPI size (%) Combined size (%)
---- - --- ----------- --- -------- --- ------------- ---
XLOG 2 ( 50,00) 138 ( 57,98) 0 ( 0,00) 138 ( 57,98)
Transaction 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Storage 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
CLOG 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Database 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Tablespace 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
MultiXact 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
RelMap 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Standby 2 ( 50,00) 100 ( 42,02) 0 ( 0,00) 100 ( 42,02)
Heap2 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Heap 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Btree 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Hash 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Gin 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Gist 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Sequence 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
SPGist 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
BRIN 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
CommitTs 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
ReplicationOrigin 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
Generic 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
LogicalMessage 0 ( 0,00) 0 ( 0,00) 0 ( 0,00) 0 ( 0,00)
-------- -------- -------- --------
Total 4 238 [100,00%] 0 [0,00%] 238 [100%]Concernant les données NUL je les voyait en ouvrant avec un éditeur, mais je pense que mon problème réel vient du archive_timeout, où toutes les minutes un fichier est créé.
Celui-ci contient beaucoup moins de données par rapport au tout premier WAL
Donc effectivement, je pense que vous avez raison ces données sont loin d'être inutiles
Je vais regarder avec vos recommandations
EDIT :
Pour mon problème de fichier WAL est-ce judicieux de laisser archive_timeout commenté et garder les valeurs actuelles max_wal_size = 1GB et min_wal_size = 80MB, dès que le fichier WAL sera à 1Go un nouveau sera créé et également bien rempli ?
Dernière modification par Funky (08/07/2022 11:42:30)
Hors ligne
Quand un paramètre est commenté, cela ne veut pas dire qu'il n'a pas de valeur. Le mieux pour connaître la valeur actuelle d'un paramètre est de se connecter à PostgreSQL et d'exécuter :
SHOW paramètre;Donc dans votre cas :
SHOW archive_timeout;Là, votre archive contient quatre enregistrements pour un total de 239 octets. Donc, dans les faits, elle est vide. Il serait bon de vérifier la vraie valeur de archive_timeout. Cela pourrait aussi venir d'une utilisation trop fréquente de la fonction pg_switch_wal().
Guillaume.
Hors ligne
Bonjour à tous,
Après quelques jours en mettant le paramètre archive_timeout à 0. Le problème des fichiers WAL est résolu.
En regardant avec :
SHOW archive_timeout;la valeur est bien à 0.
Le fichier est rempli comme il se doit.
Merci à vous, pour tous les renseignements apportés
Cordialement,
Benjamin
Hors ligne
Pages : 1