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

Resolução

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 Monitoramento de arquivos de log do Amazon RDS ou Monitoramento de arquivos de registro do Amazon Aurora.

Atualizações de longa duração

Verifique se há atividades de manutenção pendentes

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

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 atualização porque o Amazon RDS só precisa criar um backup incremental como parte da atualização.

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 da atualização for pequena, promova ou descarte sua instância de réplica e recrie as réplicas 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, haverá requisitos e processos adicionais.

Resolva transações de longa duração ou de alto workload antes da atualização

Transações de longa duração ou de alto workload 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 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 verificar se você tem capacidade de computação ou de memória suficiente, é 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ância de banco de dados 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 Amazon Aurora.

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:

"A instância não pôde ser atualizada porque um ou mais bancos de dados têm slots de replicação lógica. Elimine todos os slots de replicação lógica e tente novamente."

Você costuma usar slots de replicação lógica para a migração 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 alvos. 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)] Erro ao PROCESSAR TOC: pg\ _restore:\ [archiver (db)] não pôde executar a consulta: ERRO: não foi possível criar o arquivo “base/12345/12345678”: Nenhuma palavra-chave de espaço “deixada no dispositivo”

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:

"A instância não pôde ser atualizada porque o tipo de dados ‘desconhecido’ é usado nas tabelas de usuários. Remova todos os usos do tipo de dados ’desconhecido’ e tente novamente. “

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á uma 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 restauração incompatível 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 armazenamento cheio ou restauração incompatível.
• 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, recrie uma nova réplica de leitura com base na instância primária atualizada após a atualização.

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:

"As verificações de pré-atualização falharam: A instância não pôde ser atualizada porque um ou mais nomes de função começam com ’pg\ _’. Renomeie todas as funções com nomes que comecem com ’pg\ _’ e tente novamente”.

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 novamente a atualização.

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, receberá a mensagem de erro no arquivo pg_upgrade.log semelhante ao seguinte:

"Os logs indicam que a instância do RDS "abcd" tem uma versão mais antiga da extensão PostGIS ou de suas extensões dependentes (endereço\ _standardizer, endereço\ _standardizer\ _data\ _us, postgis\ _tiger\ _geocoder, postgis\ _topology, postgis\ _raster) instaladas em relação à versão atual necessária para a atualização. "

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 AND
name 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 RDS para PostgreSQL ou Atualização de clusters de banco de dados Amazon Aurora PostgreSQL.

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

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

"As verificações de pré-atualização falharam: A instância não pôde ser atualizada porque um ou mais bancos de dados têm visualizações ou visualizações materializadas que dependem de ’pg\ _stat\ _activity’. Solte-os e tente novamente. “

Esse erro ocorre quando você atualiza o banco de dados da versão 9.5 para 9.6. No exemplo anterior de mensagem de erro, a visualização pg\ _stat\ _activity está causando o problema. Na versão 9.6, o PostgreSQL substituiu a coluna de espera pelas colunas wait\ _event\ _type e wait\ _event.

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

"pg\ _restore: da entrada do TOC abc; abc abcd VIEW sys\ _user\ _constraints art pg\ _restore: erro: não foi possível executar a consulta: ERRO: a coluna c.consrc não existe LINHA 18: “c”. “consrc” COMO “search\ _condition”, ^ DICA: Talvez você quisesse fazer referência à coluna ‘c.conkey’ ou à coluna ‘c.conbin’. "

O exemplo de mensagem de erro anterior mostra que o erro ocorreu porque a estrutura do catálogo pg_constraint mudou na versão 12 do PostgreSQL.

Para resolver esses problemas, elimine as visualizações com base 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.

Conclusão da atualização

Depois que a atualização for concluída, execute ANALYZE em todos os bancos de dados do usuário para atualizar a tabela pg_statistics. Uma grande atualização não move o conteúdo da tabela pg\ _statistics para a nova versão. Se você não mover o conteúdo, poderá encontrar consultas de execução lenta.

Informações relacionadas

Visão geral dos processos de upgrade do Aurora PostgreSQL