Evaluación de Jepsen sobre MySQL 8.0.34

 (jepsen.io)
3 puntos por GN⁺ 2023-12-20 | 1 comentarios | Compartir por WhatsApp

Contexto de MySQL

  • MySQL ha sido una de las bases de datos SQL más ampliamente desplegadas durante los últimos 28 años.
  • Se usa principalmente para procesamiento de transacciones en línea (OLTP), y también se despliega como parte de sistemas OLAP y de colas.
  • Fue diseñada como una base de datos de servidor único, pero se ha expandido mediante diversos métodos de replicación multinodo.
  • El análisis se centra específicamente en MySQL usando el motor de almacenamiento InnoDB.

Los niveles de aislamiento ANSI SQL en realidad son malos

  • Para discutir las sutilezas de los niveles de aislamiento de SQL, es necesario explicar el contexto histórico de los cuatro niveles seguros de consistencia transaccional propuestos en 1977 y del estándar SQL publicado por ANSI en 1986.
  • ANSI SQL define los niveles de aislamiento a través de tres fenómenos posibles (lecturas sucias, lecturas no repetibles y fantasmas).
  • En 1995 se señalaron defectos en los niveles de aislamiento de ANSI SQL, y en 1999 Adya desarrolló una definición formal e independiente de la implementación para los niveles de aislamiento de ANSI SQL.

Niveles de aislamiento de MySQL

  • La documentación de MySQL dice que ofrece los cuatro niveles de aislamiento de transacciones descritos por el estándar SQL:1992.
  • Incluye explicaciones sobre cómo MySQL logra esto en cada nivel de aislamiento.
  • El nivel de aislamiento Repeatable Read de MySQL garantiza la seguridad mediante un mecanismo de instantáneas.

Diseño de pruebas

  • Se diseñó una suite de pruebas para MySQL usando la biblioteca de pruebas de Jepsen.
  • Se realizaron pruebas en diversos entornos, incluyendo un solo nodo de MySQL, un clúster de replicación binlog y clústeres de AWS RDS.
  • Se ejecutaron cargas de trabajo clave sobre aislamiento transaccional usando el verificador de list-append de Elle.

Resultados

  • El Repeatable Read de MySQL permite G2-item, que está prohibido por el nivel de aislamiento PL-2.99 de Adya.
  • El Repeatable Read de MySQL también permite G-single (read skew).
  • El Repeatable Read de MySQL permite el fenómeno P4 (lost update).
  • El Repeatable Read de MySQL muestra errores de consistencia interna.
  • El Repeatable Read de MySQL viola Monotonic Atomic View.

GN⁺ opina

  • Que el nivel de aislamiento Repeatable Read de MySQL se comporte de forma distinta a lo especificado por el estándar es información importante para desarrolladores y administradores de bases de datos. Esto significa que podría no cumplir las expectativas sobre consistencia y aislamiento de datos.
  • Los resultados de las pruebas proporcionan información esencial para entender los niveles de aislamiento de un sistema de base de datos y elegir mecanismos de aislamiento adecuados.
  • Estos hallazgos ofrecen una visión de cómo los estándares relacionados con los niveles de aislamiento de una base de datos pueden diferir de las implementaciones reales. Esto ayuda a comprender la complejidad de la tecnología de bases de datos y las diferencias sutiles entre niveles de aislamiento.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-20
Opiniones en Hacker News

  • Desde hace mucho he sostenido que repeatable read es una mala idea. Incluso si la implementación es perfecta y funciona correctamente en la base de datos, es difícil de entender al manejar consultas complejas.

    • Creo que hay dos niveles de aislamiento que tienen sentido:
      • read committed
      • serializable
    • La configuración serializable no tiene sorpresas. Con read committed, queda claro que si quieres una vista consistente de los datos, debes bloquear las filas antes de empezar a leerlas.
    • read committed es muy similar al código multihilo general y a la gestión de memoria, así que la mayoría de los ingenieros pueden entenderlo de forma intuitiva.
    • serializable es tan estricto que es difícil cometer errores inesperados.
    • El nivel intermedio es tierra de nadie, y algo menos consistente que Read Committed ya deja de ser realmente una base de datos.

  • En FOSSDEM-2024 se presentará "Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study".

    • Estudio comparativo de Oracle, MySQL, SQL Server, PostgreSQL y YugabyteDB.

  • Estoy evaluando el artículo sobre AWS RDS, pero me pregunto si también tiene enfoque en AWS Aurora (MySQL). AWS construye plataformas de bases de datos que pretenden ser MySQL o PostgreSQL. Sería interesante ver si Aurora MySQL tiene las mismas "funciones" que RDS o MariaDB.

  • Me parece un excelente ejemplo de "sistemas que realmente funcionan" construidos sobre una base que muestra muchos artefactos de consistencia.

  • Es algo preocupante que la replicación de RDS deje de funcionar en 5 minutos y que no haya una alerta por fallas en la verificación de estado.

  • Me pregunto cómo se mapea append (a) a operaciones SQL reales en la tabla dada, y si un campo TEXT se usa como lista.

    • Hubo un problema en el modo repeatable read de MySQL donde un solo SELECT elegía una sola fila y devolvía un resultado imposible. Por ejemplo, en SELECT min(value), max(value) FROM table WHERE id = 1;, aunque id era la clave primaria, alguna vez se obtuvieron valores distintos para min y max.

  • Además de compararlo con las definiciones teóricas de los modos de aislamiento, también sería útil compararlo con otras bases de datos relacionales populares como PostgreSQL, MS SQL y Oracle. Son cosas que los desarrolladores deben tener en mente cuando buscan compatibilidad.

  • Parece que SELECT ... FOR UPDATE es la respuesta a todos estos problemas; si bloqueas las filas que vas a actualizar, todo funciona como se anuncia.

  • Hoy iba a avanzar algo de trabajo, pero agradezco que el "call me maybe" de aphyr y jepsen.io estén entre los mejores contenidos que he leído en internet.

  • Me pregunto qué tanto del análisis de MySQL aplica igual a MariaDB, que usa InnoDB como motor de almacenamiento predeterminado.