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 24.4, « Serveurs de secours semi-automatique (Warm Standby) pour la haute disponibilité »).
Les fonctionnalités de pg_standby incluent :
Écrit en C, donc très portable et facile à installer
Code source facile à modifier, avec des sections spécialement conçues pour modifier selon vos besoins
Déjà testé sur Linux et Windows
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.
La syntaxe complète de la ligne de commande de pg_standby est :
pg_standby [ option ... ] archivelocation nextwalfile xlogfilepath [ restartwalfile ]
Lorsqu'il est utilisé avec restore_command, les macros %f et %p doivent être spécifiées pour, respectivement, nextwalfile et xlogfilepath, ce qui fournit ainsi le fichier réel et le chemin requis pour la restauration.
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.
Tableau F.23. Options de pg_standby
| Option | Valeur par défaut | Description |
|---|---|---|
| -c | yes | Utilise la commande cp ou copy pour restaurer les journaux de transaction à partir de l'archive. |
| -d | no | Affiche de nombreux messages de débogage sur stderr. |
| -k nb_fichiers | 0 | 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 fichiers 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 | 3 | 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 sleeptime | 5 | Initialise le nombre de seconde (jusqu'à 60) d'endormissement entre les tests pour voir si le journal de transaction à restaurer est disponible à partir de l'archive. La configuration par défaut n'est pas forcément recommandée ; consultez Section 24.4, « Serveurs de secours semi-automatique (Warm Standby) pour la haute disponibilité » pour plus d'informations. |
| -t triggerfile | none | 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 un mêms système ; par exemple /tmp/pgsql.trigger.5442. |
| -w maxwaittime | 0 | Configure le nombre maximum de secondes après lequel une bascule du maître sera exécuté. Si le délai est écoulé, la restauration s'arrête et le serveur en attente devient disponible. 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 24.4, « Serveurs de secours semi-automatique (Warm Standby) pour la haute disponibilité » pour plus d'informations. |
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_standby est conçu pour fonctionner avec PostgreSQL™ 8.2 et ultérieurs.
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 de l'archive est démandé. Cette option reste disponible en 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.
Simon Riggs <simon@2ndquadrant.com>
pgrowlocks
