Atualizando a versão secundária ou o nível de patch de um cluster de banco de dados de Aurora MySQL - Amazon Aurora
Antes de fazer upgrade da versão secundáriaPré-verificações de atualização de versão secundária do Aurora MySQLModificar a versão do mecanismoHabilitar atualizações automáticas entre versões secundárias do Como usar os patches com tempo de inatividade zeroTécnica alternativa de atualização azul/verde

Atualizando a versão secundária ou o nível de patch de um cluster de banco de dados de Aurora MySQL

É possível usar os seguintes métodos para atualizar a versão secundária de um cluster de banco de dados ou para aplicar um patch em um cluster de banco de dados:

Para obter informações sobre como a aplicação de patches sem tempo de inatividade pode reduzir interrupções durante o processo de atualização, consulte Como usar os patches com tempo de inatividade zero.

Antes de realizar um upgrade da versão secundária

Recomendamos que você execute as seguintes ações para reduzir o tempo de inatividade durante um upgrade de versão secundária:

Pré-verificações de atualização de versão secundária do Aurora MySQL

Quando você inicia uma atualização de versão secundária, o Amazon Aurora executa pré-verificações automaticamente.

Essas pré-verificações são obrigatórias. Você não pode optar por ignorá-las. As pré-verificações fornecem os seguintes benefícios:

  • Elas permitem evitar o tempo de inatividade não planejado durante a atualização.

  • Se houver incompatibilidades, o Amazon Aurora impedirá a atualização e fornecerá um log para que você saiba sobre elas. Dessa forma, você poderá usar o log para preparar o banco de dados para o upgrade e reduzir essas incompatibilidades. Consulte informações detalhadas sobre como remover incompatibilidades em Preparing your installation for upgrade na documentação do MySQL.

As pré-verificações são executadas antes que a instância de banco de dados seja interrompida para a atualização, o que significa que elas não causam nenhum tempo de inatividade quando são executadas. Se as verificações prévias encontrarem uma incompatibilidade, o Aurora cancelará automaticamente a atualização antes que a instância de banco de dados seja interrompida. O Aurora também gera um evento para a incompatibilidade. Para ter mais informações sobre eventos do Amazon Aurora, consulte Trabalhar com a notificação de eventos do Amazon RDS.

O Aurora registra informações detalhadas sobre cada incompatibilidade no arquivo de log PrePatchCompatibility.log. Na maioria dos casos, a entrada de log inclui um link para a documentação do MySQL para corrigir a incompatibilidade. Para obter mais informações sobre como exibir arquivos de log, consulte Como visualizar e listar arquivos de log do banco de dados.

Devido à natureza das pré-verificações, eles analisam os objetos do seu banco de dados. Essa análise resulta no consumo do recurso e aumenta o tempo para que a atualização seja concluída.

Atualizar o Aurora MySQL modificando a versão do mecanismo

O upgrade da versão secundária de um cluster do Aurora MySQL aplica correções adicionais e novos recursos a um cluster existente.

Esse tipo de upgrade se aplica a clusters do Aurora MySQL em que tanto a versão original como a versão atualizada têm a mesma versão principal do Aurora MySQL, a 2 ou a 3. O processo é rápido e direto porque não envolve uma conversão para os metadados do Aurora MySQL ou a reorganização de seus dados de tabela.

Execute esse tipo de atualização modificando a versão do mecanismo do cluster de banco de dados usando o AWS Management Console, a AWS CLI, ou a API do RDS. Por exemplo, se o cluster estiver executando o Aurora MySQL 2.x, escolha uma versão 2.x posterior.

Se você estiver executando uma atualização secundária em um Aurora Global Database, atualize todos os clusters secundários antes de atualizar o cluster primário.

nota

Para atualizar a versão secundária para o Aurora MySQL versão 3.03.* ou posterior ou a versão 2.12, use o seguinte processo:

  1. Remova todas as regiões secundárias do cluster global. Siga as etapas em Remover um cluster de um banco de dados global do Amazon Aurora.

  2. Atualize a versão do mecanismo da região primária para a versão 3.03.* ou posterior, ou versão 2.12.*, conforme aplicável. Siga as etapas em To modify the engine version of a DB cluster.

  3. Adicione regiões secundárias ao cluster global. Siga as etapas em Adicionar uma Região da AWS a um Amazon Aurora Global Database.

