Como atualizar a versão principal do RDS para PostgreSQL

Recomendamos o seguinte processo ao realizar uma atualização de versão principal em um banco de dados do Amazon RDS para PostgreSQL:

Tenha um grupo de parâmetros compatível com a versão pronto para uso – Se você estiver usando um grupo de parâmetros personalizado, terá duas opções. Você pode especificar um grupo de parâmetros padrão para a nova versão do mecanismo de banco de dados. Ou você pode criar seu próprio grupo de parâmetros personalizado para a nova versão do mecanismo de banco de dados. Para ter mais informações, consulte Grupos de parâmetros para Amazon RDS e Trabalhar com grupos de parâmetros de clusters de banco de dados multi-AZ.
Verifique se há classes de banco de dados não compatíveis: confirme se a classe de instância do banco de dados é compatível com a versão do PostgreSQL para a qual você está atualizando. Para ter mais informações, consulte Mecanismos de banco de dados compatíveis para classes de instância de banco de dados.

Verifique o uso sem suporte:

Transações preparadas – 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 já abertas no banco de dados.
```
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
```

Tipos de dados reg* – 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 não pode persistir esse tipo de dados, que é usado pelo Amazon RDS para fazer a atuailzação.

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

Verifique se há bancos de dados inválidos:
- Garanta que não haja bancos de dados inválidos. A coluna datconnlimit no catálogo pg_database inclui um valor de -2 para marcar como inválidos bancos de dados que foram interrompidos durante uma operação DROP DATABASE.
  
  Use a seguinte consulta para verificar se há bancos de dados inválidos:
```
SELECT datname FROM pg_database WHERE datconnlimit = - 2;
```
- A consulta anterior retorna nomes de banco de dados inválidos. É possível usar DROP DATABASE invalid_db_name; para descartar bancos de dados inválidos. Também é possível usar o seguinte comando para descartar bancos de dados inválidos:
```
SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec
```
Consulte mais informações sobre bancos de dados inválidos em Noções básicas sobre o comportamento do autovacuum com bancos de dados inválidos.
Gerencie os slots de replicação lógica: a atualização não será possível se a instância tiver algum slot de replicação lógica. Os slots de replicação lógica são normalmente usados para migração do AWS DMS e para replicar tabelas do banco de dados para data lakes, ferramentas de BI e outros destinos. Antes de atualizar, certifique-se de saber a finalidade de qualquer slot de replicação lógica que esteja em uso e confirme se não há problema em excluí-los. 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.

Se os slots de replicação lógica não forem necessários, você poderá excluí-los usando o seguinte SQL:
```
SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);
```
As configurações de replicação lógica que usam a extensão pglogical também precisam ter slots descartados para uma atualização bem-sucedida da versão principal. Para obter informações sobre como identificar e descartar slots criados utilizando a extensão pglogical, consulte Gerenciar slots de replicação lógica para RDS para PostgreSQL.
Gerencie as réplicas de leitura: a atualização de uma implantação de instância de banco de dados single-AZ ou multi-AZ também atualiza as réplicas de leitura na região e a instância de banco de dados primária. O Amazon RDS não atualiza réplicas de leitura de clusters de banco de dados multi-AZ.

Não é possível atualizar as réplicas de leitura separadamente. Se fosse possível, isso poderia levar a situações em que os bancos de dados primário e de réplica têm diferentes versões principais do PostgreSQL. Contudo, as atualizações de réplicas de leitura podem aumentar o tempo de inatividade da instância de banco de dados primária. Para impedir uma atualização de réplica de leitura, promova a réplica para uma instância independente ou exclua-a antes de iniciar o processo de atualização.

O processo de atualização recria o grupo de parâmetros da réplica de leitura com base no grupo de parâmetros atual da réplica de leitura. Você só pode aplicar um grupo de parâmetros personalizado a uma réplica de leitura após a conclusão da atualização modificando a réplica de leitura. Para obter mais informações sobre réplicas de leitura, consulte Trabalhar com réplicas de leitura do Amazon RDS para PostgreSQL.
Faça um backup – recomendamos que você faça um backup antes de atualizar a versão principal. Assim, você terá um ponto de restauração conhecido para seu banco de dados. Se o período de retenção de backup for maior que 0, o processo de atualização criará snapshots do banco de dados antes e depois da atualização. Para alterar o período de retenção de backup, consulte Modificar uma instância de banco de dados do Amazon RDS e Modificar um cluster de banco de dados multi-AZ para o Amazon RDS.

