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:

• Atualizar o Aurora MySQL modificando a versão do mecanismo (para Aurora MySQL 1.19.0 e posterior ou 2.03.2 e posterior)

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

• Atualizar o Aurora MySQL aplicando manutenção pendente a um cluster de bancos de dados Aurora MySQL (antes do Aurora MySQL 1.19.0)

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.

Atualizar o Aurora MySQL modificando a versão do mecanismo

Atualizar a versão secundária de um cluster do Aurora MySQL aplica correções adicionais e novos recursos a um cluster existente. É possível fazer esse tipo de atualização para clusters que estão executando o Amazon Aurora MySQL versão 1.19.0 e posterior ou 2.03.2 e posterior.

Esse tipo de atualização se aplica a clusters do Aurora MySQL em que a versão original e a versão atualizada estão no Aurora MySQL 1.x series ou no Aurora MySQL 2.x series. 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. Se o cluster estiver executando o Aurora MySQL 1.x, escolha uma versão 1.x posterior. Se o cluster estiver executando o Aurora MySQL 2.x, escolha uma versão 2.x posterior.

nota

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.

Para 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, a fim de atualizar para o Aurora MySQL versão 2.03.2, defina a opção --engine-version como 5.7.mysql_aurora.2.03.2. 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. Faça isso com a propriedade de atualização automática de versão secundária do cluster de banco de dados usando o AWS Management Console, a AWS CLI ou a API do RDS.

As atualizações automáticas ocorrem durante a janela de manutenção do banco de dados.

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

• Clusters de vários mestres

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

Como habilitar atualizações automáticas de versões secundárias para um cluster de bancos de dados Aurora MySQL

1. Siga o procedimento geral para modificar as instâncias de banco de dados em seu cluster, conforme descrito em Modificar uma instância de banco de dados em um cluster de banco de dados. Repita este procedimento para cada instância de banco de dados em seu cluster.

2. Faça o seguinte para habilitar atualizações automáticas de versão secundária para o cluster:

• Usando o console: conclua as seguintes etapas:

  1. Entre no console do Amazon RDS. Escolha Databases (Bancos de dados)e encontre o cluster de banco de dados no qual você deseja ativar ou desativar a atualização automática da versão secundária.

  2. Escolha cada instância de banco de dados no cluster de banco de dados que você deseja modificar. Aplique a seguinte alteração para cada instância de banco de dados em sequência.

     1. Selecione Modify.

     2. Escolha a configuração Enable auto minor version upgrade (Habilitar atualização automática de versão secundária). Essa configuração faz parte da seção Maintenance (Manutenção).

     3. Escolha Continue (Continuar) e verifique o resumo de modificações.

     4. (Opcional) Escolha Apply immediately (Aplicar imediatamente) para aplicar as alterações imediatamente.

     5. Na página de confirmação, escolha Modify DB instance(Modificar a instância de banco de dados).

• Usando a AWS CLI: chame o comando modify-db-instance da AWS CLI. Especifique o nome da instância de banco de dados para a opção --db-instance-identifier e true para a opção --auto-minor-version-upgrade. Opcionalmente, especifique a opção --apply-immediately para habilitar imediatamente essa configuração para sua instância de banco de dados. Execute um comando modify-db-instance separado para cada instância de banco de dados no cluster.

• Usando a API do RDS: chame a operação ModifyDBInstance API e especifique o nome do cluster de banco de dados para o parâmetro DBInstanceIdentifier e true para o parâmetro AutoMinorVersionUpgrade. Opcionalmente, defina o parâmetro ApplyImmediately como true para habilitar imediatamente essa configuração para sua instância de banco de dados. Chame uma operação ModifyDBInstance separada para cada instância de banco de dados no cluster.

É possível usar um comando CLI como o seguinte para verificar o status de Enable auto minor version upgrade (Habilitar atualização automática de versão secundária) 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 ...

Atualizar o Aurora MySQL aplicando manutenção pendente a um cluster de bancos de dados Aurora MySQL

Durante a atualização para o Aurora MySQL versão 1.x, novas versões secundárias do mecanismo de banco de dados e patches são mostrados como uma atualização de manutenção disponível para o cluster de banco de dados. Você pode atualizar ou aplicar um patch na versão do banco de dados do seu cluster de banco de dados realizando a ação de manutenção disponível. Recomendamos aplicar a atualização em um cluster de banco de dados que não seja de produção primeiro, para que seja possível ver como alterações na nova versão afetam as instâncias e as aplicações.

Para aplicar ações de manutenção pendentes

