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:

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:

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.

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

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.

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.

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:

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:

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.

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --no-apply-immediately

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --no-apply-immediately