Jepsen: MySQL 8.0.34

Artículo original ↗ Discusión en Hacker News ↗

El análisis de Jepsen de MySQL 8.0.34 ha renovado el escrutinio sobre las garantías transaccionales de la base de datos, mostrando que su aislamiento predeterminado de “repeatable read” todavía puede producir anomalías sorprendentes, incluso en un solo nodo, y que los proveedores y usuarios a menudo malinterpretan qué nivel de seguridad están obteniendo realmente. Los comentaristas contrastan MySQL con PostgreSQL y otros sistemas en rendimiento, replicación, complejidad operativa y semántica de aislamiento, y muchos sostienen que el aislamiento serializable debería ser el valor predeterminado, aunque reconociendo sus costes de rendimiento. El hilo destaca cómo los sistemas del mundo real pueden parecer funcionar “lo suficientemente bien” sobre modelos de consistencia más débiles o mal documentados, y lo difícil que resulta para los desarrolladores habituales razonar correctamente sobre los niveles de aislamiento.

¿Por qué empezar proyectos nuevos con MySQL?

  • Muchos usan MySQL porque ya lo conocen, pueden diagnosticarlo y “funciona lo suficientemente bien” para cargas de trabajo típicas.
  • Escala lo suficiente para la mayoría de las empresas; los casos más extremos pueden usar herramientas como Vitess.
  • Históricamente ofrecía motores enchufables y replicación sencilla; se percibe como más fácil de operar y bueno para aplicaciones con muchas lecturas.
  • Algunos encuentran que la CLI y las herramientas son más “amigables para desarrolladores” que las alternativas.

MySQL vs PostgreSQL: características y operaciones

  • PostgreSQL es elogiado por un dialecto SQL más sensato, funciones más ricas (JSONB, índices parciales/de expresión) y un ecosistema sólido.
  • Se argumenta que MySQL es operativamente más simple: actualizaciones más fáciles, replicación lógica de larga data, y un ajuste al estilo de autovacuum menos doloroso.
  • Algunos afirman que el MVCC y el modelo de hilos de MySQL son técnicamente más fuertes que el proceso-por-conexión más vacuuming de PostgreSQL, aunque otros cuestionan las afirmaciones sobre escalabilidad.
  • El planificador de consultas de Postgres es más avanzado, pero puede elegir de forma impredecible planes malos sin una forma fácil de forzarlos; el planificador más limitado de MySQL se ve como más predecible en emergencias.

Niveles de aislamiento, corrección y valores predeterminados

  • La discusión se centra en que el “Repeatable Read” de MySQL no coincide con el modelo formal y produce anomalías incluso en un solo nodo.
  • Varios sostienen que el aislamiento predeterminado debería ser SERIALIZABLE porque la mayoría de los desarrolladores no entiende el aislamiento; niveles más débiles producen errores sutiles y difíciles de depurar.
  • Otros subrayan el coste de rendimiento de SERIALIZABLE y las frecuentes reintentos de transacciones, abogando por usarlo solo cuando sea estrictamente necesario.
  • Algunos proponen solo dos niveles significativos para la mayoría de las aplicaciones: READ COMMITTED y SERIALIZABLE; cualquier cosa intermedia se considera una confusa “tierra de nadie”.
  • La aislación por instantánea se considera valiosa para consultas de solo lectura.

Prácticas de desarrollo y bloqueo

  • Muchos comentaristas dicen que los desarrolladores rara vez piensan en aislamiento o consistencia; simplemente aceptan los valores predeterminados.
  • SELECT ... FOR UPDATE y el bloqueo explícito pueden “arreglar” anomalías, pero a costa de rendimiento, contención de bloqueos y posibles interbloqueos.
  • Las transacciones largas o de gran tamaño se destacan como riesgos importantes de rendimiento y escalabilidad bajo MVCC.

Variantes de MySQL e implicaciones más amplias

  • Se informa que MariaDB muestra las mismas clases de anomalías que MySQL, incluso en pruebas de un solo nodo.
  • Aurora MySQL preserva en gran medida la semántica de MySQL/InnoDB, con algunas particularidades específicas del clúster en torno al almacenamiento compartido y purge.
  • A los comentaristas les resulta sorprendente cuántos sistemas que “prácticamente funcionan” están construidos sobre motores con artefactos de consistencia tan observables.