• Usando o console do – Conclua as seguintes etapas:

  1. Entre no console Amazon RDS, escolha Databases (Bancos de dados)e escolha o cluster de banco de dados que mostra a atualização de manutenção disponível.

  2. Escolha Actions (Ações) e Upgrade now (Atualizar agora) para atualizar imediatamente a versão do banco de dados para o cluster de banco de dados ou Upgrade at next window (Atualizar na próxima janela) para atualizar a versão do banco de dados do cluster do banco de dados durante a próxima janela de manutenção do cluster de banco de dados.

• Usando a AWS CLI: chame o comando apply-pending-maintenance-action da AWS CLI e especifique o Amazon Resource Name (ARN) do cluster do banco de dados para a opção --resource-id e system-update para a opção --apply-action. Defina a opção --opt-in-type como immediate para atualizar imediatamente a versão do banco de dados para o seu cluster de banco de dados ou como next-maintenance para atualizar a versão do banco de dados para o seu cluster de banco de dados durante a próxima janela de manutenção de cluster.

• Com a API do RDS: chame a operação de API ApplyPendingMaintenanceAction e especifique o ARN do seu cluster de banco de dados para o parâmetro ResourceId e system-update para o parâmetro ApplyAction. Defina o parâmetro OptInType como immediate para atualizar imediatamente a versão do banco de dados para o seu cluster de banco de dados ou como next-maintenance para atualizar a versão do banco de dados para o seu instância durante a próxima janela de manutenção de cluster.

Para obter mais informações sobre como o Amazon RDS gerencia atualizações de banco de dados e sistema operacional, consulte Manutenção de um cluster de banco de dados do Amazon Aurora.

nota

Se a versão atual Aurora MySQL é 1.14.x, mas inferior à 1.14.4, você só poderá atualizar para a 1.14.4 (que oferece suporte às classes de instância db.r4). Além disso, para atualizar da 1.14.x para uma versão secundária superior do Aurora MySQL, como a 1.17, a versão 1.14.x deverá ser a 1.14.4.

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.

A tabela a seguir mostra as versões do Aurora MySQL e as classes de instâncias de banco de dados em que o ZDP está disponível.

Versão	Classes de instância db.r*	Classes de instância db.t*	Classe de instância db.serverless
2.07.2 e versões 2.07 posteriores	Não	Sim	N/D
2.10.0 e versões 2.10 posteriores	Sim	Sim	N/D
3.01.0 e 3.01.1	Sim	Sim	N/D
3.02.0 e versões 3.x posteriores	Sim	Sim	Sim

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 2.10 e posterior e na versão 3, o Aurora pode executar um patch de tempo de inatividade zero quando a replicação de log binário está habilitada. O Aurora MySQL descarta 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.

• Existem conexões Secure Socket Layer (SSL) abertas.

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

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 obter 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 concluído. 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.

A tabela a seguir resume como o ZDP funciona para atualizar de e para versões 1.x e 2.x específicas do Aurora MySQL. A classe de instância da instância de banco de dados também afeta se o Aurora usa o mecanismo ZDP.

Versão original	Versão atualizada	O ZDP se aplica?
Aurora MySQL 1.*	Quaisquer	Não
Aurora MySQL 2.*, antes de 2.07.2	Quaisquer	Não
Aurora MySQL 2.07.2, 2.07.3	Versões 2.07.4 e posterior à 2.07, 2.10.*	Sim, na instância de gravação somente para classes de instância T2 e T3. O Aurora só executará o ZDP se um ponto silencioso for encontrado antes de ocorrer um tempo limite. Após o tempo limite, o Aurora executa uma reinicialização regular.
Aurora MySQL 2.07.4 e versões 2.07 posteriores	2.10.*	Sim, na instância de gravação somente para instâncias T2 e T3. O Aurora reverte transações para transações ativas e ociosas. As conexões usando SSL, as tabelas temporárias, os bloqueios de tabela ou os bloqueios de usuário são desconectados. O Aurora poderá reiniciar o mecanismo e soltar todas as conexões se o mecanismo demorar muito tempo para iniciar após a conclusão do ZDP.
Aurora MySQL 2.10.*	2.10.*	Sim, na instância gravadora para instâncias db.t* e db.r*. O Aurora reverte transações para transações ativas e ociosas. As conexões usando SSL, as tabelas temporárias, os bloqueios de tabela ou os bloqueios de usuário são desconectados. O Aurora poderá reiniciar o mecanismo e soltar todas as conexões se o mecanismo demorar muito tempo para iniciar após a conclusão do ZDP.

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

Publicação do blog: Performing major version upgrades for Aurora MySQL with minimum downtime (Executar upgrades de versões principais para o Aurora MySQL com tempo de inatividade mínimo).