Avaliação do Jepsen sobre o MySQL 8.0.34

Contexto do MySQL

• O MySQL é um dos bancos de dados SQL mais amplamente implantados nos últimos 28 anos.
• É usado principalmente para processamento de transações online (OLTP), mas também é implantado para OLAP e como parte de sistemas de filas.
• Foi projetado como um banco de dados de servidor único, mas foi expandido com vários métodos de replicação multinó.
• A análise se concentra no MySQL que usa o mecanismo de armazenamento InnoDB.

Os níveis de isolamento ANSI SQL são, na prática, ruins

• Para discutir as sutilezas dos níveis de isolamento SQL, é necessário explicar o contexto histórico dos quatro níveis de segurança da consistência transacional propostos em 1977 e do padrão SQL publicado pela ANSI em 1986.
• O ANSI SQL define os níveis de isolamento por meio de três fenômenos possíveis: dirty read, non-repeatable read e phantom.
• Em 1995, foram apontadas falhas nos níveis de isolamento do ANSI SQL, e em 1999 Adya desenvolveu uma definição formal e independente de implementação para os níveis de isolamento do ANSI SQL.

Níveis de isolamento do MySQL

• A documentação do MySQL afirma oferecer os quatro níveis de isolamento de transação descritos pelo padrão SQL:1992.
• Inclui explicações sobre como o MySQL alcança isso em cada nível de isolamento.
• O nível de isolamento Repeatable Read do MySQL garante segurança por meio de um mecanismo de snapshot.

Projeto dos testes

• Foi projetada uma suíte de testes para o MySQL usando a biblioteca de testes Jepsen.
• Os testes foram executados em vários ambientes, incluindo um único nó MySQL, um cluster com replicação por binlog e clusters AWS RDS.
• Foram executadas cargas de trabalho principais de isolamento transacional usando o verificador list-append do Elle.

Resultados

• O Repeatable Read do MySQL permite G2-item, proibido pelo nível de isolamento PL-2.99 de Adya.
• O Repeatable Read do MySQL também permite G-single (read skew).
• O Repeatable Read do MySQL permite o fenômeno P4 (lost update).
• O Repeatable Read do MySQL apresenta erros de consistência interna.
• O Repeatable Read do MySQL viola Monotonic Atomic View.

GN⁺ Opinião

• O fato de o nível de isolamento Repeatable Read do MySQL se comportar de forma diferente do que está especificado no padrão é uma informação importante para desenvolvedores e administradores de banco de dados. Isso significa que ele pode não atender às expectativas de consistência e isolamento dos dados.
• Os resultados dos testes fornecem informações essenciais para entender os níveis de isolamento de sistemas de banco de dados e escolher mecanismos de isolamento adequados.
• Essas descobertas oferecem insights sobre como os padrões relacionados aos níveis de isolamento de bancos de dados podem diferir das implementações reais. Isso ajuda a compreender a complexidade da tecnologia de bancos de dados e as diferenças sutis entre níveis de isolamento.

[GN⁺]

Comentários no Hacker News

• Há muito tempo venho argumentando que "repeatable read" é uma má ideia. Mesmo que a implementação seja perfeita e funcione corretamente no banco de dados, é difícil de entender ao lidar com consultas complexas.

  • Acho que dois níveis de isolamento fazem sentido:
    • read committed
    • serializable
  • A configuração serializable não traz surpresas. No caminho do read committed, fica claro que, se você quiser uma visão consistente dos dados, precisa bloquear as linhas antes de começar a lê-las.
  • read committed é muito semelhante a código multithread comum e gerenciamento de memória, então a maioria dos engenheiros consegue entendê-lo intuitivamente.
  • serializable é tão rigoroso que é difícil cometer erros inesperados.
  • O nível intermediário é uma terra de ninguém, e qualquer coisa menos consistente que Read Committed deixa de ser realmente um banco de dados.

• Está planejada uma apresentação na FOSSDEM-2024: "Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study".

  • Estudo comparativo entre Oracle, MySQL, SQL Server, PostgreSQL e YugabyteDB.

• Estou avaliando o texto sobre AWS RDS, mas fico curioso se há foco em AWS Aurora (MySQL). A AWS constrói plataformas de banco de dados que fingem ser MySQL ou PostgreSQL. Seria interessante ver se o Aurora MySQL tem as mesmas "funcionalidades" que o RDS ou o MariaDB.

• Acho que este é um excelente exemplo de "sistemas que realmente funcionam" construídos sobre uma base que mostra muitos artefatos de consistência.

• É um pouco preocupante que a replicação do RDS pare de funcionar em 5 minutos e não haja alerta de falha nas verificações de integridade.

• Fico curioso sobre como append (a) é mapeado para operações SQL reais em uma determinada tabela, e se um campo TEXT está sendo usado como lista.

  • Houve um problema no modo repeatable read do MySQL em que um único SELECT escolhia uma única linha e retornava um resultado impossível. Por exemplo, em SELECT min(value), max(value) FROM table WHERE id = 1;, quando o id era a chave primária, já aconteceu de obter valores diferentes para min e max.

• Seria útil comparar não apenas com as definições teóricas dos modos de isolamento, mas também com outros bancos de dados relacionais populares, como PostgreSQL, MS SQL e Oracle. É algo que os desenvolvedores precisam ter em mente quando buscam compatibilidade.

• Parece que SELECT ... FOR UPDATE é a resposta para todos esses problemas; se você bloquear as linhas que vai atualizar, tudo funciona como anunciado.

• Eu ia tentar trabalhar um pouco hoje, mas sou grato porque o 'call me maybe' do aphyr e o jepsen.io estão entre os melhores conteúdos que já li na internet.

• Fico curioso sobre quanto da análise do MySQL também se aplica ao MariaDB, que usa o InnoDB como mecanismo de armazenamento padrão.