PostgreSQLLa base de données la plus sophistiquée au monde.

Version anglaise

46.4. Protocole de réplication en continu

Pour initier la réplication en flux continu, le client envoi le paramètre replication dans son message d'ouverture. Il indique au serveur de se placer en mode walsender dans lequel en petit ensemble de commandes de réplication peuvent être utilisées à la place d'ordres SQL. Dans le mode walsender, seul le protocole de requête simple est disponible. Les commandes acceptées en mode walsender sont:

IDENTIFY_SYSTEM

Demande au serveur de s'identifier. Le serveur répond avec un set de résultat d'une seule ligne contenant trois champs:

systemid

L'identifiant système unique du cluster. Il peut être utilisé pour vérifier que la base de sauvegarde utilisée pour initialiser le serveur en attente provient du même cluster.

timeline

TimelineID courant. Tout aussi utile pour vérifier que le serveur en attente est consistant avec le maître.

xlogpos

Emmplacement de vidage courant des journaux de transactions. Utile pour connaître un emplacement dans les journaux de transactions à partir duquel le mode de réplication en flux peut commencer.

START_REPLICATION XXX/XXX

Demande au serveur de débuter l'envoi de WAL en continu, en commençant à la position XXX/XXX dans le WAL. Le serveur peu répondre avec une erreur, par exemple si la section de WAL demandée a déjà été recyclée. En cas de succès, le serveur répond avec un message CopyBothResponse et débute l'envoi en continu de WAL au client. Les WAL seront envoyé en continu jusqu'à ce que la connexion soit interrompue ; aucune autre commande ne sera acceptée.

Les données des WAL sont envoyées en une série de messages CopyData (ce qui permet d'envoyer d'autre informations dans les intervalles ; en particulier un serveur peut envoyer un message ErrorResponse s'il rencontre une erreur après la début de l'envoi en continu des données). Le contenu de chaque message CopyData suit le format suivant:

XLogData (B)
Byte1('w')

Identifie le message comme une donnée de WAL.

Byte8

Le point de départ de la donnée du WAL dans ce message, donné au format XLogRecPtr.

Byte8

Le fin courante du WAL sur le serveur, donné au format XLogRecPtr

Byte8

L'horloge système du serveur à l'heure de la transmission, donné au format TimestampTz.

Byten

Une section de donnée du flux de WAL.

Une entrée de WAL n'est jamais découpée dans deux messages CopyData. Cependant, lorsqu'une entrée bute sur la fin d'une page de WAL, et est par conséquent divisée en utilisant des enregistrements de suite, elle peut être divisée sur la fin de la page. En d'autre terme, le premier enregistrement principal et les autres de suite peuvent êtres envoyés dans différents messages CopyData.

À noter que tous les champs à l'intérieur d'une donnée de WAL et les entêtes décrites précédemment seront envoyés au format natif du serveur. L'endianisme et le format de timestamp ne sont pas prévsible à moins que le receveur ait vérifié que l'identifiant système de l'émeteur corresponde au contenu de son propre pg_control.

Si le processus d'émission de WAL se termine correctement (pendant l'arrêt du postmaster), il enverra un message CommandComplete avant de s'arrêter. Ce message pourrait évidement ne pas être envoyé en cas d'arrêt brutal.

Le processus de réception peut envoyer ses réponses à l'émetteur à tout moment, en utilisant un des formats de message suivants (ainsi que dans la charge d'un message CopyData) :

Message principal de keepalive (B)
Byte1('k')

Identifie le message comme un keepalive émis.

Byte8

La fin actuelle du journal de transactions sur le serveur, donnée au format XLogRecPtr.

Byte8

L'horloge système du serveur au moment de la transmission, donnée au format TimestampTz.

Mise à jour du statut du serveur en standby (F)
Byte1('r')

Identifie le message comme une mise à jour du statut du réceptionneur.

Byte8

L'emplacement du dernier octet des journaux de transactions + 1 reçu et écrit sur le disque du serveur en standby, dans le format XLogRecPtr.

Byte8

L'emplacement du dernier octet des journaux de transactions + 1 poussé sur le disque du serveur en standby, dans le format XLogRecPtr.

Byte8

L'emplacement du dernier octet des journaux de transactions + 1 appliqué sur le disque du serveur en standby, dans le format XLogRecPtr.

Byte8

L'horloge système du serveur au moment de la transmission, au format TimestampTz.

Message de réponse Hot Standby (F)
Byte1('h')

Identifie le message comme un message de réponse Hot Standby.

