pg_receivexlog - En ligne dans le Cloud

PROGRAMME:

Nom

pg_receivexlog - diffuser les journaux de transactions à partir d'un serveur PostgreSQL

SYNOPSIS

pg_receivexlog [option...]

DESCRIPTION

pg_receivexlog est utilisé pour diffuser le journal des transactions à partir d'un cluster PostgreSQL en cours d'exécution.
Le journal des transactions est diffusé en continu à l'aide du protocole de réplication en continu et est écrit
dans un répertoire local de fichiers. Ce répertoire peut être utilisé comme emplacement d'archivage pour
effectuer une restauration à l'aide d'une restauration à un instant donné (consultez la Section 24.3, « Archivage continu et
Point-in-Time Recovery (PITR) », dans la documentation).

pg_receivexlog diffuse le journal des transactions en temps réel au fur et à mesure qu'il est généré sur le
serveur et n'attend pas la fin des segments comme archive_command. Pour ça
Pour cette raison, il n'est pas nécessaire de définir archive_timeout lors de l'utilisation de pg_receivexlog.

Contrairement au récepteur WAL d'un serveur de secours PostgreSQL, pg_receivexlog par défaut vide
Données WAL uniquement lorsqu'un fichier WAL est fermé. L'option --synchrone doit être spécifié pour
vider les données WAL en temps réel.

Le journal des transactions est diffusé via une connexion PostgreSQL standard et utilise le
protocole de réplication. La connexion doit être établie avec un superutilisateur ou un utilisateur ayant
Autorisations de REPLICATION (voir Section 20.2, « Attributs de rôle », dans la documentation), et
pg_hba.conf doit autoriser la connexion de réplication. Le serveur doit également être configuré
avec max_wal_senders suffisamment élevé pour laisser au moins une session disponible pour le
ruisseau.

Si la connexion est perdue, ou si elle ne peut pas être établie initialement, avec un
erreur, pg_receivexlog réessayera la connexion indéfiniment et rétablira le streaming en tant que
dès que possible. Pour éviter ce comportement, utilisez le paramètre -n.

OPTIONS

-D annuaire
--répertoire=annuaire
Répertoire dans lequel écrire la sortie.

Ce paramètre est obligatoire.

--si-n'existe-pas
Ne vous trompez pas lorsque --create-slot est spécifié et un emplacement avec le spécifié
le nom existe déjà.

-n
--pas de boucle
Ne pas boucler sur les erreurs de connexion. Au lieu de cela, quittez immédiatement avec une erreur.

-s intervalle
--status-intervalle=intervalle
Spécifie le nombre de secondes entre les paquets d'état renvoyés au serveur. Cette
permet une surveillance plus facile de la progression du serveur. Une valeur de zéro désactive le
mises à jour de statut périodiques complètement, bien qu'une mise à jour soit toujours envoyée lorsque
demandé par le serveur, pour éviter le timeout de déconnexion. La valeur par défaut est de 10 secondes.

-S nom de l'emplacement
--emplacement=nom de l'emplacement
Exiger que pg_receivexlog utilise un emplacement de réplication existant (voir Section 25.2.6,
« Slots de réplication », dans la documentation). Lorsque cette option est utilisée, pg_receivexlog
signalera une position de rinçage au serveur, indiquant quand chaque segment a été
synchronisé sur le disque afin que le serveur puisse supprimer ce segment s'il n'en est pas autrement
nécessaire.

Lorsque le client de réplication de pg_receivexlog est configuré sur le serveur en tant que
veille synchrone, puis l'utilisation d'un emplacement de réplication signalera la position de vidage à
le serveur, mais uniquement lorsqu'un fichier WAL est fermé. Par conséquent, cette configuration sera
faire en sorte que les transactions sur le primaire attendent longtemps et ne fonctionnent effectivement pas
de manière satisfaisante. L'option --synchronous (voir ci-dessous) doit être spécifiée en plus de
faire en sorte que cela fonctionne correctement.

--synchrone
Videz les données WAL sur le disque immédiatement après leur réception. Envoyer également un statut
paquet vers le serveur immédiatement après le vidage, indépendamment de --status-interval.

