Vous n'êtes pas identifié(e).
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>&1Je 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
Hors ligne
Juste une petite précision pour le 'Reindex'.
Sur les serveurs de Prod, nous créons un nouvel index (identiques à celui que l'on souhaite ré-indexer) en mode "CONCURRENTLY" puis je supprime le vieux et je renomme le nouveau.
Exemple pour l'index idx_patate :
SQL> create index CONCURRENTLY idx_patate_prov on la_table(la_colonne1, la_colonne2);
...
SQL> drop index idx_patate;
...
SQL> alter index idx_patate_prov rename to idx_patate;Et Zou !
Hors ligne
Merci pour ta réponse arthurr !
En fait je n'ai pas de souci sur les locks en écriture (je peux me permettre de ne pas écrire qqtemps sur mes tables) mais en lecture! Et hier quand j'ai fait mon réindex mes requêtes (uniquement des select) sur mon slave étaient en WAITING (ce que je comprends pas bien car je pensais que c'était au moins accessible en lecture)).
Cependant ta méthode me plait car je pourrai directement créer ce nouvel index dans mon nouveau tablespace, droper l'ancien et renommer le nouveau et hop ! ainsi j'éviterai les différents locks non ?
Hors ligne
Avec le concurrently on n'a plus qu'en verrou 'share update exclusive' sur la table (qui permet les mises à jour)
Sans le concurrently, on a un verrou 'share' (qui empêche les mises à jour)
Reindex (index ou table) prend un 'access exclusive' (qui bloque les mises à jour) sur les index. Il peut (il va probablement…) bloquer les select qui auront besoin d'accéder au catalogue pendant la reconstruction de l'index (pour planifier une requête): ces select auront besoin de prendre un access share sur l'index. Une requête déjà préparée qui n'utilise pas l'index ne sera pas bloquée par contre.
Marc.
Hors ligne
super ! merci pour ces précisions Marc.
j'ai une question un peu bête du coup mais si je décide d'opter pour recréer l'index... à un moment il y aura 2 indexes avec des noms différents mais avec le même contenu, comment se comporte postgres dans ce cas là ?
Hors ligne
Il va probablement prendre le plus petit, ça sera celui qu'il estimera comme étant le moins cher à utiliser.
Marc.
Hors ligne
merci beaucoup !
je vais donc lancer une petite campagne de creation d'indexes sur mon nouveau tablespace 
Hors ligne