J'ai configuré un réplica en lecture pour mon instance Amazon Relational Database Service (Amazon RDS) for PostgreSQL. Lorsque j'interroge le réplica en lecture, l'erreur « canceling statement due to conflict with recovery » s'affiche.
Résolution
En cas de conflit de réplication entre l'instance principale et le réplica en lecture, l'erreur d’annulation d’instruction s'affiche. PostgreSQL ne peut pas appliquer les informations WAL au réplica en lecture car les modifications peuvent bloquer une activité en cours sur le réplica en lecture. Par exemple, vous exécutez une instruction DROP sur l'instance principale lorsqu'une instruction SELECT est exécutée sur la table abandonnée du réplica en lecture. Si le réplica en lecture applique l'enregistrement WAL et annule l'instruction SELECT, l'erreur d’annulation d’instruction s’affiche.
Pour résoudre l'erreur d’annulation d’instruction, définissez des paramètres personnalisés sur le réplica en lecture en fonction des détails du message d'erreur.
Vous pouvez également utiliser la vue pg_stat_database_conflicts sur le réplica en lecture pour obtenir des statistiques sur les instructions annulées en raison de conflits avec la restauration. Pour plus d'informations, consultez la page 27.2.18 pg_stat_database_conflicts sur le site Web de PostgreSQL.
Détails du message d'erreur : « User was holding a relation lock for too long »
Pour résoudre ce problème, modifiez les paramètres max_standby_streaming_delay ou max_standby_archive_delay afin de laisser plus de temps avant que le réplica en lecture n'annule une instruction de secours conflictuelle. Si le réplica en lecture lit les données WAL de la réplication de streaming, modifiez le paramètre max_standby_streaming_delay. Si le réplica en lecture les données WAL à partir de l'emplacement d'archivage dans Amazon Simple Storage Service (Amazon S3), modifiez le paramètre max_standby_archive_delay.
Pour plus d'informations sur ces paramètres, consultez les pages max_standby_streaming_delay (integer) et max_standby_archive_delay (integer) sur le site Web de PostgreSQL.
Si vous définissez la valeur du paramètre à 0, le réplica en lecture annule les requêtes conflictuelles et applique les entrées WAL à l'instance de réplica. Si vous définissez la valeur sur -1, vous autorisez l'instance de réplica à attendre indéfiniment en cas de requêtes conflictuelles, et la latence de réplication augmente. Selon votre cas d’utilisation, ajustez les valeurs de ces paramètres pour équilibrer l'annulation des requêtes ou la latence de réplication.
Remarque : Si vous augmentez max_standby_archive_delay pour conserver les requêtes qui entrent en conflit avec la lecture des entrées d'archive WAL, il est recommandé d'augmenter également max_standby_streaming_delay pour éviter les annulations.
Détails du message d'erreur : « User query might have needed to see row versions that must be removed »
Ce problème se produit généralement lorsqu'une transaction sur le réplica en lecture lit des tuples qui sont configurés pour être supprimés sur l'instance principale. Pour résoudre ce problème, vous devrez peut-être activer le paramètre hot_standby_feedback.
Lorsque vous activez hot_standby_feedback, le réplica en lecture envoie des messages de commentaire à l'instance principale contenant des informations sur la transaction active la plus ancienne. Par conséquent, l'instance principale ne supprime pas les enregistrements dont la transaction pourrait avoir besoin. Pour plus d'informations sur ce paramètre, consultez la page hot_standby_feedback (boolean) sur le site Web de PostgreSQL.
Important : Le paramètre hot_standby_feedback est désactivé par défaut. Lorsque vous activez hot_standby_feedback sur le réplica en lecture, les requêtes de longue durée sur ce dernier peuvent entraîner un gonflement de la table sur l'instance principale. Les opérations vacuum ne suppriment pas les tuples morts (gonflement) que peuvent nécessiter les requêtes de longue durée. Pour réduire le risque de gonflement, il est recommandé de réduire autovacuum_threshold et autovacuum_vacuum_scale_factor et d’augmenter autovacuum_cost_limit.