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 atualizações de versões secundárias são compatíveis com as versões secundárias anteriores e posteriores da mesma versão principal. No entanto, as principais atualizações de versão principal contêm alterações no banco de dados que não são compatíveis com versões anteriores das aplicações existentes. Essas 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 log 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 registro pg\ _upgrade\ _precheck.log. No entanto, 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 dois logs: pg\ _upgrade\ _internal.log e pg\ _upgrade\ _server.log. O Amazon RDS anexa um carimbo de data/hora ao nome do arquivo desses logs. Visualize 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.

A atualização leva muito tempo

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 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 sistema operacional, a atualização demorará mais.

Se sua instância do RDS estiver em uma implantação Multi-AZ, a manutenção do sistema operacional resultará em um failover. Quando você configura sua instância no 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 se 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 para sua instância de banco de dados Aurora. Ou execute o seguinte comando describe-pending-maintenance-actions da AWS Command Line Interface (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. Se você receber erros ao executar comandos da AWS CLI, consulte Solucionar erros da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

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 da atualização

É uma prática recomendada criar um snapshot da instância de banco de dados RDS ou do cluster de banco de dados Aurora antes de atualizar a versão. Se você já ativou os backups da sua instância, o Amazon RDS cria automaticamente um snapshot como parte do processo de upgrade. Com um snapshot, você reduz 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 principal, 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. Você experimenta uma interrupção 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 sofre uma interrupção à medida que pg_upgrade a atualiza para a nova versão principal. Observe que, 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 consulta de longa duração, use pg\ _cancel\ _backend ou pg\ _terminate\ _backend para finalizar a consulta. Para obter mais informações sobre essas funções, consulte 9.28.2. Funções de sinalização do servidor.

Verifique se você tem capacidade computacional suficiente

O utilitário pg\ _upgrade pode exigir muita computação. É uma prática recomendada realizar um upgrade de execução seca antes de atualizar seus bancos de dados de produção para verificar se você tem capacidade computacional ou de memória suficiente. A atualização de execução a seco também verifica se você pode encontrar erros de pré-verificação ou atualização. Você pode restaurar um snapshot da instância de produção e realizar uma execução seca com a mesma classe de instância do banco de dados de produção.

Falha na 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 Há transações preparadas não confirmadas no arquivo pg\ _upgrade.log. Confirme ou reverta todas as transações abertas preparadas antes de iniciar uma atualização.

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

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

Certifique-se de usar um tipo de dado compatível

Você só pode 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 processador 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 receber o seguinte 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.”

Os slots de replicação lógica geralmente são usados para a migração do AWS Database Migration Service (AMS DMS). Eles também são usados 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ão em uso para verificar se você pode 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 até poder excluir os slots de replicação lógica.

Se você não precisar dos slots de replicação lógica, execute as seguintes consultas 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á o seguinte 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á o seguinte 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 de parâmetros incompatíveis 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 desses 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á um erro no arquivo pg\ _upgrade.log semelhante ao exemplo a seguir:

“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 um problema 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 da installed_version for menor que o valor da default_version, você deverá atualizar o PostGIS para a versão padrão. Para atualizar sua extensão, execute a seguinte consulta:

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á problemas nas visualizações causados por uma alteração no catálogo do sistema da versão de destino

As colunas em determinadas visualizações variam em diferentes versões do PostgreSQL. Por exemplo, você pode receber um erro semelhante ao seguinte exemplo:

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

Nos logs, você pode receber um erro semelhante ao 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’. “

Neste exemplo, o erro ocorre porque a estrutura do catálogo pg\ _constraint foi alterada 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: É uma prática recomendada usar o pgdump para fazer backup de suas visualizações ou capturar a definição da visualização antes de descartá-la. Ao descartar uma visualização, você precisa recriá-la manualmente após a atualização da versão. Talvez seja necessário trabalhar com o database administrator.

Depois de fazer o upgrade

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