Como soluciono problemas com as principais atualizações de versão no Amazon RDS para PostgreSQL ou compatíveis com Aurora PostgreSQL?

Breve descrição

As principais atualizações de versão contêm alterações no banco de dados que não são compatíveis com versões anteriores das aplicações existentes. As atualizações podem alterar o formato interno das tabelas do sistema, dos arquivos de dados e do armazenamento de dados. O Amazon RDS usa pg_upgrade para realizar atualizações de versões principais. Para obter mais informações, consulte pg\ _upgrade no site do PostgreSQL.

Durante uma atualização de versão principal, o Amazon RDS executa um procedimento de pré-verificação que identifica problemas que podem fazer com que a atualização falhe. Ele verifica possíveis condições incompatíveis em todos os bancos de dados. Se o Amazon RDS identificar um problema durante o processo de pré-verificação, ele criará um evento de logs para a falha na pré-verificação. Os eventos de logs incluem o nome do arquivo, o carimbo de data/hora e os motivos da falha na atualização. Para obter informações sobre o processo de pré-verificação de todos os bancos de dados, consulte o log pg_upgrade_precheck.log. Para problemas específicos do mecanismo, você deve verificar os arquivos de log do banco de dados do Amazon RDS para PostgreSQL ou do Aurora compatível com PostgreSQL.

Resolução

Se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), consulte Solução de erros da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

O utilitário pg_upgrade que executa as principais atualizações de versão produz os logs pg_upgrade_internal.log e pg_upgrade_server.log. O Amazon RDS anexa um carimbo de data/hora ao nome do arquivo dos logs. Analise esses logs para obter mais informações sobre os problemas e erros encontrados durante a atualização. Para obter mais informações, consulte Monitorar arquivos de log do Amazon RDS ou Monitorar arquivos de registro do Amazon Aurora.

Atualizações de longa duração

Verifique se há atividades de manutenção pendentes

O Amazon RDS usa automaticamente as atualizações da versão do mecanismo para aplicar atividades de manutenção pendentes, como um patch de sistema operacional (SO) em sua instância do Amazon RDS. O Amazon RDS aplica primeiro a atividade pendente e depois atualiza a versão do mecanismo. Se o Amazon RDS precisar realizar atividades de manutenção do SO, a atualização demorará mais.

Se sua instância do Amazon RDS estiver em uma implantação multi-AZ, a manutenção do SO resultará em um failover. Quando você configura sua instância em um ambiente multi-AZ, o Amazon RDS normalmente cria o backup da instância na instância secundária. Em um failover, o Amazon RDS cria um backup em uma nova instância secundária após a atualização. Esse backup na nova instância secundária pode não ser o backup mais recente, então o Amazon RDS conclui um backup completo em vez de um backup incremental. Um backup completo pode levar muito tempo, especialmente quando o banco de dados for grande.

Para evitar esse problema, procure atividades de manutenção pendentes para sua instância de banco de dados RDS ou sua instância de banco de dados Aurora. Ou execute o seguinte comando describe-pending-maintenance-actions da AWS CLI em sua instância:

aws rds describe-pending-maintenance-actions --resource-identifier example-arn

Observação: substitua example-arn pelo ARN da sua instância de banco de dados.

Conclua as atividades de manutenção pendentes antes de realizar as atualizações da versão do mecanismo de banco de dados.

Crie um snapshot antes de atualizar

Antes de atualizar a versão, uma prática recomendada é criar um snapshot da instância de banco de dados RDS ou do cluster de banco de dados Aurora. Se você já ativou os backups da sua instância, o Amazon RDS cria automaticamente um snapshot como parte do processo de upgrade. Os snapshots reduzem o tempo do processo de upgrade porque o Amazon RDS só precisa criar um backup incremental para o upgrade.

Aguarde a atualização da réplica de leitura

Quando você realiza uma atualização de versão principal da sua instância de banco de dados primária, o Amazon RDS atualiza automaticamente todas as réplicas de leitura na mesma região da AWS. Após o início do fluxo de trabalho de upgrade, as réplicas de leitura aguardam que pg_upgrade seja concluído com êxito na instância de banco de dados primária. Em seguida, a atualização da instância de banco de dados primária aguarda a conclusão das atualizações da réplica de leitura. A instância de banco de dados é encerrada até que todas as atualizações sejam concluídas. Se a janela de tempo de inatividade para o upgrade for pequena, promova ou descarte sua instância de réplica. Então, recrie as réplica de leitura após a conclusão da atualização.

