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, 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. 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.

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.

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.