Cette option doit être spécifiée si le client de réplication de pg_receivexlog est
configuré sur le serveur en tant que veille synchrone, pour s'assurer qu'un retour d'information en temps opportun est
envoyé au serveur.

-v
--verbeux
Active le mode détaillé.

Les options de ligne de commande suivantes contrôlent les paramètres de connexion à la base de données.

-d connstr
--nombd=connstr
Spécifie les paramètres utilisés pour se connecter au serveur, sous forme de chaîne de connexion. Voir
Section 31.1.1, « Chaînes de connexion », dans la documentation pour plus d'informations.

L'option s'appelle --dbname par souci de cohérence avec les autres applications clientes, mais
car pg_receivexlog ne se connecte à aucune base de données particulière du cluster,
le nom de la base de données dans la chaîne de connexion sera ignoré.

-h hôte
--hôte=hôte
Spécifie le nom d'hôte de la machine sur laquelle le serveur s'exécute. Si la valeur
commence par une barre oblique, il est utilisé comme répertoire pour le socket de domaine Unix. Les
par défaut est tiré du PGHOST variable d'environnement, si définie, sinon un domaine Unix
la connexion socket est tentée.

-p port
--port=port
Spécifie le port TCP ou l'extension de fichier socket de domaine Unix local sur lequel le serveur
est à l'écoute des connexions. Par défaut à la PGPORT variable d'environnement, si elle est définie, ou
une valeur par défaut compilée.

-U Nom d'utilisateur
--nom d'utilisateur=Nom d'utilisateur
Nom d'utilisateur sous lequel se connecter.

-w
--pas de mot de passe
N'émettez jamais d'invite de mot de passe. Si le serveur requiert une authentification par mot de passe et un
le mot de passe n'est pas disponible par d'autres moyens tels qu'un fichier .pgpass, la connexion
tentative échouera. Cette option peut être utile dans les tâches par lots et les scripts où aucun utilisateur
est présent pour saisir un mot de passe.

-W
--le mot de passe
Forcez pg_receivexlog à demander un mot de passe avant de se connecter à une base de données.

Cette option n'est jamais indispensable, car pg_receivexlog demandera automatiquement un
mot de passe si le serveur demande une authentification par mot de passe. Cependant, pg_receivexlog
gaspiller une tentative de connexion en découvrant que le serveur veut un mot de passe. Dans certains cas
ça vaut la peine de taper -W pour éviter la tentative de connexion supplémentaire.

pg_receivexlog peut effectuer l'une des deux actions suivantes afin de contrôler
emplacements de réplication :

--create-slot
Créez un nouveau slot de réplication physique avec le nom spécifié dans --insérer, puis quittez.

--drop-slot
Supprimez le slot de réplication avec le nom spécifié dans --insérer, puis quittez.

D'autres options sont également disponibles :

-V
--version
Imprimez la version de pg_receivexlog et quittez.

-?
--Aidez-moi
Affichez l'aide sur les arguments de ligne de commande de pg_receivexlog et quittez.

ENVIRONNEMENT

Cet utilitaire, comme la plupart des autres utilitaires PostgreSQL, utilise les variables d'environnement
supporté par libpq (voir Section 31.14, « Variables d'environnement », dans la documentation).

NOTES

Lorsque vous utilisez pg_receivexlog au lieu de archive_command comme méthode de sauvegarde WAL principale, il est
fortement recommandé d'utiliser des emplacements de réplication. Sinon, le serveur est libre de recycler ou
supprimer les fichiers journaux des transactions avant qu'ils ne soient sauvegardés, car il n'a aucun
informations, soit depuis archive_command, soit depuis les emplacements de réplication, sur la distance à laquelle le WAL
le flux a été archivé. Notez cependant qu'un emplacement de réplication remplira le
d'espace disque si le récepteur ne parvient pas à récupérer les données WAL.

EXEMPLES

Pour diffuser le journal des transactions depuis le serveur sur mydbserver et le stocker dans le local
répertoire /usr/local/pgsql/archive :

$ pg_receivexlog -h monserveur -D /usr/local/pgsql/archive

Utilisez pg_receivexlog en ligne en utilisant les services onworks.net