Byte8

L'horloge système du serveur au moment de la transmission, au format TimestampTz.

Byte4

Le xmin courant du serveur en standby. Cela peut valoir 0 si le standby envoit des notifications que le retour du Hot Standby ne va pas renvoyer sur cette connexion. Les messages suivants différents de 0 pourraient réinitier le mécanisme de retour d'informations.

Byte4

Le epoch courant du serveur en standby.

BASE_BACKUP [LABEL 'label'] [PROGRESS] [FAST] [WAL] [NOWAIT]

Demande au serveur de commencer l'envoi d'une sauvegarde de base. Le système sera mis automatiquement en mode sauvegarde avant que celle-ci ne commence et en sera sorti une fois la sauvegarde terminée. Les options suivantes sont acceptées :

LABEL 'label'

Précise le label de la sauvegarde. Si aucun label n'est indiqué, le label utilisé est base backup. Les règles de mise entre guillemets du label sont les mêmes que pour une chaîne SQL standard avec standard_conforming_strings activé.

PROGRESS

Demande la génération d'un rapport de progression. Cela enverra la taille approximative dans l'en-tête de chaque tablespace, qui peut être utilisé pour calculer ce qu'il reste à récupérer. La taille est calculée en énumérant la taille de tous les fichiers avant de commencer le transfert. Du coup, il est possible que cela ait un impact négatif sur les performances. En particulier, la première donnée peut mettre du temps à être envoyée. De plus, comme les fichiers de la base de données peuvent être modifiés pendant la sauvegarde, la taille est seulement approximative et peut soit grandir, soit diminuer entre le moment de son calcul initial et le moment où les fichiers sont envoyés.

FAST

Demande un checkpoint rapide.

WAL

Inclut les journaux de transactions nécessaires dans la sauvegarde. Cela inclue tous les fichiers entre le début et la fin de la sauvegarde de base dans le répertoire pg_xlog dans l'archive tar.

NOWAIT

Par défaut, la sauvegarde attendra que le dernier journal de transactions requis soit archivé ou émettra un message d'avertissement si l'archivage des journaux de transactions n'est pas activé. Indiquer NOWAIT désactive les deux (l'attente et le message), laissant le client responsable de la disponibilité des journaux de transactions requis.

Quand la sauvegarde est lancée, le serveur enverra tout d'abord deux ensembles de résultats standards, suivis par un ou plusieurs résultats de CopyResponse.

Le premier ensemble de résultats standard contient la position de démarrage de la sauvegarde, dans un format XLogRecPtr en tant que colonne seule sur une seule ligne.

Le deuxième ensemble de résultats standard contient une ligne pour chaque tablespace. Voici la liste des champs d'une telle ligne :

spcoid

L'OID du tablespace, ou NULL s'il s'agit du répertoire de données.

spclocation

Le chemin complet du répertoire du tablespace, ou NULL s'il s'agit du répertoire de données.

size

La taille approximative du tablespace, si le rapport de progression a été demandé. NULL sinon.

Après l'envoi du deuxième ensemble standard de résultats, un ou plusieurs résultats de type CopyResponse seront envoyés, un pour PGDATA et un pour chaque tablespace supplémentaire, autre que pg_default et pg_global. Les données dans les résultats de type CopyResponse seront un format tar (en suivant le « format d'échange ustar » spécifié dans le standard POSIX 1003.1-2008) du contenu du tablespace, sauf que les deux blocs de zéros à la fin indiqués dans le standard sont omis. Après que l'envoi des données du tar est terminé, un ensemble final de résultats sera envoyé.

L'archive tar du répertoire des données et de chaque tablespace contiendra tous les fichiers du répertoire, que ce soit des fichiers PostgreSQL™ ou des fichiers ajoutés dans le même répertoire. Les seuls fichiers exclus sont :

  • postmaster.pid

  • postmaster.opts

  • pg_xlog, ainsi que les sous-répertoires. Si la sauvegarde est lancée avec ajout des journaux de transactions, une version synthéthisée de pg_xlog sera inclus mais elle ne contiendra que les fichiers nécessaires au bon fonctionnement de la sauvegarde, et pas le reste de son contenu.

Le propriétaire, le groupe et les droits du fichier sont conservés si le système de fichiers du serveur le permet.

Une fois que tous les tablespaces ont été envoyés, un ensemble de résultats final est envoyé. Cet ensemble contient la position finale de la sauvegarde, dans un format XLogRecPtr sur une seule colonne et une seule ligne.