Para clusters de banco de dados Aurora, pg_upgrade atualiza primeiro a instância do gravador. Em seguida, cada instância de banco de dados do leitor é desativada quando pg_upgrade a atualiza para a nova versão principal.

Observação: se você atualizar um banco de dados global do Aurora, deverá seguir requisitos e processos adicionais.

Resolva transações de longa duração ou de workloads altas antes da atualização

Transações de longa duração ou de workloads altas podem aumentar o tempo que o Amazon RDS leva para desligar o banco de dados e atualizar o mecanismo de banco de dados.

Para identificar transações de longa duração, execute a seguinte consulta:

SQL>SELECT pid, datname, application_name, state, age(query_start, clock_timestamp()), usename, query
FROM pg_stat_activity
WHERE query NOT ILIKE '%pg_stat_activity%' AND
usename!='rdsadmin'
ORDER BY query_start desc;

Se você identificar uma transação de longa duração, use pg_cancel_backend ou pg_terminate_backend para finalizar a transação. Para obter mais informações sobre pg_cancel_backend e pg_terminate_backend, consulte Server signaling functions (Funções de sinalização do servidor) no site do PostgreSQL.

Verifique se você tem capacidade computacional suficiente

O utilitário pg_upgrade pode exigir muita computação. Para conferir a capacidade de computação, memória e armazenamento livre, uma prática recomendada é realizar uma atualização de teste antes de atualizar seus bancos de dados de produção. A atualização de teste também verifica se você pode encontrar erros de pré-verificação ou atualização. É possível restaurar o snapshot da instância de produção e realizar um teste com a mesma classe de instância da classe de instância do banco de dados de produção.

Falhas de atualização

Verifique se há classes de instâncias de banco de dados e versões de mecanismos não suportadas

Se a classe de instância da sua instância de banco de dados não for compatível com a versão do PostgreSQL para a qual você está fazendo o upgrade, a atualização falhará. Verifique a compatibilidade da versão do mecanismo com a classe de instância para Amazon RDS ou Aurora.

Para verificar as versões do mecanismo que são compatíveis com a atualização da versão do mecanismo, execute o seguinte comando do describe-db-engine-versions:

aws rds describe-db-engine-versions --engine postgres --engine-version your-version --query "DBEngineVersions[].ValidUpgradeTarget[].{EngineVersion:EngineVersion}" --output text

**Observação:**substitua your-version pela versão do mecanismo.

Se sua versão atual não for compatível, uma prática recomendada é atualizar para a versão secundária mais recente. Ou você pode fazer o upgrade para uma das outras versões de upgrade disponíveis. Para obter informações sobre atualizações de versão do mecanismo, consulte Escolher uma versão principal para uma atualização do RDS para PostgreSQL.

Verifique se há transações abertas e preparadas

Se houver transações abertas preparadas no banco de dados, a atualização falhará. Você recebe o erro "There are uncommitted prepared transactions" no arquivo pg_upgrade.log. Antes de iniciar a atualização, confirme ou reverta todas as transações abertas preparadas.

Para verificar se há transações abertas preparadas em sua instância, execute a seguinte consulta:

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

Usar um tipo de dados compatível

Só é possível atualizar a versão para os tipos de dados regclass, regrole e regtype. O utilitário pg_upgrade não pode atualizar bancos de dados que incluem colunas de tabela que usam os tipos de referência do identificador de objeto (OID) reg*. Se você usar um tipo de dados regcollation, regconfig, regdictionary, regnamespace, regoper, regoperator, regproc ou regprocedure, a atualização falhará.

Para resolver esse problema, remova todos os usos dos tipos de dados reg*, exceto regclass, regrole e regtype, antes de atualizar o mecanismo de dados. Para verificar se há tipos de dados reg* não suportados em suas tabelas, execute a consulta a seguir:

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

Verifique se há slots de replicação lógica

Se sua instância tiver slots de replicação lógica, não é possível atualizar a instância e você recebe a seguinte mensagem erro no arquivo pg\ _upgrade.log:

"The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again."

Você costuma usar slots de replicação lógica para as migrações do AWS Database Migration Service (AMS DMS). Além disso, você os usa para replicar tabelas de bancos de dados para data lakes, ferramentas de business intelligence e outros destinos. Certifique-se de saber a finalidade dos slots de replicação lógica que está usando para verificar se é possível excluí-los. Se os slots de replicação lógica estiverem em uso, não os exclua. Você deve esperar para atualizar a versão antes de ser possível excluir os slots de replicação lógica.

