Como soluciono problemas de atualizações de versões principais no Amazon RDS para PostgreSQL e no Aurora para PostgreSQL?

Breve descrição

Quando o Amazon RDS oferece suporte a uma nova versão de um mecanismo de banco de dados, você pode atualizar suas instâncias de banco de dados para essa nova versão. É possível executar um upgrade de versão secundária ou um upgrade de versão principal para instâncias de banco de dados.

As atualizações de versões secundárias são usadas para corrigir vulnerabilidades de segurança e resolver bugs. Geralmente, essas atualizações não adicionam novas funcionalidades e não alteram o formato do armazenamento interno. Elas são sempre compatíveis com as versões secundárias anteriores e posteriores da mesma versão principal. No entanto, as atualizações de versões principais contêm alterações no banco de dados que não são compatíveis com as versões anteriores das aplicações existentes. Essas atualizações podem alterar o formato interno das tabelas do sistema, de arquivos de dados e do armazenamento de dados. O Amazon RDS usa o utilitário pg_upgrade do PostgreSQL para realizar atualizações de versões principais.

Durante uma atualização da versão principal de uma instância do PostgreSQL, o Amazon RDS executa um procedimento de pré-verificação. Esse procedimento identifica quaisquer problemas que possam causar falhas na atualização. 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 pré-verificação com falha. Para obter mais informações sobre o processo de pré-verificação de todos os bancos de dados, consulte o log da atualização pg_upgrade_precheck.log. O Amazon RDS acrescenta a data e o horário ao nome do arquivo. Os eventos do RDS também podem fornecer os motivos da falha de atualização. Porém, para problemas específicos do mecanismo, você deve verificar os arquivos de log do banco de dados.

Para obter mais informações, consulte Como visualizar e listar arquivos de log do banco de dados para o RDS para PostgreSQL. Ou consulte Como visualizar e listar arquivos de log do banco de dados para o Aurora para PostgreSQL.

Durante uma atualização da versão principal, o RDS conclui as etapas:

1. Criação de um snapshot da instância antes da atualização. Isso acontecerá somente se você definir o período de retenção de backup da sua instância de banco de dados como um número maior que zero.
2. Encerra a instância.
3. Use o utilitário pg_upgrade para executar o trabalho de upgrade na instância.
4. Cria um snapshot da instância após o upgrade.

Resolução

Embora o Amazon RDS gerencie essas atualizações, você pode encontrar os seguintes problemas durante uma atualização de versão:

• A atualização leva mais tempo.
• A atualização falha.

A atualização leva muito tempo

Atividades de manutenção pendentes: todas as atividades de manutenção pendentes são aplicadas automaticamente com as atualizações de versão do mecanismo. Isso pode incluir a aplicação de um patch para o sistema operacional em sua instância do RDS. Nesse caso, o patch para o sistema operacional é aplicado primeiro e, em seguida, a versão do mecanismo é atualizada. Portanto, realizar atividades de manutenção do sistema operacional resulta no aumento do tempo necessário para concluir a atualização.

Além disso, 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 backup dessa instância geralmente é criado na instância secundária. No caso de failover, um backup é criado em uma nova instância secundária após o upgrade. Esse backup na nova instância secundária pode não ser o backup mais recente. Portanto, um backup completo pode ser ativado no lugar de um backup incremental. A criação de um backup completo pode demorar muito tempo, especialmente se o banco de dados for muito grande.

Para evitar esse problema, procure atividades de manutenção pendentes na seção Pending maintenance (Manutenção pendente) no console do RDS. Para o Aurora para PostgreSQL, consulte Visualização de manutenção pendente.

Ou use o 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: conclua essas atividades de manutenção antes de realizar as atualizações de versão do mecanismo de banco de dados.

Nenhum snapshot foi criado antes da atualização: é uma prática recomendada criar um snapshot do cluster do RDS ou do Aurora para PostgreSQL antes de realizar a atualização. Caso você já tenha ativado backups para sua instância, um snapshot será criado automaticamente como parte do processo de atualização. A criação de um snapshot antes da atualização reduz o tempo necessário para a conclusão do processo de atualização. Isso ocorre porque, nesse caso, somente um backup incremental é criado durante o processo de atualização.

