# 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](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md) (para Aurora MySQL versões 2 e 3)
+ [Habilitar atualizações automáticas entre versões secundárias do Aurora MySQL](AuroraMySQL.Updates.AMVU.md)
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](AuroraMySQL.Updates.ZDP.md).
Para ter informações sobre como realizar a atualização da versão secundária do cluster de banco de dados do Aurora MySQL, consulte os tópicos a seguir.
**Topics**
+ [Antes de realizar um upgrade da versão secundária](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Pré-verificações de atualização de versão secundária do Aurora MySQL](#AuroraMySQL.minor-upgrade-prechecks)
+ [Atualizar o Aurora MySQL modificando a versão do mecanismo](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md)
+ [Habilitar atualizações automáticas entre versões secundárias do Aurora MySQL](AuroraMySQL.Updates.AMVU.md)
+ [Como usar os patches com tempo de inatividade zero](AuroraMySQL.Updates.ZDP.md)
+ [Técnica alternativa de atualização azul-verde](#AuroraMySQL.UpgradingMinor.BlueGreen)
## 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:
+ A manutenção do cluster de banco de dados do Aurora deve ser realizada durante um período de baixo tráfego. Use o Insights de Performance para identificar esses períodos a fim de configurar as janelas de manutenção corretamente. Consulte mais informações sobre o Insights de Performance em [Monitoring DB load with Performance Insights on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html). Consulte mais informações sobre a janela de manutenção do cluster de banco de dados em [Ajustar a janela de manutenção do cluster de banco de dados preferencial](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
+ Use SDKs da AWS compatíveis com oscilações e recuos exponenciais como uma prática recomendada. Consulte mais informações em [Exponential Backoff And Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/).
## 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](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) 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](USER_Events.md).
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](USER_LogAccess.Procedural.Viewing.md).
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.
## 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 Aurora para atualizações de banco de dados](blue-green-deployments.md).