Bonjour Merci Guillaume,
C'est beaucoup plus clair pour moi effectivement.

Juste un détail la réplication par streaming semble opére visiblement à la granularité au segment de wal, ce qui fait dans mon cas pratique au temps de transfert prés les deux serveurs sont quasiment synchrones.

A contrario mon troisiéme serveur lui utilise la restoration de l'archivage des wal du master, et là il semblerait que l'esclave attende qu'un wal intégral de16Mo soit archivé par le primaire avant de le récupérer puis de le jouer avec un pas de temps élastique en fonction des actions sur le primaire.

Ou cela traduit-il plutôt une erreur de fonctionnement de mon installation

Merci d'avance

Bonjour Guillaume,
loin de moi l'idée de critiquer ce phénoménal travail de traduction et de maintien à jour qui est doit être très énergivore.
Par ailleurs merci beaucoup pour la traduction qui permet de mieux appréhender certaines substilités de postgres.

Merci Daniel, en lisant la documentation du gihub, je vois comment contribuer et signaler plus efficacement les erreurs.

J'ai quand même une question sur la réplication  :

Tous les exemples que je vois sont basés, dans les documentations notamment, sur la mise en place d'une solution répliquée à partir de serveur neuf (au sens installé initialement dans ce but). Or dans ma vie, j'ai une machine virtuelle de développement sur laquelle je teste une version supérieure de moteur de postgresql avec postgis de manière autonome (sans replication donc ), j'y restore mon environnement et je l'expose à qqs clients promus déboggueurs en chef. Puis lorsque tout ou presque est ok, je retiens cette nouvelle version de moteur pour programmer une migration de tous mes serveurs réplication compris :

