pg_standby — permet la création d'un serveur PostgreSQL en Warm Standby
pg_standby [option...] archivelocation nextwalfile walfilepath [restartwalfile]
pg_standby facilite la création d'un serveur en attente (« warm standby server »). Il est conçu pour être immédiatement utilisable, mais peut aussi être facilement personnalisé si vous en avez le besoin.
pg_standby s'utilise au niveau du paramètre
restore_command. IL est utile pour transformer une
récupération d'archives ordinaire en restauration en attente. Une autre
configuration est nécessaire, elle est décrite dans le manuel du serveur
(voir Section 26.2).
Pour configurer un serveur en attente à utiliser
pg_standby, placez ceci dans le fichier de
configuration postgresql.conf :
restore_command = 'pg_standby archiveDir %f %p %r'
où archiveDir est le répertoire à partir duquel
les journaux de transaction seront restaurés.
Si restartwalfile est spécifié, normalement en
utilisant la macro %r, alors tous les journaux de
transactions précédant logiquement ce fichier seront supprimés de
archivelocation. Ceci minimise le nombre de
fichiers à conserver tout en préservant la possibilité de redémarrer après
un crash. L'utilisation de ce paramètre est appropriée si
archivelocation est une aire pour ce serveur en
attente particulier mais ne convient pas quand
archivelocation est prévu pour un archivage à
long terme des journaux de transaction.
pg_standby suppose que
archivelocation est un répertoire lisible par
l'utilisateur qui exécute le serveur. Si
restartwalfile (ou l'option -k)
est spécifié, le répertoire archivelocation
doit être accessible aussi en écriture.
Il existe deux façons de basculer un serveur « en attente » quand le maître échoue :
Dans une bascule intelligente, le serveur est disponible après avoir
appliqué tous les fichiers des journaux de transactions dans l'archive.
Cela résulte en une perte nulle, même si le serveur en attente n'était
pas complètement à jour. Du coup, s'il restait beaucoup de journaux à
ré-exécuter, cela peut prendre un long moment avant que le serveur en
attente devienne disponible. Pour déclencher une bascule intelligente,
créez un fichier trigger contenant le mot smart,
ou créez-le en le laissant vide.
Lors d'une bascule rapide, le serveur est disponible immédiatement. Tout
journal de transaction non rejoué sera ignoré. Du coup, toutes les
transactions contenues dans ces fichiers seront perdues. Pour déclencher
une bascule rapide, créez un fichier trigger contenant le mot
fast. pg_standby peut aussi
être configuré pour basculer automatiquement si aucun nouveau journal de
transactions n'apparaît dans un certain laps de temps.
pg_standby accepte les arguments suivantes en ligne de commande :
-c
Utilise la commande cp ou copy
pour restaurer les journaux de transaction à partir de l'archive. C'est
le seul comportement supporté donc cette option est inutile.
-d
Affiche de nombreux messages de débogage sur stderr.
-k
Supprime les fichiers de archivelocation
pour qu'il n'existe pas plus de ce nombre de journaux de transactions
avant le journal actuel dans l'archive. Zéro (la valeur par défaut)
signifie qu'il ne supprime aucun fichier de
archivelocation. Ce paramètre sera ignoré
si restartwalfile est spécifié car cette
méthode de spécification est plus fiable dans la détermination du
point correct de séparation des archives. L'utilisation de ce paramètre
est obsolète dès
PostgreSQL 8.3 ; il est préférable
et plus efficace d'utiliser le paramètre
restartwalfile. Une configuration trop
basse pourrait résulter en des suppressions de journaux qui sont toujours
nécessaire pour un relancement du serveur en attente alors qu'un
paramétrage trop important aurait pour conséquence un gachis en
espace disque.
-r maxretries
Configure le nombre maximum de tentatives pour la commande de copie si
celle-ci échoue. Après chaque échec, l'attente est de
sleeptime * num_retries
pour que le temps d'attente augmente progressivement. Donc, par défaut,
l'outil attend 5 secondes, puis 10, puis 15 avant de rapporter l'échec
au serveur en attente. Cela sera interprété comme une fin de
récupération par le serveur en attente, ce qui aura pour conséquence
que le serveur en attente deviendra disponible.
-s sleeptimeInitialise le nombre de seconde (jusqu'à 60, par défaut 5) d'endormissement entre les tests pour voir si le journal de transactions à restaurer est disponible à partir de l'archive. La configuration par défaut n'est pas forcément recommandée ; consultez Section 26.2 pour plus d'informations.
-t triggerfile
Spécifie un fichier trigger dont la présence cause une bascule du
serveur maître. Il est recommandé que vous utilisiez un nom de fichier
structuré pour éviter la confusion sur le serveur à déclencher au cas
où plusieurs serveurs existent sur le même système ; par exemple
/tmp/pgsql.trigger.5442.
-V--versionAffiche la version de pg_standby, puis quitte.
-w maxwaittimeConfigure le nombre maximum de secondes pour attendre le prochain journal de transactions, délai après lequel une bascule du maître est automatique exécuté. Une configuration à zéro (la valeur par défaut) fait qu'il attend indéfiniment. La valeur par défaut n'est pas forcément recommandée ; voir Section 26.2 pour plus d'informations.
-?--helpAffiche l'aide sur les arguments en ligne de commande de pg_standby, puis quitte.
pg_standby est conçu pour fonctionner à partir de PostgreSQL 8.2.
PostgreSQL 8.3 fournit la macro %r,
qui est conçue pour indiquer à pg_standby le dernier fichier
qu'il a besoin de conserver. Avec PostgreSQL 8.2, l'option
-k doit être utilisée si le nettoyage des archives est
demandé. Cette option est toujours présente dans la version 8.3, mais est devenue
obsolète.
PostgreSQL 8.4 fournit le paramètre
recovery_end_command. Sans lui, il est possible de laisser
un fichier trigger, ce qui comporte un risque.
pg_standby est écrit en C et est donc très portable et facile à modifier, avec des sections spécialement conçues pour être modifiées selon vos besoins.
Sur des systèmes Linux ou Unix, vous pouvez utiliser (le premier paramètre concerne le maître, le second concerne l'esclave) :
archive_command = 'cp %p .../archive/%f' restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2>>standby.log' recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'
alors que le répertoire d'archive est situé physiquement sur le serveur
en attente, de façon à ce que archive_command y
accède via un montage NFS, mais les fichiers sont en local pour le serveur
en attente (ce qui permet l'utilisation de ln).
produit une sortie de débogage dans standby.log
s'endort pour deux secondes entre les vérifications de disponibilité du prochain journal de transaction
arrête l'attente seulement quand un fichier trigger nommé
/tmp/pgsql.trigger.5442 apparaît,
et exécute la bascule suivant son contenu
supprime le fichier trigger quand la restauration se termine
supprime les fichiers inutiles du répertoire des archives
Sur Windows, vous pouvez utiliser :
archive_command = 'copy %p ...\\archive\\%f' restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p %r 2>>standby.log' recovery_end_command = 'del C:\pgsql.trigger.5442'
Notez que les antislashs doivent être doublés dans
archive_command, mais pas dans
restore_command ou recovery_end_command.
Cela va :
utiliser la commande copy pour restaurer les journaux
de transaction à partir de l'archive
produire une sortie de débogage dans standby.log
l'endormir pendant cinq secondes entre les vérifications de disponibilité du prochain journal de transaction
arrêter l'attente seulement quand un fichier trigger nommé
C:\pgsql.trigger.5442 apparaît,
et exécuter la bascule suivant son contenu
supprimer le fichier trigger quand la restauration se termine
supprimer les fichiers inutiles du répertoire des archives
La commande copy sur Windows configure la taille du
fichier final avant que le fichier ne soit entièrement copié, ce qui pourrait
gêner pg_standby. Du coup,
pg_standby attend sleeptime
secondes une fois qu'il a remarqué que le fichier faisait la bonne taille.
cp de GNUWin32 configure la taille du fichier seulement
lorsque la copie du fichier est terminée.
Comme l'exemple Windows utilise copy aux deux bouts,
soit l'un soit les deux serveurs pourront accéder au répertoire d'archive
via le réseau.
Simon Riggs <simon@2ndquadrant.com>