Realizar uma atualização da versão principal - Amazon Aurora
Testar um upgrade de cluster de banco de dados para uma nova versão principalRecomendações pós-atualizaçãoAtualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal

Realizar uma atualização da 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 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 Testar um upgrade de 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 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.

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

Para Linux, macOS ou Unix:

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

Para Windows:

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --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.

Testar um upgrade de 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.

      Se você estiver fazendo upgrade do Aurora PostgreSQL versão 10.x com a extensão pg_repack versão 1.4.3 instalada, remova essa extensão antes de fazer upgrade para qualquer versão superior.

  3. Verifique os bancos de dados do modelo 1 e do modelo 0.

    Para uma atualização bem-sucedida, os bancos de dados do modelo 1 e do modelo 0 devem existir e devem ser listados como um modelo. Para conferir isso, use o seguinte comando: 

    SELECT datname, datistemplate FROM pg_database; 
                        
datname    | datistemplate
-----------+---------------
template0  | t
rdsadmin   | f
template1  | t
postgres   | f

    Na saída do comando, o valor datistemplate dos bancos de dados do modelo 1 e do modelo 0 deve ser t.

  4. 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 ter mais informações, consulte Restabelecer a replicação lógica após uma atualização principal.

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

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

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

  8. 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');

  9. 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. Você pode monitorar os planos de execução na instância de teste duplicada para detectar possíveis regressões do plano de execução e avaliar sua performance. 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 ter 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 ter mais informações, consulte Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal.

  10. 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 ter 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 ter mais informações, consulte Monitorar arquivos de log do Amazon Aurora.

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

Recomendações pós-atualização

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. Você deve fazer isso para cada banco de dados em todas as suas instâncias de banco de dados PostgreSQL. As estatísticas do otimizador não são transferidas durante uma atualização de versão principal, portanto, você precisa gerar novamente todas as estatísticas para evitar problemas de performance. Execute o comando sem nenhum parâmetro para gerar estatísticas para todas as tabelas regulares no banco de dados atual da seguinte forma:

    ANALYZE VERBOSE;

    O sinalizador VERBOSE é opcional, mas usá-lo mostra o progresso. Para obter mais informações, consulte ANALYZE na documentação do PostgreSQL.

    nota

    Execute ANALYZE em seu sistema após a atualização para evitar problemas de performance.

  • 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 ter 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 Testar um upgrade de 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 Testar um upgrade de 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 ter 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: