Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 10/02/2014 00:51:02
- stylor
- Membre
Canceling statement due to conflict WITH recovery
Salut à tous,
Lorsque j'execute un simple SELECT * FROM MaTable à partir d'une DB miroir hot-standby contenant exactement les mêmes données que la production, j'ai un message d'erreur :
Canceling statement due to conflict WITH recovery
La table contient +/- 4 millions de rows. Si j'ajoute un limit(1000) par exemple, ça fonctionne. J'ai l'impression qu'il y a un soucis de transaction entre la prod et le miroir ou quelque chose du genre. Le temps que Postgres execute ma requête, la table à changé. Mais la raison est peu-être tout autre, je ne suis pas expert et je ne connais pas du tout Postgres.
C'est problématique car je dois lire en entier la table dans le but d'exporter l'ensemble des données (via un ETL) vers notre Datawarehouse, et pour se faire, je dois utiliser la DB miroir (décision du DBA).
Merci d'avance.
Hors ligne
#2 10/02/2014 00:58:34
- rjuju
- Administrateur
Re : Canceling statement due to conflict WITH recovery
Bonjour,
ces erreurs sont généralement dues à l'autovacuum sur le maître. Si vous êtes en version 9.1 ou supérieure, vous pouvez activer le paramètre hot_standby_feedback sur le maître afin d'éviter les conflits de réplication du au vacuum. Vous pouvez sinon augmenter le paramètre max_standby_streaming_delay.
Julien.
https://rjuju.github.io/
Hors ligne
#3 10/02/2014 11:55:02
- stylor
- Membre
Re : Canceling statement due to conflict WITH recovery
Après recherche sur le web, effectivement ça pourrait bien être la cause. Après discussion avec le DBA, il n'est pas possible de changer ces paramètres car il souhaite que la synchro soit la plus rapide possible et ne pas avoir de délais.
Quelle serait la solution ? Demander au DBA de faire un autre miroir mais avec un délais plus important pour la BI ?
Hors ligne
#4 10/02/2014 21:36:11
- gleu
- Administrateur
Re : Canceling statement due to conflict WITH recovery
Oui, vous pouvez avoir deux esclaves et que le second ait son paramètre max_standby_streaming_delay avec une valeur bien plus importante que le premier esclave. C'est quelque chose qui se fait couramment.
Guillaume.
Hors ligne
#5 10/02/2014 21:36:55
- gleu
- Administrateur
Re : Canceling statement due to conflict WITH recovery
Vous pouvez aussi mettre le deuxième en pause de réplication (pg_xlog_replay_pause()) le temps de l'exécution de votre requête, puis enlever la pause (pg_xlog_replay_resume()).
Guillaume.
Hors ligne
#6 10/02/2014 23:38:24
- stylor
- Membre
Re : Canceling statement due to conflict WITH recovery
OK on va essayer de faire ainsi.
Je vous remercie :-)
Hors ligne
#7 12/02/2014 13:54:01
- stylor
- Membre
Re : Canceling statement due to conflict WITH recovery
Est-il possible de faire une réplication donc pour le 2e slave mais uniquement des tables qu'on souhaite utiliser à la BI ?
Il y a +/- une vingtaine de tables dont on a besoin alors que la DB compte +/- 700 tables
Hors ligne
#8 12/02/2014 14:41:28
- rjuju
- Administrateur
Re : Canceling statement due to conflict WITH recovery
Pas avec la réplication native de postgres. Le seul moyen de le faire est d'utiliser une réplication par trigger, avec slony par exemple.
Julien.
https://rjuju.github.io/
Hors ligne
#9 12/02/2014 14:51:16
- stylor
- Membre
Re : Canceling statement due to conflict WITH recovery
D'après ce que j'ai lu, trigger n'est pas la meilleur façon point de vue performance...
Y-a-t'il une meilleur façon de faire mise à part une réplication alors ?
Dernière modification par stylor (12/02/2014 14:53:32)
Hors ligne
#10 12/02/2014 15:11:09
- rjuju
- Administrateur
Re : Canceling statement due to conflict WITH recovery
Si vous ne voulez pas mettre en pause la réplication ou délayer les autovacuum, le meilleur moyen reste un 2ème esclave sur lequel on autorise un retard plus important.
La réplication par trigger sera moins performante, mais en général l'activité sur les tables BI en journée est censé être moins importante que sur les autres tables. Tout dépend de vos contraintes en terme de volumétrie, PCA, activité etc.
Julien.
https://rjuju.github.io/
Hors ligne
#11 12/02/2014 15:39:38
- stylor
- Membre
Re : Canceling statement due to conflict WITH recovery
Est-ce ceci dont vous parlez ?
http://www.slony.info/documentation/2.2 … ml#FIRSTDB
Hors ligne
#12 12/02/2014 23:05:54
- gleu
- Administrateur
Re : Canceling statement due to conflict WITH recovery
La question des performances avec les triggers me semble peu crédible. Les triggers Slony sont écrits en C et sont très performants.
Guillaume.
Hors ligne
#13 12/02/2014 23:24:20
- stylor
- Membre
Re : Canceling statement due to conflict WITH recovery
C'est possible, je ne connais pas. J'ai dit ça de manière général pour les SGBD d'après ce que j'ai lu. Dans la pratique, j'en ai très peu utilisé.
Après disscusion avec le DBA, nous pensons extraire directement depuis le master, ainsi ça lui évite de créer un 2e slave uniquement pour la BI.
Hors ligne
#14 08/06/2016 12:41:59
- herve.lefebvre
- Membre
Re : Canceling statement due to conflict WITH recovery
Bonjour, et désolé pour cette exhumation...
vous pouvez activer le paramètre hot_standby_feedback sur le maître.
Ne serait-ce pas plutôt sur le stand-by ?
Hors ligne
#15 08/06/2016 14:05:02
- rjuju
- Administrateur
Re : Canceling statement due to conflict WITH recovery
Bonjour, et désolé pour cette exhumation...
rjuju a écrit :vous pouvez activer le paramètre hot_standby_feedback sur le maître.
Ne serait-ce pas plutôt sur le stand-by ?
Tout à fait, c'était une erreur de ma part.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1