Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous
J'ai un script shell de sauvegarde que j'utilise depuis 10 ans sur un cluster de 6 bases de données sur ubuntu
Je l'ai fait évoluer depuis postgres 9.1 jusque la migration du week-end dernier de postgres 12 à 14.
Toutes mes sauvegardes marchent sauf sur une base et je bloque à comprendre pourquoi...
les droits, comptes et option du pg_dump sont identiques et ce font avec 7 jobs parallélisés en directory (-Fd)
le script se lance crée le répertoire pour cette base puis plus rien à l'affichage on voit bien le processus select et 1 job de sauvegarde et puis ca s'arrête sans rien écrire.
Je précise que pour toutes les autres bases il n'y aucun soucis le processus de select s'initialise puis 7 connections pg_dump puis les 7 copy...
Bref je manque d'imagination... des idées inspirations?
Hors ligne
Bonjour,
Avez-vous vérifié dans pg_stat_activity / pg_locks si pg_dump était bloqué par une autre requête? En effet pg_dump commence par acquérir un verrou de type AccessShareLock sur chacun des objets de la base sauvegardée, donc si vous avez une transaction ouverte qui contient un verrou exclusif sur un des objets pg_dump sera en attente jusqu'à la fin de cette transaction.
Au dela de ce problème, avez-vous considéré l'utilisation de sauvegarde PITR? Les sauvegardes logiques ont de nombreuses limitations (pas de possibilité de restaurer à un point après le début du pg_dump, lenteur de restauration etc).
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour Julien,
Merci pour toutes ces informations...
bon j'ai repris les fondamentaux en lançant juste la ligne de commande et :
Postgres m'a répondu^^
pg_dump: erreur : échec de la requête : ERROR: out of shared memory
ASTUCE : You might need to increase max_locks_per_transaction.
Bref deux soucis identifié :
une valeur de share_buffers trop basse et un nombre de verrous par transaction trop bas...par rapport à la taille de la base à sauvegarder
Hors ligne
Le problème est uniquement lié à un trop grand nombre de verrous nécessaires, changer le shared_buffers n'aidera pas.
Je précise également que le problème ici n'est pas exactement la taille de la base, du moins pas la taille sur disque, mais le nombre d'objets à sauvegarder. La base pourrait être miniscule, par exemple si toutes les tables sont vides, et toujours nécessiter des centaines de milliers de verrous si vous aviez un très grand nombre de tables. Utiliser la sauvegarde physique / PITR permet de ne pas dépendre de max_locks_per_transaction.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1
