pg_standby — permet la création d'un serveur PostgreSQL™ en Warm Standby
pg_standby [option...] archivelocation nextwalfile xlogfilepath [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 25.2, « Serveurs de Standby par transfert de journaux »).
Pour configurer un serveur en attente à utiliser pg_standby, placez ceci dans le fichier de configuration recovery.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 :
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.
Affiche de nombreux messages de débogage sur stderr.
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.
Set the maximum number of times to retry the copy command if it fails (default 3). After each failure, we wait for sleeptime * num_retries so that the wait time increases progressively. So by default, we will wait 5 secs, 10 secs, then 15 secs before reporting the failure back to the standby server. This will be interpreted as end of recovery and the standby will come up fully as a result. 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.
Initialise 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 25.2, « Serveurs de Standby par transfert de journaux » pour plus d'informations.
Specify a trigger file whose presence should cause failover. It is recommended that you use a structured filename to avoid confusion as to which server is being triggered when multiple servers exist on the same system; for example /tmp/pgsql.trigger.5432. 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.
Affiche la version de pg_standby, puis quitte.
Configure 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 25.2, « Serveurs de Standby par transfert de journaux » pour plus d'informations.
Affiche 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.
pg_archivecleanup
