Forums PostgreSQL.fr

mortimer.pw

Membre

Rupture Comm sur Streaming replication

Bonjour,

Je travaille sur un moteur 9.5.3 sous Cent-OS 7.2. J'ai 2 VM pour moi tester la haute disponibilité.

J'ai mis  en place la STREAMING REPLICATION.

J'arrête l'esclave.

J'insère 10000 lignes sur le Maître.

Je redémarre l'esclave, les 10000 lignes ne sont pas là.

La communication entre les 2 n'est pas restaurée automatiquement ?
Je dois faire un pg_ctl reload sur le Maître pour redémarrer Sender/Receiver. Est-ce normal ?

Merci pour votre aide.

gleu

Administrateur

Re : Rupture Comm sur Streaming replication

La communication entre les 2 n'est pas restaurée automatiquement ?

Si.

Je dois faire un pg_ctl reload sur le Maître pour redémarrer Sender/Receiver. Est-ce normal ?

Non.

---

Guillaume.

mortimer.pw

Membre

Re : Rupture Comm sur Streaming replication

Bonjour Guillaume,

Effectivement, la communication est revenue, c'est juste un peu long.

Est-ce lié aux paramètres ci-dessous du PostgreSQL.conf ?
          tcp_keepalives_idle = 10
          tcp_keepalives_interval = 10
          tcp_keepalives_count = 0

Comment cela fonctionne-t-il ?
J'ai activé l'archivage des fichiers WAL.
Le transfert des enregistrements WAL se fait au travers du réseau.
Si celui-ci est coupé, est-ce que les enregistrements WAL sont stockés dans les fichiers WAL ?
Puis archivés ?
Puis restaurés sur l'esclave ?

Pourriez-vous décrire le mécanisme, svp ?

Merci.

Dernière modification par mortimer.pw (27/05/2016 09:42:29)

Marc Cousin

Membre

Re : Rupture Comm sur Streaming replication

Bonjour, ce sont les paramètres qui régissent le keepalive. C'est directement pris en compte par l'OS (c'est un paramètre de socket).

idle, c'est le temps depuis lequel une session tcp est inactive avant d'activer le mécanisme de keepalive.
interval, c'est l'espace entre les envois de paquets de keepalive (si on n'a pas de réponse bien sûr)
count, c'est le nombre de keepalives avant de considérer la session tcp comme morte. 0 ça veut dire utiliser la valeur par défaut du système...

Sous linux, par exemple, les valeurs par défaut sont:

net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200

Le paramétrage semble bon. Par contre, en 9.5, c'est wal_sender_timeout et wal_receiver_timeout, qui sont utilisés pour les sessions de réplication

---

Marc.

mortimer.pw

Membre

Re : Rupture Comm sur Streaming replication

Bonjour Marc,
Merci pour la réponse.
J'ai un peu de mal avec le mécanisme.
Les enregistrements WAL sont stockés dans les fichiers WAL "courants" et transférés sur l'esclave au fil de l'eau ?
Si je perds mon esclave, que se passe t'il ? les enregistrements WAL s'accumulent dans les fichiers WAL. Mais ils vont être recyclés au bout d'un moment ?
Voulez-vous bien m'éclairer sur le sujet, svp ?

Marc Cousin

Membre

Re : Rupture Comm sur Streaming replication

Oui, les WAL sont recyclés au bout d'un moment… sauf dans deux cas:

- si vous avez déclaré un slot de réplication, dans ce cas le maître sait où en est chacun des esclaves identifiés par replication slot, et garde les journaux aussi longtemps que nécessaire
- si la commande d'archivage échoue… tant qu'elle ne réussit pas, un fichier de WAL n'est pas recyclable.S'il y a une commande d'archivage bien sûr.

---

Marc.

mortimer.pw

Membre

Re : Rupture Comm sur Streaming replication

Donc si mon esclave traîne à redémarrer et que je n'ai pas défini de slot de réplication mais que j'ai activé l'archivage, les enregistrements WAL non transférés seront stockés dans les fichiers WAL archivés ?
Et comme mon esclave va les lire en redémarrant, tout va bien ?

Marc Cousin

Membre

Re : Rupture Comm sur Streaming replication

Oui, vous aurez les WAL dans l'archive. C'est une des raisons pour lesquelles il est intéressant d'avoir une archive en plus du streaming.

---

Marc.

mortimer.pw

Membre

Re : Rupture Comm sur Streaming replication

Super, merci Marc.