Atualizações do mecanismo de banco de dados do Aurora MySQL de 2019-11-25 (versão 1.22.0) (obsoleta)

Os clusters do Aurora MySQL já oferecem suporte para os tipos de instância r5.8xlarge, r5.16xlarge e r5.24xlarge.

O log binário tem novas melhorias para atenuar a latência do tempo de confirmação quando há transações muito grandes envolvidas.

O Aurora MySQL agora tem um mecanismo para reduzir a janela de tempo durante a qual os eventos de uma transação grande são gravados no log binário na confirmação. Ele impede com eficácia a recuperação offline demorada que ocorre quando o banco de dados trava durante essa janela de tempo. Esse recurso também corrige o problema que ocorre quando uma transação grande bloqueia transações pequenas na confirmação do log binário. Esse recurso é desativado por padrão e poderá ser habilitado pela equipe de manutenção se for necessário para sua workload. Quando habilitado, ele será acionado quando o tamanho de uma transação for > 500 MB.

Adicionamos suporte para o nível de isolamento READ COMMITTED ANSI nas réplicas de leitura. Esse nível de isolamento permite que as consultas de longa execução na réplica de leitura sejam executadas sem afetar a alta taxa de transferência das gravações no nó do gravador. Para obter mais informações, consulte Níveis de isolamento do Aurora MySQL.

Os bancos de dados globais agora permitem adicionar regiões secundárias de réplica somente para leitura para clusters de banco de dados implantados nessas AWS regiões: regiões: Leste dos EUA (Norte da Virgínia) [us-east-1], Leste dos EUA (Ohio) [us-east-2], Oeste dos EUA (Norte da Califórnia) [us-west-1], Oeste dos EUA (Oregon) [us-west-2], Europa (Irlanda) [eu-west-1]], Europa (Londres) [eu-west-2], Europa (Paris) [eu-west-3], Ásia-Pacífico (Tóquio) [ap-northeast-1], Ásia-Pacífico (Seul) [ap-northeast-2], Ásia-Pacífico (Cingapura) [ap-southeast-1], Ásia-Pacífico (Sydney) [ap-southeast-2], Canadá (Central) [ca-central-1], Europa (Frankfurt) [ eu-central-1] e Ásia-Pacífico (Mumbai) [ap-south-1].

O recurso disputa de linhas dinâmica já está disponível para o público e não exige o modo de laboratório do Aurora definido como ativado. Esse recurso melhora substancialmente as taxas de transferência para workloads com muitas transações disputando linhas na mesma página.

Esta versão tem arquivos de fuso horário atualizados para oferecer suporte à atualização de fuso horário do Brasil mais recente para novos clusters.

CVE-2019-2922

CVE-2019-2923

CVE-2019-2924

CVE-2019-2910

CVE-2019-2805

CVE-2019-2730

CVE-2019-2740

CVE-2018-3064

CVE-2018-3058

CVE-2017-3653

CVE-2017-3464

CVE-2017-3244

CVE-2016-5612

CVE-2016-5439

CVE-2016-0606

CVE-2015-4904

CVE-2015-4879

CVE-2015-4864

CVE-2015-4830

CVE-2015-4826

CVE-2015-2620

CVE-2015-0382

CVE-2015-0381

CVE-2014-6555

CVE-2014-4258

CVE-2014-4260

CVE-2014-2444

CVE-2014-2436

CVE-2013-5881

CVE-2014-0393

CVE-2013-5908

CVE-2013-5807

CVE-2013-3806

CVE-2013-3811

CVE-2013-3804

CVE-2013-3807

CVE-2013-2378

CVE-2013-2375

CVE-2013-1523

CVE-2013-2381

CVE-2012-5615

CVE-2014-6489

Corrigimos um problema no componente de recuperação DDL que resultava em um tempo de inatividade prolongado do banco de dados. Os clusters que se tornarem indisponíveis após a execução da consulta TRUNCATE TABLE em uma tabela com a coluna AUTO_INCREMENT deverão ser atualizados.

Corrigimos um problema no componente de recuperação DDL que resultava em um tempo de inatividade prolongado do banco de dados. Os clusters que se tornarem indisponíveis após a execução da consulta DROP TABLE em várias tabelas em paralelo deverão ser atualizados.

Corrigimos um problema que fazia com que as réplicas de leitura fossem inicializadas durante uma transação de execução longa. Os clientes que observarem a reinicialização de réplicas com uma queda acelerada na memória disponível deverão considerar a atualização para esta versão.

Corrigimos um problema que relatava incorretamente ERROR 1836 quando uma consulta aninhada era executada em uma tabela temporária na réplica de leitura.

Corrigimos um erro de anulação de consulta paralela em uma instância de leitor do Aurora enquanto uma workload de gravação intensa estava em execução na instância de gravador do Aurora.

Corrigimos um problema que faz com que um banco de dados configurado como mestre do log binário seja reiniciado durante a execução de uma workload de gravação intensa.

Corrigimos um problema de indisponibilidade prolongada na reinicialização do mecanismo. Isso resolve o problema na inicialização do grupo de buffers. Esse problema ocorre raramente, mas pode afetar qualquer versão compatível.

Corrigimos um problema que gerava dados inconsistentes na tabela information_schema.replica_host_status.

Corrigimos um comportamento de disputa entre a consulta paralela e os caminhos de execução padrão que fazia com que os nós do leitor fossem reiniciados de forma intermitente.

Melhoramos a estabilidade do banco de dados quando o número de conexões do cliente excede o valor do parâmetro max_connections.

Melhoramos a estabilidade das instâncias de leitor bloqueando o DDL incompatível e as consultas LOAD FROM S3.

Bug nº 16346241 - SERVER CRASH IN ITEM_PARAM::QUERY_VAL_STR

Bug nº 17733850 - NAME_CONST() CRASH IN ITEM_NAME_CONST::ITEM_NAME_CONST()

Bug nº 20989615 - INNODB AUTO_INCREMENT PRODUCES SAME VALUE TWICE

Erro nº 20181776 – O CONTROLE DE ACESSO NÃO CORRESPONDE AO HOST MAIS ESPECÍFICO QUANDO CONTÉM CARACTERES CURINGA

Bug nº 27326796 - MYSQL CRASH WITH INNODB ASSERTION FAILURE IN FILE PARS0PARS.CC

Bug nº 20590013 - IF YOU HAVE A FULLTEXT INDEX AND DROP IT YOU CAN NO LONGER PERFORM ONLINE DDL