Atualizações de réplicas de leitura do RDS para PostgreSQL: quando você executa uma atualização da versão principal da sua instância de banco de dados primária, todas as réplicas de leitura na mesma região são atualizadas automaticamente. Após o início do fluxo de trabalho de atualização, as réplicas de leitura aguardam até 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 primária aguarda a conclusão das atualizações de réplica de leitura. Haverá uma interrupção até que todas as atualizações sejam concluídas. Se o período de inatividade da atualização for limitado, você poderá promover ou descartar sua instância de réplica. Em seguida, realize a recriação das réplicas de leitura após a conclusão da atualização.

Para atualizar com segurança as instâncias de banco de dados que compõem seu cluster, o Aurora para 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 enquanto é atualizada para a nova versão principal.

Transações de longa duração ou alta workload antes da atualização: transações de longa duração ou alta workload antes da atualização podem aumentar o tempo necessário para o desligamento do banco de dados, aumentando o tempo de atualização.

Execute essa consulta para identificar transações de longa duração:

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;

Capacidade computacional insuficiente: o utilitário pg_upgrade pode requerer uso intensivo de computação. Portanto, é uma prática recomendada executar uma simulação da atualização antes de atualizar seus bancos de dados de produção. Você pode restaurar um snapshot da instância de produção e executar uma simulação com a mesma classe da instância do banco de dados de produção.

Falha no upgrade

Classes de instância de banco de dados sem suporte: o upgrade poderá falhar 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 upgrade. Certifique-se de verificar a compatibilidade da classe da instância com a versão do mecanismo. Para obter mais informações, consulte os mecanismos de banco de dados compatíveis com as classes de instâncias de banco de dados para o RDS para PostgreSQL. Ou consulte os mecanismos de banco de dados compatíveis com as classes de instâncias de banco de dados para o Aurora para PostgreSQL.

Transações preparadas em aberto: as transações preparadas que estão em aberto no banco de dados podem causar falhas de atualização. Certifique-se de confirmar ou reverter todas as transações preparadas em aberto antes de iniciar uma atualização.

Execute esta consulta para verificar se há transações preparadas em aberto em sua instância:

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

Nesse caso, o erro no arquivo pg_upgrade.log é semelhante a este:

------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with 
the requested major engine version upgrade and try the upgrade again.

*There are uncommitted prepared transactions. Please commit or rollback 
all prepared transactions.*

Tipos de dados sem suporte: a atualização falhará com um erro se você tentar atualizar o banco de dados com tipos de dados sem suporte, como os seguintes:

• regcollation
• regconfig
• regdictionary
• regnamespace
• regoper
• regoperator
• regproc
• regprocedure

Observação: há suporte para os tipos de dados regclass, regrole e regtype.

O utilitário de atualização pg_upgrade do PostgreSQL não oferece suporte à atualização de bancos de dados que incluem colunas de tabela usando os tipos de dados do sistema de referência ao OID reg*. Remova todos os usos de tipos de dados reg*, exceto regclass, regrole e regtype, antes de tentar uma atualização.

Execute esta consulta para verificar o uso de tipos de dados reg* sem suporte:

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

Slots de replicação lógica: uma atualização não poderá ocorrer se sua instância tiver slots de replicação lógica. Geralmente, os slots de replicação lógica 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 destinos. Antes de atualizar, certifique-se de conhecer a finalidade dos slots de replicação lógica que estão em uso e confirme se eles podem ser excluídos.

Se os slots de replicação lógica ainda estiverem sendo usados, você não deverá excluí-los. Nesse caso, você não poderá prosseguir com a atualização.

O erro relacionado no arquivo de log pg_upgrade é semelhante a este exemplo:

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

Se os slots de replicação lógica não forem necessários, execute estas consultas para excluí-los:

SELECT * FROM pg_replication_slots;

SELECT pg_drop_replication_slot(slot_name);

Problemas de armazenamento: enquanto o script pg_upgrade é executado, a instância pode ficar sem espaço. Isso faz com que o script falhe e você veja uma mensagem de erro semelhante a esta:

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 livre suficiente antes de iniciar a atualização.

Tipos de dados desconhecidos: as versões 10 e posteriores do PostgreSQL não oferecem suporte a tipos de dados unknown. Se um banco de dados PostgreSQL versão 9.6 usar o tipo de dados unknown, uma atualização para a versão 10 mostrará uma mensagem de erro como esta:

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

Esta é uma limitação do PostgreSQL e a automação do RDS não modifica colunas usando o tipo de dados unknown. Poderá ser necessário modificar essas colunas manualmente antes da atualização.

