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.
]]>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
]]>Pour bien comprendre pg_start_backup et pg_stop_backup ce sont des opérations qui visent à lancer la création d'un checkpoint et de mettre en cohérence les opérations d'archivage des wals et de synchronisations des timelines, non?
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.
je rends esclave un second serveur qui lui a déjà servi en autonome et pour ca je fais :
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.
rsync des fichiers du répertoire main à partir du maitre arrêté
(ainsi que)
Naïvement je pensais que le fait d'arrêter les deux serveurs faisait que le maître était dans un état stable et donc que le rsync produirait forcément un état stable en face.
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.
De toutes façons à partir du moment ou j'arrêtais le maitre je ne pouvais plus utiliser le pg_start_backup et pg_stop_backup, donc en fait vous suggérer de le faire à faire à chaud côté maitre uniquement?
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.
]]>Bon ben voila tout est dit le rsync ne suffit pas il faut en plus formaliser cela avec pg_start_backup et pg_stop_backup. J'avais imaginé que ce n'était valable que pour les opérations avec création d'un fichier sauvegarde et pas avec une synchronisation de fichier racine...en relisant la doc...
Pour bien comprendre pg_start_backup et pg_stop_backup ce sont des opérations qui visent à lancer la création d'un checkpoint et de mettre en cohérence les opérations d'archivage des wals et de synchronisations des timelines, non?
Merci en tout cas :
Pour info les opérations que je fais :
je prépare un serveur maitre avec juste un archivage de wal par archive_command
je rends esclave un second serveur qui lui a déjà servi en autonome et pour ca je fais :
mise en place d'une restore_command
rsync des fichiers du répertoire main à partir du maitre arrêté
mise en place du fichier standby.signal
et redémarrage des deux serveurs.
Naïvement je pensais que le fait d'arrêter les deux serveurs faisait que le maître était dans un état stable et donc que le rsync produirait forcément un état stable en face.
De toutes façons à partir du moment ou j'arrêtais le maitre je ne pouvais plus utiliser le pg_start_backup et pg_stop_backup, donc en fait vous suggérer de le faire à faire à chaud côté maitre uniquement?
D'avance merci pour tous ces éclaircissements.
]]>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
]]>La version 13 est indemne vu que le fichier sur les fonctions a dû être entièrement re-traduit.
]]>La dernière version sur la branche principale a le bon nom de fonction pg_last_wal_receive_lsn (https://docs.postgresql.fr/13/functions-admin.html) mais effectivement quelques versions précédentes sont passées à côté du renommage.
Vous pouvez bien sûr signaler des erreurs de traduction via github et soumettre des corrections sous forme de Pull Request.
]]>Sur la francisation de la documentation postgresql nouveau soucis sauf erreur :
9.26.4. Fonctions de contrôle de la restauration la fonction de suivi des wal est décrite ainsi (comme en 9.x)
pg_last_xlog_receive_location()
Alors que dans la doc anglaise :
https://docs.postgresql.fr/12/functions-admin.html
9.26.4. Recovery Control Functions
c'est
pg_last_wal_receive_lsn()
qui est noté
et surtout dans le moteur 12 l'ancienne dénomination n'exite plus mais ce n'est pas la seule coquille:
Qui alerté dans ce cas, et par ailleurs comment peut-on participer à la francisation des docs s'il manque des bras?
D'avance merci !
]]>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.
]]>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
]]>