Atualizar o mecanismo de banco de dados PostgreSQL para Aurora PostgreSQL - Amazon Aurora

Atualizar o mecanismo de banco de dados PostgreSQL para Aurora PostgreSQL

O Amazon Aurora disponibiliza novas versões do mecanismo de banco de dados do PostgreSQL em Regiões da AWS somente após testes extensivos. Você poderá atualizar seus clusters de banco de dados do Aurora PostgreSQL para a nova versão quando ela estiver disponível em sua região.

Dependendo da versão do Aurora PostgreSQL em que seu cluster de banco de dados está em execução no momento, uma atualização para a nova versão é secundária ou principal. Por exemplo, a atualização de um cluster de banco de dados do Aurora PostgreSQL 11.15 para o Aurora PostgreSQL 13.6 é uma atualização da versão principal. Por exemplo, a atualização de um cluster de banco de dados do Aurora PostgreSQL 11.15 para o Aurora PostgreSQL 13.6 é uma atualização da versão secundária. Nos tópicos a seguir, você encontrará informações sobre como realizar os dois tipos de atualizações.

Visão geral dos processos de atualização do Aurora PostgreSQL

As diferenças entre atualizações de versão principal e secundária são as seguintes:

Patches e atualizações de versões secundárias

Patches e atualizações de versões secundárias incluem somente alterações compatíveis com versões anteriores das aplicações existentes. Patches e atualizações de versões secundárias ficam disponíveis para você somente depois que o Aurora PostgreSQL os testa e os aprova.

Atualizações de versões secundárias podem ser aplicadas automaticamente pelo Aurora. Quando você cria um cluster de banco de dados PostgreSQL do Aurora, a opção Enable minor version upgrade (Ativar atualização de versão secundária) é pré-selecionada. A menos que você desative essa opção, as atualizações de versões secundárias serão aplicadas automaticamente durante a janela de manutenção agendada. Para obter mais informações sobre a opção de atualização automática de versão secundária (AMVU) e como modificar seu cluster de banco de dados do Aurora para usá-lo, consulte Atualizações da versão secundária automáticas para clusters de banco de dados do Aurora .

Se a opção de atualização automática de versão secundária não estiver definida para seu cluster de banco de dados do Aurora PostgreSQL, o Aurora PostgreSQL não será atualizado automaticamente para a nova versão secundária. Em vez disso, quando uma nova versão secundária é lançada em sua Região da AWS e o cluster de banco de dados do Aurora PostgreSQL está executando uma versão secundária mais antiga, o Aurora solicita a atualização. Ele faz isso adicionando uma recomendação às tarefas de manutenção do cluster.

Os patches não são considerados atualizações e não são aplicados automaticamente. O Aurora PostgreSQL solicita que você aplique todos os patches adicionando uma recomendação às tarefas de manutenção do cluster de banco de dados do Aurora PostgreSQL. Para obter mais informações, consulte Como realizar atualizações de versão secundária e aplicar patches.

nota

Patches que resolvem problemas de segurança ou outros problemas críticos também são adicionados como tarefas de manutenção. No entanto, esses patches são necessários. Aplique patches de segurança ao cluster de banco de dados do Aurora PostgreSQL quando eles estiverem disponíveis em suas tarefas de manutenção pendentes.

O processo de atualização envolve a possibilidade de breves interrupções à medida que cada instância no cluster é atualizada para a nova versão. No entanto, após o Aurora PostgreSQL 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3, bem como outras versões posteriores dessas versões secundárias e principais mais recentes, o processo de atualização usa o recurso ZDP (zero-downtime patch). Esse recurso minimiza as interrupções e, na maioria dos casos, as elimina completamente. Para obter mais informações, consulte Atualizações de versões secundárias e patches com tempo de inatividade zero.

nota

Não há suporte ao ZDP para clusters de banco de dado do Aurora PostgreSQL configurados como bancos de dados globais Aurora Serverless v2, Aurora Serverless v1 ou Aurora.

Atualizações de versão principal

Ao contrário de atualizações e patches de versões secundárias, o Aurora PostgreSQL não tem uma opção automática de atualização de versão principal. Novas versões principais do PostgreSQL podem conter alterações de banco de dados incompatíveis com versões anteriores das aplicações existentes. A nova funcionalidade pode fazer com que suas aplicações existentes parem de funcionar corretamente.

