Quand le paramètre hot_standby est configuré à true sur un serveur en attente, le serveur commencera à accepter les connexions une fois que la restauration est parvenue à un état cohérent. Toutes les connexions qui suivront seront des connexions en lecture seule ; même les tables temporaires ne pourront pas être utilisées.

Les données sur le secondaire mettent un certain temps pour arriver du serveur primaire, il y aura donc un délai mesurable entre primaire et secondaire. La même requête exécutée presque simultanément sur le primaire et le secondaire pourrait par conséquent retourner des résultats différents. On dit que la donnée est cohérente à terme avec le primaire. Une fois que l'enregistrement de validation (COMMIT) d'une transaction est rejoué sur le serveur en attente, les modifications réalisées par cette transaction seront visibles par toutes les images de bases obtenues par les transactions en cours sur le serveur en attente. Ces images peuvent être prises au début de chaque requête ou de chaque transaction, suivant le niveau d'isolation des transactions utilisé à ce moment. Pour plus de détails, voir Section 13.2.

Les transactions exécutées pendant la période de restauration sur un serveur en mode hot standby peuvent inclure les commandes suivantes :

Les transactions lancées pendant la restauration d'un serveur en hot standby ne se verront jamais affectées un identifiant de transactions et ne peuvent pas être écrites dans les journaux de transactions. Du coup, les actions suivantes produiront des messages d'erreur :

Dans le cadre normal, les transactions « en lecture seule » permettent l'utilisation des instructions LISTEN et NOTIFY, donc les sessions Hot Standby ont des restrictions légèrement inférieures à celles de sessions en lecture seule ordinaires. Il est possible que certaines des restrictions soient encore moins importantes dans une prochaine version.

Lors du fonctionnement en serveur hot standby, le paramètre transaction_read_only est toujours à true et ne peut pas être modifié. Tant qu'il n'y a pas de tentative de modification sur la base de données, les connexions sur un serveur en hot standby se comportent de façon pratiquement identiques à celles sur un serveur normal. Quand une bascule (failover ou switchover) survient, la base de données bascule dans le mode de traitement normal. Les sessions resteront connectées pendant le changement de mode. Quand le mode hot standby est terminé, il sera possible de lancer des transactions en lecture/écriture, y compris pour les sessions connectées avant la bascule.

