Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
j'ai deux serveurs sur le même réseau local que je souhaite mettre en replication physique :
sur le master
j'ai ouvert le pg_hba.conf
ave une ligne :
host replication * ip/32 md5
et j'ai monté wal_keep_segments à 1000
j'ai lancé la création du slot de replication avec :
la fonction adhoc
le resultat donne cela :
postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name | slot_type | active
-----------+-----------+--------
nom_slot | physical | f
sur le slave
primary_conninfo = 'host=IP_master port=port user=compte_non_su password='
primary_slot_name = 'nom_slot'
wal_keep_segments = 1000
j'ai fait une copie via rsync du master vers le slave.
Depuis j'ai rajouté deux nouvelles bases sur le master mais la réplication ne s'effectue pas :
les logs du master et du slave ne font état d'aucune connection même échouée...
aucun processus serveur wal_sender en route...
les serveurs sont par défaut hot= replica
Je passe a côté de qqchose, mais j'ai beau lire la doc je ne vois pas...
Si vous avez des idées...
Hors ligne
Il manque certainement un bon paquet de la mise en place d'un serveur secondaire et aussi du primaire. Les logs du serveur devraient vous en dire plus, notamment les logs du secondaire dans un premier temps.
Guillaume.
Hors ligne
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.
Hors ligne
D'ailleurs ce qui est vraiment surprenant c'est que cette option n'existe pas dans le postgresql.conf.
Même par en attente comme primary_conn'' ou restore_command'' dans la section standby server....
J'imagine que c'est parcequ'elle va disparaitre en version 13 ? la présence de primary_conn devrait permettre de déduire que l'on souhaite avoir un secondaire actif?
Dernière modification par tholot (23/10/2020 09:37:30)
Hors ligne
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?
Hors ligne
C'est l'un ou l'autre ou les deux. Plus exactement, le plus responsable est de faire une réplication en flux avec soit un slot de réplication soit de l'archivage.
La raison la plus probable de cette erreur est que vous avez oublié de créer le fichier standby.signal.
Guillaume.
Hors ligne
re,
effectviment je n'ai pas créér ce fichier "La raison la plus probable de cette erreur est que vous avez oublié de créer le fichier standby.signal."
Car sur la doc française il est mentionné recovery.signal.... (ce qui ne lui fait ni chaud ni froid)
erreur de traduction ? ou traduction automatique?
26.2.4. Paramétrer un Serveur de Standby
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.
Ou une feinte pour vérifier que l'on a bien lu.. ;-)
le slave se connecte bien au master mais la timeline 2 ne lui plait pas... faut que je creuse cela encore....
Hors ligne
Le fichier recovery.signal sert lorsque vous voulez restaurer une sauvegarde PITR. Pour mettre le serveur en réplication (plus exactement en standby), il vous faut le fichier standby.signal.
Une bête erreur de traduction (et non, on ne fait pas de trad auto). La correction devrait bientôt être disponible.
Guillaume.
Hors ligne
C'est fait. Corrigé pour les versions 12 et 13.
Guillaume.
Hors ligne
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
Hors ligne
je crois que j'ai trouvé un 000002.history qui mettait le bazard....alors que la timeline était en 000001
Hors ligne
Cela veut dire que vous avez eu par le passé une promotion de secondaire en primaire, ce qui a généré une timeline 2, mais que votre serveur est reparti d'un point plus ancien et a continué sur la timeline 1. Difficile de dire ce qu'il s'est passé exactement, mais cela me semble un peu inquiétant.
Julien.
https://rjuju.github.io/
Hors ligne
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.
Hors ligne
Bonjour,
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 !
Hors ligne
La doc en français est sur un projet github: https://github.com/gleu/pgdocs_fr maintenu principalement par Guillaume.
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.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Désolé pour cet oubli, je viens d'effectuer les corrections (versions 10 à 12). Pour l'instant, c'est uniquement sur le dépôt mais je vais générer les différents formats dans le week-end.
La version 13 est indemne vu que le fichier sur les fonctions a dû être entièrement re-traduit.
Guillaume.
Hors ligne
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
Dernière modification par tholot (10/11/2020 09:27:49)
Hors ligne
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.
Guillaume.
Hors ligne
Merci Guillaume
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.
Dernière modification par tholot (13/11/2020 09:12:06)
Hors ligne
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.
Guillaume.
Hors ligne
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
Hors ligne
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.
Guillaume.
Hors ligne
Merci Guillaume pour toutes ces précisions!
Hors ligne
Pages : 1
