Atualizações do mecanismo de banco de dados do Aurora MySQL de 2021-05-25 (versão 2.10.0) (obsoleta) - Amazon Aurora
MelhoriasIntegração de correções de bug da edição MySQL communityComparação com o Aurora MySQL versão 1Compatibilidade com o MySQL 5.7

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Atualizações do mecanismo de banco de dados do Aurora MySQL de 2021-05-25 (versão 2.10.0) (obsoleta)

Versão: 2.10.0

O Aurora MySQL 2.10.0 está disponível para o público. As versões do Aurora MySQL 2.x são compatíveis com as versões do MySQL 5.7, e as versões do Aurora MySQL 1.x são compatíveis com o MySQL 5.6.

As versões atualmente compatíveis do Aurora MySQL são 1.19.5, 1.19.6, 1.22.*, 1.23.*, 2.04.*, 2.07.*, 2.08.*, 2.09.*, 2.10.*, 3.01.* e 3.02.*.

Você pode atualizar um cluster de banco de dados existente do Aurora MySQL 2.* para o Aurora MySQL 2.10.0. Para clusters que executam o Aurora MySQL versão 1, você pode atualizar um cluster existente do Aurora MySQL 1.23 ou superior diretamente para 2.10.0. Também é possível restaurar um snapshot de qualquer versão atualmente compatível do Aurora MySQL para o Aurora MySQL 2.10.0.

Se você tiver alguma dúvida ou preocupação, o AWS Support está disponível nos fóruns da comunidade e por meio do AWS Support. Para obter mais informações, consulte Manutenção de um cluster de banco de dados do Amazon Aurora no Guia do usuário do Amazon Aurora.

nota

Para obter informações sobre como atualizar seu cluster de banco de dados do Aurora MySQL, consulte Atualizando a versão secundária ou o nível de patch de um cluster de banco de dados de Aurora MySQL no Guia do usuário do Amazon Aurora.

Melhorias

Correção de problemas de segurança e CVEs listados abaixo:

Correções e outras melhorias para ajustar o tratamento em um ambiente gerenciado. Correções adicionais do CVE abaixo:

Novos recursos:

  • A classe de instância db.t3.large agora é compatível com o Aurora MySQL.

  • Replicação de log binário:

    • Introduzido o cache de E/S de binlog para melhorar a performance do binlog, reduzindo a contenção entre processos do gravador e processos de despejo. Para obter mais informações, consulte Otimização da replicação de log binário no Guia do usuário do Amazon Aurora.

    • No Aurora MySQL versão 2.08, introduzimos melhorias no processamento de log binários (binlog) para reduzir o tempo de recuperação de falhas e a latência de tempo de confirmação quando transações muito grandes estão envolvidas. Agora, essas melhorias são compatíveis com clusters que têm o GTID ativado.

  • Maior disponibilidade da instância do leitor:

    • Anteriormente, quando uma instância do gravador era reiniciada, todas as instâncias do leitor em um cluster do Aurora MySQL também eram reiniciadas. Com o lançamento de hoje, as instâncias de leitor na região continuam a atender solicitações de leitura durante a reinicialização da instância de gravador, melhorando a disponibilidade de leitura no cluster. Para obter mais informações, consulte Rebooting an Aurora MySQL cluster (version 2.10 and higher) no Guia do usuário do Amazon Aurora.

      Importante

      Depois de atualizar para o Aurora MySQL 2.10, a reinicialização da instância de gravador não executará uma reinicialização de todo o cluster. Se você quiser reinicializar todo o cluster, agora você reinicializa todas as instâncias do leitor no cluster depois de reinicializar a instância de gravador.

  • Melhorada a performance das leituras de página de leitura antecipada solicitadas pela técnica lógica de leitura antecipada (LRA) . Isso foi feito agrupando as várias leituras de página em lotes em uma única solicitação enviada ao armazenamento do Aurora. Como resultado, as consultas que usam a otimização LRA são executadas até três vezes mais rápido.

  • Reinicializações e aplicação de patches com zero tempo de inatividade:

Melhorias de disponibilidade:

  • Melhorias para uma inicialização mais rápida quando o banco de dados tem um grande número de índices temporários e tabelas criados durante uma atividade DDL interrompida anteriormente.

  • Correção de vários problemas relacionados a reinicializações repetidas durante a recuperação após falha de operações de DDL interrompidas, como DROP TRIGGER, ALTER TABLE e, especificamente, ALTER TABLE, que modifica o tipo de particionamento ou o número de partições em uma tabela.

  • Corrigido um problema que poderia causar a reinicialização do servidor durante o processamento de log do Database Activity Streams (DAS).

  • Corrigido um problema ao imprimir uma mensagem de erro durante o processamento de uma consulta ALTER em tabelas do sistema.

