Forums PostgreSQL.fr

cecile

Membre

Replication streaming maitre- esclave

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

ruizsebastien

Membre

Re : Replication streaming maitre- esclave

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.

cecile

Membre

Re : Replication streaming maitre- esclave

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.

rjuju

Administrateur

Re : Replication streaming maitre- esclave

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/

cecile

Membre

Re : Replication streaming maitre- esclave

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

rjuju

Administrateur

Re : Replication streaming maitre- esclave

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/

cecile

Membre

Re : Replication streaming maitre- esclave

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 ?

rjuju

Administrateur

Re : Replication streaming maitre- esclave

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/

cecile

Membre

Re : Replication streaming maitre- esclave

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.

rjuju

Administrateur

Re : Replication streaming maitre- esclave

Ç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/

cecile

Membre

Re : Replication streaming maitre- esclave

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 ?

rjuju

Administrateur

Re : Replication streaming maitre- esclave

Oui.

---

Julien.
https://rjuju.github.io/

cecile

Membre

Re : Replication streaming maitre- esclave

Merci