Désolé, j'ai cassé votre recovery.conf

Dans PostgreSQL depuis des temps très anciens déjà la version 8.0 qui a été publiée en 2005, un fichier de configuration recovery.conf spécial a été utilisé pour restaurer à un moment précis. Le même fichier a ensuite commencé à être utilisé pour le mode veille et la réplication en streaming.

Cependant, depuis la prochaine version de PostgreSQL 12, recovery.conf ne fonctionnera plus: je l'ai cassé.
Mais pourquoi?

Recovery.conf avait une caractéristique: il était en lecture seule au début du SGBD. Et si la récupération ponctuelle, qui est nécessaire moins d'une fois par an, peut toujours être réconciliée, la nécessité de redémarrer la base de données entière pour modifier l'adresse du serveur de réplication en amont est quelque peu déprimante. J'ai vu différentes façons de perversions pour contourner cette restriction, comme l'utilisation du routage L3, des schémas de réplication en cascade (de sorte que pas toutes les répliques, mais au moins seulement une partie, respectivement) et même (même si je ne l'ai pas vu en production) walbouncer .

Après le prochain redémarrage planifié des répliques, juste en raison de la nécessité de modifier les paramètres de réplication, j'ai décidé de le récupérer, mais combien cela coûterait-il d'apprendre à PostgreSQL à relire primary_conninfo dans SIGHUP? Tout s'est mal passé. En principe, vous devez modifier une seule variable dans le processus de démarrage et à partir de là demander un redémarrage de WalReceiver - et c'est tout, la réplication se poursuivra correctement avec la nouvelle adresse. Reste à l'implémenter correctement. Quelques semaines plus tard, j'ai terminé le correctif avec l'implémentation de la relecture de recovery.conf sur le signal SIGHUP, alors que ce correctif n'a pas brisé le comportement de la base de données existante.

Puis, ayant le courage, l' envoya sur la liste de diffusion des développeurs PostgreSQL. Ce que Michael Paquier a répondu assez rapidement:

Avant de rendre certains d'entre eux rechargeables, changeons-les d'abord en GUC et ne réinventons pas la gestion SIGHUP des paramètres comme le fait votre patch.

Oups, il s'est avéré que j'ai posé la mauvaise question au moteur de recherche. La question n'était pas de relire recovery.conf, mais de convertir les paramètres d'un recovery.conf séparé en infrastructure GUC (grande configuration unifiée) utilisée pour tous les autres paramètres du SGBD. C'est-à-dire, certainement pas, nous n'avons pas besoin d'un tel patch, nous n'en voulons pas. Commençons par transférer tous ces paramètres de recovery.conf vers notre infrastructure de paramètres standard.

Sur cette sombre nouvelle, j'ai brûlé et pensé: "Mais transférons!". J'ai lu les discussions archivées sur la requête de recherche correcte, ouvert la dernière discussion trouvée sur le transfert des paramètres (le lien a été aimablement fourni par Michael Paquier dans sa réponse, pour laquelle je le remercie séparément, ainsi que pour la réponse rapide). À cette époque, en mai 2018, le patch a été abandonné pendant plus d'un an. Donc, nous commençons ici. Ou est-il plus correct de dire «continuer»? Selon le plan de divertissement:

1. lire et répertorier les modifications apportées à la dernière version publiée du correctif
2. analyser les modifications dans le patch et transférer le nécessaire dans la version actuelle de la base de code
3. corriger toutes les références à recovery.conf et ses paramètres dans la documentation
4. tests de réparation
5. envoyer un nouveau patch à la liste de diffusion
6. obtenir des commentaires
7. corriger quelque chose selon les souhaits et revenir au paragraphe 5
8. recevoir un refus d'accepter à nouveau le patch (dans un an et demi)

Cela ressemble à un plan d'action? Eh bien, c'est parti!

Combien de temps, brièvement, je suis arrivé au point cinq et le 21 juin 2018, j'ai publié une nouvelle version du patch dans un nouveau fil de discussion . Puis 3 mois dans le silence oppressant du silence effrayant du poisson Baskerville. Fin septembre, Peter Eisentraut, l'un des développeurs Core ayant le droit de s'engager, a soudainement montré de l'intérêt pour le patch. Après plusieurs itérations de corrections, alors que je m'éloignais tranquillement pendant quelques jours pour faire un tour à Budapest et voir les sites touristiques, une lettre décourageante de Peter Eisentraut arrive:

J'ai parcouru le patch et fait un tas de petits raffinements. J'ai également mis à jour la documentation de manière plus approfondie. Le patch ci-joint est valable pour moi.

C'est-à-dire que Peter Eisentraut a corrigé quelques petites choses à sa discrétion, a mis à jour la documentation, a brûlé toute la section recovery-config.sgml et pense que sous cette forme, le correctif peut déjà être accepté. Oh, et je pensais que cela ne se produirait que pour postgresql 13, même s'il est si chanceux que le patch atteigne généralement un état de préparation pour la validation.

Et quelques jours plus tard, à savoir le 25 novembre de ce 2018, Peter Eisentraut accepte vraiment ce patch :

Les paramètres recovery.conf sont désormais définis dans postgresql.conf (ou dans d'autres sources GUC). Actuellement, tous les paramètres affectés sont PGC_POSTMASTER; cela pourrait être affiné dans le futur au cas par cas.
La récupération est maintenant lancée par un fichier recovery.signal. Le mode veille est initié par un fichier standby.signal. Le paramètre standby_mode a disparu. Si un fichier recovery.conf est trouvé, une erreur est générée.
Le paramètre trigger_file a été renommé pour promouvoir_fichier_trigger dans le cadre du déplacement.
Le chapitre de documentation "Configuration de récupération" a été intégré dans "Configuration du serveur".
pg_basebackup -R ajoute maintenant les paramètres à postgresql.auto.conf et crée un fichier standby.signal.
Auteur: Fujii Masao <masao (dot) fujii (at) gmail (dot) com>
Auteur: Simon Riggs <simon (at) 2ndquadrant (dot) com>
Auteur: Abhijit Menon-Sen <ams (at) 2ndquadrant (dot) com>
Auteur: Sergei Kornilov <sk (at) zsrv (dot) org>

Deux semaines se sont écoulées et cet engagement n'a pas été annulé. Incroyable Et il semble qu'ils ne le feront même pas. C’est incroyable. On ne sait pas si la communauté décidera de modifier à nouveau le comportement dans n'importe quelle direction, d'autant plus qu'il reste encore un peu de temps avant la sortie du gel des fonctionnalités de postgresql 12 en avril. Mais il semble que nous n'aurons plus de recovery.conf.

Alors qu'est-ce qui a changé

D'abord et avant tout, le SGBD refusera de démarrer s'il trouve un fichier recovery.conf - cela a été fait spécifiquement pour que l'utilisateur, en utilisant l'une des nombreuses anciennes instructions, ne soit pas surpris que la base de données ignore la configuration de ce fichier.

L'ancien paramètre standby_mode a disparu. Maintenant, il, ainsi que le fait même de l'existence de recovery.conf pour activer le mode de récupération, est remplacé par deux fichiers (de tout contenu, généralement vide):

• $ PGDATA / recovery.signal - successeur idéologique standby_mode = off, la restauration à partir de l'archive sera effectuée au point spécifié dans les configurations;
• $ PGDATA / standby.signal - respectivement, standby_mode = on. Nous verrons ce fichier sur toutes les répliques.

Si le processus de démarrage de la base de données a trouvé les deux fichiers, nous considérons que nous sommes en mode veille.

Si, pour plus de clarté, pour réduire les changements de paramètres sur une plaque:

ancien recovery.conf	PostgreSQL 12+ postgresql.conf
primary_conninfo	primary_conninfo
primary_slot_name	primary_slot_name
trigger_file	Promote_trigger_file
recovery_min_apply_delay	recovery_min_apply_delay
recovery_target	recovery_target
recovery_target_name	recovery_target_name
recovery_target_time	recovery_target_time
recovery_target_xid	recovery_target_xid
recovery_target_lsn	recovery_target_lsn
recovery_target_inclusive	recovery_target_inclusive
recovery_target_timeline	recovery_target_timeline
recovery_target_action	recovery_target_action
restore_command	restore_command
archive_cleanup_command	archive_cleanup_command
recovery_end_command	recovery_end_command

Vous pouvez voir qu'un peu moins que rien n'a été changé. Pour le moment (à la seule exception du préfixe de promotion_ pour le fichier de promotion_fichier), tous les nouveaux paramètres sont nommés comme les anciens et prennent les mêmes valeurs possibles. Bien qu'en fait il y ait encore un changement concernant les paramètres de la cible de récupération. Je ne sais pas si quelqu'un l'a utilisé auparavant, mais c'était un comportement documenté et il était possible de spécifier plusieurs recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time ou recovery_target_xid en même temps. Par exemple

recovery_target_lsn = '1/1D9FEA00' recovery_target_xid = '5238954' 

La dernière ligne de recovery.conf a été utilisée pour la récupération. Ce n'est plus possible, l'objectif de récupération doit être indiqué au maximum par un. Cependant, en raison de la logique de l'infrastructure GUC, vous pouvez toujours spécifier le paramètre du même nom plusieurs fois:

 recovery_target_lsn = '1/1D9FEA00' recovery_target_lsn = '1/16AC7D0' 

Ceci est acceptable, nous reviendrons à la valeur des paramètres spécifiée en dernier.

Et, en général, c'est tout ce qu'il faut dire sur les changements visibles depuis l'extérieur de PostgreSQL. pg_basebackup -R (--write-recovery-conf) est resté à sa place et fait ce à quoi il est destiné, seulement maintenant il ajoutera des paramètres à postgresql.auto.conf au lieu de recovery.conf et créera un fichier standby.signal

Malheureusement, quand je dis que ce sont tous les changements qui sont actuellement visibles, c'est exactement ce que je veux dire. Tous les nouveaux paramètres sont toujours définis comme PGC_POSTMASTER, c'est-à-dire qu'ils ne peuvent être modifiés qu'au démarrage de PostgreSQL. Comme déjà mentionné, c'était une exigence de la part de la communauté des développeurs: tout d'abord, transférez tous les paramètres, puis voyez s'ils peuvent être modifiés sur la base de données en cours d'exécution. Alors maintenant, PostgreSQL est dans une merveilleuse phase de développement, lorsque l'ancien comportement a déjà été rompu et que des changements pour le mieux n'ont pas encore été apportés.

J'ai déjà publié un patch qui permettra de changer à la volée primary_conninfo et primary_slot_name. Voyons ce qui se passe.

Désolé, j'ai cassé votre recovery.conf

UPD 7 avril 2019

Au cours de la dernière journée avant le gel des fonctionnalités de la version 12, vous pouvez résumer. La modification des paramètres de réplication n'était pas incluse dans la version. Bien sûr, c'est aussi une histoire curieuse. Il était une fois, le patch Simon Riggs que je prenais comme base contenait déjà des modifications pour redémarrer walreceiver lors de la modification des paramètres de connexion. Je les ai sélectionnés dans un correctif distinct complétant la documentation et les tests. Et après 6 mises à jour de correctifs et quelques mois de discussion, le fait évident apparaît que si vous redémarrez walreceiver, la base de données essaiera de basculer vers la restauration des fichiers à partir de restore_command. Un comportement de machine d'état tout à fait simple, déclenché par l'arrêt de Walreceiver pour une raison quelconque. Mais cela s'avère être «quelque chose que nous ne voulons pas». Eh bien, plus tôt, c'était impossible à dire? Ok, je l'ai refait d'une manière ou d'une autre, mais le calendrier avait déjà le commitfest final pour la version 12 et personne n'a regardé ici. En général, ce n'est pas une chose rapide, comme le font les correctifs dans PostgreSQL. Mais j'ai tout à fait le droit de m'inclure dans la liste des personnes, grâce à qui le REINDEX le plus épique inachevé et inachevé A ÉTÉ CONCURRENTÉMENT inclus dans la version 12!

Il convient de mentionner à la fin qu'un certain nombre de paramètres ont la possibilité de changer à la volée: archive_cleanup_command, promotion_trigger_file, recovery_end_command, recovery_min_apply_delay