Jepsen: MySQL 8.0.34
A análise da Jepsen sobre o MySQL 8.0.34 renovou o escrutínio das garantias transacionais do banco de dados, mostrando que seu isolamento padrão “repeatable read” ainda pode produzir anomalias surpreendentes — até em um único nó — e que fornecedores e usuários muitas vezes entendem mal qual nível de segurança realmente estão obtendo. Os comentaristas contrastam MySQL com PostgreSQL e outros sistemas em desempenho, replicação, complexidade operacional e semântica de isolamento, com muitos defendendo que o isolamento serializável deveria ser o padrão, embora reconheçam seus custos de desempenho. O debate destaca como sistemas do mundo real podem parecer funcionar “bem o suficiente” sobre modelos de consistência mais fracos ou mal documentados, e como é difícil para desenvolvedores típicos raciocinarem corretamente sobre níveis de isolamento.
Por que começar novos projetos em MySQL?
- Muitos usam MySQL porque já o conhecem, conseguem depurá-lo e ele “funciona bem o suficiente” para cargas de trabalho típicas.
- Ele escala suficientemente para a maioria das empresas; casos mais extremos podem usar ferramentas como Vitess.
- Historicamente oferecia mecanismos plugáveis e replicação fácil; é percebido como mais simples de operar e bom para apps com muita leitura.
- Alguns acham a CLI e as ferramentas mais “amigáveis ao desenvolvedor” do que alternativas.
MySQL vs PostgreSQL: recursos e operação
- PostgreSQL é elogiado por um dialeto SQL mais sensato, recursos mais ricos (JSONB, índices parciais/de expressão) e ecossistema forte.
- MySQL é defendido como operacionalmente mais simples: upgrades mais fáceis, replicação lógica de longa data, menos dor ao ajustar no estilo autovacuum.
- Alguns afirmam que o MVCC e o modelo de threading do MySQL são tecnicamente superiores ao PostgreSQL, com processo por conexão e vacuuming, embora outros contestem as alegações de escala.
- O planejador de consultas do Postgres é mais avançado, mas pode escolher planos ruins de forma imprevisível sem fácil imposição; o planejador mais limitado do MySQL é visto como mais previsível em emergências.
Níveis de isolamento, correção e padrões
- O debate gira em torno do “Repeatable Read” do MySQL não corresponder ao modelo formal e produzir anomalias até em um único nó.
- Vários argumentam que o isolamento padrão deveria ser SERIALIZABLE porque a maioria dos desenvolvedores não entende isolamento; níveis mais fracos produzem bugs sutis e difíceis de depurar.
- Outros enfatizam o custo de desempenho do SERIALIZABLE e as retransmissões frequentes de transações, defendendo-o apenas quando estritamente necessário.
- Alguns propõem apenas dois níveis significativos para a maioria dos apps: READ COMMITTED e SERIALIZABLE; qualquer coisa entre eles é vista como um confuso “terra de ninguém”.
- Snapshot isolation é vista como valiosa para consultas somente de leitura.
Práticas de desenvolvimento e bloqueio
- Muitos comentaristas dizem que os desenvolvedores raramente pensam em isolamento ou consistência; eles apenas aceitam os padrões.
- SELECT … FOR UPDATE e bloqueio explícito podem “corrigir” anomalias, mas ao custo de desempenho, contenção de locks e possíveis deadlocks.
- Transações longas ou grandes são destacadas como grandes riscos de desempenho e escalabilidade sob MVCC.
Variantes do MySQL e implicações mais amplas
- É relatado que o MariaDB mostra as mesmas classes de anomalia que o MySQL, inclusive em testes de nó único.
- O Aurora MySQL preserva amplamente a semântica de MySQL/InnoDB, com algumas particularidades específicas do cluster em torno de armazenamento compartilhado e purge.
- Os comentaristas acham impressionante quantos sistemas que “funcionam na prática” são construídos sobre mecanismos com artefatos de consistência tão observáveis.