Vous n'êtes pas identifié(e).
Pages : 1
Bonjour, j'ai déployé un maitre et un esclave en 9.0 avec de la SR.
Je cherche un moyen "programmatique" (c'est à dire pas en greppant dans les logs avec mes yeux d'humain) de savoir si l'esclave arrivera à se réaligner avec le maitre via la connexion TCP et/ou la restore_command.
Sur l'esclave en lançant plusieurs fois cette requête SQL:
select pg_last_xlog_receive_location(), pg_last_xlog_replay_location();
j'obtiens à peu près ce que je veux: si les deux valeurs sont identiques c'est que l'esclave a réussi à rejoindre le maitre.
Par contre, si le maître n'a strictement aucune activité en écriture il est fréquent que la valeur de pg_last_xlog_replay_location() s'approche de l'autre sans l'atteindre, elle l'atteint quand il s'est passé archive_timeout secondes (ou qu'il y a eu des écritures sur le maitre).
Mon test case est le suivant, le master et le slave en ligne et en mode SR opérationnel.
1 - éteindre le maitre
2 - faire un restart sur le slave
3 - démarrer le maitre
4 - sur l'esclave je lance la requête SQL donnée plus haut, en espérant avoir les deux même valeurs
Est-ce que vous auriez un moyen plus fiable de savoir si on doit repartir d'un dump du master, ou bien si l'esclave peut se récupérer tout seul ?
Hors ligne
j'obtiens à peu près ce que je veux: si les deux valeurs sont identiques c'est que l'esclave a réussi à rejoindre le maitre.
Pas vraiment. C'est plutôt que l'esclave a réussi à rejouer tout ce qu'il a reçu du maître. Mais le maître peut être bien plus avancé que l'esclave.
Par contre, si le maître n'a strictement aucune activité en écriture il est fréquent que la valeur de pg_last_xlog_replay_location() s'approche de l'autre sans l'atteindre, elle l'atteint quand il s'est passé archive_timeout secondes (ou qu'il y a eu des écritures sur le maitre).
Vous êtes sûrs ? n'est-ce pas plutôt parce que les sessions en question ont mis du temps à envoyer leur commit ?
Est-ce que vous auriez un moyen plus fiable de savoir si on doit repartir d'un dump du master, ou bien si l'esclave peut se récupérer tout seul ?
Le mieux est la comparaison entre pg_current_xlog_location() sur le maître et pg_last_xlog_receive_location()/pg_last_xlog_replay_location(); sur l'esclave. Ce que fait d'ailleurs pgPool-II pour abandonner un esclave s'il laggue trop.
Guillaume.
Hors ligne
j'obtiens à peu près ce que je veux: si les deux valeurs sont identiques c'est que l'esclave a réussi à rejoindre le maitre.
Pas vraiment. C'est plutôt que l'esclave a réussi à rejouer tout ce qu'il a reçu du maître. Mais le maître peut être bien plus avancé que l'esclave.
Certe mais le cas que je veux adresser est surtout celui où au démarrage l'esclave n'arrive pas à récupérer les premiers logs et est donc sûr de ne pas réussir à se resynchroniser.
Par contre, si le maître n'a strictement aucune activité en écriture il est fréquent que la valeur de pg_last_xlog_replay_location() s'approche de l'autre sans l'atteindre, elle l'atteint quand il s'est passé archive_timeout secondes (ou qu'il y a eu des écritures sur le maitre).
Vous êtes sûrs ? n'est-ce pas plutôt parce que les sessions en question ont mis du temps à envoyer leur commit ?
A priori non, car si j'abaisse l'archive_timeout à 60 secondes j'ai un "alignement" total de l'esclave dans les 60 secondes. De plus mon maitre et mon esclave n'ont strictement aucune activité.
Est-ce que vous auriez un moyen plus fiable de savoir si on doit repartir d'un dump du master, ou bien si l'esclave peut se récupérer tout seul ?
Le mieux est la comparaison entre pg_current_xlog_location() sur le maître et pg_last_xlog_receive_location()/pg_last_xlog_replay_location(); sur l'esclave. Ce que fait d'ailleurs pgPool-II pour abandonner un esclave s'il laggue trop.
Oui merci, je suis parti sur cette manière de faire.
L'autre possibilité que je voyais était de faire tourner les logs sur le maitre avec un pg_switch_xlog()
Hors ligne
Pages : 1