Dans mon cas de figure 2 sont l'un a côté de l'autre (et donc je propose de recycler de ce fait la machine qui m'a servi à faire le test de montée de version).

Comme je ne veux pas refaire toute la maquette et que malheureusement il est rare que je réussisse sans itération à obtenir une solution stable.

Je réutilise le postgres autonome pour en faire le nouvel esclave. Et donc je prends une machine vierge sur laquelle je deploie tous les outils, migres mes bases puis je synchronise avec rsync tout le répertoire main de postgresql.

Je mets le fichier recovery.signal et la restore_command en place puis je redémarre l'esclave puis le maitre qui lui utilise l'archive_command.

Fréquemment le serveur esclave se souvient de sa vie antérieure en m'indiquant via une erreur de timeline ou de recherche de fichier history. Comment puis je le rendre vierge de cette mémoire? Sauf erreur de ma part le seul répertoire qui n'est pas synchronisé est le log hormis bien sûr les répertoires protégés par postgres bien sûr.

D'avance votre éclairage à ce sujet

Yann

Bonjour,

j'ai l'impression que cela provient du fait que je n'avais pas de replication effective entre mes deux serveurs du fait de la confusion entre standby.signal et recovery.signal et donc que les deux serveurs ont eu des phases ou ils étaient ou répliqués ou autonome. et comme j'ai restauré sur l'un et l'autre des bases de bon volume conséquents (1To) la croissance des wal a été volumineuse.

Je suis reparti de quasi 0 et les timelines semblent en accord maintenant.

Merci c'est pas grave Guillaume, juste que postgres ne disait rien pour me mettre sur la voix...

Maintenant j'ai ce message là :

LOG:  démarré le flux des journaux depuis le principal à 156/6C000000 sur la timeline 1
2020-10-23 12:48:01.517 CEST [30552] FATAL:  la timeline requise 2 n'est pas un fils de l'historique de ce serveur
2020-10-23 12:48:01.517 CEST [30552] DÉTAIL:  Le dernier checkpoint est à 156/6C000028 sur la timeline 1, mais dans l'historique de la timeline demandée, le serveur est sorti de cette timeline à 156/670000A0.
2020-10-23 12:48:01.519 CEST [30550] LOG:  processus de lancement (PID 30552) a quitté avec le code de sortie 1
2020-10-23 12:48:01.519 CEST [30550] LOG:  annulation du démarrage à cause d'un échec dans le processus de lancement
2020-10-23 12:48:01.524 CEST [30550] LOG:  le système de base de données est arrêté

Je crois que j'ai trop bidouillé et l'esclave est perdu, je vais tenter un rsync de tous les fichier de la base et refaire un fichier standby.signal

Alors en fait c'est plus sioux que cela :

2020-10-23 09:12:46.645 CEST [28985] LOG:  le système de bases de données a été arrêté à 2020-10-23 09:06:41 CEST
2020-10-23 09:12:46.645 CEST [28985] FATAL:  doir spécifier une restore_command quand standby_mode n'est pas activé
2020-10-23 09:12:46.648 CEST [28983] LOG:  processus de lancement (PID 28985) a quitté avec le code de sortie 1
2020-10-23 09:12:46.648 CEST [28983] LOG:  annulation du démarrage à cause d'un échec dans le processus de lancement
2020-10-23 09:12:46.662 CEST [28983] LOG:  le système de base de données est arrêté

Il considère que standby mode n'est pas activé et exige donc une restore_command, pourquoi considère-t-il que primary_conn ou primary_slot n'active pas le mode standby?

De ce que j'ai lu on peut choisir la replication par streaming ou l'accès à un répertoire d'archive continu du master. Je me trompe?

Hello, merci guillaume j'avais oublié le fichier recovery.signal mais il faut que je remonte la pelote....car il y a d'autres choses :

petit soucis dans la doc de la 12 : (il manque la mention de standy_mode=on (qui existe bien dans la doc de la 11 et plus dans la 12)..

Pour paramétrer le serveur de standby, restaurez la sauvegarde de base effectué sur le serveur primaire (voir (see Section 25.3.4). Créez un fichier recovery.signal dans le répertoire de données du cluster de standby. 

Positionnez restore_command à une simple commande qui recopie les fichiers de l'archive de WAL. Si vous comptez disposer de plusieurs serveurs de stanby pour mettre en œuvre de la haute disponibilité, assurez-vous que recovery_target_timeline est configuré à latest (la valeur par défaut), pour indiquer que le serveur de standby devra prendre en compte la ligne temporelle définie lors de la bascule à un autre serveur de standby.

Je vais le signaler car j'ai l'impression que cette omission ne vient pas de la traduction mais de la doc anglaise de la 12.

Bonjour,

Merci beaucoup pour cette réponse je pensais bien que j'avais omis quelquechose

Bonjour,

Tu as du mettre un paramètre qui exige le commit avant l'envoi du journal.

Peut-être as tu créé un slot de replication qui n'est jamais demandé par un esclave, dans l'attente postgres conserve les wal correspondant?

Petit complémént :

sur un ubuntu 14.04 également et sur le même réseau j'ai la même difficulté avec la mise à jour en postgresql 10.9 d'un autre serveur qui reste obstinément en 10.8 en spécifiant que c'est la version la plus à jour?

l'apt-get update atteint bien le dépot :

Atteint http://apt.postgresql.org trusty-pgdg/main amd64 Packages

?

Je reformule pour être sûr d'avoir bien compris :

Pour refaire un esclave à partir du nouveau maitre je suis obligé de refaire un rsync complet, or pour qu"il soit intégrè il faut que je stoppe le nouveau (master) au moins pour la synchronisation des fichiers à l'arrêt.

A l'étape des deux arrêts n'est-il pas plus simple de supprimer le trigger file sur le nouveau master et de renommer son recovery.done en recovery.conf ?

Ou s'agit-il d'une étape visant à assurer l'intégrité des données.

Bonjour,

Merci pour l'explication , c'est exactement ce que je me disais en parcourant la table pg_class qui montre seulement 10 000 entrées pour 16300 fichiers ....

ok pour la solution la plus sur.

Concrétement je liste dans un fichier liste tous les fichiers du répertoire je le charge en base et fait une jointure avec relfinode avec un not in je ne risque pas d'en prendre un de trop en théorie.

par contre pour aller jusqu'au bout de la logique mon esclave en streaming replication auras toujours 1,2 To de trop puisque cette modification physique n'entrainera en rien des wal et donc une répercussion sur le serveur distant.

C'est ce qui me ferait militer pour une restauration complète.