Para evitar problemas, é altamente recomendável seguir o processo descrito em Antes de atualizar o cluster de banco de dados de produção para uma nova versão principal antes de atualizar as instâncias de banco de dados em seus clusters de banco de dados do Aurora PostgreSQL. Primeiro, verifique se suas aplicações podem ser executadas na nova versão seguindo esse procedimento. Depois, você pode atualizar manualmente o cluster de banco de dados do Aurora PostgreSQL para a nova versão.

O processo de atualização envolve a possibilidade de breves interrupções à medida que cada instância no cluster é atualizada para a nova versão. O processo de planejamento preliminar também leva tempo. Recomendamos que você sempre execute tarefas de atualização durante a janela de manutenção do cluster ou quando as operações forem mínimas. Para obter mais informações, consulte Como realizar uma atualização de versão principal.

nota

Tanto as atualizações de versões secundárias quanto as atualizações de versões principais podem envolver breves interrupções. Por esse motivo, recomendamos que você execute ou programe atualizações durante sua janela de manutenção ou durante outros períodos de baixa utilização.

Como realizar uma atualização de versão principal

As atualizações da versão principal podem conter alterações de banco de dados incompatíveis com as versões anteriores do banco de dados. A nova funcionalidade em uma nova versão pode fazer com que suas aplicações existentes parem de funcionar corretamente. Para evitar problemas, o Amazon Aurora não aplica atualizações da versão principal automaticamente. Em vez disso, recomendamos planejar cuidadosamente uma atualização de versão principal seguindo estas etapas:

  1. Escolha na lista de destinos disponíveis a versão principal desejada das listadas para sua versão na tabela. Você pode obter uma lista precisa de versões disponíveis em suaRegião da AWS para sua versão atual usando a AWS CLI. Para obter mais detalhes, consulte Obter uma lista de versões disponíveis em sua Região da AWS.

  2. Verifique se suas aplicações funcionam conforme o esperado em uma implantação de avaliação da nova versão. Para obter informações sobre o processo completo, consulte Antes de atualizar o cluster de banco de dados de produção para uma nova versão principal.

  3. Depois de verificar se suas aplicações funcionam conforme o esperado na implantação de avaliação, você pode atualizar seu cluster. Para obter mais detalhes, consulte Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal.

nota

Você pode realizar uma atualização da versão principal de versões 13 do Babelfish para Aurora PostgreSQL a partir da 13.6 para versões 14 do Aurora PostgreSQL a partir da 14.6. As versões 13.4 e 13.5 do Babelfish para Aurora PostgreSQL não oferecem suporte a atualizações da versão principal.

Na tabela, você pode encontrar as atualizações de versões disponíveis para várias versões do banco de dados do Aurora PostgreSQL.

Para qualquer versão que você esteja considerando, verifique sempre a disponibilidade da classe de instância de banco de dados do cluster. Por exemplo, o db.r4 não é compatível com o Aurora PostgreSQL 13. Se seu cluster de banco de dados do Aurora PostgreSQL atualmente usa uma classe de instância db.r4, você precisará mover para db.r5 antes de tentar realizar a atualização. Para obter mais informações sobre classes de instância de banco de dados, incluindo quais são baseadas em Graviton2 e quais são baseadas em Intel, consulte Classes de instância de banco de dados Aurora.

Obter uma lista de versões disponíveis em sua Região da AWS

Você pode obter uma lista de versões do mecanismo disponíveis como destinos de atualização para seu banco de dados do Aurora PostgreSQL consultando sua Região da AWS usando o comando describe-db-engine-version AWS CLI da forma a seguir.

Para Linux, macOS ou Unix:

aws rds describe-db-engine-versions \ --engine aurora-postgresql \ --engine-version 12.10 \ --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \ --output text

Para Windows:

aws rds describe-db-engine-versions ^ --engine aurora-postgresql ^ --engine-version 12.10 ^ --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}" ^ --output text

Em alguns casos, a versão para a qual você deseja atualizar não é um destino para sua versão atual. Nesses casos, use as informações na versions table para realizar atualizações de versões secundárias até que o cluster esteja em uma versão que tenha o destino escolhido em sua linha de destinos.

Antes de atualizar o cluster de banco de dados de produção para uma nova versão principal

