Atualizações do mecanismo de banco de dados do Aurora MySQL: 2017-02-23 (versão 1.11) (obsoleta)

Versão: 1.11

Aplicaremos patches em todos os clusters de bancos de dados Aurora MySQL com a versão mais recente durante um curto período após o lançamento. Os clusters de banco de dados são corrigidos usando o procedimento legado com um tempo de inatividade de cerca de 5 a 30 segundos.

A aplicação de patches ocorre durante a janela de manutenção do sistema que você especificou para cada uma das suas instâncias de banco de dados. Você pode visualizar ou alterar essa janela usando o AWS Management Console. 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.

Como alternativa, você pode aplicar o patch imediatamente no AWS Management Console escolhendo um cluster de banco de dados, escolhendo Cluster Actions (Ações do cluster) e escolhendo Upgrade Now (Atualizar agora).

Com a versão 1.11 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.

Novos recursos

• Opção MANIFEST para LOAD DATA FROM S3 – LOAD DATA FROM S3 foi lançado na versão 1.8. As opções para esse comando foram expandidas, e agora você pode especificar uma lista de arquivos a serem carregados em um cluster de bancos de dados Aurora do Amazon S3 usando um arquivo manifesto. Isso facilita o carregamento de dados de arquivos específicos em um ou mais locais, ao contrário do carregamento de dados de um único arquivo usando a opção FILE ou do carregamento de dados de vários arquivos que têm a mesma localização e prefixo usando a opção PREFIX. O formato do arquivo manifesto é o mesmo usado pelo Amazon Redshift. Para obter mais informações sobre como usar LOAD DATA FROM S3 com a opção MANIFEST, consulte Usar um manifesto para especificar arquivos de dados para carregamento no Guia do usuário do Amazon Aurora.

• Indexação espacial habilitada por padrão – esse recurso foi lançado no modo de laboratório na versão 1.10 e agora está ativado por padrão. A indexação espacial melhora a performance das consultas em conjuntos de dados grandes para consultas que utilizam dados espaciais. Para obter mais informações sobre o uso da indexação espacial, consulte Amazon Aurora MySQL e dados espaciais no Guia do usuário do Amazon Aurora.

• Alteração no cronograma de auditoria avançada: esse recurso foi lançado na versão 1.10.1 para fornecer uma facilidade de alta performance para a auditoria de atividades do banco de dados. Nessa versão, a precisão dos carimbos de data/hora do log de auditoria foi alterada de um segundo para um microssegundo. Os carimbos de data/hora mais precisos permitem compreender melhor quando um evento de auditoria ocorreu. Para obter mais informações sobre auditoria, consulte Como utilizar a auditoria avançada em um cluster de banco de dados do Amazon Aurora MySQL no Guia do usuário do Amazon Aurora.

Melhorias

• Modificação do parâmetro thread_handling para evitar que você o defina como algo diferente de multiple-connections-per-thread, que é o único modelo com suporte no grupo de threads do Aurora.

• Correção de um problema causado quando você define o parâmetro buffer_pool_size e query_cache_size para ser maior que a memória total do cluster de banco de dados. Nessa circunstância, o Aurora define o parâmetro modificado como o valor padrão e, portanto, o cluster de banco de dados pode ser inicializado e não falhar.

• Correção de um problema no cache de consulta em que uma transação obtém resultados de leitura obsoletos se a tabela é invalidada em outra transação.

• Correção de um problema em que arquivos binlog marcados para exclusão são removidos depois de um pequeno atraso em vez de serem removidos imediatamente.

• Correção de um problema em que um banco de dados criado com o nome tmp é tratado como um banco de dados do sistema armazenado em armazenamento temporário e não persistente no armazenamento distribuído do Aurora.

• Modificação do comportamento de SHOW TABLES para excluir determinadas tabelas internas do sistema. Essa alteração ajuda a evitar um failover desnecessário causado depois que mysqldump bloqueia todos os arquivos listados em SHOW TABLES, o que, por sua vez, evita gravações na tabela interna do sistema, causando o failover.