Para realizar um backup manualmente, consulte Criar um snapshot de banco de dados para uma instância de banco de dados single-AZ para o Amazon RDS e Criar um snapshot do cluster de banco de dados multi-AZ para o Amazon RDS.
Atualizar determinadas extensões antes de uma atualização da versão principal: se você planeja ignorar uma versão principal com a atualização, é necessário atualizar determinadas extensões antes de executar a atualização da versão principal. Por exemplo, fazer upgrade das versões 9.5.x ou 9.6.x para uma versão 11.x ignora uma versão principal. As extensões a serem atualizadas incluem PostGIS e extensões relacionadas para processamento de dados espaciais.
- address_standardizer
- address_standardizer_data_us
- postgis_raster
- postgis_tiger_geocoder
- postgis_topology
Execute o comando a seguir para cada extensão que você está usando:
```
ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
```
Para ter mais informações, consulte Atualizar extensões do PostgreSQL em bancos de dados do RDS para PostgreSQL. Para saber mais sobre como fazer upgrade do PostGIS, consulte Etapa 6: Atualize a extensão PostGIS.
Descartar determinadas extensões antes da atualização da versão principal – uma atualização que avança de uma versão principal para a versão 11.x não é compatível com a atualização da extensão pgRouting. O upgrade das versões 9.4.x, 9.5.x ou 9.6.x para as versões 11.x ignora uma versão principal. É seguro descartar a extensão pgRouting e reinstalá-la em uma versão compatível após a atualização. Para obter versões de extensão para as quais você pode atualizar, consulte Versões de extensões do PostgreSQL compatíveis.

As extensões tsearch2 e chkpass não são mais compatíveis com o PostgreSQL versões 11 ou posterior. Se você estiver atualizando para a versão 11.x, descarte as extensões tsearch2 e chkpass antes da atualização.
Libere os tipos de dados desconhecidos – libere os tipos de dados unknown dependendo da versão de destino.

O PostgreSQL versão 10 descontinuou o suporte para tipos de dados unknown. Se um banco de dados da 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 para remover a coluna incorreta ou para alterar para um tipo de dados compatível, use o seguinte SQL:
```
SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
```
Realizar uma simulação – é altamente recomendável testar uma atualização da versão principal em uma cópia do 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 no banco de dados de teste duplicado para detectar possíveis regressões do plano de execução e avaliar a performance. Para criar uma instância de teste duplicada, restaure o banco de dados a partir de um snapshot recente ou faça uma restauração point-in-time para o último momento restaurável.

Para obter mais informações, consulte Restauração a partir de um snapshot ou Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS. Para clusters de banco de dados multi-AZ, consulte Restaurar a partir de um snapshot para cluster de banco de dados multi-AZ ou Restaurar um cluster de banco de dados multi-AZ para um horário especificado.

Para obter detalhes sobre como realizar a atualização, consulte Atualizar manualmente a versão do mecanismo.

Ao atualizar um banco de dados versão 9.6 para a versão 10, esteja ciente de que o PostgreSQL 10 habilita consultas paralelas por padrão. Teste o impacto do paralelismo antes da atualização alterando o parâmetro max_parallel_workers_per_gather no banco de dados de teste para 2.

nota
O valor padrão para o parâmetro max_parallel_workers_per_gather no grupo de parâmetros de banco de dados default.postgresql10 é 2.

Para obter mais informações, consulte o tópico sobre Parallel Query na documentação do PostgreSQL. Para desabilitar o paralelismo na versão 10, defina o parâmetro max_parallel_workers_per_gather para 0.

Durante a atualização da versão principal, os bancos de dados public e template1 e o esquema de public em cada banco de dados são renomeados temporariamente. Esses objetos aparecerão nos logs com o nome original e uma string aleatória anexada. A string é anexada para que as configurações personalizadas, como locale e owner, sejam preservadas durante a atualização da versão principal. Quando a atualização for concluída, os objetos serão renomeados de volta com seus nomes originais.