Toda nova versão principal inclui melhorias no otimizador de consulta projetadas para aprimorar a performance. No entanto, sua workload pode incluir consultas que resultem em um plano de performance inferior na nova versão. É por isso que recomendamos que você teste e avalie a performance antes de atualizar na produção. Você pode gerenciar a estabilidade do plano de consulta entre versões usando a extensão Query Plan Management (QPM), conforme detalhado em Garantir a estabilidade do plano após a atualização da versão principal.

Antes de atualizar os clusters de banco de dados do Aurora PostgreSQL de produção para uma nova versão principal, é altamente recomendável que você teste a atualização para verificar se todas as suas aplicações funcionam corretamente:

  1. Tenha um grupo de parâmetros compatível com a versão pronto para uso.

    Se você estiver usando um grupo de parâmetros de instância de banco de dados ou de cluster de banco de dados personalizado, poderá escolher entre duas opções:

    1. Especifique a instância de banco de dados padrão, o grupo de parâmetros do cluster de banco de dados, ou ambos, para a nova versão do mecanismo do banco de dados.

    2. Crie seu próprio grupo de parâmetros personalizado para a nova versão do mecanismo de banco de dados.

    Se você associar um novo grupo de parâmetros da instância de banco de dados ou do cluster de banco de dados como parte da solicitação da atualização, certifique-se de reiniciar o banco de dados após a atualização ser concluída para aplicar os parâmetros. Se uma instância de banco de dados precisar ser reinicializada para aplicar as alterações de grupo de parâmetros, o status do grupo de parâmetros da instância mostrará pending-reboot. Você pode visualizar o status do grupo de parâmetros de uma instância no console ou usando um comando da CLI, como describe-db-instances ou describe-db-clusters

  2. Verifique o uso sem suporte:

    • Confirme ou reverta todas as transações preparadas abertas antes de tentar uma atualização. Você pode usar a consulta a seguir para verificar se não há transações preparadas abertas na sua instância.

      SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
    • Remova todos os usos dos tipos de dados reg* antes de tentar fazer uma atualização. Exceto por regtype e regclass, você não pode atualizar os tipos de dados reg*. O utilitário pg_upgrade (usado pelo Amazon Aurora para fazer a atualização) não pode persistir esse tipo de dados. Para saber mais sobre esse utilitário, consulte pg_upgrade na documentação do PostgreSQL.

      Para verificar se não há nenhum uso de tipos de dados reg* sem suporte, use a consulta a seguir para cada banco de dados.

      SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a WHERE c.oid = a.attrelid AND NOT a.attisdropped AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype, 'pg_catalog.regprocedure'::pg_catalog.regtype, 'pg_catalog.regoper'::pg_catalog.regtype, 'pg_catalog.regoperator'::pg_catalog.regtype, 'pg_catalog.regconfig'::pg_catalog.regtype, 'pg_catalog.regdictionary'::pg_catalog.regtype) AND c.relnamespace = n.oid AND n.nspname NOT IN ('pg_catalog', 'information_schema');
    • Se você estiver atualizando do Aurora PostgreSQL versão 10.18 ou posterior e tiver a extensão pgRouting instalada, remova essa extensão antes de atualizar para a versão 12.4 ou posterior.

  3. Descarte slots de replicação lógica.

    O processo de upgrade não poderá continuar se o cluster de banco de dados do Aurora PostgreSQL estiver usando qualquer slot de replicação lógica. Os slots de replicação lógica são normalmente usados para tarefas de migração de dados de curto prazo, como a migração de dados usando o AWS DMS, ou para replicar tabelas do banco de dados para data lakes, ferramentas de BI ou outros destinos. Antes de atualizar, certifique-se de saber a finalidade de qualquer slot de replicação lógica existente e confirme se não há problema em excluí-los. Você pode verificar os slots de replicação lógica usando a seguinte consulta:

    SELECT * FROM pg_replication_slots;

    Se os slots de replicação lógica ainda estiverem sendo usados, você não deve excluí-los e não poderá continuar com a atualização. No entanto, se os slots de replicação lógica não forem necessários, você poderá excluí-los usando o seguinte SQL:

    SELECT pg_drop_replication_slot(slot_name);

    Os cenários de replicação lógica que usam a extensão pglogical também precisam ter slots retirados do nó do editor para uma atualização bem-sucedida da versão principal nesse nó. No entanto, você pode reiniciar o processo de replicação a partir do nó do assinante após a atualização. Para obter mais informações, consulte Restabelecer a replicação lógica após uma atualização principal.

  4. Execute um backup.

    O processo de atualização cria um snapshot do cluster de banco de dados durante a atualização. Se você também quiser realizar um backup manual antes do processo de atualização, consulte Criar um snapshot de cluster de banco de dados para obter mais informações.

  5. Atualize determinadas extensões para a versão mais recente disponível antes de executar a atualização da versão principal. As extensões a serem atualizadas incluem as seguintes:

    • pgRouting

    • postgis_raster

    • postgis_tiger_geocoder

    • postgis_topology

    • address_standardizer

    • address_standardizer_data_us

    Execute o comando a seguir para cada extensão instalada.

    ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version'

    Para obter mais informações, consulte Atualizar extensões do PostgreSQL. Para saber mais sobre como fazer upgrade do PostGIS, consulte Etapa 6: Atualize a extensão PostGIS.

  6. Se você estiver atualizando para a versão 11.x, descarte as extensões não compatíveis antes de executar a atualização da versão principal. As extensões a serem descartadas incluem:

    • chkpass

    • tsearch2

  7. Descarte os tipos de dados unknown de acordo com a versão de destino.

    O PostgreSQL versão 10 não dá suporte ao tipo de dados unknown. Se um banco de dados versão 9.6 utilizar o tipo de dados unknown, uma atualização para uma versão 10 exibirá uma mensagem de erro como a seguinte:

    Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: The instance could not be upgraded because the 'unknown' data type is used in user tables. Please remove all usages of the 'unknown' data type and try again."

    Para localizar o tipo de dados unknown no banco de dados a fim de remover coluna incorreta ou alterar para um tipo de dados compatível, use o código SQL a seguir para cada banco de dados.

    SELECT n.nspname, c.relname, a.attname FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a WHERE c.oid = a.attrelid AND NOT a.attisdropped AND a.atttypid = 'pg_catalog.unknown'::pg_catalog.regtype AND c.relkind IN ('r','m','c') AND c.relnamespace = n.oid AND n.nspname !~ '^pg_temp_' AND n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema');
  8. Execute uma simulação de atualização.

    É altamente recomendável testar uma atualização da versão principal em uma cópia do seu banco de dados de produção antes de fazer a atualização no banco de dados de produção. Para criar uma instância de teste duplicada, restaure o banco de dados a partir de um snapshot recente ou clone o banco de dados. Para obter mais informações, consulte Restauração a partir de um snapshot ou Clonar um volume para um cluster de banco de dados do Amazon Aurora.

    Para obter mais informações, consulte Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal.

  9. Atualize sua instância de produção.

    Se a simulação da atualização da versão principal for bem-sucedida, você será capaz de atualizar seu banco de dados de produção com segurança. Para obter mais informações, consulte Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal.

    nota

    Durante o processo de upgrade, o Aurora PostgreSQL gerará um snapshot do cluster de banco de dados se o período de retenção de backup for maior que 0. Não é possível fazer uma restauração a um ponto anterior no tempo do cluster durante esse processo. Posteriormente, você pode fazer uma restauração a um ponto anterior no tempo (para momentos antes da atualização) e depois da conclusão do snapshot automático da sua instância. No entanto, não é possível fazer uma restauração a um ponto anterior no tempo para uma versão secundária anterior.

    Para obter informações sobre uma atualização em andamento, você pode usar o Amazon RDS para visualizar dois logs que são produzidos pelo utilitário pg_upgrade. Esses logs são pg_upgrade_internal.log e pg_upgrade_server.log. O Amazon Aurora acrescenta a data e a hora ao nome de arquivo desses logs. Você pode visualizar esses logs como visualiza qualquer outro log. Para obter mais informações, consulte Monitorar arquivos de log do Amazon Aurora.

  10. Atualizar extensões do PostgreSQL. O processo de atualização do PostgreSQL não atualiza nenhuma extensão do PostgreSQL. Para obter mais informações, consulte Atualizar extensões do PostgreSQL.