• Correção de um problema em que uma Réplica do Aurora é reiniciada incorretamente ao criar uma tabela temporária de uma consulta que invoca uma função cujo argumento é uma coluna de uma tabela do InnoDB.

• Correção de um problema relacionado a um conflito de bloqueio de metadados em um nó de Réplica do Aurora que faz com que a Réplica do Aurora fique atrás do cluster de banco de dados principal e acabe sendo reiniciada.

• Correção de uma trava inoperante no pipeline de replicação em nós leitores, o que faz com que uma Réplica do Aurora se atrase e acabe sendo reiniciada.

• Correção de um problema em que uma Réplica do Aurora fica muito atrasada com volumes criptografados maiores que 1 terabyte (TB).

• Melhoria na detecção de travas inoperantes da Réplica do Aurora com o uso de uma melhor maneira de ler o tempo do relógio do sistema.

• Correção de um problema em que uma Réplica do Aurora pode ser reiniciada duas vezes em vez de uma após o cancelamento do registro pelo gravador.

• Correção de um problema de performance de consultas lentas em Réplicas do Aurora que ocorre quando estatísticas transitórias causam discrepância em colunas de índice não exclusivas.

• Correção de um problema em que uma Réplica do Aurora pode falhar quando uma instrução DDL é replicada na Réplica do Aurora ao mesmo tempo que a Réplica do Aurora está processando uma consulta relacionada.

• Alteração nas melhorias do pipeline de replicação que foram introduzidas na versão 1.10 de habilitadas por padrão para desabilitadas por padrão. Essas melhorias foram apresentadas para aplicar atualizações de stream de log ao cache de buffer de uma Réplica do Aurora e, embora esse recurso ajude a melhorar a performance e a estabilidade em Réplicas do Aurora, ele aumenta o atraso dessas réplicas em determinadas workloads.

• Correção de um problema em que a ocorrência simultânea de uma instrução DDL contínua e da Leitura antecipada paralela pendente na mesma tabela causa uma falha de asserção durante a fase de confirmação da transação DDL.

• Melhoria do log geral e do log de consultas lentas para sobreviver ao reinício do cluster de banco de dados.

• Correção de um problema de falta de memória para determinadas consultas de longa execução, reduzindo o consumo de memória no módulo ACL.

• Correção de um problema de reinício que ocorre quando uma tabela possui índices não espaciais, quando existem predicados espaciais na consulta, quando o planejador opta por usar um índice não espacial e quando o planejador envia incorretamente a condição espacial ao índice.

• Correção de um problema no qual o cluster de banco de dados é reiniciado quando há uma exclusão, atualização ou limpeza de objetos geoespaciais muito grandes que estão armazenados externamente (como LOBs).

• Correção de um problema em que a simulação de falhas usando ALTER SYSTEM SIMULATE... FOR INTERVAL não está funcionando corretamente.

• Correção de um problema de estabilidade causado por uma declaração inválida em um invariante incorreto no gerenciador de bloqueios.

• Desabilitação das duas melhorias a seguir para a pesquisa de texto completo do InnoDB que foram introduzidas na versão 1.10, pois introduzem problemas de estabilidade para algumas workloads exigentes:

  • Atualização do cache somente após uma solicitação de leitura para uma Réplica do Aurora a fim de melhorar a velocidade de replicação do cache de índice de pesquisa de texto completo.

  • Descarregando a tarefa de sincronização de cache em um thread separado, assim que o tamanho do cache atingir 10% do tamanho total, para evitar que consultas MySQL fiquem paradas por muito tempo durante a sincronização do cache de FTS com o disco. (Bugs nº 22516559, nº 73816).

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

• A execução da tabela ALTER da chave estrangeira DROP simultaneamente com outra operação DROP faz com que a tabela desapareça. (Bug nº 16095573)

• Algumas consultas INFORMATION_SCHEMA que usaram ORDER BY não usaram uma otimização de classificação de arquivo como fizeram anteriormente. (Bug nº 16423536)

• FOUND_ROWS () retorna a contagem incorreta de linhas em uma tabela. (Bug nº 68458)

• O servidor falha em vez de indicar um erro quando muitas tabelas temporárias estão abertas. (Bug nº 18948649)