 Types de données des message
|
 
|
Formats de message
|
Pour initier la réplication en flux continu, le client envoi le paramètre replication dans son message d'ouverture. Une valeur booléenne true indique au processus serveur de basculer en mode walsender, où un petit ensemble de commandes de réplication peut être exécuté à la place de requêtes SQL. Seul le protocole simple de requêtes peut être utilisé dans le mode walsender. Les commandes de réplication sont tracées dans les fichiers du serveur quand le paramètre log_replication_commands est activé. Passer database comme valeur indique au walsender de se connecter à la base spécifiée dans le paramètre dbname, ce qui permettra l'utilisation de la connexion pour la réplication logique de cette base de données.
Pour tester les commandes de réplication, vous pouvez réaliser une connexion de réplication via psql ou tout autre outil utilisant libpq avec une chaîne de connexion utilisant l'option replication, par exemple :
psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
Néanmoins, il est souvent plus utile d'utiliser pg_receivexlog (pour la réplication physique) ou pg_recvlogical (pour la réplication logique).
Les commandes acceptées en mode walsender sont:
Demande au serveur de s'identifier. Le serveur répond avec un set de résultat d'une seule ligne contenant quatre champs:
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.
TimelineID courant. Tout aussi utile pour vérifier que le serveur en attente est consistant avec le maître.
Emplacement 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.
Base de données connectée ou NULL.
Demande au serveur l'envoi du fichier historique de la ligne de temps tli. Le serveur réponds avec un résultat sur une seule ligne, contenant deux champs :
Nom du fichier de l'historique de la ligne de temps, par exemple 00000002.history.
Contenu du fichier historique de la ligne de temps.
Crée un slot de réplication physique ou logique. Voir Section 25.2.6, « Slots de réplication » pour plus d'informations sur les slots de réplication.
Le nom du slot à créer. Doit être un nom d'un slot de réplication valide (voir Section 25.2.6.1, « Requêter et manipuler des slots de réplication »).
Le nom d'un plugin en sortie utilisé pour le décodage logique (voir Section 46.6, « Plugins de sortie de décodage logique »).
Demande au serveur de débuter l'envoi de WAL en continu, en commençant à la position XXX/XXX dans le WAL. Si l'option TIMELINE est spécifiée, le flux commence sur la timeligne tli. Dans le cas contraire, la timeline actuelle du serveur est utilisée. 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.
Si un nom de slot est fourni via nom_slot, il sera mis à jour au fur et à mesure de la progression de la réplication pour que le serveur maître connaisse les segments WAL sont toujours nécessaires pour le serveur standby. Si hot_standby_feedback est activé, la granularité est au niveau de chaque transaction.
Si le client demande une ligne de temps qui ne correspond pas à la dernière ligne de temps mais qui fait néanmoins partie de l'historique du serveur, le serveur va envoyer tous les journaux de transactions en commençant à partir de point de démarrage demandé sur cette ligne de temps, jusqu'à arriver au moment où le serveur a changé de nouveau de ligne de temps. Si le client réclame l'envoi à partir de la fin de l'ancienne ligne de temps, le serveur réponds immédiatement avec CommandComplete sans entrer en mode COPY.
Après l'envoi de tous les journaux de transactions sur une ligne de temps qui n'est pas la dernière, le serveur arrêtera le flux en quittant le mode COPY. Quand le client accepte ceci en quittant lui-aussi le mode COPY, le serveur envoie un ensemble de résultats comprenant une ligne et deux colonnes, indiquant la prochaine timeline dans l'histoire de ce serveur. La première colonne est l'identifiant de la prochaine timeline et la deuxième colonne est la position XLOG où la bascule a eu lieu. Généralement, la position de la bascule correspond à la fin du journal de transactions qui a été envoyé mais il existe des cas particuliers où le serveur peut envoyer quelques enregistrements de journaux à partir de l'ancienne timeline qu'il n'a pas encore rejoué avant la promotion. Enfin, le serveur envoie la commande CommandComplete message, et est prêt à accepter une nouvelle commande.
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 à partir du serveur vers le client contient un message faisant partie d'un des formats suivants :
Identifie le message comme une donnée de WAL.
Le point de départ de la donnée du WAL dans ce message.
Le fin courante du WAL sur le serveur.
L'horloge système du serveur à l'heure de la transmission, en microsecondes à partir du 1er janvier 2000, à minuit.
Une section de donnée du flux de WAL.
Un enregistrement d'un journal de transactions n'est jamais divisé en deux messages XLogData. Quand un enregistrement dépasse la limite d'une page d'un journal de transactions, et est de ce fait déjà divisé en utilisant les enregistrements de suivi, il peut être divisé sur la limite de la page. En d'autres termes, le premier enregistrement principal d'un journal de transactions et ses enregistrements de suivi peuvent être envoyés sur différents messages XLogData.
Identifie le message comme un keepalive émis.
La fin actuelle du journal de transactions sur le serveur.
L'horloge système du serveur au moment de la transmission, en microsecondes depuis le 1er janvier 2000 à minuit.
1 signifie que le client doit répondre à ce message dès que possible pour éviter une déconnexion après délai. 0 dans les autres cas.
Le processus en réception répond à l'envoyeur à tout moment en utilisant un des formats de message suivants (aussi dans la charge d'un message CopyData) :
Identifie le message comme une mise à jour du statut du réceptionneur.
L'emplacement du dernier octet des journaux de transactions + 1 reçu et écrit sur le disque du serveur en standby.
L'emplacement du dernier octet du journal de transactions + 1 poussé sur le standby.
L'emplacement du dernier octet du journal de transactions + 1 appliqué sur le standby.
L'horloge système du client au moment de la transmission, en microsecondes depuis le 1er janvier 2000 à minuit.
Si 1, le client demande une réponse immédiate du serveur à ce message. Cela peut être utilisé pour tester si la connexion est toujours bonne.
Identifie le message comme un message de réponse Hot Standby.
L'horloge système du client au moment de la transmission, en microsecondes depuis le 1er janvier 2000 à minuit.
Le xmin courant du serveur standby. Il peut valoir 0 si le standby envoie des notifications pour indiquer que le retour Hot Standby ne sera plus nécessaire pour cette connexion. Les messages suivants différents de zéro peuvent reinitialiser le mécanisme de retour.
Le epoch courant du serveur en standby.
Indique au serveur de commencer le flux de réplication pour de la réplication logique, en commençant à la position XXX/XXX dans le journal des transactions. Le serveur peut répondre avec une erreur, par exemple si la section demandée du journal de transactions a déjà été recyclée. En cas de succès, le serveur répond avec un message CopyBothResponse, puis commence à envoyer le flux vers le client.
Les messages à l'intérieur du message CopyBothResponse sont du même format que ceux documentés pour START_REPLICATION ... PHYSICAL.
Le plugin en sortie associé avec le slot sélectionné est utilisé pour traiter la sortie pour le flux.
Le nom du slot. Ce paramètre est requis et doit correspond à un slot de réplication existant créé avec CREATE_REPLICATION_SLOT en mode LOGICAL.
La position WAL où commencer le flux.
Le nom d'une option passée au plugin de décodage logique du slot.
Une valeur en option, sous la forme d'une chaîne de caractères, associée à l'option indiquée.
Supprime un slot de réplication, libérant toute ressource réservée du côté serveur. Si le slot est en cours d'utilisation par une connexion active, cette commande échoue.
Le nom du slot à supprimer.
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 :
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é.
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.
Demande un checkpoint rapide.
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.
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.
Limite la quantité maximale de données transférées du serveur au client par unité de temps. L'unité attendue est le Ko/s. Si cette option est indiquée, la valeur doit être soit égale à zéro, soit être comprise entre 32 Ko et 1 Go (inclus). Si zéro est passé ou que l'option n'est pas indiquée, aucune restriction n'est imposée sur le transfert.
Inclut les informations sur les liens symboliques présents dans le répertoire pg_tblspc dans un fichier nommé tablespace_map. Le fichier de correspondance des tablespaces inclut les noms des liens symboliques tels qu'ils existent dans le répertoire pg_tblspc/ et le chemin complet de ce lien symbolique.
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 une seule ligne avec deux colonnes. La première colonne contient la position de départ donnée dans le format XLogRecPtr, et la deuxième colonne contient l'identifiant correspondant de la ligne de temps.
Le deuxième ensemble de résultats standard contient une ligne pour chaque tablespace. Voici la liste des champs d'une telle ligne :
L'OID du tablespace, ou NULL s'il s'agit du répertoire de données.
Le chemin complet du répertoire du tablespace, ou NULL s'il s'agit du répertoire de données.
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é, contenant la position finale de la sauvegarde dans les journaux de transactions, au même format que la position de départ.
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
différents fichiers temporaires créés pendant l'opération du serveur PostgreSQL
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.
pg_replslot est copiée sous la forme d'un répertoire vide.
Les fichiers autres que les fichiers standards et les répertoires (par exemple les liens symboliques et les fichiers périphériques) sont ignorés. (Les liens symboliques dans pg_tblspc sont maintenus.)
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.