Após a conclusão da atualização da versão principal, recomendamos o seguinte:

  • Execute a operação ANALYZE para atualizar a tabela pg_statistic.

  • Se você atualizou para o PostgreSQL versão 10, execute REINDEX em todos os índices de hash que tiver. Os índices de hash foram alterados na versão 10 e devem ser recriados. Para localizar índices de hash inválidos, execute o SQL a seguir para cada banco de dados que contém índices de hash.

    SELECT idx.indrelid::regclass AS table_name, idx.indexrelid::regclass AS index_name FROM pg_catalog.pg_index idx JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid JOIN pg_catalog.pg_am am ON am.oid = cls.relam WHERE am.amname = 'hash' AND NOT idx.indisvalid;
  • Recomendamos testar a aplicação no banco de dados atualizado com uma workload semelhante para verificar se tudo funciona como esperado. Verificada a atualização, é possível excluir essa instância de teste.

Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal

Quando você inicia o processo de atualização para uma nova versão principal, o Aurora PostgreSQL tira um snapshot do cluster de banco de dados do Aurora antes de fazer qualquer alteração no cluster. Esse snapshot é criado apenas para atualizações de versão principal, não para atualizações de versão secundária. Quando o processo de atualização for concluído, você poderá encontrar esse snapshot entre os snapshots manuais listados em Snapshots no console do RDS. O nome do snapshot inclui preupgrade como prefixo, o nome do cluster de banco de dados do Aurora PostgreSQL, a versão de origem, a versão de destino e a data e o carimbo de data e hora, conforme mostrado no exemplo a seguir.