Execute esta consulta para localizar colunas em seu banco de dados com o tipo de dados unknown:

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

Depois de identificar as colunas, você poderá removê-las ou modificá-las para um tipo de dados compatível.

Falha na atualização da réplica de leitura (somente no RDS para PostgreSQL): se a instância do PostgreSQL tiver réplicas de leitura, as falhas na atualização da réplica de leitura poderão causar paralisação da atualização de sua instância primária. A falha na atualização da réplica de leitura também pode resultar em falha da atualização da instância primária. Uma réplica de leitura com falha é colocada no estado incompatible-restore e a replicação é interrompida na instância de banco de dados.

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

• A réplica de leitura não acompanha a atualização da instância de banco de dados primária mesmo após o tempo de espera.
• A réplica de leitura está em um estado de ciclo de vida terminal ou incompatível, como armazenamento cheio ou incompatible-restore.
• Quando a atualização da instância de banco de dados primária é iniciada, uma atualização da versão secundária separada está em execução 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 da instância primária.

Nome de usuário principal incorreto: se o nome de usuário principal começar com “pg_”, a atualização falhará e a seguinte mensagem de erro será exibida:

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. Você pode entrar em contato com o AWS Support para atualizar esse usuário como o novo usuário principal.

Erro de parâmetro incompatível: esse erro ocorrerá se um parâmetro relacionado à memória, como shared_buffer ou work_memory, for definido como um valor superior. Isso pode fazer com que o script de atualização falhe. Para corrigir o problema, reduza os valores desses parâmetros e tente executar a atualização novamente.

Extensões não atualizadas antes da atualização: uma atualização da versão principal não atualiza nenhuma extensão do PostgreSQL. Se você não atualizou as extensões antes de realizar uma atualização da versão principal, verá este erro no arquivo pg_upgrade.log:

The Logs indicates that the RDS instance ''xxxx'' 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.

Essa mensagem de erro indica um problema com a extensão PostGIS.

Execute esta consulta para verificar as versões padrões e instaladas do PostGIS e suas extensões dependentes:

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

Se o valor para a installed_version for menor que o da default_version, você deverá atualizar o PostGIS para a versão padrão. Para fazer isso, execute esta consulta:

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Para obter mais informações, consulte Atualizar extensões do PostgreSQL para o RDS para PostgreSQL ou Atualizar extensões do PostgreSQL para o Aurora PostgreSQL.

Problema nos modos de exibição devido a alterações no catálogo do sistema da versão de destino: as colunas em determinados modos de exibição variam em diferentes versões do PostgreSQL.

Por exemplo, você pode ver uma mensagem de erro como esta:

PreUpgrade checks failed: The instance could not be upgraded because one or more databases have views or materialized views which depend on 'pg_stat_activity'. Please drop them and try again.

Este erro ocorre quando você atualiza o banco de dados da versão 9.5 para a 9.6. Esse erro é causado devido à exibição pg_stat_activity porque a coluna em waiting é substituída pelas colunas wait_event_type e wait_event na versão 9.6.

pg_restore: from TOC entry xxx; xxx xxxx 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".

Este erro ocorre porque a estrutura do catálogo pg_constraint foi alterada na versão 12 do PostgreSQL.

Você pode resolver esses problemas descartando os modos de exibição com base nos catálogos do sistema da versão de destino.

Observação: tenha cuidado ao descartar esses modos de exibição. Certifique-se de consultar seu DBA.

Outras considerações

• O utilitário pg_upgrade produz dois logs: pg_upgrade_internal.log e pg_upgrade_server.log. O Amazon RDS acrescenta a data e a hora ao nome de 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 Monitorar arquivos de log do Amazon RDS para o RDS para PostgreSQL ou Monitorar arquivos de log do Amazon Aurora para o Aurora para PostgreSQL.
• Quando a atualização estiver concluída, atualize a tabela pg_statistics executando ANALYZE em todos os bancos de dados do usuário. Um upgrade principal não move o conteúdo da tabela pg_statistics para a nova versão. Ignorar essa etapa pode resultar em consultas lentas.
• Se você atualizou para a versão 10 do PostgreSQL, execute REINDEX em quaisquer índices de hash que você tenha. Os índices de hash foram alterados na versão 10 e devem ser recompilados. Para localizar índices de hash inválidos, execute este SQL 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;

---

Informações relacionadas

Visão geral do upgrade do PostgreSQL

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