Se você não precisar dos slots de replicação lógica, execute os seguintes comandos para excluí-los:

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);

Observação: substitua o slot_name pelo nome do slot de replicação lógica.

Verifique se há problemas de armazenamento

Se a instância ficar sem espaço quando o script pg_upgrade for executado, a atualização falhará e você receberá a seguinte mensagem de erro:

"pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] could not execute query: ERROR: could not create file "base/12345/12345678": No space keyword" left on device"

Para resolver esse problema, certifique-se de que a instância tenha armazenamento gratuito suficiente antes de iniciar a atualização.

Verifique se há tipos de dados desconhecidos

Não é possível usar tipos de dados desconhecidos nas versões 10 e posteriores do PostgreSQL. Por exemplo, se um banco de dados PostgreSQL versão 9.6 usar o tipo de dados desconhecido, você receberá a seguinte mensagem de erro ao atualizar para a versão 10:

"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 resolver esse problema, remova manualmente as colunas que usam o tipo de dados desconhecido ou modifique-as para um tipo de dados compatível.

Para encontrar as colunas em seu banco de dados que usam o tipo de dados desconhecido, execute a seguinte consulta:

SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

(Somente RDS para PostgreSQL) Verifique se há alguma falha na atualização da réplica de leitura

Se a instância do PostgreSQL tiver réplicas de leitura, as falhas no upgrade da réplica de leitura podem fazer com que a atualização da instância primária fique paralisada ou falhe. O Amazon RDS define uma réplica de leitura com falha no estado de incompatible-restore e, em seguida, interrompe a replicação na instância de banco de dados.

Uma atualização de réplica de leitura pode falhar por um dos seguintes motivos:

• A réplica de leitura não consegue alcançar a instância de banco de dados primária mesmo após o tempo de espera.
• A réplica de leitura está em um estado terminal ou de ciclo de vida incompatível, como storage-full ou incompatible-restore.
• Quando a atualização da instância de banco de dados primária começa, uma atualização de versão secundária separada é executada na réplica de leitura.
• A réplica de leitura usa parâmetros incompatíveis.
• A réplica de leitura não consegue se comunicar com a instância de banco de dados primária para sincronizar a pasta de dados.

Para resolver esse problema, exclua a réplica de leitura. Em seguida, crie uma nova réplica de leitura com base na instância primária atualizada após o upgrade.

Certifique-se de que seu nome de usuário principal esteja correto

Se o nome de usuário principal começar com pg_, a atualização falhará e você receberá a seguinte mensagem de erro:

"PreUpgrade checks failed: The instance could not be upgraded because one or more role names start with 'pg_'. Please rename all roles with names that start with 'pg_' and try again."

Para resolver esse problema, crie outro usuário com a função rds_superuser que não comece com pg_.

Verifique se há parâmetros incompatíveis

O erro "incompatible parameters" ocorre quando o valor de um parâmetro relacionado à memória, como shared_buffer ou work_memory, é muito alto para sua configuração. Esse erro faz com que o script de atualização falhe. Para resolver o problema, reduza os valores dos parâmetros e execute o upgrade novamente.

Atualize suas extensões antes de fazer o upgrade

As principais atualizações de versão não atualizam as extensões do PostgreSQL. Se você não atualizar as extensões antes de uma atualização de versão principal, poderá receber a seguinte mensagem de erro no arquivo pg_upgrade.log:

"The Logs indicates that the RDS instance ''abcd'' has older version of PostGIS extension or its dependent extensions (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) installed as against the current version required for the upgrade."

O exemplo de erro anterior mostra uma mensagem de erro com a extensão PostGIS. Para resolver esse problema, execute a consulta a seguir para verificar as versões padrão e instaladas do PostGIS e suas extensões dependentes:

SELECT name, default_version, installed_versionFROM pg_available_extensions WHERE installed_version IS NOT NULL ANDname LIKE 'postgis%' OR name LIKE 'address%';

Observação: substitua postgis% pela sua extensão.

Se o valor de installed_version for menor que o valor de default_version, você deverá atualizar o PostGIS para a versão padrão. Para atualizar sua extensão, execute o seguinte comando:

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Observação: substitua default_version_number pelo valor default_version.