preupgrade-docs-lab-apg-global-db-12-8-to-13-6-2022-05-19-00-19

Após a conclusão da atualização, você poderá usar o snapshot que o Aurora criou e armazenou na sua lista de snapshots manuais para restaurar o cluster de banco de dados para sua versão anterior, se necessário.

dica

Em geral, os snapshots fornecem várias maneiras de restaurar seu cluster de banco de dados do Aurora para vários pontos no tempo. Para saber mais, consulte Restauração de um snapshot de um cluster de banco de dados e Restaurar um cluster de banco de dados para um horário especificado. No entanto, o Aurora PostgreSQL não oferece suporte ao uso de um snapshot para restaurar uma versão secundária anterior.

Durante o processo de atualização da versão principal, o Aurora aloca um volume e clona o cluster de banco de dados Aurora PostgreSQL de origem. Se a atualização falhar por qualquer motivo, o Aurora PostgreSQL usará o clone para reverter a atualização. Depois que mais de 15 clones de um volume de origem são alocados, os clones subsequentes se tornam cópias completas e levam mais tempo. Isso pode fazer com que o processo de atualização demore mais tempo. Se o Aurora PostgreSQL reverter a atualização, lembre-se de que:

  • Você poderá ver entradas de faturamento e métricas do volume original e do volume clonado alocados durante a atualização. O Aurora PostgreSQL limpará o volume extra depois que a janela de retenção do backup do cluster for superior ao tempo da atualização.

  • A próxima cópia do snapshot de região cruzada desse cluster será uma cópia completa em vez de uma cópia incremental.

Para atualizar com segurança as instâncias de banco de dados que compõem o cluster, o Aurora PostgreSQL usa o utilitário pg_upgrade. Após a conclusão da atualização do gravador, cada instância do leitor passa por uma breve interrupção durante a atualização para a nova versão principal. Para saber mais sobre esse utilitário do PostgreSQL, consulte pg_upgrade na documentação do PostgreSQL.

Você pode atualizar o cluster de banco de dados do Aurora PostgreSQL para uma nova versão usando o AWS Management Console, a AWS CLI ou a API do RDS.

Como atualizar a versão do mecanismo de um cluster de banco de dados
  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Databases (Bancos de dados) e o cluster de banco de dados que você deseja atualizar.

  3. Selecione Modify. A página Modify DB cluster (Modificar cluster de banco de dados) é exibida.

  4. Em Engine version (Versão do mecanismo), escolha a nova versão.

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

  6. Para aplicar as alterações imediatamente, escolha Apply immediately. Escolher essa opção pode causar uma interrupção em alguns casos. Para obter mais informações, consulte Modificar um cluster de bancos de dados Amazon Aurora.

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