Melhorias gerais:

  • Corrigido um problema em que o cache de consultas poderia retornar resultados obsoletos em uma instância de leitor.

  • Corrigido um problema em que algumas métricas de confirmação do Aurora não estavam sendo atualizadas quando a variável do sistema innodb_flush_log_at_trx_commit estava definida como 0 ou 2.

  • Corrigido um problema em que um resultado de consulta armazenado no cache de consulta não era atualizado por transações com várias instruções.

  • Corrigido um problema que poderia fazer com que o carimbo de data/hora da última modificação dos arquivos de log binário não fosse atualizado corretamente. Isso podia levar à limpeza prematura os arquivos de log binários, antes de atingir o período de retenção configurado pelo cliente.

  • Corrigida a posição e o nome de arquivo do binlog relatados como incorretos do InnoDB após a recuperação de falhas.

  • Correção de um problema que poderia fazer com que grandes transações gerassem eventos de logs binários incorretos se o parâmetro binlog_checksum fosse definido como NONE.

  • Correção de um problema que fazia com que uma réplica de log binário parasse com um erro, se a transação replicada contivesse uma instrução DDL e um grande número de alterações de linha.

  • Corrigido um problema que levava a uma reinicialização em uma instância de leitor ao descartar uma tabela.

  • Corrigido um problema que fazia com que os conectores de código aberto falhassem ao tentar consumir um arquivo de binlog com uma grande transação.

  • Corrigido um problema que poderia levar a resultados de consulta incorretos na coluna de geometria grande depois de criar um índice espacial na tabela com os grandes valores de geometria.

  • O banco de dados agora recria o tablespace temporário durante a reinicialização, o que permite que o espaço de armazenamento associado seja liberado e recuperado.

  • Correção de um problema que impedia que as tabelas performance_schema fossem truncadas em instâncias de leitor do Aurora.

  • Corrigido um problema que fazia com que uma réplica de log binário parasse com um erro HA_ERR_KEY_NOT_FOUND.

  • Corrigido um problema que fazia com que o banco de dados fosse reiniciado ao executar a instrução FLUSH TABLES WITH READ LOCK.

  • Corrigido um problema que impedia o uso de funções de bloqueio no nível do usuário em instâncias de leitor do Aurora.

