# Realizar uma atualização da versão secundária É 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: **Topics** + [Antes de realizar um upgrade da versão secundária](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor) + [Como realizar atualizações de versão secundária e aplicar patches](#USER_UpgradeDBInstance.PostgreSQL.Minor) + [Atualizações de versões secundárias e patches com tempo de inatividade zero](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp) + [Limitações da aplicação de patches com tempo de inatividade zero](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations) + [Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão secundária](#USER_UpgradeDBInstance.MinorUpgrade) ## 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/). ## Como realizar atualizações de versão secundária e aplicar patches Patches e atualizações de versões secundárias ficam disponíveis em Regiões da AWS somente após testes rigorosos. Antes de lançar atualizações e patches, o Aurora PostgreSQL testa para garantir que problemas de segurança conhecidos, erros e outros problemas que surgem após o lançamento da versão secundária da comunidade não interrompam a estabilidade da frota do Aurora PostgreSQL. Se você ativar **Habilitar o upgrade automático da versão secundária**, o Aurora PostgreSQL atualizará periodicamente o cluster de banco de dados durante a janela de manutenção especificada. Verifique se a opção **Habilitar o upgrade automático da versão secundária** está ativada para todas as instâncias de banco de em seu cluster de banco de dados do Aurora PostgreSQL. Para obter informações sobre como definir a configuração **Upgrade automático de versões secundárias** e como ela funciona quando aplicada nos níveis de cluster e instância, consulte [Atualizações da versão secundária automáticas para clusters de banco de dados do Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU). Confira o valor da opção **Habilitar o upgrade automático da versão secundária** para todos os clusters de banco de dados do Aurora PostgreSQL usando o comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) da AWS CLI da forma a seguir. ``` aws rds describe-db-instances \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}' ``` Essa consulta retorna uma lista de todos os clusters de banco de dados do Aurora e de suas instâncias com um valor `true` ou `false` para o status da configuração `AutoMinorVersionUpgrade`. O comando pressupõe que você tenha a AWS CLI configurada para a Região da AWS padrão pretendida. Para obter mais informações sobre a opção AmVU e como modificar o cluster de banco de dados do Aurora para usá-la, consulte [Atualizações da versão secundária automáticas para clusters de banco de dados do Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU). Você pode atualizar seus clusters de banco de dados do Aurora PostgreSQL para novas versões secundárias respondendo a tarefas de manutenção ou modificando o cluster para usar a nova versão. Você pode identificar todas as atualizações ou patches disponíveis para seus clusters de banco de dados do Aurora PostgreSQL usando o console do RDS e abrindo o menu **Recommendations** (Recomendações). Nesse menu, é possível encontrar uma lista de vários problemas de manutenção, como **Old minor versions** (Versões secundárias antigas). Dependendo do ambiente de produção, você pode optar por programar (**Schedule**) a atualização ou tomar medidas imediatas, escolhendo **Apply now** (Aplicar agora), conforme mostrado a seguir. ![\[Imagem do console mostrando Recommendation (Recomendação) para realizar a atualização para uma versão secundária mais recente.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/apg-maintenance-upgrade-minor.png) Para saber mais sobre como manter um cluster de banco de dados do Aurora, inclusive como aplicar manualmente patches e atualizações de versões secundárias, consulte [Manutenção de um cluster de banco de dados do Amazon Aurora](USER_UpgradeDBInstance.Maintenance.md). ## Atualizações de versões secundárias e patches com tempo de inatividade zero A atualização de um cluster de banco de dados do Aurora PostgreSQL envolve a possibilidade de uma interrupção. Durante o processo de atualização, o banco de dados é desligado à medida que está sendo atualizado. 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 ZDP (zero-time patch) melhora o processo de atualização. Com o ZDP, atualizações de versões menores e patches podem ser aplicados com impacto mínimo no cluster de banco de dados do Aurora PostgreSQL. O ZDP é usado ao aplicar patches ou atualizações de versões secundárias mais recentes para o Aurora PostgreSQL e outras versões posteriores dessas versões secundárias e principais mais recentes. Ou seja, a atualização para novas versões secundárias de qualquer uma dessas versões em diante usa o ZDP. A tabela a seguir mostra as versões do Aurora PostgreSQL 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\$1 | Classes de instância db.t\$1 | Classes de instância db.x\$1 | Classe de instância db.serverless | | --- | --- | --- | --- | --- | | 10.21 e versões posteriores | Sim | Sim | Sim | N/D | | 11.16 e versões posteriores | Sim | Sim | Sim | N/D | | 11.17 e versões posteriores | Sim | Sim | Sim | N/D | | 12.11 e versões posteriores | Sim | Sim | Sim | N/D | | 12.12 e versões posteriores | Sim | Sim | Sim | N/D | | 13.7 e versões posteriores | Sim | Sim | Sim | N/D | | 13.8 e versões posteriores | Sim | Sim | Sim | Sim | | 14.3 e versões posteriores | Sim | Sim | Sim | N/D | | 14.4 e versões posteriores | Sim | Sim | Sim | N/D | | 14.5 e versões posteriores | Sim | Sim | Sim | Sim | | 15.3 e versões posteriores | Sim | Sim | Sim | Sim | | 16.1 e versões posteriores | Sim | Sim | Sim | Sim | Durante o processo de upgrade usando o recurso ZDP, o mecanismo de banco de dados procura um ponto tranquilo para pausar todas as novas transações. Essa ação protege o banco de dados durante patches e upgrades. Para garantir que suas aplicações funcionem sem problemas com transações pausadas, recomendamos integrar a lógica de novas tentativas em seu código. Essa abordagem garante que o sistema consiga gerenciar qualquer breve tempo de inatividade sem falhas e possa tentar realizar novamente as novas transações depois do upgrade. Quando o recurso ZDP é concluído com êxito, as sessões da aplicação são preservadas, exceto aquelas com conexões descartadas, e o mecanismo de banco de dados é reiniciado enquanto o upgrade ainda está em andamento. Embora a reinicialização do mecanismo de banco de dados possa causar uma queda temporária no throughput, em geral, ela dura apenas alguns segundos ou, no máximo, cerca de um minuto. Em alguns casos, a aplicação de patch de tempo de inatividade zero (ZDP) pode não ter êxito. Por exemplo, as alterações de parâmetros no estado `pending` no cluster de banco de dados do Aurora PostgreSQL ou em suas instâncias interferem no ZDP. Você pode encontrar métricas e eventos para operações do ZDP na página **Events** (Eventos) no console. Os eventos incluem o início da atualização do ZDP e a conclusão da atualização. Nesse caso, é possível descobrir quanto tempo o processo demorou e o número de conexões preservadas e descartadas que ocorreram durante a reinicialização. É possível localizar detalhes no log de erros do banco de dados. ## Limitações da aplicação de patches com tempo de inatividade zero As seguintes limitações se referem à aplicação de patches com tempo de inatividade zero: + O ZDP tenta preservar as conexões atuais do cliente com a instância de gravador do Aurora PostgreSQL durante todo o processo de upgrade do Aurora PostgreSQL. No entanto, nos seguintes casos, as conexões serão interrompidas para que o ZDP seja concluído: + Consultas ou transações de longa execução estão em andamento. + As instruções Data Definition Language (DDL) estão em execução. + As tabelas temporárias ou bloqueios de tabela estão em uso. + Todas as sessões estão sendo ouvidas nos canais de notificação. + Um cursor no status “'WITH HOLD” está em uso. + As conexões TLSv1.1 estão em uso. A partir das versões do Aurora PostgreSQL posteriores a 16.1, 15.3, 14.8, 13.11, 12.15 e 11.20, o ZDP é compatível com conexões TLSv1.3. + O ZDP não é compatível nos seguintes casos: + Quando os clusters de banco de dados do Aurora PostgreSQL são configurados como o Aurora Serverless v1. + Durante o upgrade de qualquer instância de leitor do Aurora. + Durante o upgrade de qualquer instância de leitor do Aurora que faça parte de um cluster do Aurora Global Database em uma região secundária. + Durante os patches e atualizações do sistema operacional. ## Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão secundária Você pode atualizar o cluster de banco de dados do Aurora PostgreSQL para uma nova versão secundária usando o console, a AWS CLI ou a API do RDS. Antes de realizar o upgrade, recomendamos seguir as mesmas práticas recomendadas para atualizações de versão principais. Assim como nas novas versões principais, as novas versões secundárias também podem ter melhorias no otimizador, como correções, que podem causar regressões no plano de consulta. Para garantir a estabilidade do plano, recomendamos usar a extensão Query Plan Management (QPM) conforme detalhado em [Garantir a estabilidade do plano após a atualização da versão principal](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade). ### Console **Como atualizar o mecanismo de seu cluster de banco de dados do Aurora PostgreSQL** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Databases (Bancos de dados)** e o cluster de banco de dados que você deseja atualizar. 1. Selecione **Modify**. A página **Modify DB cluster (Modificar cluster de banco de dados)** é exibida. 1. Em **Engine version** (Versão do mecanismo), escolha a nova versão. 1. Escolha **Continue (Continuar)** e verifique o resumo de modificações. 1. Para aplicar as alterações imediatamente, escolha **Apply immediately**. Escolher essa opção pode causar uma interrupção em alguns casos. Para ter mais informações, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md). 1. Na página de confirmação, revise suas alterações. Se estiverem corretas, escolha **Modify cluster (Modificar cluster)** para salvar suas alterações. Ou selecione **Back (Voltar)** para editar as alterações ou **Cancel (Cancelar)** para cancelar as alterações. ### AWS CLI Para atualizar a versão do mecanismo de um cluster de banco de dados, use o comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) da AWS CLI com os seguintes parâmetros: + `--db-cluster-identifier`: o nome de seu cluster de banco de dados do Aurora PostgreSQL. + `--engine-version`: o número da versão do mecanismo de banco de dados para a qual será feita a atualização. Para obter informações sobre versões de mecanismo válidas, use o comando AWS CLI [ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html). + `--no-apply-immediately`: aplica as alterações durante a próxima janela de manutenção. Para aplicar as alterações imediatamente, use `--apply-immediately`. Para Linux, macOS ou Unix: ``` aws rds modify-db-cluster \ --db-cluster-identifier mydbcluster \ --engine-version new_version \ --no-apply-immediately ``` Para Windows: ``` aws rds modify-db-cluster ^ --db-cluster-identifier mydbcluster ^ --engine-version new_version ^ --no-apply-immediately ``` ### API do RDS Para atualizar a versão do mecanismo de um cluster de banco de dados, use a operação [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Especifique os seguintes parâmetros: + `DBClusterIdentifier` – o nome do cluster de banco de dados. Por exemplo *`mydbcluster`*. + `EngineVersion`: o número da versão do mecanismo de banco de dados para a qual será feita a atualização. Para obter informações sobre versões de mecanismo válidas, use a operação [ DescribeDBEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html). + `ApplyImmediately`: se deseja ou não aplicar as alterações imediatamente ou durante a próxima janela de manutenção. Para aplicar as alterações imediatamente, defina o valor como `true`. Para aplicar alterações durante a próxima janela de manutenção, defina o valor como `false`.