Para atualizar a versão de mecanismo de um cluster de banco de dados, use o comando modify-db-cluster da AWS CLI. Especifique os seguintes parâmetros:

  • --db-cluster-identifier: o nome do cluster de banco de dados.

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

  • --allow-major-version-upgrade: um sinalizador obrigatório quando o parâmetro --engine-version for uma versão principal diferente da versão principal atual do cluster de banco de dados.

  • --no-apply-immediately: aplica as alterações durante a próxima janela de manutenção. Para aplicar as alterações imediatamente, use --apply-immediately.

exemplo

Para Linux, macOS ou Unix:

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

Para Windows:

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

Para atualizar a versão do mecanismo de um cluster de banco de dados, use a operação ModifyDBCluster. 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.

  • AllowMajorVersionUpgrade: um sinalizador obrigatório quando o parâmetro EngineVersion for uma versão principal diferente da versão principal atual do cluster de banco de dados.

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

Atualizações principais de bancos de dados globais

Para um cluster de banco de dados global do Aurora, o processo de atualização atualiza simultaneamente todos os clusters de banco de dados que compõem seu banco de dados global do Aurora. Ele faz isso para garantir que cada um execute a mesma versão do Aurora PostgreSQL. Isso também garante que todas as alterações nas tabelas do sistema, em formatos de arquivo de dados, etc. sejam replicadas automaticamente para todos os clusters secundários.

Para atualizar um cluster de banco de dados global para uma nova versão principal do Aurora PostgreSQL, recomendamos que você teste suas aplicações na versão atualizada, conforme detalhado em Antes de atualizar o cluster de banco de dados de produção para uma nova versão principal. Prepare as configurações do grupo de parâmetros de cluster de banco de dados e do grupo de parâmetros de banco de dados para cada Região da AWS em seu banco de dados global do Aurora antes da atualização, conforme detalhado em step 1. do Antes de atualizar o cluster de banco de dados de produção para uma nova versão principal.

Se o cluster de banco de dados global do Aurora PostgreSQL tiver um objetivo de ponto de recuperação (RPO) definido para o parâmetro rds.global_db_rpo, redefina o parâmetro antes de atualizar. O processo de atualização da versão principal não funcionará se o RPO estiver ativado. Por padrão, esse parâmetro permanece desativado. Para obter mais informações sobre bancos de dados globais e RPO do Aurora PostgreSQL, consulte Gerenciamento de RPOs para bancos de dados globais baseados em Aurora PostgreSQL–.

Se você confirmar que suas aplicações podem ser executadas conforme o esperado na implantação de avaliação da nova versão, poderá iniciar o processo de atualização. Para fazer isto, consulte Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal. Escolha o item de nível superior na lista Databases (Bancos de dados) no console do RDS, Global database (Banco de dados global), conforme mostrado na imagem a seguir.


                    Imagem do console mostrando um banco de dados global do Aurora, um cluster de banco de dados do Aurora Serverless e outro cluster de banco de dados do Aurora PostgreSQL

Como em qualquer modificação, você pode confirmar que deseja que o processo prossiga quando solicitado.


                    Imagem do console mostrando o prompt para confirmar o processo de atualização de um cluster de banco de dados do Aurora PostgreSQL

Em vez de usar o console, você pode iniciar o processo de atualização usando a AWS CLI ou a API do RDS. Assim como no console, você trabalha no cluster de banco de dados global do Aurora, não em seus componentes, da seguinte forma:

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, bugs e outros problemas que surgem após o lançamento da versão secundária da comunidade não interrompam a estabilidade geral da frota do Aurora PostgreSQL.

À medida que o Aurora PostgreSQL disponibiliza novas versões secundárias, as instâncias que compõem o cluster de banco de dados do Aurora PostgreSQL podem ser atualizadas automaticamente durante a janela de manutenção especificada. Para que isso aconteça, o cluster de banco de dados do Aurora PostgreSQL deve ter a opção Enable auto minor version upgrade (Ativar atualização automática da versão secundária) ativada. Todas as instâncias de banco de dados que compõem o cluster de banco de dados do Aurora PostgreSQL devem ter a opção de atualização automática de versão secundária (AMVU) ativada para que a atualização secundária seja aplicada em todo o cluster.

dica

Verifique se a opção Enable auto minor version upgrade (Ativar atualização automática da versão secundária) está ativada para todas as instâncias de banco de dados do PostgreSQL que compõem seu cluster de banco de dados do Aurora PostgreSQL. Essa opção deve estar ativada para que todas as instâncias no cluster de banco de dados funcionem.