Integração de correções de bug da edição MySQL community

  • As transações intercaladas poderiam, por vezes, impedir o aplicador de réplica quando o nível de isolamento da transação foi definido como LEITURA REPETIDA. (Erro nº 25040331)

  • Quando um procedimento armazenado continha uma instrução referente a uma visão que, por sua vez, se referia a outra visão, não era possível invocar o procedimento com sucesso mais de uma vez. (Erro n.º 87858, erro n.º 26864199)

  • Para consultas com muitas condições OR, o otimizador agora é mais eficiente em memória e menos provável exceder o limite de memória imposto pela variável de sistema range_optimizer_max_mem_size. Além disso, o valor padrão dessa variável foi aumentado de 1.536.000 para 8.388.608. (Erro n.º 79450, erro n.º 22283790)

  • Replicação: na função next_event(), que é chamada por um processo SQL de uma réplica para ler o próximo evento do log de retransmissão, o processo SQL não liberava o relaylog.log_lock adquirido quando ocorria um erro (por exemplo, devido a um log de retransmissão fechado), fazendo com que todos os outros processos ficassem esperando para adquirir um bloqueio no log de retransmissão para continuar. Com essa correção, o bloqueio é liberado antes que o processo SQL deixe a função sob a situação. (Bug nº 21697821)

  • Corrigindo uma corrupção de memória em ALTER TABLE com coluna virtual. (Erro n.º 24961167, erro n.º 24960450)

  • Replicação: réplicas de vários processos não poderiam ser configuradas com pequenos tamanhos de fila usando slave_pending_jobs_size_max se precisassem processar transações maiores que esse tamanho. Qualquer pacote maior que slave_pending_jobs_size_max era rejeitado com o erro ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, mesmo que o pacote fosse menor que o limite definido por slave_max_allowed_packet. Com essa correção, slave_pending_jobs_size_max se torna um limite flexível em vez de um limite rígido. Se o tamanho de um pacote exceder slave_pending_jobs_size_max, mas for menor que slave_max_allowed_packet, a transação será retida até que todos os operadores de réplica tenham filas vazias e, em seguida, é processada. Todas as transações subsequentes são retidas até que a grande transação seja concluída. O tamanho da fila para operadores de réplica pode, portanto, ser limitado e ainda permitir transações maiores ocasionais. (Erro n.º 21280753, erro n.º 77406)

  • Replicação: ao usar uma réplica de vários processos, os erros do aplicador exibiram dados de ID do trabalhador que eram inconsistentes com os dados externalizados nas tabelas de replicação do Performance Schema. (Erro nº 25231367)

  • Replicação: em uma réplica de replicação baseada em GTID executada com -GTID-mode=ON, -log-bin=OFF e usando -, quando um erro que deveria ser ignorado não estava sendo atualizado corretamenteslave-skip-errors, causando perda de sincronia com. Exec_Master_Log_Pos Exec_Master_Log_Pos Read_master_log_pos Se um GTID_NEXT não estava especificado, a réplica nunca atualizaria seu estado GTID ao reverter de uma única transação de instrução. O Exec_Master_Log_Pos não seria atualizado porque, mesmo que a transação tivesse sido concluída, seu estado GTID mostraria o contrário. A correção remove a restrição da atualização do estado GTID quando uma transação é revertida somente se GTID_NEXT estiver especificado. (Erro nº 22268777)

  • Replicação: uma instrução com falha parcial não estava consumindo corretamente um GTID gerado ou especificado automaticamente quando o registro em log binário era desabilitado. A correção garante que um DROP TABLE, DROP USER ou DROP VIEW com falha parcial consuma respectivamente o GTID relevante e o salve em @@GLOBAL.GTID_EXECUTED e na tabela mysql.gtid_executed quando o registro em log binário está desabilitado. (Erro nº 21686749)

  • Replicação: as réplicas que executam o MySQL 5.7 não conseguiam se conectar a uma origem do MySQL 5.5 devido a um erro ao recuperar o server_uuid, que não faz parte do MySQL 5.5.0 Isso foi causado por mudanças no método de recuperação do server_uuid. (Erro nº 22748612)

  • Replicação: o mecanismo de salto de transação GTID que ignora silenciosamente uma transação GTID executada anteriormente não funcionava corretamente para transações XA. (Erro nº 25041920)

  • Declarações “>XA ROLLBACK, que falharam porque foi fornecido o ID incorreto de uma transação, poderiam ser registradas no log binário com o ID correto da transação e, portanto, poderiam ser acionadas por réplicas de replicação. Agora é feita uma verificação da situação de erro antes que o registro em log binário ocorra, e ROLLBACK as instruções XA com falha não são registradas em log. (Erro nº 26618925)

  • Replicação: Se uma réplica foi configurada usando uma instrução CHANGE MASTER TO que não especificou o nome do arquivo de log de origem e a posição do log de origem, desligue antes da emissão de START SLAVE e reinicie com a opção - relay-log-recovery set, a replicação não foi iniciada. Isso aconteceu porque o processo do receptor não havia sido iniciado antes da tentativa de recuperação do log de retransmissão, portanto, nenhum evento de rotação de log estava disponível no log de retransmissão para fornecer o nome de arquivo e a posição do log de origem. Nessa situação, a réplica agora ignora a recuperação do log de retransmissão e registra um aviso. Em seguida, prossegue para iniciar a replicação. (Erro n.º 28996606, erro n.º 93397)

  • Replicação: na replicação baseada em linha, uma mensagem que exibia incorretamente comprimentos de campo era retornada ao replicar de uma tabela com uma coluna utf8mb3 para uma tabela da mesma definição em que a coluna foi definida com um conjunto de caracteres utf8mb4. (Erro n.º 25135304, erro n.º 83918)

  • Replicação: quando uma instrução RESET SLAVE era emitida em uma réplica de replicação com GTIDs em uso, os arquivos de log de retransmissão existentes eram removidos, mas o novo arquivo de log de retransmissão de substituição era gerado antes que o conjunto de GTIDs recebidos para o canal fosse limpo. Portanto, o antigo conjunto GTID era gravado no novo arquivo de log de retransmissão como o evento PREVIOUS_GTIDS, causando um erro fatal na replicação informando que a réplica tinha mais GTIDs do que a origem, mesmo que o conjunto gtid_executed definido para ambos os servidores estivesse vazio. Agora, quando RESET SLAVE é emitido, o conjunto de GTIDs recebidos é apagado antes que o novo arquivo de log de retransmissão seja gerado, para que essa situação não ocorra. (Erro nº 27411175)

  • Replicação: com GTIDs em uso para replicação, transações incluindo instruções que causaram um erro de análise (ER_PARSE_ERROR) não puderam ser ignoradas manualmente pelo método recomendado de injetar uma transação vazia ou de substituição com o mesmo GTID. Essa ação deve resultar na réplica que identifica o GTID como já usado e, portanto, ignorando a transação indesejada que compartilhou seu GTID. No entanto, no caso de um erro de análise, como a instrução era analisada antes que o GTID fosse verificado para ver se ele precisava ser ignorado, o processo do aplicador de replicação parava devido ao erro de análise, mesmo que a intenção fosse ignorar a transação de qualquer maneira. Com essa correção, o processo do aplicador de replicação agora ignora erros de análise se a transação em questão precisar ser ignorada porque o GTID já foi usado. Observe que essa alteração de comportamento não se aplica no caso de workloads que consistem em saída de log binário produzida por mysqlbinlog. Nessa situação, haveria o risco de que uma transação com um erro de análise que viesse imediatamente após uma transação ignorada também fosse ignorada silenciosamente, quando deveria gerar um erro. (Erro nº 27638268)

  • Replicação: habilite o processo SQL para que o GTID ignore uma transação parcial. (Erro nº 25800025)

  • Replicação: quando um parâmetro de tempo limite negativo ou fracionário era fornecido a WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(), o servidor se comportava de maneiras inesperadas. Com esta correção:

    • Um valor de tempo limite fracionário é lido como está, sem arredondamento.

    • Um valor de tempo limite negativo é rejeitado com um erro se o servidor estiver em um modo SQL estrito. Se o servidor não estiver em um modo SQL estrito, o valor fará com que a função retorne NULL imediatamente sem qualquer espera e, em seguida, emita um aviso. (Erro n.º 24976304, erro n.º 83537)

  • Replicação: se a função WAIT_FOR_EXECUTED_GTID_SET() fosse usada com um valor de tempo limite incluindo uma parte fracionada (por exemplo, 1,5), um erro na lógica de transmissão significava que o tempo limite foi arredondado para o segundo inteiro mais próximo e para zero para valores menores que 1 segundo (por exemplo, 0,1). Agora a lógica de transmissão foi corrigida para que o valor do tempo limite seja aplicado conforme especificado originalmente, sem arredondamento. Agradecemos a Dirkjan Bussink pela contribuição. (Erro n.º 29324564, erro n.º 94247)

  • Com os GTIDs ativados, o XA COMMIT em uma transação XA desconectada dentro de uma transação de várias instruções gerava uma afirmação. (Erro nº 22173903)

  • Replicação: uma afirmação era gerada em compilações de depuração se uma instrução XA ROLLBACK fosse emitida para um identificador de transação desconhecido quando o valor de gtid_next tivesse sido definido manualmente. Agora, o servidor não tenta atualizar o estado de GTID se uma instrução XA ROLLBACK falhar com um erro. (Erro n.º 27928837, erro n.º 90640)

  • Corrigido o problema de ordem de classificação incorreta quando várias funções CASE são usadas na cláusula ORDER BY (Erro nº 22810883).

  • Algumas consultas que usavam ordenação podiam acessar uma coluna não inicializada durante a otimização e causar a saída do servidor. (Bug nº 27389294)

Comparação com o Aurora MySQL versão 1

Os seguintes recursos do Amazon Aurora MySQL são compatíveis no Aurora MySQL versão 1 (compatível com o MySQL 5.6), mas não são compatíveis atualmente no Aurora MySQL versão 2 (compatível com o MySQL 5.7).

Compatibilidade com o MySQL 5.7

Esta versão do Aurora MySQL é compatível com o MySQL 5.7 e inclui recursos como suporte a JSON, índices espaciais e colunas geradas. O Aurora MySQL usa uma implementação nativa de indexação espacial com curvas de ordem z para oferecer performance de gravação 20 vezes melhor e performance de leitura 10 vezes melhor do que os conjuntos de dados espaciais do MySQL 5.7.

Atualmente, essa versão do Aurora MySQL não oferece suporte aos seguintes recursos do MySQL 5.7:

  • Plugin de replicação de grupo

  • Maior tamanho de página

  • Carregamento de grupo de buffers InnoDB na inicialização

  • Plugin de analisador de texto completo do InnoDB

  • Replicação em várias origens

  • Redimensionamento online do grupo de buffers

  • Plugin de validação de senha

  • Plugins de regravação de consulta

  • Filtragem de replicação

  • A declaração SQL CREATE TABLESPACE