Atualizações do mecanismo de banco de dados do Aurora MySQL de 2017-10-24 (versão 1.15) (obsoleta)

Versão: 1.15

O Aurora MySQL 1.15 está disponível para o público. Todos os novos clusters de banco de dados, inclusive os restaurados de snapshots, serão criados no Aurora 1.15. Você tem a opção, mas não a obrigatoriedade, de atualizar os clusters de banco de dados existentes para o Aurora 1.15. É possível criar novos clusters de banco de dados no Aurora 1.14.1. É possível fazer isso usando a AWS CLI ou a API do Amazon RDS e especificando a versão do mecanismo.

Com a versão 1.15 do Aurora, estamos usando um modelo de aplicação de patch de cluster em que todos os nós em um cluster de bancos de dados Aurora recebem patch ao mesmo tempo. Como as atualizações exigem a reinicialização do banco de dados, você terá de 20 a 30 segundos de tempo de inatividade, após o qual poderá continuar usando seus clusters de banco de dados. Se os clusters de banco de dados estiverem executando o Aurora 1.14 ou o Aurora 1.14.1, o recurso de aplicação de patch com tempo de inatividade zero no Aurora MySQL poderá permitir conexões de clientes à instância principal do Aurora MySQL para persistir na atualização, dependendo da workload.

Em caso de dúvidas ou preocupações, 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.

Aplicação de patches com tempo de inatividade zero

O recurso de aplicação de patches com tempo de inatividade zero (ZDP) tenta, com o melhor esforço, preservar as conexões do cliente por meio de um patch de mecanismo. Para obter mais informações sobre ZDP, consulte Como usar os patches com tempo de inatividade zero no Guia do usuário do Amazon Aurora.

Novos recursos

• Asynchronous Key Prefetch: o Asynchronous Key Prefetch (AKP – Pré-busca de chave assíncrona) é um recurso destinado a melhorar a performance de junções de índice não armazenadas em cache pré-buscando chaves na memória quando necessário. O caso de uso principal segmentado por AKP é uma junção de índice entre uma tabela externa pequena e interna grande, em que o índice é altamente seletivo na tabela maior. Além disso, quando a interface Multi-Range Read (MRR – Leitura de vários intervalos) estiver habilitada, o AKP será aproveitado para uma pesquisa de índice de secundária para primária. Instâncias menores que tenham restrições de memória podem, em alguns casos, ser capazes de utilizar o AKP, dada a cardinalidade da chave certa. Para obter mais informações, consulte Otimizar consultas de junção indexadas do Aurora MySQL com pré-busca de chave assíncrona no Guia do usuário do Amazon Aurora.

• Fast DDL – estendemos o recurso que foi lançado no Aurora 1.13 para operações que incluem valores padrão. Com essa extensão, o DDL rápido se aplica a operações que adicionam uma coluna anulável ao final de uma tabela, com ou sem valores padrão. O recurso permanece em modo de laboratório do Aurora. Para obter mais informações, consulte Alterar tabelas no Amazon Aurora usando a DDL rápida no Guia do usuário do Amazon Aurora.

Melhorias

• Corrigiu um erro de cálculo durante a otimização de consultas espaciais WITHIN/CONTAINS que resultaram em um conjunto de resultados vazio.

• Corrigiu o comando SHOW VARIABLE para mostrar o valor de parâmetro innodb_buffer_pool_size atualizado sempre que é alterado no parameter group.

• A maior estabilidade da instância primária durante a inserção em lote em uma tabela alterada usando o DDL rápido quando a indexação de hash adaptável está desabilitada e o registro a ser inserido é o primeiro de uma página.

• Maior estabilidade do Aurora quando o usuário tenta definir o valor do parâmetro do cluster de banco de dados server_audit_events como default.

• Corrigido um problema no qual uma alteração feita no conjunto de caracteres do banco de dados de uma instrução ALTER TABLE executada na instância primária do Aurora não replicada nas réplicas do Aurora até serem reiniciadas.

• Maior estabilidade corrigindo uma condição de corrida na instância principal que o permitiu registrar uma réplica do Aurora, mesmo que a instância primária tenha fechado o próprio volume.

• Aprimoramento da performance da instância primária durante a criação do índice em uma tabela grande alterando o protocolo de bloqueio para habilitar instruções DML durante a criação do índice.

• Corrigiu a inconsistência de metadados de InnoDB durante a consulta ALTER TABLE RENAME que aumentou a estabilidade. Exemplo: quando colunas da tabela t1(c1, c2) são renomeadas de maneira cíclica t1(c2, c3) dentro da mesma instrução ALTER.

• Maior estabilidade de réplicas do Aurora para o cenário em que uma réplica do Aurora não tem workload ativa e a instância primária não responde.

• Maior disponibilidade de réplicas do Aurora para um cenário no qual a réplica do Aurora mantém um bloqueio explícito em uma tabela e impede o thread de replicação de aplicar qualquer alteração feita no DDL recebida da instância primária.

• Maior estabilidade da instância primária quando uma chave externa e uma coluna são adicionadas a uma tabela de duas sessões separadas ao mesmo tempo e o DDL rápido foi habilitado.

• Maior estabilidade do thread de purga na instância principal durante uma workload de gravação pesada bloqueando o truncamento de registros para desfazer até serem purgados.

• Maior estabilidade corrigindo a ordem de versão do bloqueio durante o processo de confirmação de transações que descartam tabelas.

• Corrigiu um defeito em réplicas do Aurora em que a instância de banco de dados não pode ser inicializada e reclamou que a porta 3306 já estava em uso.

• Corrigiu uma condição de corrida em que uma execução de consulta SELECT em determinadas tabelas information_schema (innodb_trx, innodb_lock, innodb_lock_waits) aumentou a instabilidade do cluster.

Integração de correções de bugs do MySQL

• CREATE USER aceita plugin e hash de senha, mas ignora o hash de senha (erro #78033)

• O mecanismo de particionamento adiciona campos ao conjunto de bits de leitura capazes de retornar entradas classificadas de um índice particionado. Isso leva o buffer de junção a tentar ler campos desnecessários. Corrigido não adicionando todos os campos de particionamento ao read_set, mas em vez de somente classificar nos campos de prefixo definidos no read_set. Adicionado um DBUG_ASSERT que, se key_cmp, pelo menos o primeiro campo deverá ser lido (Bug 16367691).

• Instância do MySQL paralisada ao "fazer um índice SYNC" (Bug nº 73816)

• Declaração RBT_EMPTY(INDEX_CACHE->WORDS) na COLUNA DE ALTERAÇÃO DE ALTER TABLE (Bug 17536995)

• Pesquisa de texto completo de InnoDB não encontra registros quando pontos de salvamento estão envolvidos (erro #70333)