Analyse de PostgreSQL 17.4 sur Amazon RDS - ne garantit pas la Snapshot Isolation

• Les clusters multi-AZ d’Amazon RDS for PostgreSQL prennent officiellement en charge la Snapshot Isolation, mais en pratique on y observe fréquemment des cycles G-nonadjacent et le phénomène de Long Fork qui la violent
• Les tests ont été réalisés à partir d’une charge transactionnelle PostgreSQL construite directement pour l’occasion, et des erreurs de cohérence apparaissent sur toutes les versions, de PostgreSQL 13.15 à 17.4
• Ces erreurs surviennent principalement sur les nœuds secondaires en lecture seule, et la Snapshot Isolation est rompue même au niveau "Repeatable Read"
• Les clusters RDS pourraient fournir un niveau de cohérence de type Parallel Snapshot Isolation, un modèle plus faible que celui d’un nœud PostgreSQL standard
• Les transactions en lecture seule peuvent observer des ordres de transactions différents, et ces divergences peuvent conduire à des erreurs d’intégrité des données

---

Contexte

• PostgreSQL est une base SQL open source fondée sur le MVCC, offrant plusieurs niveaux d’isolation transactionnelle. En pratique, Repeatable Read correspond à la Snapshot Isolation
• Amazon RDS fournit PostgreSQL sous forme de cluster managé, avec une architecture Multi-AZ pensée pour la réplication et la tolérance aux pannes
• L’endpoint principal permet la lecture/écriture, tandis que les secondaires sont en lecture seule et ne prennent pas en charge le niveau Serializable

Conception du test

• L’outil de test Jepsen pour PostgreSQL a été encapsulé pour l’adapter à RDS afin d’exécuter des tests transactionnels automatisés
• Les transactions ont été conçues pour lire des listes sur certaines clés ou y ajouter des entiers uniques, avec détection de cycles via le vérificateur Elle
• Sous une charge de 150 TPS en écriture et 1600 TPS en lecture, l’apparition de Long Fork et de G-nonadjacent a été confirmée en moins de deux minutes

Résultats

• Une violation de la Snapshot Isolation a été démontrée à l’aide d’un cycle G-nonadjacent composé de 4 transactions
  • T₂ a observé les modifications de T₁ mais pas celles de T₃, tandis que T₄ a vu T₃ mais pas T₁ → contradiction mutuelle dans l’ordre temporel
• Il s’agit à la fois d’un phénomène de Long Fork et d’un cas fort démontrant une violation de la Snapshot Isolation
• Aucun Write Skew n’a été observé, ce qui renforce l’hypothèse d’une possible Parallel Snapshot Isolation

Discussion

• Le niveau de cohérence de RDS Multi-AZ est inférieur à celui d’un PostgreSQL mono-nœud
• L’utilisation de nœuds en lecture seule peut entraîner des erreurs de cohérence ; il peut donc être nécessaire de n’utiliser que le nœud d’écriture, ou d’envisager d’inclure au moins une écriture dans toutes les transactions
• Cette analyse reste à un stade de test initial ; elle prouve l’existence du problème, sans pouvoir garantir son absence ailleurs

[GN⁺]

Avis Hacker News

• Ce n’est pas indiqué clairement dans le titre de l’article, mais cela concerne la nouvelle fonctionnalité RDS appelée cluster multi-AZ

  • Les instances multi-AZ correspondent à l’ancienne fonctionnalité où la base principale est répliquée de façon synchrone vers une base secondaire dans une autre AZ
  • Les clusters multi-AZ disposent de deux bases secondaires, et les transactions sont répliquées de façon synchrone vers au moins l’une d’elles
  • C’est plus robuste si une base secondaire tombe en panne ou voit ses performances se dégrader, et cela permet un accès en lecture seule aux bases secondaires
  • Les clusters multi-AZ ne sont pas une fonctionnalité Postgres standard, ce qui peut expliquer l’échec aux tests Jepsen

• Dans une ancienne entreprise, quand ils ont modifié la commande pg_dump du script de sauvegarde pour utiliser des workers parallèles (option -j), des problèmes de cohérence sont apparus à la restauration des sauvegardes (erreurs de clé dupliquée et violations de contraintes FK)

  • Le problème a été signalé à AWS et sur les mailing lists Postgres, mais il n’a pas été résolu car il était difficile à reproduire de manière fiable
  • Ils sont finalement revenus à des dumps mono-thread, et il se demande si ce problème est lié au comportement qu’ils avaient observé

• Jepsen a mené ce travail de façon indépendante, sans rémunération

  • Ce n’est pas le genre de nouvelle qu’une partie prenante d’un SGBDR a envie d’entendre un bon jour
  • Respect à aphyr

• En pratique, cela signifie que des lectures effectuées peu après une écriture sur la même ligne peuvent renvoyer des données obsolètes

  • Avant qu’une transaction d’écriture soit marquée comme terminée, toutes les couches distribuées d’une instance RDS multi-AZ ne sont pas forcément entièrement mises à jour, si bien qu’une lecture immédiate peut renvoyer une ligne inexistante ou une ancienne valeur
  • En raison du fonctionnement par snapshots de PostgreSQL, il ne s’agit pas d’une mise à jour partielle de quelques octets d’un type de colonne multi-octets qui ferait lire une valeur incohérente
  • Cela ressemble plutôt à une condition de course à cohérence éventuelle

• On ne sait pas clairement si le problème n’existe pas sur un cluster Postgres upstream multi-instance

  • Il se demande si AWS a ajouté quelque chose à la configuration du cluster ou un patch provoquant ce comportement

• Le titre soumis masque l’essentiel : RDS pour PostgreSQL 17.4 n’implémente pas correctement la snapshot isolation

• Si les développeurs supposent une snapshot isolation, mais qu’Amazon RDS for PostgreSQL ne fournit en réalité qu’une snapshot isolation parallèle, on peut se demander quels problèmes de sûreté ou quels bugs au niveau applicatif cela peut provoquer, en particulier dans les configurations multi-AZ utilisant un endpoint de réplica en lecture

• Ce phénomène a été observé sur toutes les versions testées, de 13.15 à 17.4

  • Il craignait que la mise à niveau vers une nouvelle version majeure ait été un mauvais choix, mais il s’agit apparemment non pas d’une régression, mais d’une demande de fonctionnalité ou d’un bug ancien

• Ce serait bien de faire passer toutes les versions d’Amazon RDS aux tests Jepsen

• AWS devrait mettre à jour sa documentation pour l’indiquer

  • On peut se demander si corriger la snapshot isolation entraînerait une régression de performances en latence ou en débit, ou si AWS soutiendra que l’état actuel est suffisamment robuste
  • Dans tous les cas, AWS devrait en parler