Você pode conferir o valor da opção Enable auto minor version upgrade (Ativar atualização automática 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 com a consulta 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 conforme mostrado pressupõe que você tenha a AWS CLIconfigurada para almejar sua Região da AWS padrão.

Para obter mais informações sobre a opção AMVU e como modificar seu 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.


                Imagem do console mostrando Recommendation (Recomendação) para realizar a atualização para uma versão secundária mais recente.

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 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3 e outras versões posteriores dessas versões secundárias ou 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.

nota

Não há suporte ao ZDP para clusters de banco de dado do Aurora PostgreSQL configurados como bancos de dados globais Aurora Serverless v2, Aurora Serverless v1 ou Aurora.

O ZDP funciona preservando as conexões atuais do cliente com seu cluster de banco de dados Aurora PostgreSQL durante todo o processo de atualização do Aurora PostgreSQL. Se o ZDP for concluído com êxito, as sessões da aplicação serão preservadas, e o mecanismo de banco de dados será reiniciado enquanto a atualização estiver em andamento. Embora o reinício do mecanismo de banco de dados possa causar uma queda 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, se consultas ou transações de longa duração estiverem em andamento, talvez o ZDP precise cancelá-las para ser concluído. Se as instruções DDL (Data Definition Language) estiverem sendo executadas ou se tabelas temporárias ou bloqueios de tabela estiverem em uso por qualquer outro motivo, o ZDP talvez precise cancelar a transação em aberto. Alterações de parâmetros no estado pending no cluster de banco de dados do Aurora PostgreSQL ou em suas instâncias também 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.

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.

Como atualizar o mecanismo de seu cluster de banco de dados do Aurora PostgreSQL
  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Databases (Bancos de dados) e o cluster de banco de dados que você deseja atualizar.

  3. Selecione Modify. A página Modify DB cluster (Modificar cluster de banco de dados) é exibida.

  4. Em Engine version (Versão do mecanismo), escolha a nova versão.

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

  6. Para aplicar as alterações imediatamente, escolha Apply immediately. Escolher essa opção pode causar uma interrupção em alguns casos. Para obter mais informações, consulte Modificar um cluster de bancos de dados Amazon Aurora.

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

Para atualizar a versão do mecanismo de um cluster de banco de dados, use o comando modify-db-cluster 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.

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

Para atualizar a versão do mecanismo de um cluster de banco de dados, use a operação ModifyDBCluster. 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.

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

Atualizar extensões do PostgreSQL

A atualização do cluster de banco de dados do Aurora PostgreSQL para uma nova versão principal não atualiza as extensões do PostgreSQL simultaneamente. Para a maioria das extensões, você atualiza a extensão após a conclusão da atualização da versão principal. No entanto, em alguns casos, você atualiza a extensão antes de atualizar o mecanismo de banco de dados do Aurora PostgreSQL. Para obter mais informações, consulte list of extensions to update em Antes de atualizar o cluster de banco de dados de produção para uma nova versão principal.

A instalação das extensões do PostgreSQL exigem privilégios de rds_superuser. Normalmente, um rds_superuser delega permissões por extensões específicas para usuários relevantes (perfis), para facilitar o gerenciamento de uma determinada extensão. Isso significa que a tarefa de atualizar todas as extensões do cluster de banco de dados do Aurora PostgreSQL pode envolver muitos usuários (perfis) diferentes. Tenha isso em mente principalmente se você quiser automatizar o processo de atualização usando scripts. Para obter mais informações sobre privilégios e funções do PostgreSQL, consulte Segurança com o Amazon Aurora PostgreSQL.

nota

Para obter informações sobre como atualizar a versão da extensão PostGIS, consulte Gerenciar dados espaciais com a extensão PostGIS (Etapa 6: Atualize a extensão PostGIS).

Para atualizar uma extensão após uma atualização de mecanismo, use o comando ALTER EXTENSION UPDATE.

ALTER EXTENSION extension_name UPDATE TO 'new_version';

Para listar as extensões instaladas no momento, use o catálogo pg_extension do PostgreSQL no comando a seguir.

SELECT * FROM pg_extension;

Para visualizar uma lista das versões de extensão específicas disponíveis para a instalação, use a visualização pg_available_extension_versions do PostgreSQL no comando a seguir.

SELECT * FROM pg_available_extension_versions;