nota
Durante o processo de atualização da versão principal, não é possível fazer uma restauração para um ponto no tempo da instância de banco de dados ou do cluster de banco de dados multi-AZ. Depois que o Amazon RDS realizar a atualização, ele usará um backup automático do banco de dados. Você pode fazer uma restauração para um ponto no tempo anterior à atualização e posterior ao backup automático do banco de dados.
Se uma atualização falhar com erros de procedimento de pré-verificação, resolva os problemas – durante o processo de atualização da versão principal, o Amazon RDS para PostgreSQL executa primeiro um procedimento de pré-verificação para identificar quaisquer problemas que possam causar falha na atualização. O procedimento de pré-verificação verifica todas as possíveis condições incompatíveis em todos os bancos de dados da instância.

Se a pré-verificação encontrar um problema, ele criará um evento de log indicando que a pré-verificação da atualização falhou Os detalhes do processo de pré-verificação estão em um log de atualização chamado pg_upgrade_precheck.log para todos os bancos de dados de um banco de dados. O Amazon RDS acrescenta a data e a hora ao nome de arquivo. Para obter mais informações sobre como visualizar logs, consulte Monitorar arquivos de log do Amazon RDS.

Se uma atualização de réplica de leitura falhar na pré-verificação, a replicação na réplica de leitura com falha será interrompida e a réplica de leitura ficará com estado de encerrada. Exclua a réplica de leitura e recrie uma nova com base na instância de banco de dados primária atualizada.

Resolva todos os problemas identificados no log de pré-verificação e tente fazer a atualização da versão principal novamente. Veja a seguir um exemplo de log de pré-verificação.
```
------------------------------------------------------------------------
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.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.

* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].

* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.
```
Se uma atualização de réplica de leitura falhar durante a atualização do banco de dados, resolva o problema. Uma réplica de leitura com falha será colocada no estado incompatible-restore e a replicação será encerrada no banco de dados. Exclua a réplica de leitura e recrie uma nova com base na instância de banco de dados primária atualizada.

nota
O Amazon RDS não atualiza réplicas de leitura para clusters de banco de dados multi-AZ. Se você realizar uma atualização de versão principal em um cluster de banco de dados multi-AZ, o estado da replicação das réplicas de leitura mudará para Encerrado.

Uma atualização de réplica de leitura pode falhar pelos seguintes motivos:
- Não foi possível acompanhar a instância de banco de dados primária, mesmo após a espera.
- Ela estava em um estado de ciclo de vida incompatível ou terminal, como armazenamento esgotado, restauração incompatível e assim por diante.
- Quando a atualização da instância de banco de dados primária foi iniciada, havia uma atualização de versão secundária separada em execução na réplica de leitura.
- A réplica de leitura usou parâmetros incompatíveis.
- A réplica de leitura não pôde se comunicar com a instância de banco de dados primária para sincronizar a pasta de dados.
Atualize o banco de dados de produção: quando a simulação da atualização da versão principal é realizada com êxito, você pode atualizar o banco de dados de produção com segurança. Para ter mais informações, consulte Atualizar manualmente a versão do mecanismo.
Execute a operação ANALYZE para atualizar a tabela pg_statistic. Você deve fazer isso para cada banco de dados em todos os bancos de dados do 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.

Após a conclusão da atualização da versão principal, recomendamos o seguinte:

Uma atualização do PostgreSQL não atualiza nenhuma extensão do PostgreSQL. Para atualizar extensões, consulte Atualizar extensões do PostgreSQL em bancos de dados do RDS para PostgreSQL.
Como opção, use o Amazon RDS para visualizar dois logs que o utilitário pg_upgrade produz. Esses logs são pg_upgrade_internal.log e pg_upgrade_server.log. O Amazon RDS acrescenta a data e a hora ao nome de arquivo desses logs. Você pode visualizar esses logs como visualiza qualquer outro log. Para obter mais informações, consulte Monitorar arquivos de log do Amazon RDS.

Você também pode fazer upload dos logs de atualização para o Amazon CloudWatch Logs. Para obter mais informações, consulte Publicação de logs do PostgreSQL no Amazon CloudWatch Logs.
Para verificar se tudo funciona como esperado, teste o aplicativo no banco de dados atualizado com uma workload semelhante. Verificada a atualização, é possível excluir essa instância de teste.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Escolher uma atualização de versão principal

Atualizações automáticas da versão secundária

Como atualizar a versão principal do RDS para PostgreSQL

nota

nota

nota

nota