Bonjour,

Je suis dans le cas suivant:
- deux serveurs postgresql (un maître et un esclave) synchronisé via une réplication hot stand by par wal shipping. - postgresql v9.1 installé via les packages backports Debian Squeeze
- un pgpool a été configuré en front par lequel toutes les lectures passent qui est configuré en failover (le poids du slave est 1000 > à celui du master qui ne sert donc que si le slave n'est plus dispo) et en connection pooler (connection_life_time = 300 afin d'éviter l'overhead de la reconnection) - pgpool 3.0.5 compilé à partir des sources

Reprenons le cas suivant:
- depuis un client j'ouvre une première connexion en passant par pgpool que je laisse ouverte : je vois bien un process au niveau de pgpool et un au niveau de mon serveur slave - OK
- je referme cette connexion : la connexion sur pgpool mais la connexion sur mon serveur slave est toujours présente (cf. connection_life_time) - OK
- depuis le même client sur la même base et avec le même user j'ouvre à nouveau une connexion juste pour faire un "select 1" via pgpool : je vois qu'un nouveau process sur mon serveur slave est créé et donc j'ai 2 connexions - NOK

pourquoi lors de cette dernière connexion, il ne réutilise pas la session idle qui reste ouverte ?

si vous avez des pistes je suis preneur.
merci d'avance !
/Erwan

Bonjour,

J'ai une question un peu candide sur l'activation/désactivation des logs d'un serveur postgresql v9.1 (installé via les packages backports debian)

Jusqu'à présent j'avais fait deux fichiers de configuration, l'une ou j'active les logs et l'autre ou ces derniers sont disablés. Je jongle entre les deux configurations lorsque je veux faire tourner un pgfouine sur mes logs
Voici les parties qui différent

conf avec activation des logs:

log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d-%H.log'
log_rotation_age = 60
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration = on
log_error_verbosity = default
log_hostname = on
log_line_prefix = '%t [%p]: [%l-1] '
log_statement = 'all'

conf avec désactivation des logs:

log_destination = 'stderr'
logging_collector = off
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d-%H.log'
log_rotation_age = 60
log_checkpoints = off
log_connections = off
log_disconnections = off
log_duration = off
log_error_verbosity = default
log_hostname = off
log_line_prefix = '%t [%p]: [%l-1] '
log_statement = 'none'

Tout ceci fonctionne bien sauf que je ne peux activer/désactiver mes logs sans faire un restart alors que j'aimerai juste faire un reload à cause du logging_collector qui nécessite un restart du service.

Je voulais donc savoir s'il y avait un best practice sur ce sujet, car une idée bien moche m'est venue à l'idée à savoir d'avoir une conf avec désactivation des logs comme suit:

log_destination = 'stderr'
logging_collector = on      # on active le logging_collector
log_directory = 'pg_log'
log_filename = 'postgresql-no_log' # et en fait pg_log/postgresql-no_log est un symlink vers /dev/null
log_rotation_age = 0                       # on desactive la rotation des logs
log_checkpoints = off
log_connections = off
log_disconnections = off
log_duration = off
log_error_verbosity = default
log_hostname = off
log_line_prefix = '%t [%p]: [%l-1] '
log_statement = 'none'

Ainsi quand je jongle entre mes confs je ne restart jamais le service vu que logging_collector sera toujours "on" mais dans un cas j'écris dans un vrai fichier alors que dans le second je redirige tout vers /dev/null... ça me paraît trop laid et j'imagine que je suis passé à côté de qqchose, donc si vous avez une piste je suis preneur!

Merci d'avance

Bonjour,

Je me permets d'ouvrir à nouveau un thread concernant ma réplication dans un contexte master-slave par une réplication hot standby sur des serveurs PostgreSQL 9.0 (installés via les backports Debian Squeeze).

Suite à mon thread précédent, j'ai bien compris que pour réaliser certaines opérations de maintenance (type réindex, alter de tablespace, full vaccum...) ma base allait être inaccessible en écriture mais aussi en lecture le temps de l'opération.
Cependant j'ai un pgpool-II en frontal par lequel toutes mes requêtes en lecture passent. Mon idée était de stopper la réplication et de rediriger toutes les lectures sur le slave le temps de faire mes opérations de maintenance sur mon master. Une fois ces opérations finies, je réactive la synchro (qui va en fait envoyer tous les WAL générés durant la maintenance) tout en redirigeant toute mes requêtes en lecture sur mon master.
Une fois que mon slave a bien tout rattrapé, alors je peux reconfigurer mon pgpool-II comme avant.

Ce que j'ai fait pour cela est de changer mon script archive_command, en ajoutant la condition suivante: si un fichier témoin existe alors le script sort en "exit 1"

#!/bin/bash
# Script to copy WAL archives to slave servers
# Usage:
# archive_command = '/usr/local/sbin/postgres_archive_command %p %f'


FILE_SRC="$1"
FILE_DEST="/var/lib/postgresql/wal_hot_standby/$2"
slave="10.0.1.48"
MAIL="plop@plop.com"
LOG="/var/log/postgresql/archives_log_process.log"
DEBUG_VALUE=1
STOP_FILE="/var/run/postgresql/pg_standby-stopfile"

[ $DEBUG_VALUE -ge 1 ] && echo "$0 2.0 - `date` - INFO - start archive log process" >> $LOG 2>&1


if [ -e "$STOP_FILE" ]
then
        echo "$0 2.0 - `date` - WARN - $STOP_FILE exists, archive process suspended..." >> $LOG 2>&1
        exit 1
fi

[ $DEBUG_VALUE -ge 1 ] && echo "$0 2.0 - `date` - INFO - start transfert for $slave" >> $LOG 2>&1
[ $DEBUG_VALUE -ge 1 ] && echo "$0 2.0 - `date` - INFO - scp $FILE_SRC postgres@$slave:$FILE_DEST" >> $LOG 2>&1
scp $FILE_SRC postgres@$slave:$FILE_DEST  >> $LOG 2>&1
if [ $? -ne 0 ] 
then
                echo "$0 2.0 - `date` - ERROR when trying to scp $FILE_SRC postgres@$slave:$FILE_DEST" >> $LOG 2>&1
                (echo -e "Master: `hostname -f`\nSlave: $slave\nFile: $FILE_SRC\nLog: $LOG\n\n") | mail -s "[Postgresql ALERT] error copying wal file $FILE_SRC" $MAIL
                exit 1
fi

[ $DEBUG_VALUE -ge 1 ] && echo "$0 2.0 - `date` - INFO - archive log process done" >> $LOG 2>&1

Je viens de tester et ça semble bien fonctionner... quand je supprime mon fichier témoin les WAL sont bien tous renvoyés et mon slave rattrape son retard. Mais je doutais de la bonne pratique de cette méthode (en imaginant que je n'ai pas de souci de stockage des WALs durant cette opération)

De plus je n'ai pas bien compris pourquoi mon master essaye toutes les minutes de renvoyer les WALs alors qu'en temps normal s'il n'y a pas d'activité, il envoie le WAL toutes les 5 minutes (== checkpoint_timeout)... Sachant que pour mes tests j'ai mis archive_timeout à 30 secondes. J'imagine qu'il y a d'autres paramètres expliquant le "toutes les minutes" mais je ne vois pas bien lequel, si vous avez des pistes je suis preneur!

D'avance, merci beaucoup !
/Erwan