Níveis de isolamento do Aurora MySQL

Descubra como as instâncias de banco de dados de um cluster do Aurora MySQL implementam a propriedade de isolamento do banco de dados. Este tópico explica como o comportamento padrão do Aurora MySQL se equilibra entre consistência rigorosa e alta performance. Você pode usar essas informações para decidir quando alterar as configurações padrão com base nas características da sua workload.

Níveis de isolamento disponíveis para instâncias do gravador

Você pode usar os níveis de isolamento REPEATABLE READ, READ COMMITTED, READ UNCOMMITTED e SERIALIZABLE na instância primária de um cluster de banco de dados do Aurora MySQL. Esses níveis de isolamento funcionam no Aurora MySQL da mesma maneira que no RDS para MySQL.

Nível de isolamento REPEATABLE READ (leitura repetível) para instâncias leitoras

Por padrão, as instâncias de banco de dados do Aurora MySQL configuradas como réplicas somente leitura do Aurora sempre usam o nível de isolamento REPEATABLE READ. Essas instâncias de banco de dados ignoram quaisquer instruções SET TRANSACTION ISOLATION LEVEL e continuam usando o nível de isolamento REPEATABLE READ.

Você não pode definir o nível de isolamento para instâncias de banco de dados de leitor usando parâmetros de banco de dados ou parâmetros de cluster de banco de dados.

Nível de isolamento READ COMMITTED (leitura confirmada) para instâncias leitoras

Se sua aplicação incluir uma workload com alta demanda de gravação na instância primária e consultas demoradas nas réplicas do Aurora, você poderá enfrentar um atraso significativo na limpeza. Atraso na limpeza acontece quando a coleta de lixo interna é bloqueada por consultas demoradas. O sintoma visto é um valor alto para history list length na saída do comando SHOW ENGINE INNODB STATUS. Você pode monitorar esse valor usando a métrica RollbackSegmentHistoryListLength no CloudWatch. O atraso substancial na limpeza pode reduzir a eficácia dos índices secundários, reduzir a performance geral da consulta e gerar desperdício de espaço de armazenamento.

Se enfrentar esses problemas, você poderá definir uma configuração no nível da sessão do Aurora MySQL, aurora_read_replica_read_committed, para usar o nível de isolamento READ COMMITTED nas réplicas do Aurora. Ao aplicar essa configuração, você pode ajudar a reduzir a desaceleração e o desperdício de espaço resultantes da execução de consultas demoradas ao mesmo tempo em que as transações que modificam suas tabelas.

Recomendamos que você entenda o comportamento específico do Aurora MySQL de isolamento de READ COMMITTED antes de usar essa configuração. O comportamento de READ COMMITTED da réplica do Aurora está em conformidade com o padrão ANSI SQL. No entanto, o isolamento é menos rigoroso do que o comportamento típico de READ COMMITTED do MySQL com o qual você pode estar familiarizado. Portanto, os resultados da consulta com READ COMMITTED em uma réplica de leitura do Aurora MySQL poderão ser diferentes dos resultados da mesma consulta com READ COMMITTED na instância primária do Aurora MySQL ou no RDS para MySQL. Você pode usar a configuração aurora_read_replica_read_committed para esses casos como um relatório abrangente que verifica um banco de dados muito grande. Por outro lado, você pode evitá-la para consultas breves com pequenos conjuntos de resultados, em que a precisão e a repetibilidade são importantes.

O nível de isolamento READ COMMITTED não está disponível para sessões em um cluster secundário em um banco de dados global Aurora que usam o recurso de encaminhamento de gravação. Para obter informações sobre o encaminhamento de gravação, consulte Como usar o encaminhamento de gravação em um banco de dados global Amazon Aurora.

Usar READ COMMITTED para leitores

Para usar o nível de isolamento READ COMMITTED para réplicas do Aurora, defina a configuração aurora_read_replica_read_committed como ON. Use essa configuração no nível da sessão enquanto estiver conectada a uma réplica específica do Aurora. Para fazer isso, execute os comandos SQL a seguir:

set session aurora_read_replica_read_committed = ON;
set session transaction isolation level read committed;

Você pode usar essa configuração temporariamente para executar consultas únicas interativas. Você também pode executar uma aplicação de relatórios ou análise de dados que se beneficie do nível de isolamento READ COMMITTED, mantendo a configuração padrão inalterada para outras aplicações.

Quando a configuração aurora_read_replica_read_committed estiver ativada, use o comando SET TRANSACTION ISOLATION LEVEL para especificar o nível de isolamento das transações apropriadas.

set transaction isolation level read committed;

Diferenças no comportamento READ COMMITTED (LEITURA CONFIRMADA) das réplicas do Aurora

A configuração aurora_read_replica_read_committed disponibiliza o nível de isolamento READ COMMITTED para uma Réplica do Aurora, com comportamento de consistência otimizado para transações de longa execução. O nível de isolamento READ COMMITTED nas réplicas do Aurora é menos rigoroso do que nas instâncias primárias do Aurora. Por esse motivo, habilite essa configuração apenas nas Réplicas do Aurora, onde você sabe que suas consultas podem aceitar a possibilidade de certos tipos de resultados inconsistentes.

Suas consultas podem enfrentar certos tipos de anomalias de leitura quando a configuração aurora_read_replica_read_committed está habilitada. Dois tipos de anomalias são especialmente importantes para entender e lidar com o código da aplicação. Uma non-repeatable read (leitura não repetível) ocorre quando outra transação é confirmada enquanto sua consulta está em execução. Uma consulta demorada pode ter dados diferentes no início e no final da consulta. Uma phantom read (leitura fantasma) ocorre quando outras transações fazem com que as linhas existentes sejam reorganizadas enquanto a consulta está em execução, e uma ou mais linhas são lidas duas vezes pela consulta.

Suas consultas podem ter contagens de linhas inconsistentes como resultado de leituras fantasmas. Suas consultas também podem retornar resultados incompletos ou inconsistentes devido a leituras não repetíveis. Por exemplo, vamos supor que uma operação de junção se refira a tabelas modificadas simultaneamente por instruções SQL como INSERT ou DELETE. Nesse caso, a consulta de junção poderá ler uma linha de uma tabela, mas não a linha correspondente de outra tabela.

O padrão SQL ANSI permite esses comportamentos para o nível de isolamento READ COMMITTED. No entanto, esses comportamentos são diferentes da implementação típica do MySQL no READ COMMITTED. Portanto, antes de habilitar a configuração aurora_read_replica_read_committed, verifique qualquer código SQL existente para saber se ele opera conforme o esperado no modelo de consistência mais flexível.

A contagem de linhas e outros resultados podem não ser altamente consistentes no nível de isolamento READ COMMITTED enquanto essa configuração estiver habilitada. Dessa forma, geralmente habilita-se a configuração apenas ao executar consultas analíticas que agregam grandes quantidades de dados e não exigem precisão absoluta. Se você não tiver esse tipo de consultas demoradas com uma workload de gravação intensa, provavelmente não precisará da configuração aurora_read_replica_read_committed. Sem a combinação de consultas demoradas e uma workload de gravação intensa, é improvável que você enfrente problemas com o comprimento da lista de histórico.