Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Suite à une bascule d'une base standby en primaire, nous nous retrouvons avec des doublons sur une table malgré une contrainte UNIQUE. La bascule s'est passé normalement.
Nous sommes sur une version pg 9.6.18. Le seul fait notable est que nous avons en même temps upgradé d'une version 9.6.15 en 9.6.18
Sur tous les doublons, nous avons une ligne avec une date d'avant la bascule et une autre d'après (nous avons des colonnes d'horodatage).
Je ne comprends absolument pas comment s'est possible.
Merci pour votre aide
Hors ligne
Quel est la définition de la table et des contraintes ? Quel système d'exploitation pour le serveur primaire et le serveur secondaire ?
Guillaume.
Hors ligne
Je ne comprends absolument pas comment s'est possible.
Pour les colonnes de type texte, Il suffit d'avoir le COLLATE basé une locale qui s'appelle pareil mais qui ne trie pas pareil entre le primaire et le secondaire. C'est pourquoi le primaire et le secondaire devraient avoir exactement le même OS dans la même version.
Sur linux il y a une MAJ majeure récente de la libc qui a accru le risque ces derniers temps, cf https://blog-postgresql.verite.pro/2018 … grade.html
quand on ne réindexe pas suite à un upgrade, ou quand le couple (primaire,secondaire) a des versions décalées de la libc.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Je ne comprends absolument pas comment s'est possible.
Pour les colonnes de type texte, Il suffit d'avoir le COLLATE basé une locale qui s'appelle pareil mais qui ne trie pas pareil entre le primaire et le secondaire. C'est pourquoi le primaire et le secondaire devraient avoir exactement le même OS dans la même version.
Sur linux il y a une MAJ majeure récente de la libc qui a accru le risque ces derniers temps, cf https://blog-postgresql.verite.pro/2018 … grade.html
quand on ne réindexe pas suite à un upgrade, ou quand le couple (primaire,secondaire) a des versions décalées de la libc.
En effet, une des colonnes de la clé unique est un champ text.
Hors ligne
dverite,
Je pense, en effet, que l'on est dans la cas de figure impliquant la libc
Ancien serveur primaire:
- Debian 8.11
- libc 2.19
Nouveau serveur primaire, après bascule:
- Debian 10.4
- libc 2.28
En dehors du problème de la contrainte UNIQUE, est ce que qu'il faut reconstruire tous les index basés sur une colonne text ?
Hors ligne
Oui, tous les index portant sur des colonnes ayant un type avec une collation sont potentiellement corrompus. Cela vaut pour les colonnes de l'index mais aussi pour les colonnes utilisées dans des expressions.
Julien.
https://rjuju.github.io/
Hors ligne
Cela vaut pour les colonnes de l'index mais aussi pour les colonnes utilisées dans des expressions.
Que je comprenne bien , les expressions dans les index ?
Hors ligne
Tout à fait, par exemple:
CREATE INDEX ON unetable(int_colonne) WHERE texte_colonne > 'meh'serait potentiellement corrompu.
Julien.
https://rjuju.github.io/
Hors ligne
En tout cas , merci à vous, je comprends mieux ce qu'il se passe et je vais pouvoir agir.
Hors ligne
Pages : 1