| > > > | |
 pgrowlocks
|
pgstattuple
|
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 :
Support de la copie et de la création de lien pour restaurer les journaux de transaction
É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.
Tableau F.26. 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. |
| -l | no | Utilise la commande ln pour restaurer les journaux de transactions depuis l'archive. Le lien est plus efficace que la copie mais la valeur par défaut est la copie car le lien ne fonctionne pas dans tous les scénarios. Sur Windows, cette option utilise la commande mklink qui fournir un lien symbolique de fichier à fichier. -l ne fonctionnera pas sur les versions de Windows antérieures à Vista. |
| -r maxretries | 3 | Configure le nombre maximum de tentatives pour la commande de copie ou de lien 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 l'arrêt de la restauration et la disponibilité du serveur que le prochain journal de transaction soit présent ou pas. 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 à attendre pour obtenir le prochain journal de transaction. 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. |
![[Attention]](images/caution.png)
Il est essentiel que le fichier trigger soit créé avec des droits permettant au processus postgres de supprimer ce fichier. Généralement, cela se fait en créant le fichier à partir du compte utilisateur postgres. Si ce n'est pas fait, cela empêchera la fin de la restauration des journaux de transactions et la mise en ligne du serveur PostgreSQL.
![[Note]](images/note.png)
--help n'est pas accepté car pg_standby n'a pas pour but d'être utilisé de façon interactive, sauf lors des développements et lors des tests.
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 -l -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2>>standby.log'
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).
utilisation de la commande ln pour restaurer les journaux de transaction à partir de l'archive
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
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'
Notez que les antislashs doivent être doublés dans archive_command, mais pas dans restore_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
supprimer les fichiers inutiles du répertoire des archives
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.
Simon Riggs <simon@2ndquadrant.com>
