Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
ma configuration sur le maitre et l'esclave:
Debian 8
Postgresql 9.6.2
RAM 16
CPU 8
Recovery.conf sur l'esclave
standby_mode = 'on'
primary_conninfo = 'host=10.XXX.XXX.XXX port=5432 user=replicator password= toto'
primary_slot_name = 'tata'
restore_command = 'cp %p /postgresql/9.6/wals/%f'
archive_cleanup_command = '/usr/lib/postgresql/9.6/bin/pg_archivecleanup /postgresql/9.6/wals %r'
recovery_target_timeline = 'latest'
Sur le Master on insere 1000000 de lignes dans une table.
On démarre le salve. Il replique bien avec le master.
Le recovery.conf ne change pas pour devenir recovery.done. Pourquoi ?
Sinon
La réplication par le flux se passe bien entre les deux machines.
Que faire ?
Merci
Hors ligne
Bonjour,
de mémoire le recovery.conf ne change en recovery.done que quand la restauration est terminé.
Hors dans le cas de la réplication, par définition la restauration n'est jamais terminée jusqu'à ce que le slave soit promu master.
Cordialement.
Cordialement,
Sébastien.
Hors ligne
L'esclave se trouve en mode récupération au démarrage. Il commence la lecture des fichiers WAL archivés dont il
a besoin.
À la fin du processus de récupération, le serveur renomme recovery.conf en recovery.done (pour éviter
de retourner accidentellement en mode de récupération), puis passe en mode de fonctionnement normal.
Il me semble que c'est comme cela qu'il fonctionne l'esclave.
Hors ligne
Si vous voulez monitorer le retard entre le primaire et le secondaire et/ou que le secondaire est toujours en réplication, il faut plutôt regarder du côté de pg_stat_replication. Vous pouvez utiliser l'action streaming_delta de la sonde check_pgactivity pour ça par exemple.
edit: Tout dépend de ce que vous entendez par mode normal. Si le mode normal est "être en réplication" alors vous ne voulez pas promouvoir votre secondaire en primaire, et il faut donc conserver le recovery.conf
Je pense que vous confondez avec le mode récupération suite à un arrêt brutal, mais ce mode est géré entièrement en interne. Vous ne pouvez pas l'empêcher et il n'a rien à voir avec le recovery.conf
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour Julien,
Merci pour ta réponse.
En fait, je veux comprendre une chose. Il me semble que seule la réplication par flux se déroule correctement. Pas la réplication par les WALs.
Je pense que le slave modifie le recovery.conf en recovery.done quand il a fini de rejouer tous les WALs archivés. Est c'est le cas ?
Cordialement
Hors ligne
La réplication par flux et par WAL revient au même, c'est uniquement le canal de transmission qui change.
Et le recovery.conf est renommé en recovery.done une fois que la restauration est terminée, ou que l'on décide de promouvoir l'instance. La procédure est relativement semblable car la même infrastructure est utilisée. Concrètement, une réplication est une restauration qui ne s'arrête jamais, ou une restauration est une réplication qui s'arrête à un point dans le temps, au choix. Conserver le recovery.conf revient à dire à postgres "reste en serveur secondaire tant que je ne demande pas explicitement de basculer en tant que serveur primaire et donc mettre fin à la réplication".
Julien.
https://rjuju.github.io/
Hors ligne
Je confondais a quel moment le recovery.conf etait renommé. Merci.
Dans les log du slave on doit voir l'exécution de la commande restore_command (cp dans mon cas) du recovery.conf au moins ?
Hors ligne
Vous ne voyez pas l'exécution de la commande sauf si votre commande affiche un message. Vous voyez par contre un message dans les logs pour chaque archive restaurée avec succès via le paramètre restore_command (message du type « restored log file "XXXX" from archive ». Si les paramètres restore_command et primary_conninfo sont utilisés, il y a de fortes chances que le message n'apparaisse pas si les données sont restaurées via la streaming replication .
Julien.
https://rjuju.github.io/
Hors ligne
J'ai comme impression qui passe par la réplication par le flux.
Dans les logs aucune information sur le rejeu des wals archivés.
Hors ligne
Ça me parait normal. Le fonctionnement général est le suivant :
1) récupération du maximum d'information depuis les journaux de transaction
2) une fois le dernier journal récupéré (archive_command renvoie != 0), connexion en streaming replication
3) tant que la streaming replication renvoie des données, récupération des données via la streaming
4) retour à la première étape si la streaming réplication ne renvoie plus de données (typiquement serveur secondaire trop en retard)
Vous êtes probablement constamment dans l'étape 3.
Julien.
https://rjuju.github.io/
Hors ligne
Merci beaucoup.
Alors si jamais l'étape 4 se produisait, on doit pouvoir trouver dans les logs une ligne sur l'exécution de la commande restore_command ?
Hors ligne
Hors ligne
Merci
Hors ligne
Pages : 1
