Como usar os patches com tempo de inatividade zero - Amazon Aurora

Como usar os patches com tempo de inatividade zero

A execução de atualizações para clusters de bancos de dados Aurora MySQL envolve a possibilidade de uma interrupção quando o banco de dados é desligado e enquanto ele está sendo atualizado. Por padrão, se você iniciar a atualização enquanto o banco de dados estiver ocupado, perderá todas as conexões e transações que o cluster de banco de dados está processando. Se você esperar até que o banco de dados fique ocioso para realizar a atualização, talvez seja necessário esperar muito tempo.

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 upgrade do Aurora MySQL. Se a ZDP for concluída com êxito, as sessões da aplicação serão preservadas, e o mecanismo de banco de dados será reiniciado enquanto o upgrade estiver em andamento. A reinicialização do mecanismo de banco de dados pode causar uma queda na taxa de transferência com duração de alguns segundos a aproximadamente um minuto.

O ZDP não se aplica ao seguinte:

  • Patches e upgrades do sistema operacional (SO)

  • Atualizações da versão principal

O ZDP está disponível para todas as versões do Aurora MySQL e as classes de instâncias de banco de dados.

O ZDP não é compatível com o Aurora Serverless v1 nem com bancos de dados globais do Aurora.

nota

Recomendamos usar as classes de instância de banco de dados T somente para servidores de desenvolvimento e teste, ou outros servidores que não sejam de produção. Para obter mais detalhes sobre as classes de instâncias T, consulte Uso de classes de instância T para desenvolvimento e testes.

Você pode ver métricas de atributos importantes durante o ZDP no log de erros do MySQL. Você também pode ver informações sobre quando o Aurora MySQL usa o ZDP ou escolhe não usar o ZDP na página Events (Eventos) no AWS Management Console.

No Aurora MySQL versão 2.10 e posterior e na versão 3, o Aurora pode executar um patch de tempo de inatividade zero estando ou não habilitada a replicação de logs binários. Se a replicação de logs binários estiver habilitada, o Aurora MySQL descartará automaticamente a conexão com o destino do log binário durante uma operação de ZDP. O Aurora MySQL se reconecta automaticamente ao destino do log binário e retoma a replicação quando a reinicialização é concluída.

O ZDP também funciona em combinação com os aprimoramentos de reinicialização no Aurora MySQL 2.10 e posteriores. A aplicação de patches à instância de banco de dados do gravador corrige automaticamente os leitores ao mesmo tempo. Depois de executar o patch, o Aurora restaura as conexões nas instâncias de banco de dados do gravador e do leitor. Antes do Aurora MySQL 2.10, o ZDP se aplica somente à instância de banco de dados do gravador de um cluster.

A ZDP pode não ser concluída com êxito nas seguintes condições:

  • Consultas ou transações de longa execução estão em andamento. Se o Aurora puder realizar a ZDP nesse caso, todas as transações em aberto serão canceladas, mas suas conexões serão retidas.

  • Tabelas temporárias, bloqueios de usuário ou de tabela estão em uso; por exemplo, enquanto as declarações da linguagem de definição de dados (DDL) são executadas. O Aurora descarta essas conexões.

  • Existem alterações de parâmetros pendentes.

Se nenhuma janela de tempo apropriada para executar a ZDP estiver disponível devido a uma ou mais dessas condições, a aplicação de patch será revertida para o comportamento padrão.

nota

Para o Aurora MySQL versão 2 inferior à 2.11.0 e versão 3 inferior à 3.04.0, o ZDP pode não ser concluído com êxito quando há conexões abertas de Secure Socket Layer (SSL) ou Transport Layer Security (TLS).

Embora as conexões permaneçam intactas após uma operação ZDP bem-sucedida, algumas variáveis e recursos são reinicializados. Os seguintes tipos de informações não são preservados por meio de uma reinicialização causada pela aplicação de patches com tempo de inatividade zero:

  • Variáveis globais. O Aurora restaura variáveis de sessão, mas não restaura variáveis globais após a reinicialização.

  • Variáveis de status. Especificamente, o valor do tempo de atividade informado pelo status do mecanismo é redefinido após uma reinicialização que usa os mecanismos ZDR ou ZDP.

  • LAST_INSERT_ID.

  • Estado de auto_increment na memória para tabelas. O estado de incremento automático na memória é reinicializado. Para ter mais informações sobre valores de incremento automático, consulte o Guia de referência do MySQL.

  • Informações diagnósticas das tabelas INFORMATION_SCHEMA e PERFORMANCE_SCHEMA. Essas informações de diagnóstico também aparecem na saída de comandos como SHOW PROFILE e SHOW PROFILES.

As seguintes atividades relacionadas à reinicialização do tempo de inatividade zero são relatadas na página Events (Eventos):

  • Tentar atualizar o banco de dados com tempo de inatividade zero.

  • Tentar atualizar o banco de dados com tempo de inatividade zero. O evento relata quanto tempo o processo demorou. O evento também informa quantas conexões foram preservadas durante a reinicialização e quantas conexões foram descartadas. Você pode consultar o log de erros do banco de dados para ver mais detalhes sobre o que aconteceu durante a reinicialização.