Bonjour,

Je voudrais savoir quels critères peut nous conduire à l'utilisation de pgPool-II?

Hormis les fonctionnalités de répartition de charge, de failover et  de online-recovery, quelle situation demande de mettre en place du pooling de connexion?

Plus particulièrement, j'ai pu lire un article sur Dalibo qui disait qu'au delà de 1000 connexions concurrentes, il fallait envisager du pooling de connexion. Est ce toujours d'actualité pour la 9.3.4?

Si oui, quels est alors l'inconvénient de positionner un max_connections > 1000? Est ce un problème de gestion de la mémoire partagée ou autre?

Voici l'extrait sur http://www.dalibo.org/hs44_rapide_confi … postgresql:

Par défaut, il est à 100, ce qui est une valeur généralement correcte. Il ne faut pas hésiter à l'augmenter, tout en sachant que des valeurs supérieures à 1000 ne sont pas conseillées. Il vaudra mieux utiliser un pooler de connexions dans ce cas. Les deux disponibles pour PostgreSQL vous seront présentés dans le reste de ce hors-série. 

Merci d'avance pour vos explications en espérant avoir été assez précis dans mes demandes.

Bonjour,

Je voudrais avoir vos lumières sur les bonnes pratiques concernant la gestion des archives WAL dans une configuration MAITRE/ESCLAVE avec streaming Replication.
Notamment la configuration des paramètres archive_command sur le maitre dans le postgresql.conf et restore_command dans le recovery.conf sur l'esclave.

Je pars du principe qu'il n'y a pas de ressource partagée donc toutes les opérations se font via scp.

Quelle est la bonne pratique à utiliser?

Faut il envoyer via scp les archive_WAL depuis le maitre vers le standby via archive_command (en plus de l'archivage local des WAL sur le maitre)? Dans ce cas, que vaut le paramètre restore_command?

ou

Faut il seulement archiver sur le maitre en local via archive_command et récupérer les archives_WAL depuis le standby via scp dans la restore_command du recovery.conf du slave?

ou

les deux solutions se valent. Mais quels sont les avantages et inconvénients de telle ou telle configuration.

Auriez vous un exemple simple pour illuster en prenant en compte que le host du maitre pgprmy et le host du standby est pgstdby?

Une autre question bonus sur la gestion du lag avec la streaming replication :

Les archives WAL sont ils utilisés pour remonter un gros gap dans le cadre d'une réplication par flux?

Admettons j'arrête le standby un temps. je génère du WAL sur le primaire. Je redémarre le standby.

Comment se comporte le standby pour remonter le gap? Récupère t il les WAL et les appliquent d'abord. Puis une fois remonté, il repasse en mode stream?

ou

Remonte il le gap directement par la réplication en flux sans passer par les WAL?

Je vous remercie d'avance pour les réponses que vous pourrez m'apporter.

Bonjour,

J'ai parcouru la documentation de pgpool-II. je souhaiterai avoir des explications sur ce passage dans le chapitre "Failover with Streaming Replication":

If a second standby took over primary when the first standby has already taken over too, you would get bogus data from the second standby.
We recommend not to plan this kind of configuration.

Cela veut il dire qu'il faut éviter les configurations à plusieurs standby pour une configuration pgpool + streaming?

Pour information, il s'agit d'une conf pgpool3.3.2 et postgreSQL 9.3.4

Merci d'avance pour les réponses que vous pourrez m'apporter.

Cordialement

Bonjour,

J'ai lu une documentation provenant de DALIBO ("Les nouveautés de PostgreSQL 9.3") qui évoque le changement de MASTER dans une configuration avec plusieurs secours pointant sur le même master. (Je ne parle pas du cas d'un "cascading" de serveurs de secours).

Le mode de réplication n'étant pas précisé, j'en ai déduit qu'on parlait de log shipping et/ou de réplication par flux.

A l'époque de ce document, la version PostgreSQL était encore en version 9.3 beta 1.

En effet, voici l'exemple cité dans ce document :

Avant 9.3 : Un clone ne peut pas changer de source

Avec 9.3
• P1 réplique vers R1, R2 et R3.
• P1 est arrêté pour maintenance
• R1 devient le serveur principal
• R2 et R3 se “raccrochent” à R1

Est ce que ceci est possible avec la 9.3 actuelle ou est ce que c'était une amélioration de la réplication qui était prévue pour la 9.3 à l'origine et qui a été repoussé pour une version future?

Si cela est possible, est ce automatique (avec une configuration du recovery.conf) ou faut il raccrocher les autres secours au nouveau maitre à la main?

Toujours, dans le cas où c'est possible, existe il une documentation sur la mise en œuvre d'une telle configuration (plus précisément le rattachement des secours restant sur le nouveau maître)  ?

En effet, j'ai parcouru le chapitre "Haute disponibilité" dans la documentation officielle 9.3.4 mais je n'ai rien trouvé sur ce sujet. (A part le paramètre recovery_target_timeline = 'latest' dans le cas d'un cascading de serveurs).

Merci d'avance pour les réponses que vous pourrez m'apporter.

Cordialement

Bonjour,

Je viens vers vous pour savoir si une sauvegarde à chaud d'une instance Postgres peut être effectuée via bacula?

Je fais des recherches sur le sujet à titre personnel.

J'ai vu que netBackup pouvait le faire via les sauvegardes PITR.

Par contre Bacula qui s'appuye sur une base PostgreSQL pour gérer son catalogue, peut-il servir d'outil de sauvegarde pour le répertoire PGDATA d'une instance?

Avez vous des informations sur ce point?   

Je vous remercie d'avance.

Cordialement.