Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je travaille sur des moteurs entre 9.3 et 10.1 sous Cent-OS 6/7.
Ce week-end un petit problème avec une BDD (lock sur une table).
En cascade, de nombreux Users bloqués, mon export journalier (pg_dump) et un vacuum full hebdo bloqués.
Lundi matin en arrivant, je veux me connecter à la base pour voir qui bloque et là le drame : FATAL: sorry, too many clients already
Vilain petit canard que je suis, j'utilise le superuser par défaut pour l'export et le vacuum, superuser_reserved_connections = 3, PAS BIEN.
Je prends donc le sujet au sérieux, j'ai vu sur le net que beaucoup pratique ceci pour un User spécifique sauvegarde :
CREATE USER backadm SUPERUSER password '<PASS>';
ALTER USER backadm set default_transaction_read_only = on;
Est-ce la bonne pratique ?
J'imagine que l'on ne peut pas utiliser le même User pour la restauration ? donc superuser (différent du par défaut) ?
Et même problématique pour le vacuum full ?
D'avance merci pour vos éclaircissements.
Hors ligne
Le paramètre superuser_reserved_connections est commun pour tous les utilisateurs ayant le privilège SUPERUSER, donc y compris votre nouvel utilisateur. Voyez plutôt pour augmenter ce paramètre (et peut être augmenter le nombre maximum de connexions si l'utilisation standard approche les 97 connexions).
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Désolé pour la réponse tardive, j'étais sur une urgence.
Le problème c'est que j'utilise le superuser pour mes exports journaliers et mon vacuum hebdomadaire mis en crontab.
Donc si jamais un client lock une table, le vacuum va bloquer, les exports aussi, si c'est pendant un week-end prolongé par exemple, je peux vite arriver à 5-6 connexions utilisées et plus possible d'accéder à la base en rentrant du week-end.
Est-ce la meilleure solution ?
Ne vaut-il mieux pas créer un user avec les droits adéquats pour les exports et vacuum ?
Hors ligne
Je ne vois pas en quoi des droits et un utilisateur particulier vont corriger le problème indiqué ici. Un VACUUM FULL a besoin d'un verrou exclusif. Si un verrou est déjà sur la table, il sera bloqué et bloquera tous les prochains utilisateurs de cette table. Si vous voulez garder une marge possible pour vous connecter en superutilisateur, il faut augmenter la valeur du superuser_reserved_connections.
Guillaume.
Hors ligne
Et aussi vous pouvez utiliser l'option --lock-wait-timeout de pg_dump (si c'est ce que vous utilisez), pour éviter le problème. Pensez bien évidemment à vérifier le code retour de pg_dump avant de supprimer les anciennes sauvegardes.
Julien.
https://rjuju.github.io/
Hors ligne
Rebonjour,
Guillaume : Je pensais qu'en utilisant un autre User, je préserverais les connexions superuser.
Julien : ok, merci pour l'option.
Hors ligne
Le VACUUM FULL ne prend qu'une connexion, et les exports (pg_dump ?) ne doivent pas en prendre beaucoup. Du coup, ce sont les autres connexions qui vont gêner.
Guillaume.
Hors ligne
Une pour le vacuum.
Quatre pour les exports (oui pg_dump et pg_dumpall), si long week-end.
Je vais donc réserver 6 superuser_reserved_connections.
Merci.
Hors ligne
Pages : 1