Les utilisateurs peuvent déterminer si le Hot Standby est actuellement actif pour leur session en exécutant SHOW in_hot_standby. (Le paramètre in_hot_standby n'existant pas avant la version 14, SHOW transaction_read_only est donc à utiliser sur les serveurs en version plus ancienne.) De plus, un jeu de fonctions (Tableau 9.96) permettent aux utilisateurs d'accéder à des informations à propos du serveur secondaire. Ceci vous permet d'écrire des programmes qui sont conscients de l'état actuel de la base. Vous pouvez vous en servir pour superviser l'avancement de la récupération, ou pour écrire des programmes complexes qui restaurent la base dans des états particuliers.

Les nœuds primaire et secondaire sont faiblement couplés à bien des égards. Des actions sur le primaire auront un effet sur le secondaire. Par conséquent, il y a un risque d'interactions négatives ou de conflits entre eux. Le conflit le plus simple à comprendre est la performance : si un gros chargement de données a lieu sur le primaire, il générera un flux similaire d'enregistrements WAL sur le secondaire, et les requêtes du secondaire pourrait entrer en compétition pour les ressources systèmes, comme les entrées-sorties.

Il y a aussi d'autres types de conflits qui peuvent se produire avec le Hot Standby. Ces conflits sont des conflits durs dans le sens où des requêtes pourraient devoir être annulées et, dans certains cas, des sessions déconnectées, pour les résoudre. L'utilisateur dispose de plusieurs moyens pour gérer ces conflits. Voici les différents cas de conflits possibles :

Sur le serveur primaire, ces cas résultent en une attente supplémentaire ; l'utilisateur peut choisir d'annuler une des actions en conflit. Néanmoins, sur le serveur en attente, il n'y a pas de choix possibles : l'action enregistrée dans les journaux de transactions est déjà survenue sur le serveur primaire et le serveur secondaire doit absolument réussir à l'appliquer. De plus, permettre que l'enregistrement de l'action attende indéfiniment pourrait avoir des effets fortement non désirables car le serveur en attente sera de plus en plus en retard par rapport au primaire. Du coup, un mécanisme est fourni pour forcer l'annulation des requêtes sur le serveur en attente qui entreraient en conflit avec des enregistrements des journaux de transactions en attente.

Voici un exemple de problème type : un administrateur exécute un DROP TABLE sur une table du serveur primaire qui est actuellement utilisé dans des requêtes du serveur en attente. Il est clair que la requête ne peut pas continuer à s'exécuter si l'enregistrement dans les journaux de transactions, correspondant au DROP TABLE est appliqué sur le serveur en attente. Si cette situation survient sur le serveur primaire, l'instruction DROP TABLE attendra jusqu'à ce que l'autre requête se termine. Par contre, quand le DROP TABLE est exécuté sur le serveur primaire, ce dernier ne sait pas les requêtes en cours d'exécution sur le serveur en attente, donc il n'attendra pas la fin de l'exécution des requêtes sur le serveur en attente. L'enregistrement de cette modification dans les journaux de transactions arrivera au serveur en attente alors que la requête sur le serveur en attente est toujours en cours d'exécution, causant un conflit. Le serveur en attente doit soit retarder l'application des enregistrements des journaux de transactions (et tous ceux qui sont après aussi) soit annuler la requête en conflit, pour appliquer l'instruction DROP TABLE.

Quand une requête en conflit est courte, il est généralement préférable d'attendre un peu pour l'application du journal de transactions. Mais un délai plus long n'est généralement pas souhaitable. Donc, le mécanisme d'annulation dans l'application des enregistrements de journaux de transactions dispose de deux paramètres, max_standby_archive_delay et max_standby_streaming_delay, qui définissent le délai maximum autorisé pour appliquer les enregistrements. Les requêtes en conflit seront annulées si l'application des enregistrements prend plus de temps que celui défini. Il existe deux paramètres pour que des délais différents puissent être observés suivant le cas : lecture des enregistrements à partir d'un journal archivé (par exemple lors de la restauration initiale à partir d'une sauvegarde ou lors d'un « rattrapage » si le serveur en attente accumulait du retard par rapport au primaire) et lecture des enregistrements à partir de la réplication en flux.

Pour un serveur en attente dont le but principal est la haute-disponibilité, il est préférable de configurer des valeurs assez basses pour les paramètres de délai, de façon à ce que le serveur en attente ne soit pas trop en retard par rapport au serveur primaire à cause des délais suivis à cause des requêtes exécutées sur le serveur en attente. Par contre, si le serveur en attente doit exécuter des requêtes longues, alors une valeur haute, voire infinie, du délai pourrait être préférable. Néanmoins, gardez en tête qu'une requête mettant du temps à s'exécuter pourrait empêcher les autres requêtes de voir les modifications récentes sur le serveur primaire si elle retarde l'application des enregistrements de journaux de transactions.

Une fois que le délai spécifié par max_standby_archive_delay ou max_standby_streaming_delay a été dépassé, toutes les requêtes en conflit seront annulées. Ceci résulte habituellement en une erreur d'annulation, bien que certains cas, comme un DROP DATABASE, peuvent occasionner l'arrêt complet de la connexion. De plus, si le conflit intervient sur un verrou détenu par une transaction en attente, la session en conflit sera terminée (ce comportement pourrait changer dans le futur).

Les requêtes annulées peuvent être ré-exécutées immédiatement (après avoir commencé une nouvelle transaction, bien sûr). Comme l'annulation des requêtes dépend de la nature des enregistrements dans le journal de transactions, une requête annulée pourrait très bien réussir si elle est de nouveau exécutée.

Gardez en tête que les paramètres de délai sont comparés au temps passé depuis que la donnée du journal de transactions a été reçue par le serveur en attente. Du coup, la période de grâce accordée aux requêtes n'est jamais supérieure au paramètre de délai, et peut être considérablement inférieure si le serveur en attente est déjà en retard suite à l'attente de la fin de l'exécution de requêtes précédentes ou suite à son impossibilité de conserver le rythme d'une grosse mise à jour.

La raison la plus fréquente des conflits entre les requêtes en lecture seule et le rejeu des journaux de transactions est le « nettoyage avancé ». Habituellement, PostgreSQL permet le nettoyage des anciennes versions de lignes quand aucune transaction ne peut les voir pour s'assurer du respect des règles de MVCC. Néanmoins, cette règle peut seulement s'appliquer sur les transactions exécutées sur le serveur primaire. Donc il est possible que le nettoyage effectué sur le primaire supprime des versions de lignes toujours visibles sur une transaction exécutée sur le serveur en attente.

Le nettoyage des versions de ligne n'est pas la seule cause de conflits avec les requêtes exécutées sur les secondaires. Tous les parcours d'index seuls (ceci incluant ceux qui s'exécutent sur les secondaires) doivent utiliser un snapshot MVCC qui « accepte » la carte de visibilité. Les conflits sont de ce fait requis à chaque fois que VACUUM indique une page comme toutes-visibles dans la carte de visibilité contenant une ou plusieurs lignes non visibles pour toutes les requêtes du secondaire. Donc même exécuter VACUUM sur une table sans lignes mises à jour ou supprimées nécessitant du nettoyage peut amener à des conflits.

Les utilisateurs doivent s'attendre à ce que les tables fréquemment mises à jour sur le serveur primaire seront aussi fréquemment la cause de requêtes annulées sur le serveur en attente. Dans un tel cas, le paramétrage d'une valeur finie pour max_standby_archive_delay ou max_standby_streaming_delay peut être considéré comme similaire à la configuration de statement_timeout.

Si le nombre d'annulations de requêtes sur le serveur en attente est jugé inadmissible, quelques solutions existent. La première option est de définir la variable hot_standby_feedback qui permet d'empêcher les conflits liés au nettoyage opéré par la commande VACUUM en lui interdisant de nettoyer les lignes récemment supprimées. Si vous le faites, vous devez noter que cela retardera le nettoyage des versions de lignes mortes sur le serveur primaire, ce qui pourrait résulter en une fragmentation non désirée de la table. Néanmoins, cette situation ne sera pas meilleure si les requêtes du serveur en attente s'exécutaient directement sur le serveur primaire. Vous avez toujours le bénéfice de l'exécution sur un serveur distant. Si des serveurs secondaires se connectent et se déconnectent fréquemment, vous pourriez vouloir faire des ajustements pour gérer la période durant laquelle hot_standby_feedback n'est pas renvoyé. Par exemple, vous pouvez considérer l'augmentation de max_standby_archive_delay pour que les requêtes ne soient pas annulées rapidement par des conflits avec le journal de transactions d'archive durant les périodes de déconnexion. Vous pouvez également considérer l'augmentation de max_standby_streaming_delay pour éviter des annulations rapides par les nouvelles données de flux de transaction après la reconnexion.

Le nombre de requêtes annulées et le motif de cette annulation peut être visualisé avec la vue système pg_stat_database_conflicts sur le serveur secondaire. La vue système pg_stat_database contient aussi des informations synthétiques sur ce sujet.

Les utilisateurs peuvent contrôler si un message doit être écrit dans les traces du serveur lorsque le rejeu des journaux de transactions est en conflit depuis plus longtemps que deadlock_timeout. Ce comportement est contrôlé par le paramètre log_recovery_conflict_waits.

Si hot_standby est positionné à on dans postgresql.conf (valeur par défaut) et qu'un fichier standby.signal est présent, le serveur fonctionnera en mode Hot Standby. Toutefois, il pourrait s'écouler du temps avant que les connections en Hot Standby soient autorisées, parce que le serveur n'acceptera pas de connexions tant que la récupération n'aura pas atteint un point garantissant un état cohérent permettant aux requêtes de s'exécuter. Pendant cette période, les clients qui tentent de se connecter seront rejetés avec un message d'erreur. Pour confirmer que le serveur a démarré, vous pouvez soit tenter de vous connecter en boucle, ou rechercher ces messages dans les journaux du serveur:

LOG:  entering standby mode

... puis, plus loin ...

LOG:  consistent recovery state reached
LOG:  database system is ready to accept read-only connections
    

L'information sur la cohérence est enregistrée une fois par checkpoint sur le primaire. Il n'est pas possible d'activer le mode Hot Standby si on lit des WAL générés durant une période pendant laquelle wal_level n'était pas positionné à replica ou logical sur le primaire. L'arrivée à un état cohérent peut aussi être retardée si ces deux conditions se présentent:

Si vous effectuez du log shipping par fichier (warm standby), vous pourriez devoir attendre jusqu'à l'arrivée du prochain fichier de WAL, ce qui pourrait être aussi long que le paramètre archive_timeout du primaire.

Certains paramètres déterminent la taille de la mémoire partagée pour le suivi des identifiants de transaction, des verrous, et des transactions préparées. Ces structures mémoires partagées ne peuvent pas être plus petites sur le secondaire que sur le primaire pour s'assurer que le secondaire ne tombera pas à court de mémoire partagée pendant la récupération. Par exemple, si le primaire avait utilisé des transactions préparées mais que le secondaire n'avait pas alloué de mémoire partagée pour suivre ces transactions préparées, alors la récupération ne pourrait reprendre avant que la configuration du secondaire ne soit adaptée. Les paramètres concernés sont:

La façon la plus simple pour éviter que cela ne devienne un problème est d'avoir tous ces paramètres définis sur les serveurs secondaires à des valeurs égales ou supérieures que celles du primaire. C'est pourquoi, si vous voulez augmenter ces valeurs, vous devez le faire d'abord sur tous les serveurs secondaires avant de le faire sur le serveur primaire. De la même façon, si vous voulez diminuer ces valeurs, vous devez d'abord le faire sur le serveur primaire, puis sur tous les serveurs secondaires. Gardez également à l'esprit que lorsqu'un secondaire est promu, il devient alors la nouvelle référence des valeurs de ces paramètres pour les secondaires qui s'y raccrochent. De ce fait, pour éviter que cela ne devienne un problème lors d'une bascule (switchover ou failover), il est recommandé de conserver ces paramètres identiques sur tous les serveurs secondaires.

Les journaux de transactions tracent le changement de ces paramètres sur le serveur primaire. Si un serveur hot standby rejoue un journal de transactions qui indique que la valeur actuelle sur le primaire est plus élevée que la sienne, un message d'avertissement sera écrit dans les traces du serveur et le rejeu mis en pause. Par exemple :

WARNING:  hot standby is not possible because of insufficient parameter settings
DETAIL:  max_connections = 80 is a lower setting than on the primary server, where its value was 100.
LOG:  recovery has paused
DETAIL:  If recovery is unpaused, the server will shut down.
HINT:  You can then restart the server after making the necessary configuration changes.

A ce stade, les paramètres du secondaire doivent être ajustés et l'instance redémarrée avant que le rejeu ne puisse reprendre. Si le secondaire n'est pas en mode hot standby alors, lorsqu'il rencontrera un changement de paramètre incompatible, il s'éteindra immédiatement sans pause, puisqu'il serait inutile de rester actif.

Il est important que l'administrateur sélectionne le paramétrage approprié pour max_standby_archive_delay et max_standby_streaming_delay. Le meilleur choix varie les priorités. Par exemple, si le serveur a comme tâche principale d'être un serveur de haute-disponibilité, alors il est préférable d'avoir une configuration assez basse, voire à zéro, de ces paramètres. Si le serveur en attente est utilisé comme serveur supplémentaire pour des requêtes du type décisionnel, il sera acceptable de mettre les paramètres de délai à des valeurs allant jusqu'à plusieurs heures, voire même -1 (cette valeur signifiant qu'il est possible d'attendre que les requêtes se terminent d'elles-même).

Les "hint bits" (bits d'indices) écrits sur le primaire ne sont pas journalisés en WAL, il est donc probable que les hint bits soient réécrits sur le secondaire. Ainsi, le serveur secondaire fera toujours des écritures disques même si tous les utilisateurs sont en lecture seule ; aucun changement ne se produira sur les données elles mêmes. Les utilisateurs écriront toujours les fichiers temporaires pour les gros tris et re-génèreront les fichiers d'information relcache, il n'y a donc pas de morceau de la base qui soit réellement en lecture seule en mode hot standby. Notez aussi que les écritures dans des bases distantes en utilisant le module dblink, et d'autres opérations en dehors de la base s'appuyant sur des fonctions PL seront toujours possibles, même si la transaction est en lecture seule localement.

Les types suivants de commandes administratives ne sont pas acceptées durant le mode de récupération:

Notez encore une fois que certaines de ces commandes sont en fait autorisées durant les transactions en "lecture seule" sur le primaire.

Par conséquent, vous ne pouvez pas créer d'index supplémentaires qui existeraient uniquement sur le secondaire, ni des statistiques qui n'existeraient que sur le secondaire. Si ces commandes administratives sont nécessaires, elles doivent être exécutées sur le primaire, et ces modifications se propageront à terme au secondaire.

pg_cancel_backend() et pg_terminate_backend() fonctionneront sur les processus utilisateurs, mais pas sur les processus de démarrage, qui effectuent la récupération. pg_stat_activity ne montre pas les transactions de récupération comme actives. Ainsi, pg_prepared_xacts est toujours vide durant la récupération. Si vous voulez traiter des transactions préparées douteuses, interrogez pg_prepared_xacts sur le primaire, et exécutez les commandes pour résoudre le problème à cet endroit ou résolvez-les après la fin de la restauration.

pg_locks affichera les verrous posés par les processus, comme en temps normal. pg_locks affiche aussi une transaction virtuelle gérée par le processus de démarrage qui possède tous les AccessExclusiveLocks posés par les transactions rejouées par la récupération. Notez que le processus de démarrage n'acquiert pas de verrou pour effectuer les modifications à la base, et que par conséquent les verrous autre que AccessExclusiveLocks ne sont pas visibles dans pg_locks pour le processus de démarrage; ils sont simplement censés exister.

Le plugin Nagios check_pgsql fonctionnera, parce que les informations simples qu'il vérifie existent. Le script de supervision check_postgres fonctionnera aussi, même si certaines valeurs retournées pourraient être différentes ou sujettes à confusion. Par exemple, la date de dernier vacuum ne sera pas mise à jour, puisqu’aucun vacuum ne se déclenche sur le secondaire. Les vacuums s'exécutant sur le primaire envoient toujours leurs modifications au secondaire.

Les options de contrôle des fichiers de WAL ne fonctionneront pas durant la récupération, comme pg_backup_start, pg_switch_wal, etc...

Les modules à chargement dynamique fonctionnent, comme pg_stat_statements.

Les verrous consultatifs fonctionnent normalement durant la récupération, y compris en ce qui concerne la détection des verrous mortels (deadlocks). Notez que les verrous consultatifs ne sont jamais tracés dans les WAL, il est donc impossible pour un verrou consultatif sur le primaire ou le secondaire d'être en conflit avec la ré-application des WAL. Pas plus qu'il n'est possible d'acquérir un verrou consultatif sur le primaire et que celui-ci initie un verrou consultatif similaire sur le secondaire. Les verrous consultatifs n'ont de sens que sur le serveur sur lequel ils sont acquis.

Les systèmes de réplications à base de triggers tels que Slony, Londiste et Bucardo ne fonctionneront pas sur le secondaire du tout, même s'ils fonctionneront sans problème sur le serveur primaire tant que les modifications ne sont pas envoyées sur le serveur secondaire pour y être appliquées. Le rejeu de WAL n'est pas à base de triggers, vous ne pouvez donc pas utiliser le secondaire comme relais vers un système qui aurait besoin d'écritures supplémentaires ou utilise des triggers.

Il n'est pas possible d'assigner de nouveaux OID, bien que des générateurs d'UUID puissent tout de même fonctionner, tant qu'ils n'ont pas besoin d'écrire un nouveau statut dans la base.

À l'heure actuelle, la création de table temporaire n'est pas autorisée durant les transactions en lecture seule, certains scripts existants pourraient donc ne pas fonctionner correctement. Cette restriction pourrait être levée dans une version ultérieure. Il s'agit à la fois d'un problème de respect des standards et d'un problème technique.

DROP TABLESPACE ne peut réussir que si le tablespace est vide. Certains utilisateurs pourraient utiliser de façon active le tablespace via leur paramètre temp_tablespaces. S'il y a des fichiers temporaires dans le tablespace, toutes les requêtes actives sont annulées pour s'assurer que les fichiers temporaires sont supprimés, afin de supprimer le tablespace et de continuer l'application des WAL.

Exécuter DROP DATABASE ou ALTER DATABASE ... SET TABLESPACE sur le serveur primaire générera un enregistrement dans les journaux de transactions qui causera la déconnexion de tous les utilisateurs actuellement connectés à cette base de données. Cette action survient immédiatement, quelque soit la valeur du paramètre max_standby_streaming_delay. Notez que ALTER DATABASE ... RENAME ne déconnecte pas les utilisateurs qui, dans la plupart des cas, ne s'en apercevront pas. Cela peut néanmoins semer de la confusion pour un programme qui dépendrait du nom de la base.

En fonctionnement normal (pas en restauration), si vous exécutez DROP USER ou DROP ROLE pour un rôle ayant l'attribut LOGIN alors que cet utilisateur est toujours connecté alors rien ne se produit pour cet utilisateur connecté -- il reste connecté. L'utilisateur ne peut toutefois pas se reconnecter. Ce comportement est le même en récupération, un DROP USER sur le primaire ne déconnecte donc pas cet utilisateur sur le secondaire.

Le système de statistiques cumulatives est actif pendant la restauration. Tous les parcours, lectures, blocs, utilisations d'index, etc. seront enregistrés normalement sur le standby. Néanmoins, le rejeu des journaux de transactions n'incrémentera pas les compteurs spécifiques des relations et des bases. Le rejeu n'incrémentera pas les colonnes de pg_stat_all_tables (comme n_tup_ins), pas plus que les lectures et écritures réalisées par le processus de démarrage ne seront tracées dans les vues pg_statio_, ou que les colonnes associées de pg_stat_database ne seront incrémentées.

Autovacuum n'est pas actif durant la récupération, il démarrera normalement à la fin de la récupération.

Les processus d'écriture en arrière plan (checkpointer et background writer) sont actifs durant la restauration. Le processus checkpointer process effectuera les restartpoints (similaires aux checkpoints sur le primaire) et le processus background writer réalisera les activités normales de nettoyage de blocs. Ceci peut inclure la mise à jour des information de hint bit des données du serveur secondaire. La commande CHECKPOINT est acceptée pendant la récupération, bien qu'elle déclenche un restartpoint et non un checkpoint.

De nombreux paramètres ont été mentionnés ci-dessus dans Section 26.4.2 et Section 26.4.3.

Sur le primaire, le paramètre wal_level peut être utilisé. max_standby_archive_delay et max_standby_streaming_delay n'ont aucun effet sur le primaire.

Sur le serveur en attente, les paramètres hot_standby, max_standby_archive_delay et max_standby_streaming_delay peuvent être utilisés.

Il y a plusieurs limitations au Hot Standby. Elles peuvent et seront probablement résolues dans des versions ultérieures: