Forums PostgreSQL.fr

ebs

Membre

[Hot Standby Replication] Mise en pause de la replication

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

arthurr

Membre

Re : [Hot Standby Replication] Mise en pause de la replication

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 !

ebs

Membre

Re : [Hot Standby Replication] Mise en pause de la replication

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 ?

Marc Cousin

Membre

Re : [Hot Standby Replication] Mise en pause de la replication

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.

ebs

Membre

Re : [Hot Standby Replication] Mise en pause de la replication

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à ?

Marc Cousin

Membre

Re : [Hot Standby Replication] Mise en pause de la replication

Il va probablement prendre le plus petit, ça sera celui qu'il estimera comme étant le moins cher à utiliser.

---

Marc.

ebs

Membre

Re : [Hot Standby Replication] Mise en pause de la replication

merci beaucoup !
je vais donc lancer une petite campagne de creation d'indexes sur mon nouveau tablespace