Para obter mais informações, consulte Atualizações do mecanismo de banco de dados do RDS para PostgreSQL ou Como atualizar os clusters de banco de dados de Amazon Aurora MySQL.

Verifique se há alterações no catálogo do sistema da versão que causem problemas nas visualizações

As colunas em determinadas visualizações variam entre as diferentes versões do PostgreSQL. Por exemplo, você poderá receber uma mensagem de erro semelhante à seguinte:

"pg_restore: error: could not execute query: ERROR: column reference 'backend_type' is ambiguous"

Esse erro ocorre quando você tenta atualizar o banco de dados da versão 12.x para 13.x, e pg_stat_activity tem estruturas diferentes nas versões 12.x e 13.x.

Para solucionar esse problema, conclua as etapas a seguir:

1. Execute o comando a seguir para consultar a definição da visualização:

   SELECT pg_get_viewdef('pg_stat_activity_allusers', true);

2. Execute o comando a seguir para eliminar a visualização:

   DROP VIEW pg_stat_activity_allusers;

3. Atualize a versão do mecanismo.

4. Execute o comando a seguir para recriar a visualização:

   CREATE VIEW pg_stat_activity_allusers AS SELECT * FROM get_sa();
   GRANT SELECT ON pg_stat_activity_allusers TO public;

Ou você pode receber uma mensagem de erro semelhante à seguinte:

"pg_restore: from TOC entry abc; abc abcd VIEW sys_user_constraints art pg_restore: error: could not execute query: ERROR: column c.consrc does not exist LINE 18: 'c'.'consrc' AS 'search_condition', ^ HINT: Perhaps you meant to reference the column 'c.conkey' or the column 'c.conbin'."

Esse erro ocorre quando a estrutura do catálogo pg_constraint é alterada na versão 12 do PostgreSQL.

Para resolver esse problema, remova as visualizações baseadas nos catálogos do sistema da versão de destino.

Importante: antes de descartar as visualizações, é uma prática recomendada usar o pgdump para fazer backup das suas visualizações ou capturar a definição delas. Quando você descarta uma visualização, você ou o administrador do banco de dados devem recriá-la manualmente após a atualização da versão.

Verifique se há tabelas externas com um valor de pré-busca

Use a extensão oracle_fdw para pré-buscar entre 0 e 10.240 linhas dos bancos de dados Oracle. Defina parâmetro prefetch na cláusula OPTIONS da tabela externa. Valores mais altos melhoram o desempenho, mas usam mais memória no servidor PostgreSQL. Para reduzir o uso de memória, uma prática recomendada é definir prefetch durante a fase de pré-verificação de uma atualização de versão principal.

Se o valor de prefetch for maior que 1.000, você poderá receber a seguinte mensagem de erro:

"pg_restore: error: could not execute query: ERROR: invalid value for option 'prefetch'"

**Observação:**Os valores válidos nesse contexto são números inteiros entre 0 e 1000.

Para resolver o problema, defina os valores de prefetch entre 1 e 1.000 em todas as tabelas externas e, em seguida, repita o upgrade.

Para alterar as tabelas externas, execute o seguinte comando:

ALTER FOREIGN TABLE dwh_ddl_sync.fdw_all_tab_cols OPTIONS (SET prefetch '999');

Para listar todas as tabelas externas, execute o seguinte comando:

SELECT * from information_schema.foreign_tables;

Para verificar o valor de prefetch das tabelas, execute o seguinte comando:

SELECT * FROM pg_foreign_table;

**Verifique se você atualizou seu cluster Babelfish para Aurora compatível com PostgreSQL **

Ao realizar uma atualização importante da versão do mecanismo em um cluster Babelfish para Aurora compatível com PostgreSQL, você pode receber uma mensagem de erro semelhante à seguinte:

"You can't perform a multi major version upgrade on a Babelfish for Aurora PostgreSQL DB cluster 13.20 and lower versions."

Para resolver esse problema, atualize o cluster para uma versão que ofereça suporte à atualização da versão principal e, em seguida, atualize para a próxima versão principal.

Conclusão da atualização

Depois que a atualização for concluída, execute o comando ANALYZE em todos os bancos de dados do usuário para atualizar a tabela pg_statistics. As principais atualizações de versão não migram o conteúdo da tabela pg_statistics para a nova versão. Se você não migrar o conteúdo, poderá encontrar consultas de execução lenta.

Informações relacionadas

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

Best practices for upgrading Amazon RDS to major and minor versions of PostgreSQL