Atualizações do mecanismo de banco de dados do Aurora MySQL: 2017-08-07 (versão 1.14) (obsoleta) - Amazon Aurora

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: 2017-08-07 (versão 1.14) (obsoleta)

Versão: 1.14

O Aurora MySQL 1.14 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 MySQL 1.14. O Aurora MySQL 1.14 também é uma atualização obrigatória para clusters de banco de dados existentes do Aurora MySQL. Enviaremos um anúncio separado com a linha do tempo para reprovar versões anteriores do Aurora MySQL.

Com a versão 1.14 do Aurora MySQL, 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 a versão 1.13, o recurso de patches com tempo de inatividade zero do Aurora poderá permitir conexões cliente à instância primária do Aurora para manter a 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.

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.

Melhorias

  • Corrigiu um erro "record not found" incorreto quando um registro foi encontrado no índice secundário, mas não no índice primário.

  • Corrigiu um problema de estabilidade que pode ocorrer por causa de uma declaração defensiva (adicionada no 1.12) que estava muito forte quando um indivíduo escreve algo abrangendo mais de 32 páginas. Essa situação pode ocorrer, por exemplo, com valores BLOB grandes.

  • Corrigiu um problema de estabilidade por causa de inconsistências entre os caches do espaço de tabela e do dicionário.

  • Corrigiu um problema no qual uma réplica do Aurora se tornará sem resposta depois que exceder o número máximo de tentativas de conexão com a instância primária. Uma réplica do Aurora será reiniciada se o período de inatividade for além do período de pulsação usado para verificação de integridade pela instância primária.

  • Corrigiu um livelock que pode ocorrer sob simultaneidade muito alta quando uma conexão tenta adquirir um Meta Data Lock (MDL – Bloqueio de metadado) exclusivo enquanto emite um comando, como ALTER TABLE.

  • Corrigiu um problema de estabilidade em uma réplica de leitura do Aurora diante da leitura lógica/paralela à frente.

  • Melhorou LOAD FROM S3 de duas maneiras:

    1. Processamento melhor de erros de tempo limite do Amazon S3 usando a nova tentativa do SDK, além da nova tentativa existente.

    2. Otimização de performance durante o carregamento de arquivos muito grandes ou muitos arquivos armazenando em cache e reutilizando o estado do cliente.

  • Corrigiu os seguintes problemas de estabilidade com DDL rápido para operações ALTER TABLE:

    1. Quando a instrução ALTER TABLE tem vários comandos ADD COLUMN e os nomes de coluna não estão em ordem crescente.

    2. Quando a string de nome da coluna a ser atualizada e a string de nome correspondente, buscadas na tabela do sistema interno, difere por um caractere de encerramento nulo (/0).

    3. Em determinadas operações de divisão da árvore B.

    4. Quando a tabela tem uma chave principal de comportamento variável.

  • Corrigiu um problema de estabilidade com réplicas do Aurora quando demora muito para criar o cache de índice Full Text Search (FTS – Pesquisa de texto completa) consistente com essa instância primária. Isso poderá acontecer se uma parte grande das entradas de índice FTS recém-criadas na instância primária ainda não tiver sido enviada para disco.

  • Corrigiu um problema de estabilidade que pode acontecer durante a criação do índice.

  • Nova infraestrutura que acompanha o consumo de memória por conexão e a telemetria associada que serão usados na compilação de estratégias de saída OOM.

  • Corrigiu um problema em que ANALYZE TABLE estava permitido incorretamente em réplicas do Aurora. Isso já foi bloqueado.

  • Corrigiu um problema de estabilidade causado por um deadlock raro por causa de uma condição de corrida entre a leitura lógica e a limpeza.

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

  • Uma pesquisa de texto completo combinada com tabelas derivadas (subconsultas na cláusula FROM) causou uma saída do servidor. Agora, se uma operação de texto completa depender de uma tabela derivada, o servidor produzirá um erro indicando que uma pesquisa de texto completa não pode ser realizada em uma tabela materializada. (Bug nº 68751, Bug nº 16539903)