Vous n'êtes pas identifié(e).
Pages : 1
Bonjour
Nous utilisons le mode streaming sous plusieurs versions de Postgresql.
Jusqu'à la V11, le passage d'un secondaire en mode R/W par fichier trigger est très rapide. Quelques secondes pas plus.
Par contre, depuis la V12, la bascule de secondaire streaming en primaire (par promote ou par fichier trigger) peut prendre plusieurs minutes en production. Je suis monté à 10mn sans aucune trace particulière dans le fichier de log du secondaire.
Hors production, je n'ai pas pu reproduire le phénomène.
Comme je le disais, aucune trace. Je ne sais absolument pas ce que peut faire l'instance Postgresql pendant cette phase de 'promote'.
Auriez-vous quelques pistes de recherche à me fournir ? Y aurait-il des paramètres qui pourrait expliquer ceci ?
Si vous avez besoin de plus d'informations sur la configuration en place, sur les traces de l'instance, je peux vous fournir cela sans problème.
Merci à tous pour votre aide
Philippe
Hors ligne
Bonjour,
Lors de la promotion, le standby va d'abord finir de rejouer tous les WAL disponibles localement ou via les archives (restore_command).
La promotion peut prendre plus ou moins de temps en fonction du retard de votre secondaire par rapport à la production, du nombre de WAL à restaurer, de la commande de restauration, etc...
Hors ligne
Bonjour ioguix
Merci pour ta réponse.
Je suis d'accord avec toi, lors d'une bascule il est normal qu'il y ait la fin des WAL disponibles à traiter. Je vais rajouter plus de traces dans mon outil lancé par le restore_command pour essayer d'avoir plus d'information sur cette étape.
Pour le retard de réplication, comme nous sommes en bascule volontaire, je contrôle que le secondaire est à jour et je stoppe proprement le primaire de manière à éviter les connexions applicatives sur cette BDD qui doit perdre la production. Une fois ceci, j'engage le promote du secondaire.
Je vous tiens au courant dès que j'ai pu ajouter des traces dans mes outils.
Encore merci
Philippe
Hors ligne
Pages : 1