Como modificar a versão do mecanismo de um cluster de banco de dados

  • Usando o console: modifique as propriedades de seu cluster. Na janela Modify DB cluster (Modificar o cluster de banco de dados), altere a versão do mecanismo do Aurora MySQL na caixa DB engine version (Versão do mecanismo de banco de dados). Se você não estiver familiarizado com o procedimento geral para modificar um cluster, siga as instruções em Modificar o cluster de banco de dados usando o console, a CLI e a API.

  • Usando a AWS CLI: chame o comando modify-db-cluster da AWS CLI e especifique o nome do cluster de banco de dados para a opção --db-cluster-identifier e a versão do mecanismo para a opção --engine-version.

    Por exemplo, para fazer upgrade para o Aurora MySQL versão 2.12.1, defina a opção --engine-version como 5.7.mysql_aurora.2.12.1. Especifique a opção --apply-immediately para atualizar imediatamente a versão de banco de dados para o cluster de banco de dados.

  • Usando a API do RDS – Call the ModifyDBCluster API operation (Chame a operação de API ModifyDBCluster) e especifique o nome do cluster de banco de dados do parâmetro DBClusterIdentifier e a versão do mecanismo do parâmetro EngineVersion. Defina o parâmetro ApplyImmediately como true para atualizar imediatamente a versão do mecanismo do cluster de banco de dados.

Habilitar atualizações automáticas entre versões secundárias do Aurora MySQL

Para um cluster de bancos de dados Amazon Aurora MySQL, você pode especificar que o Aurora atualize o cluster de banco de dados automaticamente para novas versões secundárias. Isso é feito definindo-se a propriedade AutoMinorVersionUpgrade (Upgrade automático de versões secundárias no AWS Management Console) do cluster de banco de dados.

Os upgrades automáticos ocorrem durante as janelas de manutenção. Se as instâncias de banco de dados individuais no cluster de banco de dados tiverem janelas de manutenção diferentes da janela de manutenção do cluster, a janela de manutenção do cluster terá precedência.

A atualização automática de versão secundária não se aplica aos seguintes tipos de clusters do Aurora MySQL:

  • Clusters que fazem parte de um banco de dados global Aurora

  • Clusters que têm réplicas entre regiões

A duração da interrupção varia de acordo com a workload, o tamanho do cluster, a quantidade de dados de log binário e se o Aurora pode usar o recurso de aplicar patches de tempo de inatividade zero (ZDP). O Aurora reinicia o cluster de banco de dados, então você poderá enfrentar um curto período de indisponibilidade antes de retomar o uso do cluster. Em específico, a quantidade de dados do log binário afeta o tempo de recuperação. A instância de banco de dados processa os dados de log binário durante a recuperação. Assim, um alto volume de dados de log binário aumenta o tempo de recuperação.

nota

O Aurora só executará atualizações automáticas se todas as instâncias de banco de dados no cluster de banco de dados tiverem a configuração AutoMinorVersionUpgrade habilitada. Para ter informações sobre como defini-la e como ela funciona quando aplicada em níveis de cluster e de instância, consulte Atualizações da versão secundária automáticas para clusters de banco de dados do Aurora.

Portanto, se existir um caminho de atualização para as instâncias do cluster de banco de dados para uma versão secundária do mecanismo de banco de dados com o recurso AutoUpgrade definido como verdadeiro, a atualização ocorrerá. A configuração de AutoUpgrade é dinâmica e definida pelo RDS.

As atualizações automáticas de versões secundárias são realizadas para a versão secundária padrão.

É possível usar um comando de CLI como o seguinte para conferir o status da configuração AutoMinorVersionUpgrade para todas as instâncias de banco de dados em seus clusters do Aurora MySQL.

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

Esse comando gerará uma saída semelhante à seguinte:

[
  {
      "DBInstanceIdentifier": "db-t2-medium-instance",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": true
  },
  {
      "DBInstanceIdentifier": "db-t2-small-original-size",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": false
  },
  {
      "DBInstanceIdentifier": "instance-2020-05-01-2332",
      "DBClusterIdentifier": "cluster-57-2020-05-01-4615",
      "AutoMinorVersionUpgrade": true
  },
... output omitted ...

Neste exemplo, a opção Habilitar atualização automática da versão secundária está desativada para o cluster de banco de dados cluster-57-2020-06-03-6411 porque está desativada para uma das instâncias de banco de dados no cluster.

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.

  • Tabelas temporárias ou bloqueios de tabela estão em uso, por exemplo, enquanto as instruções DDL (Data Definition Language) são executadas. Se o Aurora puder realizar a ZDP nesse caso, todas as transações em aberto serão canceladas.

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

Técnica alternativa de atualização azul/verde

Em algumas situações, a prioridade é executar um switchover imediato do cluster antigo para um atualizado. Nessas situações, você pode seguir um processo de várias etapas que executa clusters antigos e novos lado a lado. Nesse caso, você replica dados do cluster antigo para o novo até que esteja pronto para que o novo cluster assuma o controle. Para obter mais detalhes, consulte Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados.