Quand vous posez une question, merci de créer un nouveau thread.

Pour répondre rapidement, non, elle ne le détectera pas automatiquement.

Oui, sur https://github.com/pgbackrest/pgbackrest/issues

Les WAL archivés sont le principal (seul ?) intérêt des restore points. Je ne vois pas quel autre cas t'intéresserait ?

Par contre, je préfère les restore point à une date/heure. Je peux placer le restore point quand je veux et donc être bien plus précis qu'une date/heure.

Aucun outil n'existe réellement pour ça (à ma connaissance en tout cas). Il faut utiliser pg_waldump pour retrouver la liste des enregistrements XLOG d'un journal de transaction. J'avais écrit ce script pour ça :

pg_waldump -r XLOG $@ 2>&1                \
  | grep "RESTORE_POINT"                  \
  | sed -e 's/.*RESTORE_POINT \(.*\)/\1/'

$@ étant remplacé en bash par la liste des arguments fournis. En enregistrant ce script dans un fichier ~/bin/pg_list_restore_points.sh, ça me permet de faire :

$ ~/bin/pg_list_restore_points.sh 000000010000000400000005 
toto
ttiti

Et d'avoir ainsi la liste des restore points du journal 000000010000000400000005.

PostgreSQL génère des messages d'erreurs qu'il stocke dans des fichiers (généralement le sous-répertoire log du répertoire principal des données), ou qu'il envoie à un gestionnaire de log (syslog sous unix et journal des événements sous Windows). Ce sont ces fichiers dont je parle.

La granularité de la réplication par streaming est l'enregistrement WAL, donc un très petit sous-ensemble d'un segment WAL. On est dans le quasi synchrone s'il n'y a pas trop d'écritures sur le primaire.

La granularité de la réplication par log shipping est le segment WAL entier, donc habituellement 16 Mo. Le lag est forcément plus important.

Donc non, ce n'est pas une erreur de fonctionnement de l'installation.

This is a french forum, so you're supposed to ask your questions in french.

C'est un forum en français, donc vous êtes supposé poser vos questions en français. Concernant votre erreur, elle ne me rappelle rien, je ne l'ai pas déjà rencontré. Concernant votre requête, elle est illisible. Pensez à l'indenter, ça pourrait aider à identifier le problème.

Je ne vois pas trop ce que vous entendez par "mettre en cohérence les opérations d'archivage des wals et de synchronisations des timelines".

pg_start_backup() va exécuter un checkpoint, mettre à jour le fichier pg_control et créer un fichier backup_label qui contiendra notamment la position d'écriture dans les WAL datant de pg_start_backup.

pg_stop_backup() va exécuter un nouveau checkpoint, mettre à jour le fichier pg_control, et modifier le fichier backup_label pour y ajouter notamment la position d'écriture dans les WAL datant de pg_stop_backup.

Ainsi, à la restauration du serveur (pour en faire un serveur autonome ou un serveur secondaire), au démarrage, PostgreSQL saura quel journaux il doit au minimum rejouer pour avoir une restauration cohérente, ces journaux allant de celui du pg_start_backup à celui du pg_stop_backup. Il peut en rejouer d'autres, mais c'est optionnel.

Si le serveur a déjà servi comme serveur autonome, il convient de supprimer tous les fichiers de ce serveur, donc ceux du répertoire de données principal, ceux du répertoire des jounaux de transactions (s'ils ne sont pas dans le répertoire de données), et enfin ceux des tablepaces.

(ainsi que)

Ce n'est pas naïf, c'est vrai. Si le serveur primaire est arrêté, il n'est pas nécessaire de faire un pg_start_backup et un pg_stop_backup. Ces derniers n'ont un intérêt qu'à partir du moment où il y a des écritures sur le serveur primaire pendant la sauvegarde.

La majorité des utilisateurs le fait à chaud parce qu'ils ne peuvent pas se permettre d'arrêter la production le temps d'une sauvegarde de fichiers. Si vous le pouvez, c'est plus simple, vous n'avez pas besoin de pg_start_backup et pg_stop_backup.

J'avoue que j'ai du mal à comprendre ce que vous faites. Il faudrait détailler plus les opérations que vous réalisez. Notamment, je ne vois pas les étapes pg_start_backup et pg_stop_backup respectivement avant et après le rsync.

Qu'est-ce qui vous pose problème ?

Il n'y a pas de commande pour ça, il faut configurer correctement le fichier pg_hba.conf. https://docs.postgresql.fr/13/client-au … ation.html pour les détails.

Soit vous avez un firewall qui empêche la connexion, soit vous n'avez pas correctement configuré le paramètre listen_adresses dans le fichier postgresql.conf.