Análisis de PostgreSQL 17.4 en Amazon RDS: no garantiza Snapshot Isolation

• El clúster multi-AZ de Amazon RDS for PostgreSQL oficialmente soporta Snapshot Isolation, pero en la práctica ocurren con frecuencia ciclos G-nonadjacent y el fenómeno Long Fork que la vulneran
• Las pruebas se realizaron con una carga de trabajo de transacciones PostgreSQL configurada directamente, y se produjeron errores de consistencia en todas las versiones desde PostgreSQL 13.15 hasta 17.4
• Estos errores ocurren principalmente en nodos secundarios de solo lectura, y Snapshot Isolation se rompe incluso en el nivel "Repeatable Read"
• Es posible que el clúster RDS ofrezca un nivel de consistencia de Parallel Snapshot Isolation, que es un modelo más débil que PostgreSQL base en un solo nodo
• Las transacciones de solo lectura pueden observar órdenes distintos de transacciones, y estas inconsistencias pueden derivar en errores de integridad de datos

---

Background

• PostgreSQL es una base de datos SQL open source basada en MVCC, y ofrece varios niveles de aislamiento de transacciones. Repeatable Read en realidad significa Snapshot Isolation
• Amazon RDS ofrece PostgreSQL como un clúster administrado, y la configuración Multi-AZ es una arquitectura para replicación y tolerancia a fallos
• El endpoint principal permite lectura/escritura, los secundarios son de solo lectura y no soportan el nivel Serializable

Test Design

• Se envolvió la herramienta de pruebas Jepsen para PostgreSQL para adaptarla a RDS y ejecutar pruebas automatizadas de transacciones
• Las transacciones se diseñaron para leer listas en claves específicas o hacer append de enteros únicos, con detección de ciclos mediante el verificador Elle
• Con una carga de 150 TPS de escritura y 1600 TPS de lectura, se confirmó la aparición de Long Fork y G-nonadjacent en menos de 2 minutos

Results

• Se demostró una violación de Snapshot Isolation mediante un ciclo G-nonadjacent compuesto por 4 transacciones
  • T₂ observó los cambios de T₁ pero no los de T₃; T₄ sí vio T₃ pero no vio T₁ → aparece una contradicción mutua en el orden temporal
• Esto constituye un caso de fenómeno Long Fork y una evidencia fuerte de violación de Snapshot Isolation, y
• No se encontró Write Skew, lo que respalda la posibilidad de Parallel Snapshot Isolation

Discussion

• Multi-AZ RDS tiene un nivel de consistencia inferior al de PostgreSQL en un solo nodo
• Como pueden ocurrir errores de consistencia al usar nodos de solo lectura, conviene considerar usar únicamente el nodo de escritura o hacer que todas las transacciones incluyan al menos una escritura
• Este análisis está en un nivel de pruebas inicial y demuestra la existencia del problema, pero no garantiza su ausencia

[GN⁺]

Comentarios en Hacker News

• Aunque no se menciona claramente en el título del artículo, esto trata sobre la nueva función de RDS llamada clúster Multi-AZ

  • La instancia Multi-AZ es la función más antigua en la que la BD principal se replica de forma síncrona a una BD secundaria en otra AZ
  • El clúster Multi-AZ tiene dos BD secundarias, y la transacción se replica de forma síncrona al menos a una de ellas
  • Esto es más robusto si una BD secundaria falla o baja su rendimiento, y permite acceso de solo lectura a las BD secundarias
  • El clúster Multi-AZ no es una función estándar de Postgres, y esa podría ser la razón por la que falla en las pruebas de Jepsen

• En una empresa anterior, cuando cambiamos el comando pg_dump del script de respaldos para usar workers en paralelo (flag -j), aparecieron problemas de consistencia al restaurar el respaldo (errores de clave duplicada y errores de restricciones fk)

  • Reportamos el problema a AWS y a la lista de correo de Postgres, pero como no era fácil reproducirlo, no se resolvió
  • Al final volvimos a un dump de un solo hilo, y me pregunto si este problema está relacionado con el comportamiento que vimos

• Jepsen hizo este trabajo de forma independiente y no recibió pago

  • No es algo que a los interesados en un RDBMS les gustaría escuchar en un buen día
  • Mis respetos para aphyr

• La implicación práctica de este problema es que una lectura que ocurre rápidamente después de una escritura sobre la misma fila puede devolver datos obsoletos

  • Antes de que la transacción de escritura sea marcada como completada, no todas las capas distribuidas de una instancia RDS Multi-AZ quedan totalmente actualizadas, por lo que una lectura inmediata puede devolver una fila inexistente o un valor antiguo
  • Debido al mecanismo de snapshots de PostgreSQL, no significa que solo se actualicen algunos bytes de un tipo de columna multibyte y que la lectura obtenga un valor sin sentido
  • Esto parece una condición de carrera que eventualmente termina siendo consistente

• No está claro si en un clúster upstream de Postgres con múltiples instancias no habría problemas

  • Me pregunto si AWS agregó algo a la configuración del clúster o algún parche que provoque este comportamiento

• El título enviado oculta el punto clave: RDS para PostgreSQL 17.4 no implementa correctamente el aislamiento por snapshots

• Si los desarrolladores asumen aislamiento por snapshots, pero Amazon RDS for PostgreSQL en realidad solo ofrece aislamiento por snapshots en paralelo, me pregunto qué tipo de fallas de seguridad o bugs a nivel aplicación podrían ocurrir, especialmente en configuraciones Multi-AZ que usan endpoints de réplicas de lectura

• Este fenómeno ocurrió en todas las versiones probadas, desde 13.15 hasta 17.4

  • Me preocupaba que actualizar la versión mayor hubiera sido una mala decisión, pero esto no es una regresión sino una solicitud de funcionalidad o un bug de larga data

• Sería bueno hacer pruebas de Jepsen a todas las versiones de Amazon RDS

• AWS debería actualizar la documentación para comunicar esto

  • Me pregunto si corregir el aislamiento por snapshots causaría una regresión de rendimiento en latencia o throughput, o si van a sostener que el estado actual es suficientemente sólido
  • En cualquier caso, AWS debería pronunciarse al respecto