# Amazon RDS para PostgreSQL
O Amazon RDS oferece suporte a instâncias de banco de dados executando várias versões do PostgreSQL. Para obter uma lista das versões disponíveis, consulte [Versões disponíveis do banco de dados PostgreSQL](PostgreSQL.Concepts.General.DBVersions.md).
Você pode criar instâncias de banco de dados e snapshot de banco de dados, além de restaurações e backup pontuais. As instâncias de banco de dados que executam o PostgreSQL oferecem suporte a implantações multi-AZ, réplicas de leitura, IOPS provisionadas e podem ser criadas dentro de uma nuvem privada virtual (VPC). Você também pode usar o Secure Socket Layer (SSL) para conectar-se a uma instância de banco de dados executando PostgreSQL.
Antes de criar uma instância de banco de dados, conclua as etapas em [Configuração do ambiente do Amazon RDS](CHAP_SettingUp.md).
Você pode usar qualquer aplicação cliente padrão SQL para executar comandos para a instância no computador do cliente. Dentre essas aplicações, estão pgAdmin, uma ferramenta popular de administração e de desenvolvimento de código aberto para PostgreSQL, ou o psql, um utilitário de linha de comando que faz parte da instalação do PostgreSQL. Para oferecer uma experiência de serviço gerenciada, o Amazon RDS não fornece acesso ao host para as instâncias de banco de dados. Ele também restringe o acesso a determinados procedimentos e tabelas do sistema que exigem privilégios avançados. O Amazon RDS oferece suporte a acesso a bancos de dados em uma instância de banco de dados que usa qualquer aplicação cliente SQL padrão. O Amazon RDS não permite o acesso direto do host a uma instância de banco de dados usando Telnet ou Secure Shell (SSH).
O Amazon RDS para PostgreSQL é compatível com vários padrões do setor. Por exemplo, você pode usar os bancos de dados do Amazon RDS para PostgreSQL para criar aplicativos em conformidade com a HIPAA e para armazenar informações relacionadas à saúde. Isso inclui o armazenamento de informações de saúde protegidas sob um Business Associate Agreement (BAA – Acordo de Associação Comercial) concluído com a AWS. O Amazon RDS para PostgreSQL também atende aos requisitos de segurança do Federal Risk and Authorization Management Program (FedRAMP). O Amazon RDS para PostgreSQL recebeu uma autoridade provisória da Joint Authorization Board (JAB) da FedRAMP para operar (P-ATO) na linha de base ALTA da FedRAMP nas regiões da AWS GovCloud (US). Para obter mais informações sobre padrões de conformidade com suporte, consulte [Conformidade da nuvem AWS](https://aws.amazon.com/compliance/).
Para importar os dados PostgreSQL em uma instância de banco de dados, siga as informações na seção [Como importar dados no PostgreSQL do Amazon RDS](PostgreSQL.Procedural.Importing.md).
**Importante**
Se você encontrar algum problema com a instância de banco de dados do RDS para PostgreSQL, o atendente do AWS Support poderá precisar de mais informações sobre a integridade dos bancos de dados. O objetivo é garantir que o AWS Support receba as informações necessárias o mais rápido possível.
É possível usar o PG Collector para ajudar a reunir informações valiosas do banco de dados em um arquivo HTML consolidado. Para ter mais informações sobre o PG Collector, como executá-lo e como baixar o relatório HTML, consulte [PG Collector](https://github.com/awslabs/pg-collector).
Após a conclusão bem-sucedida e salvo indicação em contrário, o script exibe a saída em um formato HTML legível. O script foi projetado para excluir desse HTML quaisquer dados ou detalhes de segurança que possam comprometer sua empresa. Ele também não faz modificações no banco de dados ou no ambiente. No entanto, se houver informações no HTML que você não se sinta confortável para compartilhar, fique à vontade para removê-las antes de fazer upload do HTML. Quando o HTML estiver aceitável, faça upload dele utilizando a seção de anexos nos detalhes do caso de suporte.
**Topics**
+ [
# Tarefas comuns de gerenciamento do Amazon RDS para PostgreSQL
](CHAP_PostgreSQL.CommonTasks.md)
+ [
# Trabalhar com o ambiente de visualização de banco de dados
](working-with-the-database-preview-environment.md)
+ [
# Versões disponíveis do banco de dados PostgreSQL
](PostgreSQL.Concepts.General.DBVersions.md)
+ [
# Conceitos básicos sobre o processo de lançamento incremental do RDS para PostgreSQL
](PostgreSQL.Concepts.General.ReleaseProcess.md)
+ [
# Versões de extensões do PostgreSQL compatíveis
](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md)
+ [
# Trabalhar com recursos do PostgreSQL compatíveis com o Amazon RDS para PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.md)
+ [
# Conectar a uma instância de banco de dados executando o mecanismo de banco de dados do PostgreSQL
](USER_ConnectToPostgreSQLInstance.md)
+ [
# Proteger conexões com o RDS para PostgreSQL com SSL/TLS
](PostgreSQL.Concepts.General.Security.md)
+ [
# Usar a autenticação Kerberos com o Amazon RDS para PostgreSQL
](postgresql-kerberos.md)
+ [
# Usar um servidor DNS personalizado para acesso à rede de saída
](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
+ [
# Atualizações do mecanismo de banco de dados do RDS para PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.md)
+ [
# Atualizar uma versão do mecanismo de snapshot de banco de dados PostgreSQL
](USER_UpgradeDBSnapshot.PostgreSQL.md)
+ [
# Trabalhar com réplicas de leitura do Amazon RDS para PostgreSQL
](USER_PostgreSQL.Replication.ReadReplicas.md)
+ [
# Melhorar a performance das consultas para o RDS para PostgreSQL com leituras otimizadas pelo Amazon RDS
](USER_PostgreSQL.optimizedreads.md)
+ [
# Como importar dados no PostgreSQL do Amazon RDS
](PostgreSQL.Procedural.Importing.md)
+ [
# Exportar dados de uma instância de banco de dados do RDS para PostgreSQL para o Amazon S3
](postgresql-s3-export.md)
+ [
# Invocar uma função do AWS Lambda de uma instância de bancos de dados PostgreSQL do RDS
](PostgreSQL-Lambda.md)
+ [
# Tarefas comuns de DBA do Amazon RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.md)
+ [
# Ajustar com eventos de espera do RDS para PostgreSQL
](PostgreSQL.Tuning.md)
+ [
# Ajustar o RDS para PostgreSQL com insights proativos do Amazon DevOps Guru
](PostgreSQL.Tuning_proactive_insights.md)
+ [
# Usar extensões PostgreSQL com o Amazon RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Extensions.md)
+ [
# Trabalhar com os invólucros de dados externos compatíveis do Amazon RDS for PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)
+ [
# Trabalhar com Trusted Language Extensions para PostgreSQL
](PostgreSQL_trusted_language_extension.md)
# Tarefas comuns de gerenciamento do Amazon RDS para PostgreSQL
Estas são tarefas de gerenciamento comuns que você executa com uma instância de banco de dados do Amazon RDS para PostgreSQL, com links para documentação relevante de cada tarefa.
| Área de tarefa | Documentação relevante |
| --- | --- |
| **Configuração do Amazon RDS para o primeiro uso** Antes de criar sua instância de banco de dados, certifique-se de concluir alguns pré-requisitos. Por exemplo, as instâncias de banco de dados são criadas por padrão com um firewall que impede acessá-las. Então é necessário criar um grupo de segurança com os endereços IP corretos e uma configuração de rede para acessar a instância de banco de dados. | [Configuração do ambiente do Amazon RDS](CHAP_SettingUp.md) |
| **Noções básicas sobre instâncias de banco de dados do Amazon RDS** Se você estiver criando uma instância de banco de dados para fins de produção, deve entender como classes de instâncias, tipos de armazenamento e IOPS provisionadas funcionam no Amazon RDS. | [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md) [Tipos de armazenamento do Amazon RDS](CHAP_Storage.md#Concepts.Storage) [Armazenamento SSD de IOPS provisionadas](CHAP_Storage.md#USER_PIOPS) |
| **Encontrar versões disponíveis do PostgreSQL** O Amazon RDS oferece suporte a várias versões do PostgreSQL. | [Versões disponíveis do banco de dados PostgreSQL](PostgreSQL.Concepts.General.DBVersions.md) |
| **Configuração do suporte à alta disponibilidade e failover** Uma instância de banco de dados de produção deve usar implantações multi-AZ. As implantações multi-AZ oferecem maior disponibilidade, durabilidade de dados e tolerância a falhas para instâncias de banco de dados. | [Configurar e gerenciar uma implantação multi-AZ para o Amazon RDS](Concepts.MultiAZ.md) |
| **Noções básicas sobre a rede da Amazon Virtual Private Cloud (VPC** Se a sua conta AWS tiver uma VPC padrão, a instância de banco de dados será criada automaticamente dentro da VPC padrão. Em alguns casos, sua conta pode não ter uma VPC padrão e você pode querer uma instância de banco de dados em uma VPC. Nesses casos, crie a VPC e os grupos de sub-redes antes de criar a instância de banco de dados. | [Trabalhar com uma instância de banco de dados em uma VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md) |
| **Importar dados para o PostgreSQL do Amazon RDS** Você pode usar várias ferramentas diferentes para importar os dados para sua instância de banco de dados PostgreSQL no Amazon RDS. | [Como importar dados no PostgreSQL do Amazon RDS](PostgreSQL.Procedural.Importing.md) |
| **Configurar réplicas de leitura somente leitura (primárias e em espera)** O RDS para PostgreSQL oferece suporte às réplicas de leitura na mesma região da AWS e em uma região da AWS diferente da instância primária. | [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md) [Trabalhar com réplicas de leitura do Amazon RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md) [Criar uma réplica de leitura em uma diferente Região da AWS](USER_ReadRepl.XRgn.md) |
| **Noções básicas sobre grupos de segurança** Por padrão, as instâncias de banco de dados são criadas com um firewall que impede o acesso a elas. Para fornecer acesso por meio desse firewall, você edita as regras de entrada do grupo de segurança de VPC associado à VPC que hospeda a instância de banco de dados. | [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md) |
| **Configuração de grupos de parâmetros e recursos** Para alterar os parâmetros padrão para sua instância de banco de dados, crie um grupo de parâmetros de banco de dados personalizado e altere as configurações dele. Se você fizer isso antes de criar sua instância de banco de dados, é possível escolher seu grupo de parâmetros de banco de dados personalizado ao criar a instância. | [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md) |
| **Conectar à instância de banco de dados PostgreSQL** Após criar um grupo de segurança e associá-lo a uma instância de banco de dados, você poderá se conectar à instância de banco de dados usando qualquer aplicação de cliente SQL padrão, como `psql` ou `pgAdmin`. | [Conectar a uma instância de banco de dados executando o mecanismo de banco de dados do PostgreSQL](USER_ConnectToPostgreSQLInstance.md) [Usar o SSL com uma instância de banco de dados PostgreSQL](PostgreSQL.Concepts.General.SSL.md) |
| **Backup e restauração da instância de banco de dados** Você pode configurar a instância de banco de dados para fazer backups automáticos ou snapshots manuais e, depois, restaurar instâncias a partir dos backups ou snapshots. | [Backup, restauração e exportação de dados](CHAP_CommonTasks.BackupRestore.md) |
| **Monitorar atividades e da performance da instância de banco de dados** Monitore uma instância de banco de dados PostgreSQL usando as métricas, eventos e o monitoramento avançado do Amazon RDS do CloudWatch. | [Visualizar métricas no console do Amazon RDS](USER_Monitoring.md) [Visualizar eventos do Amazon RDS](USER_ListEvents.md) |
| **Atualização da versão do banco de dados PostgreSQL** Você pode fazer atualizações das versões principal e secundária para sua instância de banco de dados PostgreSQL. | [Atualizações do mecanismo de banco de dados do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md) [Escolher uma versão principal para uma atualização do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md) |
| **Trabalhar com arquivos de log** Você pode acessar os arquivos de log de sua instância de banco de dados PostgreSQL. | [Arquivos de log do banco de dados RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md) |
| **Noções básicas sobre as práticas recomendadas para instâncias de banco de dados PostgreSQL** Encontre algumas de práticas recomendadas para trabalhar com o PostgreSQL no Amazon RDS. | [Práticas recomendadas para trabalhar com PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL) |
Veja a seguir uma lista de outras seções deste guia que podem ajudar você a entender e usar recursos importantes do RDS para PostgreSQL:
+ [Noções básicas de perfis e permissões do PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Controlar o acesso de usuários ao banco de dados PostgreSQLControlar o acesso de usuários ao PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Trabalhar com parâmetros na instância de banco de dados do RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
+ [Entender os mecanismos de registro compatíveis com o RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Trabalhar com o autovacuum do PostgreSQL no Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Usar um servidor DNS personalizado para acesso à rede de saída](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
# Trabalhar com o ambiente de visualização de banco de dados
A comunidade do PostgreSQL lança novas versões e novas extensões do PostgreSQL continuamente. Isso dá aos usuários do PostgreSQL a oportunidade de experimentar uma nova versão do PostgreSQL mais cedo. Para saber mais sobre o processo de lançamento beta da comunidade do PostgreSQL, consulte [Beta Information](https://www.postgresql.org/developer/beta/) (Informações sobre a versão beta) na documentação do PostgreSQL. Da mesma forma, o Amazon RDS disponibiliza determinadas versões beta do PostgreSQL como versões prévias. Isso permite que você crie instâncias de banco de dados usando a versão prévia e teste seus recursos no ambiente de visualização do banco de dados.
As instâncias de banco de dados do RDS para PostgreSQL no Database Preview Environment são semelhantes às outras instâncias do RDS para PostgreSQL em termos de funcionalidade. No entanto, você não pode usar uma versão prévia para produção.
Lembre-se das seguintes limitações importantes:
+ Todas as instâncias de banco de dados são excluídas 60 dias após serem criadas, juntamente com backups e snapshots.
+ Só é possível criar uma instância de banco de dados em uma virtual private cloud (VPC) com base no serviço da Amazon VPC.
+ Você só pode usar o SSD de uso geral e o armazenamento em SSD IOPS provisionadas.
+ Você não pode obter ajuda do AWS Support com instâncias de banco de dados. Em vez disso, você pode postar suas perguntas na comunidade de perguntas e respostas gerenciadas do AWS, [AWSre:Post](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service).
+ Não é possível copiar um snapshot de uma instância de banco de dados para um ambiente de produção.
As opções a seguir são compatíveis com a visualização.
+ Você só pode criar instâncias de banco de dados com o uso dos tipos M6i, R6i, M6g, M5, T3, R6g e R5. Para obter mais informações sobre as classes de instância do RDS, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md).
+ Você pode usar implantações single-AZ e multi-AZ.
+ Você pode usar funções padrão de despejo e carregamento do PostgreSQL para exportar ou importar bancos de dados para o Database Preview Environment.
**Topics**
+ [
## Atributos não compatíveis com o ambiente de visualização de banco de dados
](#preview-environment-exclusions)
+ [
## PostgreSQL versão 17 no Ambiente de Pré-visualização do Banco de Dados
](#PostgreSQL.Concepts.General.version17)
+ [
# Criar uma nova instância de banco de dados no ambiente de visualização de banco de dados
](create-db-instance-in-preview-environment.md)
## Atributos não compatíveis com o ambiente de visualização de banco de dados
Os atributos a seguir não estão disponíveis no ambiente de visualização de banco de dados:
+ Cópia de snapshots entre regiões
+ Réplicas de leitura entre regiões
## PostgreSQL versão 17 no Ambiente de Pré-visualização do Banco de Dados
**nota**
Esta é a documentação prévia do Amazon RDS PostgreSQL versão 17. Está sujeita a alteração.
O PostgreSQL versão 17.0 já está disponível no Ambiente de Pré-visualização do Banco de Dados do Amazon RDS. O PostgreSQL versão 17.0 contém várias melhorias que estão descritas na seguinte documentação do PostgreSQL: [PostgreSQL 17 Released\$1](https://www.postgresql.org/docs/17/release-17.html)
Para obter informações sobre o ambiente de visualização de banco de dados, consulte [Trabalhar com o ambiente de visualização de banco de dados](#working-with-the-database-preview-environment). Para acessar o ambiente de visualização do console, selecione [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/).
# Criar uma nova instância de banco de dados no ambiente de visualização de banco de dados
Use o procedimento a seguir para criar uma instância de banco de dados no ambiente de visualização.
**Para criar uma instância de banco de dados no ambiente de visualização de banco de dados**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha **Dashboard** (Painel) no painel de navegação.
1. Na página Dashboard (Painel), localize a seção **Database Preview Environment** (Ambiente de visualização do banco de dados) na página Dashboard (Painel), conforme mostrado na imagem a seguir.
![\[Seção de visualização do ambiente com link exibido no console do RDS, painel\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
Você também pode navegar diretamente para o [Ambiente de visualização do banco de dados](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#). Antes de continuar, você deve reconhecer e aceitar as limitações.
![\[Caixa de diálogo Preview environment limitations (Limitações do ambiente de visualização)\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. Para criar a instância de banco de dados do RDS para PostgreSQL, siga o mesmo processo de criação de qualquer instância de banco de dados do Amazon RDS. Para obter mais informações, consulte o procedimento [Console](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) em [Criar uma instância de banco de dados](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
Para criar uma instância no ambiente de visualização do banco de dados usando a API do RDS ou a AWS CLI, use o endpoint a seguir.
```
rds-preview.us-east-2.amazonaws.com
```
# Versões disponíveis do banco de dados PostgreSQL
O Amazon RDS oferece suporte a instâncias de banco de dados executando várias edições do PostgreSQL. Você pode especificar qualquer versão do PostgreSQL disponível atualmente ao criar uma nova instância de banco de dados. Você pode especificar a versão principal (como o PostgreSQL 14) e qualquer versão secundária disponível para a versão principal especificada. Se nenhuma versão for especificada, o Amazon RDS usará uma versão disponível por padrão, geralmente a versão mais recente. Se uma versão principal for especificada, mas uma versão secundária não, o Amazon RDS usará por padrão um lançamento recente da versão principal que você especificou.
Para ver uma lista de versões disponíveis, bem como os padrões para instâncias de banco de dados recém-criadas, use o comando da AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html). Por exemplo, para exibir a versão padrão do mecanismo PostgreSQL, use o seguinte comando:
```
aws rds describe-db-engine-versions --default-only --engine postgres
```
Para obter detalhes sobre as versões do PostgreSQL compatíveis com o Amazon RDS, consulte [*“Amazon RDS for PostgreSQL Release Notes”* (Notas de lançamento do Amazon RDS para PostgreSQL)](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html). Você também pode visualizar informações sobre datas de suporte para as versões principais do mecanismo executando o comando [describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html)AWS CLI ou usando a operação de API [DescribeDBMajorEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) do RDS.
Se ainda não estiver tudo pronto para fazer upgrade manualmente para uma nova versão do mecanismo principal antes da data de término do suporte padrão do RDS, o Amazon RDS inscreverá automaticamente seus bancos de dados no Suporte estendido do Amazon RDS após a data de término do suporte padrão do RDS. Assim, você poderá continuar executando o RDS para PostgreSQL versão 11 e posterior. Para obter mais informações, consulte [Suporte estendido do Amazon RDS com Amazon RDS](extended-support.md) e [Preço do Amazon RDS](https://aws.amazon.com/rds/pricing/).
## Versões obsoletas do Amazon RDS for PostgreSQL
Observe as seguintes versões obsoletas:
+ O RDS para PostgreSQL 10 foi descontinuado em fevereiro de 2023.
+ O RDS para PostgreSQL 9.6 foi descontinuado em março de 2022.
+ O RDS para PostgreSQL 9.5 foi descontinuado em março de 2021.
Para saber mais sobre a política de descontinuação do RDS para PostgreSQL, consulte [Perguntas frequentes sobre o Amazon RDS](https://aws.amazon.com/rds/faqs/). Para obter mais informações sobre as versões do PostgreSQL, consulte [Versionamento de política](https://www.postgresql.org/support/versioning/) na documentação do PostgreSQL.
# Conceitos básicos sobre o processo de lançamento incremental do RDS para PostgreSQL
O RDS para PostgreSQL oferece correções de segurança, melhorias de performance e novos recursos por meio de versões incrementais, mantendo a compatibilidade com versões secundárias. Essas versões são rotuladas como R1, R2, R3 e assim por diante.
**Convenção de nomenclatura de versões de lançamento**
+ R1 é a versão inicial de uma versão secundária. Ocasionalmente, ela inclui novos recursos, extensões ou atualizações de extensões existentes.
+ As versões de lançamento subsequentes (R2, R3 e posteriores) incluem:
+ Atualizações de segurança
+ Melhorias de performance
+ Correções de erros
+ Atualizações de extensão
## Vantagens do processo de lançamento incremental do RDS para PostgreSQL.
O processo de lançamento incremental oferece as seguintes vantagens:
+ Adoção rápida de novas versões da comunidade do PostgreSQL e, ao mesmo tempo, gerenciamento separado dos aprimoramentos específicos do RDS por meio de versões subsequentes. Isso simplifica o processo de lançamento e garante a entrega mais rápida de atualizações essenciais.
+ Acesso a correções de bugs, novos recursos e atualizações de segurança e de extensões, mantendo a compatibilidade com a versão secundária do PostgreSQL.
## Gerenciamento de atualizações de versão
O Amazon RDS notifica você sobre novos lançamentos incrementais por meio de ações de manutenção pendentes no Console de gerenciamento da AWS. Você pode atualizar o banco de dados usando um destes métodos:
+ Habilite atualizações automáticas durante as janelas de manutenção programada.
+ Aplique atualizações manualmente por meio de ações de manutenção pendentes.
+ Use implantações azul/verde com replicação física para minimizar o tempo de inatividade. Para obter mais informações, consulte [Implantações azul/verde do Amazon RDS oferecem suporte à atualização de versões secundárias do RDS para PostgreSQL](https://aws.amazon.com/about-aws/whats-new/2024/11/rds-blue-green-deployments-upgrade-rds-postgresql/).
Antes de atualizar o banco de dados, considere os seguintes pontos principais:
+ É necessário reinicializar o banco de dados para fazer atualizações, a menos que você use implantações azul/verde com replicação física.
+ Algumas versões incrementais são obrigatórias, particularmente aquelas que incluem correções de segurança.
Para obter mais informações sobre como atualizar sua instância de banco de dados do Amazon RDS, consulte [Extensões confiáveis do PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted) e [apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/rds/apply-pending-maintenance-action.html).
# Versões de extensões do PostgreSQL compatíveis
O RDS para PostgreSQL é compatível com várias extensões do PostgreSQL. A comunidade PostgreSQL às vezes se refere a elas como módulos. Extensões expandem a funcionalidade fornecida pelo mecanismo PostgreSQL. Você pode encontrar uma lista de extensões às quais o Amazon RDS oferece suporte no grupo de parâmetros de banco de dados padrão para essa versão do PostgreSQL. Você também pode ver a lista de extensões atuais que usam o `psql` exibindo o parâmetro `rds.extensions` conforme o exemplo a seguir.
```
SHOW rds.extensions;
```
**nota**
Os parâmetros adicionados em uma versão secundária podem ser exibidos incorretamente ao usar o parâmetro `rds.extensions` em `psql`.
A partir do RDS para PostgreSQL 13, determinadas extensões podem ser instaladas por usuários do banco de dados que não sejam o `rds_superuser`. Elas são conhecidas como *extensões confiáveis*. Para saber mais, consulte [Extensões confiáveis do PostgreSQL](#PostgreSQL.Concepts.General.Extensions.Trusted).
Determinadas versões do RDS para PostgreSQL oferecem suporte ao parâmetro `rds.allowed_extensions`. Esse parâmetro permite que um `rds_superuser` limite as extensões que podem ser instaladas na instância de banco de dados do RDS para PostgreSQL. Para obter mais informações, consulte [Restringir a instalação de extensões do PostgreSQL](#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Para listas das versões e extensões do PostgreSQL compatíveis com cada versão disponível do RDS para PostgreSQL, consulte [“PostgreSQL extensions supported on Amazon RDS”](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) (Extensões do PostgreSQL compatíveis com o Amazon RDS) em *“Amazon RDS for PostgreSQL Release Notes”* (Notas de lançamento do Amazon RDS para PostgreSQL).
## Restringir a instalação de extensões do PostgreSQL
Você pode restringir quais extensões podem ser instaladas em uma instância de banco de dados PostgreSQL. Por padrão, esse parâmetro não está definido, portanto, qualquer extensão compatível pode ser adicionada se o usuário tiver permissões para isso. Para fazer isso, defina o parâmetro `rds.allowed_extensions` para uma string de nomes de extensão separados por vírgulas. Ao adicionar uma lista de extensões a esse parâmetro, você identifica explicitamente as extensões que a instância de banco de dados do RDS para PostgreSQL pode usar. Somente essas extensões podem ser instaladas na instância de banco de dados PostgreSQL.
A string padrão para o `rds.allowed_extensions` parâmetro é '\$1', o que significa que qualquer extensão disponível para a versão do motor pode ser instalada. Alterar o parâmetro `rds.allowed_extensions` não requer uma reinicialização do banco de dados porque é um parâmetro dinâmico.
O mecanismo de instância de banco de dados PostgreSQL deve ser uma das seguintes versões para você usar o parâmetro `rds.allowed_extensions`:
+ Todas as versões 16 do PostgreSQL
+ PostgreSQL 15 e todas as versões posteriores
+ PostgreSQL 14 e todas as versões posteriores
+ PostgreSQL 13.3 e versões secundárias posteriores
+ PostgreSQL 12.7 e versões secundárias posteriores
Para ver quais instalações de extensão são permitidas, use o comando psql a seguir.
```
postgres=> SHOW rds.allowed_extensions;
rds.allowed_extensions
------------------------
*
```
Se uma extensão foi instalada antes de ser deixada de fora da lista no parâmetro `rds.allowed_extensions`, a extensão ainda pode ser usada normalmente, e comandos como `ALTER EXTENSION` e `DROP EXTENSION` continuarão a funcionar. No entanto, depois que uma extensão é restrita, `CREATE EXTENSION` os comandos para a extensão restrita falharão.
Instalação de dependências de extensão com `CREATE EXTENSION CASCADE` também são restritas. A extensão e suas dependências devem ser especificadas em `rds.allowed_extensions`. Se uma instalação de dependência de extensão falhar, a instrução `CREATE EXTENSION CASCADE` inteira falhará.
Se uma extensão não estiver incluída no parâmetro `rds.allowed_extensions`, você verá um erro como o mostrado a seguir, caso tente instalá-la.
```
ERROR: permission denied to create extension "extension-name"
HINT: This extension is not specified in "rds.allowed_extensions".
```
## Extensões confiáveis do PostgreSQL
Para instalar a maioria das extensões do PostgreSQL são necessários privilégios de `rds_superuser`. O PostgreSQL 13 introduziu as extensões confiáveis, o que reduz a necessidade de privilégios de `rds_superuser` para usuários comuns. Com esse recurso, os usuários podem instalar diversas extensões, se tiverem o privilégio `CREATE` no banco de dados atual, em vez de precisarem ter a função `rds_superuser`. Para obter mais informações, consulte o comando SQL [CREATE EXTENSION](https://www.postgresql.org/docs/current/sql-createextension.html) na documentação do PostgreSQL.
A seguir listamos as extensões que podem ser instaladas por um usuário que tem o privilégio `CREATE` no banco de dados atual e não necessitam da função `rds_superuser`:
+ bool\$1plperl
+ [btree\$1gin](http://www.postgresql.org/docs/current/btree-gin.html)
+ [btree\$1gist](http://www.postgresql.org/docs/current/btree-gist.html)
+ [citext ](http://www.postgresql.org/docs/current/citext.html)
+ [cube ](http://www.postgresql.org/docs/current/cube.html)
+ [ dict\$1int ](http://www.postgresql.org/docs/current/dict-int.html)
+ [fuzzystrmatch](http://www.postgresql.org/docs/current/fuzzystrmatch.html)
+ [hstore](http://www.postgresql.org/docs/current/hstore.html)
+ [ intarray](http://www.postgresql.org/docs/current/intarray.html)
+ [isn](http://www.postgresql.org/docs/current/isn.html)
+ jsonb\$1plperl
+ [ltree ](http://www.postgresql.org/docs/current/ltree.html)
+ [pg\$1trgm](http://www.postgresql.org/docs/current/pgtrgm.html)
+ [pgcrypto](http://www.postgresql.org/docs/current/pgcrypto.html)
+ [plperl](https://www.postgresql.org/docs/current/plperl.html)
+ [plpgsql](https://www.postgresql.org/docs/current/plpgsql.html)
+ [pltcl](https://www.postgresql.org/docs/current/pltcl-overview.html)
+ [tablefunc](http://www.postgresql.org/docs/current/tablefunc.html)
+ [tsm\$1system\$1rows](https://www.postgresql.org/docs/current/tsm-system-rows.html)
+ [tsm\$1system\$1time](https://www.postgresql.org/docs/current/tsm-system-time.html)
+ [unaccent](http://www.postgresql.org/docs/current/unaccent.html)
+ [uuid-ossp](http://www.postgresql.org/docs/current/uuid-ossp.html)
Para listas das versões e extensões do PostgreSQL compatíveis com cada versão disponível do RDS para PostgreSQL, consulte [PostgreSQL extensions supported on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) (Extensões do PostgreSQL compatíveis com o Amazon RDS) em *“Amazon RDS for PostgreSQL Release Notes”* (Notas de lançamento do Amazon RDS para PostgreSQL).
# Trabalhar com recursos do PostgreSQL compatíveis com o Amazon RDS para PostgreSQL
O Amazon RDS para PostgreSQL oferece suporte a muitos dos recursos mais comuns do PostgreSQL. Por exemplo, o PostgreSQL tem um recurso autovacuum que executa manutenção de rotina no banco de dados. O recurso de autovacuum está ativo por padrão. Embora você possa desativar esse recurso, é altamente recomendável que você o mantenha ativado. Compreender esse recurso e o que você pode fazer para garantir que ele funcione como deveria é uma tarefa básica de qualquer DBA. Para obter mais informações sobre o autovacuum, consulte [Trabalhar com o autovacuum do PostgreSQL no Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md). Para saber mais sobre outras tarefas comuns do DBA, consulte ., [Tarefas comuns de DBA do Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md).
O RDS para PostgreSQL também oferece suporte a extensões que adicionam funcionalidades importantes à instância de banco de dados. Por exemplo, você pode usar a extensão PostGIS para trabalhar com dados espaciais ou usar a extensão pg\$1cron para programar a manutenção de dentro da instância. Para obter mais informações sobre as extensões PostgreSQL, consulte [Usar extensões PostgreSQL com o Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md).
Os invólucros de dados externos são um tipo específico de extensão projetado para permitir que sua instância de banco de dados do RDS para PostgreSQL funcione com outros bancos de dados comerciais ou tipos de dados. Para obter mais informações sobre invólucros de dados externos compatíveis com o RDS para PostgreSQL, consulte [Trabalhar com os invólucros de dados externos compatíveis do Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
A seguir, você pode encontrar informações sobre mais alguns recursos compatíveis com o RDS para PostgreSQL.
**Topics**
+ [
# Tipos de dados personalizados e enumerações com o RDS para PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.AlterEnum.md)
+ [
# Acionadores de eventos para RDS para PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.EventTriggers.md)
+ [
# Páginas grandes para RDS para PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md)
+ [
# Executar replicação lógica para o Amazon RDS para PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)
+ [
# Configurar a autenticação do IAM para conexões de replicação lógica
](PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.md)
+ [
# Disco de RAM para o stats\$1temp\$1directory
](PostgreSQL.Concepts.General.FeatureSupport.RamDisk.md)
+ [
# Tablespaces para RDS para PostgreSQL
](PostgreSQL.Concepts.General.FeatureSupport.Tablespaces.md)
+ [
# Agrupamentos do RDS para PostgreSQL para EBCDIC e outras migrações de mainframe
](PostgreSQL.Collations.mainframe.migration.md)
+ [
# Gerenciar sincronização de slots lógicos do RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pglogical.slot.synchronization.md)
# Tipos de dados personalizados e enumerações com o RDS para PostgreSQL
O PostgreSQL é compatível com a criação de tipos de dados personalizados e o trabalho com enumerações. Para obter mais informações sobre como criar e trabalhar com enumerações e outros tipos de dados, consulte [Enumerated types](https://www.postgresql.org/docs/14/datatype-enum.html) (Tipos enumerados) na documentação do PostgreSQL.
Veja a seguir como criar um tipo como uma enumeração e, em seguida, inserir valores em uma tabela.
```
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');
CREATE TYPE
CREATE TABLE t1 (colors rainbow);
CREATE TABLE
INSERT INTO t1 VALUES ('red'), ( 'orange');
INSERT 0 2
SELECT * from t1;
colors
--------
red
orange
(2 rows)
postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson';
ALTER TYPE
postgres=> SELECT * from t1;
colors
---------
crimson
orange
(2 rows)
```
# Acionadores de eventos para RDS para PostgreSQL
Todas as versões atuais do PostgreSQL suportam acionadores de eventos, assim como todas as versões disponíveis do RDS para PostgreSQL. Você pode usar a conta de usuário principal (padrão, `postgres`) para criar, modificar, renomear e excluir acionadores de eventos. Os acionadores de eventos estão no nível da instância do banco de dados, portanto, podem ser aplicados a todos os bancos de dados em uma instância.
Por exemplo, o código a seguir cria um acionador de evento que imprime o usuário atual no final de cada comando de linguagem de definição de dados (DDL).
```
CREATE OR REPLACE FUNCTION raise_notice_func()
RETURNS event_trigger
LANGUAGE plpgsql AS
$$
BEGIN
RAISE NOTICE 'In trigger function: %', current_user;
END;
$$;
CREATE EVENT TRIGGER event_trigger_1
ON ddl_command_end
EXECUTE PROCEDURE raise_notice_func();
```
Para obter mais informações sobre os triggers de eventos do PostgreSQL, consulte [Triggers de eventos](https://www.postgresql.org/docs/current/static/event-triggers.html) na documentação do PostgreSQL.
Há várias limitações de uso para os acionadores de eventos do PostgreSQL no Amazon RDS. Incluindo o seguinte:
+ Não é possível criar gatilhos de eventos em réplicas de leitura. No entanto, você pode criar triggers de eventos na origem de uma réplica de leitura. Os acionadores de eventos serão copiados para a réplica de leitura. Os triggers de eventos na réplica de leitura não são acionados nela quando há mudanças provenientes da origem. No entanto, se a réplica de leitura for promovida, os acionadores de eventos existentes serão ativados quando ocorrerem operações do banco de dados.
+ Para realizar uma atualização de versão principal da instância de banco de dados do PostgreSQL que usa acionadores de eventos, exclua os acionadores antes de atualizar a instância.
# Páginas grandes para RDS para PostgreSQL
*Páginas grandes* são um recurso de gerenciamento de memória que reduz a sobrecarga quando uma instância de banco de dados está trabalhando com grandes blocos contíguos de memória, como os usados por buffers compartilhados. Esse recurso PostgreSQL é compatível com todas as versões do RDS para PostgreSQL atualmente disponíveis. As páginas grandes são alocadas à aplicação usando chamadas de memória compartilhada para a memória compartilhada `mmap` ou `SYSV`. O RDS para PostgreSQL comporta tamanhos de página de 4 KB e 2 MB.
Você pode ativar ou desativar páginas muito grandes alterando o valor do parâmetro `huge_pages`. O recurso é ativado por padrão para todas as classes de instância de banco de dados que não sejam classes de instância de banco de dados micro, pequenas e médias.
O RDS para PostgreSQL usa páginas enormes com base na memória compartilhada disponível. Se a instância de banco de dados não puder usar páginas enormes devido a restrições de memória compartilhada, o Amazon RDS impedirá que a instância de banco de dados seja iniciada. Nesse caso, o Amazon RDS define o status da instância de banco de dados como um estado de parâmetros incompatíveis. Nesse caso, configure o parâmetro `huge_pages` como `off` para permitir que o Amazon RDS inicie a instância de banco de dados.
O parâmetro `shared_buffers` é essencial para configurar o grupo de memória compartilhada, necessário para usar páginas grandes. O valor padrão para o parâmetro `shared_buffers` usa uma macro de parâmetros de banco de dados. Essa macro define uma porcentagem do total de 8 KB de páginas que estão disponíveis para a memória da instância de banco de dados. Quando você usa páginas enormes, elas estão localizadas com as páginas enormes. O Amazon RDS coloca uma instância de banco de dados em um estado de parâmetros incompatível se os parâmetros da memória compartilhada estão configurados para exigir mais de 90% da memória da instância de banco de dados.
Para saber mais sobre o gerenciamento de memória do PostgreSQL, consulte [Consumo de recursos](https://www.postgresql.org/docs/current/static/runtime-config-resource.html) na documentação do PostgreSQL.
# Executar replicação lógica para o Amazon RDS para PostgreSQL
A partir da versão 10.4, o RDS para PostgreSQL é compatível com a sintaxe SQL de publicação e assinatura, que foi introduzida pela primeira vez no PostgreSQL 10. Para saber mais, consulte [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) (Replicação lógica) na documentação do PostgreSQL.
**nota**
Além do recurso nativo de replicação lógica do PostgreSQL introduzido no PostgreSQL 10, o RDS para PostgreSQL também é compatível com a extensão `pglogical`. Para obter mais informações, consulte [Usar pglogical para sincronizar dados entre instâncias](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
A seguir, você pode encontrar informações sobre como configurar a replicação lógica de uma instância de banco de dados do RDS para PostgreSQL.
**Topics**
+ [
## Considerações sobre a replicação lógica e a decodificação lógica
](#PostgreSQL.Concepts.General.FeatureSupport.LogicalDecoding)
+ [
## Como trabalhar com slots de replicação lógica
](#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots)
+ [
## Replicar dados em nível de tabela usando replicação lógica
](#PostgreSQL.Concepts.LogicalReplication.Tables)
## Considerações sobre a replicação lógica e a decodificação lógica
O RDS para PostgreSQL oferece suporte a transmissão de alterações de Write-Ahead Log (WAL – Log de gravação antecipada) usando slots de replicação lógica. Ele também permite o uso de decodificação lógica. Você pode configurar slots de replicação lógica em sua instância e transmitir alterações no banco de dados por meio desses slots para um cliente, como `pg_recvlogical`. Você cria slots de replicação lógica no nível do banco de dados. Esses slots são compatíveis com conexões de replicação para um único banco de dados.
Os clientes mais comuns para replicação lógica do PostgreSQL são o AWS Database Migration Service ou um host gerenciado personalizado em uma instância do Amazon EC2. O slot de replicação lógica não tem informações sobre o receptor do transmissão. Além disso, não é exigido que o destino seja um banco de dados de réplica. Se você configurar um slot de replicação lógica e não fizer a leitura no slot, os dados poderão ser gravados no armazenamento da instância de banco de dados e lotá-lo rapidamente.
Ative a replicação lógica do PostgreSQL e a descodificação lógica no Amazon RDS com um parâmetro, um tipo de conexão de replicação e uma função de segurança. O cliente da descodificação lógica pode ser qualquer cliente que possa estabelecer uma conexão de replicação a um banco de dados em uma instância de banco de dados PostgreSQL.
**Como ativar a descodificação lógica de uma instância de banco de dados do RDS para PostgreSQL**
1. Verifique se a conta de usuário que você está usando tem as seguintes funções:
+ A função `rds_superuser` para que você possa ativar a replicação lógica
+ A função `rds_replication` atribui as permissões necessárias para gerenciar slots lógicos e transmitir dados usando slots lógicos.
1. Defina o parâmetro estático `rds.logical_replication` como 1. Como parte da aplicação desse parâmetro, defina também os parâmetros `wal_level`, `max_wal_senders`, `max_replication_slots` e `max_connections`. Essas alterações de parâmetros podem aumentar a geração de WALs. Portanto, configure o parâmetro `rds.logical_replication` quando estiver usando slots lógicos.
1. Reinicialize a instância de banco de dados para que o parâmetro estático `rds.logical_replication` tenha efeito.
1. Crie um slot de replicação lógica conforme explicado na próxima seção. Esse processo requer que você especifique um plug-in de decodificação. Atualmente, o RDS para PostgreSQL aceita os plug-ins de saída test\$1decoding e wal2json fornecidos com o PostgreSQL.
Para obter mais informações sobre a descodificação lógica do PostgreSQL, consulte a [documentação do PostgreSQL](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html).
## Como trabalhar com slots de replicação lógica
Você pode usar comandos SQL para trabalhar com slots lógicos. Por exemplo, o comando a seguir cria um slot lógico denominado `test_slot` usando o plug-in de saída padrão `test_decoding` do PostgreSQL.
```
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)
```
Para listar slots lógicos, use o seguinte comando.
```
SELECT * FROM pg_replication_slots;
```
Para descartar um slot lógico, use o seguinte comando.
```
SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot
-----------------------
(1 row)
```
Para obter mais exemplos sobre como trabalhar com slots lógicos de replicação, consulte [“Logical decoding examples”](https://www.postgresql.org/docs/9.5/static/logicaldecoding-example.html) (Exemplos de decodificação lógica) na documentação do PostgreSQL.
Após criar um slot de replicação lógica, você pode iniciar o streaming. O exemplo a seguir mostra como a decodificação lógica é controlada sobre o protocolo de replicação de streaming. Este exemplo usa o programa pg\$1recvlogical, incluído na distribuição do PostgreSQL. Para fazer Isso, a autenticação do cliente deve estar configurada para permitir conexões de replicação.
```
pg_recvlogical -d postgres --slot test_slot -U postgres
--host -instance-name.111122223333.aws-region.rds.amazonaws.com
-f - --start
```
Para ver o conteúdo da visualização `pg_replication_origin_status`, consulte a função `pg_show_replication_origin_status`.
```
SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
(0 rows)
```
## Replicar dados em nível de tabela usando replicação lógica
Você pode usar a replicação lógica para replicar dados das tabelas de origem para as tabelas de destino no RDS para PostgreSQL. A replicação lógica primeiro executa um carregamento inicial dos dados existentes das tabelas de origem e, em seguida, continua a replicar as alterações em andamento.
1.
**Criar as tabelas de origem**
Conecte-se ao banco de dados de origem na instância de banco de dados do RDS para PostgreSQL:
```
source=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
1.
**Inserir dados nas tabelas de origem**
```
source=> INSERT INTO testtab VALUES (generate_series(1,1000));
INSERT 0 1000
```
1.
**Criar uma publicação para tabelas de origem**
+ Crie uma publicação para tabelas de origem:
```
source=> CREATE PUBLICATION testpub FOR TABLE testtab;
CREATE PUBLICATION
```
+ Use uma consulta SELECT para verificar os detalhes da publicação que foi criada:
```
source=> SELECT * FROM pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
--------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
115069 | testpub | 16395 | f | t | t | t | t | f
(1 row)
```
+ Verifique se as tabelas de origem foram adicionadas à publicação:
```
source=> SELECT * FROM pg_publication_tables;
pubname | schemaname | tablename
---------+------------+-----------
testpub | public | testtab
(1 rows)
```
+ Para replicar todas as tabelas em um banco de dados, use:
```
CREATE PUBLICATION testpub FOR ALL TABLES;
```
+ Se a publicação já tiver sido criada para uma tabela individual e você precisar adicionar uma nova tabela, execute a seguinte consulta para adicionar novas tabelas à publicação existente:
```
ALTER PUBLICATION add table ;
```
1.
**Conectar-se ao banco de dados de destino e criar tabelas de destino**
+ Conecte-se ao banco de dados de destino na instância de banco de dados de destino. Crie as tabelas de destino com o mesmo nome das tabelas de origem:
```
target=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
+ Verifique se não há dados presentes nas tabelas de destino executando uma consulta SELECT nas tabelas de destino:
```
target=> SELECT count(*) FROM testtab;
count
-------
0
(1 row)
```
1.
**Criar e verificar a assinatura no banco de dados de destino**
+ Crie a assinatura no banco de dados de destino:
```
target=> CREATE SUBSCRIPTION testsub
CONNECTION 'host= port=5432 dbname= user= password='
PUBLICATION testpub;
NOTICE: Created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
+ Use uma consulta SELECT para verificar se a assinatura está habilitada:
```
target=> SELECT oid, subname, subenabled, subslotname, subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16434 | testsub | t | testsub | {testpub}
(1 row)
```
+ Quando a assinatura é criada, ela carrega todos os dados das tabelas de origem para as tabelas de destino. Execute uma consulta SELECT nas tabelas de destino para verificar se os dados iniciais foram carregados:
```
target=> SELECT count(*) FROM testtab;
count
-------
1000
(1 row)
```
1.
**Verificar o slot de replicação no banco de dados de origem**
A criação de uma assinatura no banco de dados de destino cria um slot de replicação no banco de dados de origem. Verifique os detalhes do slot de replicação executando a seguinte consulta SELECT no banco de dados de origem:
```
source=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size
----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------
testsub | pgoutput | logical | 115048 | source | f | t | 846 | | 6945 | 58/B4000568 | 58/B40005A0 | reserved |
(1 row)
```
1.
**Testar a replicação**
+ Teste se as alterações de dados nas tabelas de origem estão sendo replicadas para as tabelas de destino inserindo linhas nas tabelas de origem:
```
source=> INSERT INTO testtab VALUES(generate_series(1001,2000));
INSERT 0 1000
source=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
+ Verifique o número de linhas nas tabelas de destino para confirmar se novas inserções estão sendo replicadas:
```
target=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
1.
**Atualizar a assinatura depois de adicionar tabelas**
+ Quando você adiciona novas tabelas a uma publicação existente, é obrigatório atualizar a assinatura para que as alterações entrem em vigor:
```
ALTER SUBSCRIPTION REFRESH PUBLICATION;
```
+ Esse comando busca informações ausentes da tabela no publicador e inicia a replicação das tabelas que foram adicionadas às publicações assinadas desde que a assinatura foi criada ou atualizada pela última vez.
# Configurar a autenticação do IAM para conexões de replicação lógica
A partir das versões 11 e posterior do RDS para PostgreSQL, você pode usar a autenticação do AWS Identity and Access Management Identity and Access Management (IAM) para conexões de replicação. Esse recurso aprimora a segurança ao permitir que você gerencie o acesso ao banco de dados usando perfis do IAM em vez de senhas. Ele funciona na granularidade do cluster e da instância e segue o mesmo modelo de segurança que a autenticação padrão do IAM.
A autenticação do IAM para conexões de replicação é um atributo opcional. Para habilitá-lo, defina o parâmetro `rds.iam_auth_for_replication` como 1 no seu grupo de parâmetros de banco de dados ou de cluster de banco de dados. Como esse é um parâmetro dinâmico, sua instância ou cluster de banco de dados não precisa ser reiniciado, permitindo que você utilize a autenticação do IAM com workloads existentes sem tempo de inatividade. Antes de habilitar esse recurso, você deve atender aos pré-requisitos listados abaixo.
**Topics**
+ [
## Pré-requisitos
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites)
+ [
## Habilitar a autenticação do IAM para conexões de replicação
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Enabling)
+ [
## Desabilitar a autenticação do IAM para conexões de replicação
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Disabling)
+ [
## Limitações e considerações
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Limitations)
## Pré-requisitos
Para usar a autenticação do IAM para conexões de replicação, você precisa cumprir todos os requisitos abaixo:
+ A instância de banco de dados do RDS para PostgreSQL deve ser a versão 11 ou posterior.
+ Na instância de banco de dados do RDS para PostgreSQL do publicador:
+ Habilite a autenticação do banco de dados do IAM. Para ter mais informações, consulte [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Habilite a replicação lógica definindo o parâmetro `rds.logical_replication` como 1.
Na replicação lógica, o publicador é o banco de dados do RDS para PostgreSQL de origem que envia dados ao banco de dados de assinantes. Para ter mais informações, consulte [Executar replicação lógica para o Amazon RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
**nota**
Tanto a autenticação do IAM quanto a replicação lógica devem estar habilitadas na instância de banco de dados do RDS para PostgreSQL do publicador. Se nenhuma delas estiver habilitada, você não poderá usar a autenticação do IAM para conexões de replicação.
## Habilitar a autenticação do IAM para conexões de replicação
Conclua as etapas a seguir para habilitar a autenticação do IAM para a conexão de replicação.
**Como habilitar a autenticação do IAM para conexões de replicação**
1. Verifique se seu cluster ou instância de banco de dados do RDS para PostgreSQL atende a todos os pré-requisitos para autenticação do IAM com conexões de replicação. Para obter detalhes, consulte [Pré-requisitos](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites).
1. Configure o parâmetro `rds.iam_auth_for_replication` com base na configuração do RDS para PostgreSQL:
+ Para instâncias de banco de dados do RDS para PostgreSQL: modifique seu grupo de parâmetros de banco de dados.
+ Para clusters multi-AZ: modifique o grupo de parâmetros de cluster de banco de dados.
Defina `rds.iam_auth_for_replication` como 1. Esse é um parâmetro dinâmico que entra em vigor imediatamente sem exigir a reinicialização.
**nota**
Clusters multi-AZ usam grupos de parâmetros de cluster de banco de dados. Grupos de parâmetros de instâncias individuais não podem ser modificados em clusters multi-AZ.
1. Conecte-se ao seu banco de dados e conceda os perfis necessários ao seu usuário de replicação:
Os comandos SQL a seguir concedem os perfis necessários para habilitar a autenticação do IAM para conexões de replicação:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Depois de concluir essas etapas, o usuário especificado deve usar a autenticação do IAM para conexões de replicação.
**Importante**
Quando você habilita o recurso, os usuários com os perfis `rds_iam` e `rds_replication` devem usar a autenticação do IAM para conexões de replicação. Isso se aplicará se os perfis forem atribuídos diretamente ao usuário ou herdados por meio de outros perfis.
## Desabilitar a autenticação do IAM para conexões de replicação
Você pode desabilitar a autenticação do IAM para conexões de replicação usando qualquer um dos seguintes métodos:
+ Defina o parâmetro `rds.iam_auth_for_replication` como 0 em seu grupo de parâmetros de banco de dados para instâncias de banco de dados ou grupo de parâmetros de cluster de banco de dados para clusters multi-AZ.
+ Você também pode desabilitar qualquer um desses recursos em seu cluster ou instância de banco de dados do RDS para PostgreSQL:
+ Desabilitar a replicação lógica definindo o parâmetro `rds.logical_replication` como 0
+ Desabilitar a autenticação do IAM
Quando você desabilita o recurso, as conexões de replicação podem usar senhas de banco de dados para autenticação.
**nota**
As conexões de replicação para usuários sem o perfil `rds_iam` podem usar a autenticação por senha mesmo quando o recurso está habilitado.
## Limitações e considerações
Pense nas seguintes limitações e considerações ao usar a autenticação do IAM para conexões de replicação lógica:
+ Esse recurso está disponível somente para as versões 11 e posterior do RDS para PostgreSQL.
+ O publicador deve oferecer suporte à autenticação do IAM para conexões de replicação.
+ Por padrão, o token de autenticação do IAM expira após 15 minutos. Talvez seja necessário atualizar as conexões de replicação de longa duração antes que o token expire.
# Disco de RAM para o stats\$1temp\$1directory
Você pode usar o parâmetro `rds.pg_stat_ramdisk_size` do RDS para PostgreSQL para especificar a memória do sistema alocada a um disco RAM para armazenar o `stats_temp_directory` do PostgreSQL. O parâmetro de disco de RAM só está disponível no RDS para PostgreSQL 14 e versões anteriores.
Mediante certas workloads, definir este parâmetro pode melhorar a performance e diminuir os requisitos de E/S. Para obter mais informações sobre como usar o `stats_temp_directory`, consulte a [documentação do PostgreSQL](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY).
Para configurar um disco RAM para o parâmetro `stats_temp_directory`, configure o parâmetro `rds.pg_stat_ramdisk_size` como um valor literal inteiro no grupo de parâmetros usado pela instância de banco de dados. Esse parâmetro denota MB, portanto, você deve usar um valor inteiro. Expressões, fórmulas e funções não são válidas para o parâmetro `rds.pg_stat_ramdisk_size`. Reinicialize a instância de banco de dados para que o novo valor entre em vigor. Para obter informações sobre como configurar parâmetros, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Por exemplo, o seguinte comando da AWS CLI define o parâmetro do disco de RAM para 256 MB.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name pg-95-ramdisk-testing \
--parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot"
```
Depois de reiniciar, execute o seguinte comando para ver o status de : `stats_temp_directory`.
```
postgres=> SHOW stats_temp_directory;
```
O comando deve retornar um resultado parecido com o exemplo a seguir.
```
stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)
```
# Tablespaces para RDS para PostgreSQL
O RDS para PostgreSQL oferece suporte a tablespaces para compatibilidade. Como todo o armazenamento está em um único volume lógico, você não pode usar tablespaces para divisão ou isolamento de E/S. Nossos benchmarks e experiência indicam que um único volume lógico é a melhor configuração para a maioria dos casos de uso.
Para criar e usar tablespaces com sua instância de banco de dados do RDS para PostgreSQL é necessário a função `rds_superuser`. A sua conta de usuário principal da instância de banco de dados do RDS para PostgreSQL (nome padrão, `postgres`) é membro dessa função. Para obter mais informações, consulte [Noções básicas de perfis e permissões do PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Se você especificar um nome de arquivo ao criar um espaço de tabela, o prefixo de caminho será `/rdsdbdata/db/base/tablespace`. O exemplo a seguir coloca arquivos de espaço de tabela em `/rdsdbdata/db/base/tablespace/data`. Este exemplo pressupõe que um usuário `dbadmin` (função) existe e que lhe foi concedido a função `rds_superuser` necessária para trabalhar com tablespaces.
```
postgres=> CREATE TABLESPACE act_data
OWNER dbadmin
LOCATION '/data';
CREATE TABLESPACE
```
Para saber mais sobre tablespaces do PostgreSQL, consulte [Tablespaces](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html) na documentação do PostgreSQL.
# Agrupamentos do RDS para PostgreSQL para EBCDIC e outras migrações de mainframe
O RDS para PostgreSQL versões 10 e posteriores inclui a ICU versão 60.2, que é baseada no Unicode 10.0 e inclui agrupamentos do Unicode Common Locale Data Repository, CLDR 32. Essas bibliotecas de internacionalização de software garantem que as codificações de caracteres sejam apresentadas de forma consistente, independentemente do sistema operacional ou da plataforma. Para obter mais informações sobre o Unicode CLDR-32, consulte a [“CLDR 32 Release Note”](https://cldr.unicode.org/index/downloads/cldr-32) (Nota de lançamento do CLDR 32) no site do Unicode CLDR. Você pode saber mais sobre os componentes de internacionalização do Unicode (ICU) no site do [Comitê Técnico do ICU (ICU-TC)](https://icu.unicode.org/home). Para obter informações sobre o ICU-60, consulte [Baixar o ICU 60](https://icu.unicode.org/download/60).
A partir da versão 14.3, o RDS para PostgreSQL também inclui agrupamentos que ajudam na integração e conversão de dados de sistemas baseados em EBCDIC. O código de intercâmbio decimal codificado binário estendido ou codificação *EBCDIC* é comumente usada pelos sistemas operacionais de mainframe. Esses agrupamentos fornecidos pelo Amazon RDS são definidos de forma restrita para classificar somente os caracteres Unicode que são mapeados diretamente para páginas de código EBCDIC. Os caracteres são classificados em ordem de pontos de código EBCDIC para permitir a validação dos dados após a conversão. Esses agrupamentos não incluem formulários desnormalizados nem incluem caracteres Unicode que não são mapeados diretamente para um caractere na página de código EBCDIC de origem.
Os mapeamentos de caracteres entre páginas de código EBCDIC e pontos de código Unicode são baseados em tabelas publicadas pela IBM. O conjunto completo é disponibilizado pela IBM como um [arquivo compactado](http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip) para download. O RDS para PostgreSQL usou esses mapeamentos com as ferramentas fornecidas pelo ICU para criar os agrupamentos listados nas tabelas desta seção. Os nomes do agrupamento incluem um idioma e um país, conforme exigido pelo ICU. No entanto, as páginas de código EBCDIC não especificam idiomas, e algumas páginas de código EBCDIC abrangem vários países. Isso significa que a parte do idioma e do país dos nomes de agrupamento na tabela é arbitrária e não precisa corresponder à localidade atual. Em outras palavras, o número da página de código é a parte mais importante do nome do agrupamento nesta tabela. Você pode usar qualquer um dos agrupamentos listados nas tabelas a seguir em qualquer banco de dados do RDS para PostgreSQL.
+ [Unicode to EBCDIC collations table](#ebcdic-table): algumas ferramentas de migração de dados de mainframe usam internamente LATIN1 ou LATIN9 para codificar e processar dados. Essas ferramentas usam esquemas de ida e volta para preservar a integridade dos dados e oferecer suporte à conversão reversa. Os agrupamentos nesta tabela podem ser usados por ferramentas que processam dados usando a codificação LATIN1, que não exige tratamento especial.
+ [Unicode to LATIN9 collations table](#latin9-table): você pode usar esses agrupamentos em qualquer banco de dados do RDS para PostgreSQL.
Na tabela a seguir, você encontra agrupamentos disponíveis no RDS para PostgreSQL que mapeiam páginas de código EBCDIC para pontos de código Unicode. Recomendamos usar os agrupamentos nesta tabela para o desenvolvimento de aplicações que exijam classificação com base na ordem das páginas de código da IBM.
| Nome do agrupamento PostgreSQL | Descrição do mapeamento da página de código e ordem de classificação |
| --- | --- |
| da-DK-cp277-x-icu | Os caracteres Unicode que são mapeados diretamente para a página de código IBM EBCDIC 277 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 277 |
| de-DE-cp273-x-icu | Os caracteres Unicode que são mapeados diretamente para a página de código IBM EBCDIC 273 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 273 |
| en-GB-cp285-x-icu | Os caracteres Unicode que são mapeados diretamente para a página de código IBM EBCDIC 285 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 285 |
| en-US-cp037-x-icu | Os caracteres Unicode que são mapeados diretamente para a página de código IBM EBCDIC 037 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 37 |
| es-ES-cp284-x-icu | Os caracteres Unicode que são mapeados diretamente para a página de código IBM EBCDIC 284 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 284 |
| fi-FI-cp278-x-icu | Os caracteres Unicode que são mapeados diretamente para a página de código IBM EBCDIC 278 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 278 |
| fr-FR-cp297-x-icu | Os caracteres Unicode que são mapeados diretamente para a página de código IBM EBCDIC 297 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 297 |
| it-IT-cp280-x-icu | Os caracteres Unicode que são mapeados diretamente para a página de código IBM EBCDIC 280 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 280 |
| nl-BE-cp500-x-icu | Os caracteres Unicode que são mapeados diretamente para a página de código IBM EBCDIC 500 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 500 |
O Amazon RDS fornece um conjunto de agrupamentos adicionais que classificam pontos de código Unicode mapeados para caracteres LATIN9 usando as tabelas publicadas pela IBM, na ordem dos pontos de código originais, de acordo com a página de código EBCDIC dos dados de origem.
| Nome do agrupamento PostgreSQL | Descrição do mapeamento da página de código e ordem de classificação |
| --- | --- |
| da-DK-cp1142m-x-icu | Caracteres Unicode mapeados para caracteres LATIN9 originalmente convertidos da página de código IBM EBCDIC 1142 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 1142 |
| de-DE-cp1141m-x-icu | Caracteres Unicode mapeados para caracteres LATIN9 originalmente convertidos da página de código IBM EBCDIC 1141 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 1141 |
| en-GB-cp1146m-x-icu | Caracteres Unicode mapeados para caracteres LATIN9 originalmente convertidos da página de código IBM EBCDIC 1146 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 1146 |
| en-US-cp1140m-x-icu | Caracteres Unicode mapeados para caracteres LATIN9 originalmente convertidos da página de código IBM EBCDIC 1140 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 1140 |
| es-ES-cp1145m-x-icu | Caracteres Unicode mapeados para caracteres LATIN9 originalmente convertidos da página de código IBM EBCDIC 1145 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 1145 |
| fi-FI-cp1143m-x-icu | Caracteres Unicode mapeados para caracteres LATIN9 originalmente convertidos da página de código IBM EBCDIC 1143 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 1143 |
| fr-FR-cp1147m-x-icu | Caracteres Unicode mapeados para caracteres LATIN9 originalmente convertidos da página de código IBM EBCDIC 1147 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 1147 |
| it-IT-cp1144m-x-icu | Caracteres Unicode mapeados para caracteres LATIN9 originalmente convertidos da página de código IBM EBCDIC 1144 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 1144 |
| nl-BE-cp1148m-x-icu | Caracteres Unicode mapeados para caracteres LATIN9 originalmente convertidos da página de código IBM EBCDIC 1148 (por tabelas de conversão) são classificados na ordem de pontos de código IBM CP 1148 |
A seguir, você pode encontrar um exemplo de como usar um agrupamento do RDS para PostgreSQL.
```
db1=> SELECT pg_import_system_collations('pg_catalog');
pg_import_system_collations
-----------------------------
36
db1=> SELECT '¤' < 'a' col1;
col1
------
t
db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1;
col1
------
f
```
Recomendamos usar os agrupamentos na [Unicode to EBCDIC collations table](#ebcdic-table) e na [Unicode to LATIN9 collations table](#latin9-table) para desenvolvimento de aplicações que exijam classificação com base na ordenação das páginas de código da IBM. Os seguintes agrupamentos (com o sufixo “b”) também são visíveis em `pg_collation`, mas são destinados ao uso por ferramentas de integração e migração de dados de mainframe em AWS que mapeiam páginas de código com mudanças específicas de pontos de código e exigem tratamento especial em agrupamento. Ou seja, o uso dos agrupamentos a seguir não é recomendado.
+ da-DK-277b-x-icu
+ da-DK-1142b-x-icu
+ de-DE-cp273b-x-icu
+ de-DE-cp1141b-x-icu
+ en-GB-cp1146b-x-icu
+ en-GB-cp285b-x-icu
+ en-US-cp037b-x-icu
+ en-US-cp1140b-x-icu
+ es-ES-cp1145b-x-icu
+ es-ES-cp284b-x-icu
+ fi-FI-cp1143b-x-icu
+ fr-FR-cp1147b-x-icu
+ fr-FR-cp297b-x-icu
+ it-IT-cp1144b-x-icu
+ it-IT-cp280b-x-icu
+ nl-BE-cp1148b-x-icu
+ nl-BE-cp500b-x-icu
Para saber mais sobre a migração de aplicações de ambientes de mainframe para a AWS, consulte [O que é o AWS Mainframe Modernization?](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html)
Para obter mais informações sobre como gerenciar agrupamentos no PostgreSQL, consulte [“Collation Support”](https://www.postgresql.org/docs/current/collation.html) (Compatibilidade com agrupamentos) na documentação do PostgreSQL.
# Gerenciar sincronização de slots lógicos do RDS para PostgreSQL
A partir da comunidade PostgreSQL 17, um novo recurso para sincronizar automaticamente os slots de replicação lógica dos servidores primários para os servidores em espera foi introduzido por meio do parâmetro `sync_replication_slots` ou da função `pg_sync_replication_slots()` relacionada, que sincroniza manualmente os slots na execução.
Esses recursos estão disponíveis a partir do RDS para PostgreSQL 17. Uma configuração típica terá uma instância primária e sua [réplica de leitura](USER_PostgreSQL.Replication.ReadReplicas.md), bem como um assinante de replicação lógica para a primária.
Garanta que a assinatura seja criada com a opção de failover definida como verdadeira:
```
CREATE SUBSCRIPTION subname CONNECTION 'host=...' PUBLICATION pubname WITH (failover = true);
```
Isso cria um slot lógico no publicador com o failover habilitado.
```
postgres=> SELECT slot_name, slot_type, failover FROM pg_catalog.pg_replication_slots;
slot_name | slot_type | failover
-----------+-----------+----------
subname | logical | t
(1 row)
```
Ao habilitar a sincronização de slots, todos os slots de replicação lógica de failover na primária são criados automaticamente nos standbys físicos e sincronizados periodicamente. Garante que os seguintes valores foram definidos por meio de [grupos de parâmetros](USER_WorkingWithParamGroups.Associating.md):
+ `rds.logical_replication` deve ser `1` para permitir a replicação lógica.
+ `hot_standby_feedback` deve ser `1` no standby.
+ `rds.logical_slot_sync_dbname` no standby deve ser definido como um nome de banco de dados válido.
O valor padrão do parâmetro é `postgres`. Se a instância de publicação lógica tiver o banco de dados `postgres`, o parâmetro padrão não precisará ser alterado.
+ `synchronized_standby_slots` na primária deve ser configurado para o slot de replicação física do standby que deve ser sincronizado.
+ `sync_replication_slots` deve ser `1` para habilitar a sincronização automática.
Com um slot de assinatura habilitado para failover e os valores dos parâmetros acima, quando um standby é promovido, o assinante pode alterar sua assinatura dessa instância recém-promovida e continuar a replicação lógica sem problemas.
# Conectar a uma instância de banco de dados executando o mecanismo de banco de dados do PostgreSQL
Depois que o Amazon RDS provisiona a sua instância de banco de dados, você pode usar qualquer aplicação cliente padrão SQL para se conectar à instância. Para que você possa se conectar à sua instância de banco de dados, ela precisa estar disponível e acessível. O que determina se você pode se conectar à instância de fora da VPC é a maneira como você criou a instância de banco de dados do Amazon RDS:
+ Se você tiver criado sua instância de banco de dados como *pública*, dispositivos e instâncias do Amazon EC2 fora da VPC poderão se conectar ao seu banco de dados.
+ Se você tiver criado sua instância de banco de dados como *privada*, somente instâncias e dispositivos do Amazon EC2 dentro da Amazon VPC poderão se conectar ao seu banco de dados.
Para verificar se sua instância de banco de dados é pública ou privada, use o Console de gerenciamento da AWS para visualizar a guia **Connectivity & security** (Conectividade e segurança) para sua instância. Em **Security** (Segurança), você pode encontrar o valor “Publicly accessible” (Acessível ao público), com No (Não) para privado e Yes (Sim) para público.
Para saber mais sobre diferentes configurações do Amazon RDS e da Amazon VPC e como elas afetam a acessibilidade, consulte [Cenários para acessar uma instância de banco de dados em uma VPC](USER_VPC.Scenarios.md).
**Contents**
+ [
## Instalar o cliente psql
](#install-psql)
+ [
## Localizar as informações de conexão para uma instância de banco de dados do RDS para PostgreSQL
](#postgresql-endpoint)
+ [
# Usar pgAdmin para se conectar a uma instância de banco de dados RDS for PostgreSQL
](USER_ConnectToPostgreSQLInstance.pgAdmin.md)
+ [
# Usar psql para se conectar à sua instância de banco de dados RDS for PostgreSQL
](USER_ConnectToPostgreSQLInstance.psql.md)
+ [
# Conectar-se ao RDS para PostgreSQL com o driver JDBC da Amazon Web Services (AWS)
](PostgreSQL.Connecting.JDBCDriver.md)
+ [
# Conectar-se ao RDS para PostgreSQL com o driver Python da Amazon Web Services (AWS)
](PostgreSQL.Connecting.PythonDriver.md)
+ [
# Solucionar problemas de conexões com a sua instância RDS for PostgreSQL
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md)
+ [
## Erro – FATAL: o banco de dados *nome* não existe
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [
## Erro – Não foi possível conectar-se ao servidor: a conexão expirou por exceder o tempo limite.
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [
## Erros com regras de acesso a grupos de segurança
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Instalar o cliente psql
Para se conectar à sua instância de banco de dados por meio de uma instância do EC2, você pode instalar um cliente PostgreSQL na instância do EC2. Para instalar a versão mais recente do cliente psql no Amazon Linux 2023, execute o seguinte comando:
```
sudo dnf install postgresql
```
Para instalar a versão mais recente do cliente psql no Amazon Linux 2, execute o seguinte comando:
```
sudo yum install -y postgresql
```
Para instalar a versão mais recente do cliente psql no Ubuntu, execute o seguinte comando:
```
sudo apt install -y postgresql-client
```
## Localizar as informações de conexão para uma instância de banco de dados do RDS para PostgreSQL
Se a instância de banco de dados estiver disponível e acessível, você poderá se conectar fornecendo as seguintes informações à aplicação cliente SQL:
+ O endpoint da instância de banco de dados, que serve como o nome do host (nome DNS) da instância.
+ A porta na qual a instância de banco de dados está ouvindo. Para o PostgreSQL, a porta padrão é 5432.
+ O nome e senha do usuário da instância de banco de dados. O "nome de usuário primário" padrão do PostgreSQL é `postgres`.
+ O nome e a senha do banco de dados (nome do banco de dados).
Você pode obter esses detalhes usando o comando Console de gerenciamento da AWS, o comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) da AWS CLI ou a operação [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) da API do Amazon RDS.
**Para localizar o endpoint, o número da porta e o nome do banco de dados utilizando o Console de gerenciamento da AWS**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Abra o console do RDS e escolha **Databases (Bancos de dados)** para exibir uma lista das instâncias de banco de dados.
1. Escolha o nome da instância de banco de dados do PostgreSQL para exibir os detalhes.
1. Na guia **Connectivity & security (Conectividade e segurança)**, copie o endpoint. Além disso, anote o número da porta. Você precisará do endpoint e do número da porta para conectar-se à instância de banco de dados.
![\[Obter o endpoint do Console do RDS\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/PostgreSQL-endpoint.png)
1. Na guia **Configuration** (Configuração), anote o nome do banco de dados. Se você tiver criado um banco de dados quando criou a instância do RDS for PostgreSQL, verá o nome listado abaixo do nome do banco de dados. Se você não tiver criado um banco de dados, o nome do banco de dados exibirá um traço (‐).
![\[Obter o nome do banco de dados no Console do RDS\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/PostgreSQL-db-name.png)
A seguir, veja dois jeitos de se conectar a uma instância de banco de dados PostgreSQL. O primeiro exemplo usa o pgAdmin, uma popular ferramenta de administração e desenvolvimento de código aberto para o PostgreSQL. O segundo exemplo usa psql, um utilitário de linha de comando que faz parte de uma instalação do PostgreSQL.
# Usar pgAdmin para se conectar a uma instância de banco de dados RDS for PostgreSQL
É possível utilizar a ferramenta de código aberto pgAdmin para se conectar a uma instância de banco de dados RDS for PostgreSQL. Você pode baixar e instalar pgAdmin em [http://www.pgadmin.org/](http://www.pgadmin.org/) sem ter uma instância local do PostgreSQL no seu computador cliente.
**Para se conectar a uma instância de banco de dados RDS for PostgreSQL utilizando pgAdmin**
1. Inicie a aplicação pgAdmin no computador cliente.
1. Na guia **Dashboard (Painel)**, escolha **Add New Server (Adicionar novo servidor)**.
1. Na caixa de diálogo **Create - Server (Criar - Servidor)**, digite um nome na guia **Geral** para identificar o servidor no pgAdmin.
1. Na guia **Connection (Conexão)**, digite as informações a seguir de sua instância de banco de dados:
+ Para **Host**, digite o endpoint, por exemplo `mypostgresql.c6c8dntfzzhgv0.us-east-2.rds.amazonaws.com`.
+ Para **Port (Porta)**, digite a porta designada.
+ Em **Username** (Nome de usuário), digite o nome de usuário que você inseriu ao criar a instância de banco de dados (se você alterou o padrão do "nome de usuário primário", `postgres`).
+ Para **Password** (Senha), digite a senha que você inseriu quando criou a instância de base de dados.
![\[Digite a senha que você inseriu quando criou a instância de base de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/Postgres-Connect01.png)
1. Escolha **Salvar**.
Se você tiver quaisquer problemas para se conectar, consulte [Solucionar problemas de conexões com a sua instância RDS for PostgreSQL](USER_ConnectToPostgreSQLInstance.Troubleshooting.md).
1. Para acessar um banco de dados no navegador de pgAdmin, expanda **Servers (Servidores)**, a instância de banco de dados, e **Databases (Bancos de dados)**. Escolha o nome do banco de dados da instância de banco de dados.
![\[Escolha o nome do banco de dados da instância de banco de dados no navegador pgAdmin.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/Postgres-Connect02.png)
1. Para abrir um painel onde você pode inserir comandos SQL, escolha **Tools (Ferramentas)**, **Query Tool (Ferramenta de consulta)**.
# Usar psql para se conectar à sua instância de banco de dados RDS for PostgreSQL
É possível utilizar uma instância local do utilitário de linha de comando psql para conectar-se a uma instância de banco de dados RDS for PostgreSQL. Você precisa do PostgreSQL ou do cliente psql instalado em seu computador de cliente.
Você pode baixar o cliente PostgreSQL no site do [PostgreSQL](https://www.postgresql.org/download/). Siga as instruções específicas da versão de seu sistema operacional para instalar o psql.
Para se conectar à sua instância de banco de dados RDS for PostgreSQL utilizando psql, você precisa fornecer as informações do host (DNS), as credenciais de acesso e o nome do banco de dados.
Use um dos formatos a seguir para se conectar a uma instância de banco de dados RDS for PostgreSQL. Ao se conectar, você terá de inserir uma senha. Para trabalhos ou scripts de lotes, use a opção `--no-password`. Essa opção é definida para toda a sessão.
**nota**
Uma tentativa de conexão com `--no-password` falha quando o servidor requer autenticação de senha e uma senha não está disponível de outras fontes. Para ter mais informações, consulte a [documentação do psql](https://www.postgresql.org/docs/13/app-psql.html).
Se esta é a primeira vez que você está se conectando a essa instância de banco de dados, ou se você ainda não criou um banco de dados para essa instância RDS para PostgreSQL, será possível conectar-se ao banco de dados **Postgres** utilizando o “nome de usuário primário” e a senha.
Para Unix, use o formato a seguir.
```
psql \
--host= \
--port= \
--username= \
--password \
--dbname=
```
Para Windows, use o formato a seguir.
```
psql ^
--host= ^
--port= ^
--username= ^
--password ^
--dbname=
```
Por exemplo, o comando a seguir se conecta a um banco de dados chamado `mypgdb` em uma instância de banco de dados PostgreSQL chamada `mypostgresql` usando credenciais fictícias.
```
psql --host=mypostgresql.c6c8mwvfdgv0.us-west-2.rds.amazonaws.com --port=5432 --username=awsuser --password --dbname=mypgdb
```
# Conectar-se ao RDS para PostgreSQL com o driver JDBC da Amazon Web Services (AWS)
O driver JDBC da Amazon Web Services (AWS) foi projetado como um wrapper JDBC avançado. Esse wrapper é complementar e amplia a funcionalidade do driver JDBC existente. O driver é compatível de forma intercambiável com o driver pgJDBC.
Para instalar o driver JDBC da AWS, anexe o arquivo .jar do driver JDBC da AWS (localizado na aplicação `CLASSPATH`) e mantenha referências ao respectivo driver da comunidade. Atualize o respectivo prefixo do URL de conexão da seguinte forma:
+ `jdbc:postgresql://` para `jdbc:aws-wrapper:postgresql://`
Consulte mais informações sobre o driver JDBC da AWS e siga as instruções para usá-lo em [Amazon Web Services (AWS) JDBC Driver GitHub repository](https://github.com/awslabs/aws-advanced-jdbc-wrapper).
# Conectar-se ao RDS para PostgreSQL com o driver Python da Amazon Web Services (AWS)
O driver Python da Amazon Web Services (AWS) foi projetado como um wrapper Python avançado. Esse wrapper é complementar e amplia a funcionalidade do driver Psycopg de código aberto. O driver Python da AWS é compatível com as versões 3.8 e posterior do Python. É possível instalar o pacote `aws-advanced-python-wrapper` usando o comando `pip`, bem como os pacotes de código aberto `psycopg`.
Para ter mais informações sobre o driver Python da AWS e instruções completas para usá-lo, consulte [Amazon Web Services (AWS) Python Driver GitHub repository](https://github.com/awslabs/aws-advanced-python-wrapper).
# Solucionar problemas de conexões com a sua instância RDS for PostgreSQL
**Topics**
+ [
## Erro – FATAL: o banco de dados *nome* não existe
](#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [
## Erro – Não foi possível conectar-se ao servidor: a conexão expirou por exceder o tempo limite.
](#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [
## Erros com regras de acesso a grupos de segurança
](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Erro – FATAL: o banco de dados *nome* não existe
Se você receber um erro como `FATAL: database name does not exist` ao tentar se conectar, tente usar o nome padrão do banco de dados **postgres** para a opção `--dbname`.
## Erro – Não foi possível conectar-se ao servidor: a conexão expirou por exceder o tempo limite.
Se você não puder conectar-se à instância do banco de dados, o erro mais comum é `Could not connect to server: Connection timed out.` Se receber esse erro, verifique o seguinte:
+ Verifique se o nome do host usado é o endpoint da instância de banco de dados e se o número da porta usado está correto.
+ Certifique-se de que a acessibilidade pública da instância de banco de dados esteja definida como **Yes (Sim)** para permitir conexões externas. Para modificar a configuração **Public access (Acesso público)**, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md).
+ Garante que o usuário que está se conectando ao banco de dados tenha acesso CONNECT a ele. Você pode usar a consulta a seguir para fornecer acesso de conexão ao banco de dados.
```
GRANT CONNECT ON DATABASE database name TO username;
```
+ Verifique se o grupo de segurança atribuído à instância do banco de dados tem as regras para permitir o acesso através de qualquer firewall que sua conexão possa passar. Por exemplo, se a instância de banco de dados foi criada usando a porta padrão 5432, sua empresa pode empregar regras de firewall bloqueando conexões a essa porta a partir de dispositivos externos da empresa.
Para corrigir isso, modifique a instância de banco de dados para usar uma porta diferente. Além disso, certifique-se de que o grupo de segurança aplicado à instância do banco de dados permite conexões com a nova porta. Para modificar a configuração **Database port (Porta do banco de dados)**, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md).
+ Verifique se a porta que você está tentando usar já está ocupada por uma instância local do PostgreSQL ou por outro serviço em execução no computador. Por exemplo, se você tiver um banco de dados do PostgreSQL local em execução na mesma porta (o padrão é 5432), isso poderá impedir uma conexão bem-sucedida com a instância de banco de dados do RDS para PostgreSQL. Certifique-se de que a porta esteja livre ou tente se conectar com um número de porta diferente, se possível.
+ Consulte também [Erros com regras de acesso a grupos de segurança](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules).
## Erros com regras de acesso a grupos de segurança
O problema de comunicação mais comum é com as regras de acesso de grupo de segurança atribuídas à instância do banco de dados. Se você usou o grupo de segurança padrão quando criou a instância de banco de dados, é provável que o grupo de segurança não tenha as regras que lhe permitem acessar a instância.
Para a conexão funcionar, o grupo de segurança que você atribuiu à instância de banco de dados em sua criação quando o criou deve permitir o acesso à instância de banco de dados. Por exemplo, se a instância de banco de dados foi criada em uma VPC, ela deverá ter um grupo de segurança da VPC que autorize as conexões. Verifique se a instância de banco de dados foi criada usando um grupo de segurança que não autoriza conexões do dispositivo ou da instância do Amazon EC2 em que o aplicativo está sendo executado.
É possível adicionar ou editar uma regra de entrada no grupo de segurança. Em **Source (Origem)**, selecionar **My IP (Meu IP)** concede acesso à instância de banco de dados do endereço IP detectado no navegador. Para ter mais informações, consulte [Fornecer acesso à instância de banco de dados na VPC criando um grupo de segurança](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
De forma alternativa, se a instância de banco de dados tiver sido criada fora de uma VPC, ela deverá ter um grupo de segurança de banco de dados que autorize essas conexões.
Para ter mais informações sobre grupos de segurança do Amazon RDS, consulte [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md).
# Proteger conexões com o RDS para PostgreSQL com SSL/TLS
O RDS para PostgreSQL é compatível com a criptografia Secure Sockets Layer (SSL) para instâncias de banco de dados PostgreSQL. Por meio do SSL, você pode criptografar uma conexão do PostgreSQL entre seus aplicativos e suas instâncias de banco de dados PostgreSQL. Você também pode forçar todas as conexões à instância de banco de dados PostgreSQL a usarem SSL. O RDS para PostgreSQL também é compatível com Transport Layer Security (TLS), o protocolo sucessor do SSL.
Para saber mais sobre o Amazon RDS e a proteção de dados, incluindo criptografia de conexões usando SSL/TLS, consulte [Proteção de dados no Amazon RDS](DataDurability.md).
**Topics**
+ [
# Usar o SSL com uma instância de banco de dados PostgreSQL
](PostgreSQL.Concepts.General.SSL.md)
+ [
# Atualizar aplicações para conexão com instâncias de banco de dados PostgreSQL usando novos certificados SSL/TLS
](ssl-certificate-rotation-postgresql.md)
# Usar o SSL com uma instância de banco de dados PostgreSQL
O Amazon RDS oferece suporte à criptografia de Secure Socket Layer (SSL) para instâncias de banco de dados PostgreSQL. Por meio do SSL, você pode criptografar uma conexão do PostgreSQL entre seus aplicativos e suas instâncias de banco de dados PostgreSQL. Por padrão, o RDS para PostgreSQL usa e espera que todos os clientes se conectem usando SSL/TLS, mas você também pode exigir isso. O RDS para PostgreSQL é compatível com o Transport Layer Security (TLS) versões 1.1, 1.2 e 1.3.
Para obter informações gerais sobre o suporte para SSL e bancos de dados PostgreSQL, consulte [Suporte para SSL](https://www.postgresql.org/docs/11/libpq-ssl.html) na documentação do PostgreSQL. Para obter informações sobre como usar uma conexão SSL via JDBC, consulte [Configurar o cliente](https://jdbc.postgresql.org/documentation/head/ssl-client.html) na documentação do PostgreSQL.
O suporte a SSL está disponível em todas as regiões da AWS para o PostgreSQL. O Amazon RDS cria um certificado SSL para sua instância de banco de dados do PostgreSQL quando essa instância é criada. Se você habilitar a verificação de certificado SSL, o certificado SSL incluirá o endpoint da instância de banco de dados como o nome comum (CN) do certificado SSL para se proteger contra ataques de falsificação.
**Topics**
+ [
## Conectar-se à instância de banco de dados PostgreSQL via SSL
](#PostgreSQL.Concepts.General.SSL.Connecting)
+ [
## Exigir uma conexão SSL para uma instância de banco de dados PostgreSQL
](#PostgreSQL.Concepts.General.SSL.Requiring)
+ [
## Determinar o status de conexão SSL
](#PostgreSQL.Concepts.General.SSL.Status)
+ [
## Suítes de cifras SSL no RDS para PostgreSQL
](#PostgreSQL.Concepts.General.SSL.Ciphers)
## Conectar-se à instância de banco de dados PostgreSQL via SSL
**Para se conectar à instância de banco de dados PostgreSQL via SSL**
1. Baixe o certificado.
Para obter informações sobre como baixar certificados, consulte [Usar SSL/TLS para criptografar uma conexão com uma instância ou um cluster de banco de dados](UsingWithRDS.SSL.md).
1. Conecte-se à sua instância de banco de dados PostgreSQL via SSL.
Quando você se conecta usando SSL, seu cliente pode escolher se deseja verificar a cadeia de certificados. Se os seus parâmetros de conexão especificarem `sslmode=verify-ca` ou `sslmode=verify-full`, seu cliente exigirá que os certificados de CA do RDS estejam no armazenamento confiável ou sejam referenciados no URL da conexão. Esse requisito tem o objetivo de verificar a cadeia de certificados que assina o seu certificado de banco de dados.
Quando um cliente, como psql ou JDBC, é configurado com suporte para SSL, primeiro ele tenta se conectar ao banco de dados via SSL por padrão. Se esse cliente não puder se conectar via SSL, ele voltará a se conectar sem SSL. O modo `sslmode` padrão utilizado é diferente entre os clientes baseados em libpq (como o psql) e o JDBC. Os clientes JDBC e baseados em libpq usam `prefer` como padrão.
Use o parâmetro `sslrootcert` para fazer referência ao certificado, por exemplo `sslrootcert=rds-ssl-ca-cert.pem`.
Veja a seguir um exemplo de uso do `psql` para se conectar a uma instância de banco de dados do PostgreSQL usando SSL com verificação de certificado.
```
$ psql "host=db-name.555555555555.ap-southeast-1.rds.amazonaws.com
port=5432 dbname=testDB user=testuser sslrootcert=rds-ca-rsa2048-g1.pem sslmode=verify-full"
```
## Exigir uma conexão SSL para uma instância de banco de dados PostgreSQL
Você pode exigir que conexões estabelecidas a sua instância de banco de dados PostgreSQL usem SSL por meio do parâmetro `rds.force_ssl`. O valor padrão do parâmetro `rds.force_ssl` é 1 (ativado) para o RDS para PostgreSQL versão 15 e posterior. Para todas as outras versões principais do RDS para PostgreSQL 14 e posterior, o valor padrão desse parâmetro é 0 (desativado). Você pode definir o parâmetro `rds.force_ssl` como 1 (ativado) para exigir SSL/TLS para conexões com o seu cluster de banco de dados. Você pode definir o parâmetro `rds.force_ssl` como 1 (ativado) para exigir o SSL para conexões a sua instância de banco de dados.
Para alterar o valor desse parâmetro, você precisa criar um grupo de parâmetros de banco de dados personalizado. Depois precisará alterar o valor de `rds.force_ssl` em seu grupo de parâmetros de banco de dados personalizado para `1` para ativar esse recurso. Se você preparar o grupo de parâmetros de banco de dados personalizado antes de criar sua instância de banco de dados do RDS para PostgreSQL, poderá escolhê-lo (em vez de um grupo de parâmetros padrão) durante o processo de criação. Se você fizer isso depois que a instância de banco de dados do RDS para PostgreSQL já estiver em execução, será necessário reinicializar a instância para que ela use o grupo de parâmetros personalizado. Para obter mais informações, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Quando o recurso `rds.force_ssl` está ativo em sua instância de banco de dados, as tentativas de conexão que não estão usando SSL são rejeitadas com a seguinte mensagem:
```
$ psql -h db-name.555555555555.ap-southeast-1.rds.amazonaws.com port=5432 dbname=testDB user=testuser
psql: error: FATAL: no pg_hba.conf entry for host "w.x.y.z", user "testuser", database "testDB", SSL off
```
## Determinar o status de conexão SSL
O status criptografado da conexão é mostrado no banner de login ao se conectar à instância de banco de dados:
```
Password for user master:
psql (10.3)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
Você também pode carregar a extensão `sslinfo` e chamar a função `ssl_is_used()` para determinar se o SSL está sendo usado. A função retornará `t` se a conexão estiver usando o SSL, caso contrário, retornará `f`.
```
postgres=> CREATE EXTENSION sslinfo;
CREATE EXTENSION
postgres=> SELECT ssl_is_used();
ssl_is_used
---------
t
(1 row)
```
Para obter informações mais detalhadas, use a seguinte consulta para obter informações de `pg_settings`:
```
SELECT name as "Parameter name", setting as value, short_desc FROM pg_settings WHERE name LIKE '%ssl%';
Parameter name | value | short_desc
----------------------------------------+-----------------------------------------+-------------------------------------------------------
ssl | on | Enables SSL connections.
ssl_ca_file | /rdsdbdata/rds-metadata/ca-cert.pem | Location of the SSL certificate authority file.
ssl_cert_file | /rdsdbdata/rds-metadata/server-cert.pem | Location of the SSL server certificate file.
ssl_ciphers | HIGH:!aNULL:!3DES | Sets the list of allowed SSL ciphers.
ssl_crl_file | | Location of the SSL certificate revocation list file.
ssl_dh_params_file | | Location of the SSL DH parameters file.
ssl_ecdh_curve | prime256v1 | Sets the curve to use for ECDH.
ssl_key_file | /rdsdbdata/rds-metadata/server-key.pem | Location of the SSL server private key file.
ssl_library | OpenSSL | Name of the SSL library.
ssl_max_protocol_version | | Sets the maximum SSL/TLS protocol version to use.
ssl_min_protocol_version | TLSv1.2 | Sets the minimum SSL/TLS protocol version to use.
ssl_passphrase_command | | Command to obtain passphrases for SSL.
ssl_passphrase_command_supports_reload | off | Also use ssl_passphrase_command during server reload.
ssl_prefer_server_ciphers | on | Give priority to server ciphersuite order.
(14 rows)
```
Você também pode coletar todas as informações sobre o uso de SSL da instância de banco de dados do RDS para PostgreSQL por processo, cliente e aplicação usando a seguinte consulta:
```
SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
FROM pg_stat_ssl
JOIN pg_stat_activity
ON pg_stat_ssl.pid = pg_stat_activity.pid
ORDER BY ssl;
Database name | User name | ssl | client_addr | application_name | backend_type
---------------+-----------+-----+----------------+------------------------+------------------------------
| | f | | | autovacuum launcher
| rdsadmin | f | | | logical replication launcher
| | f | | | background writer
| | f | | | checkpointer
| | f | | | walwriter
rdsadmin | rdsadmin | t | 127.0.0.1 | | client backend
rdsadmin | rdsadmin | t | 127.0.0.1 | PostgreSQL JDBC Driver | client backend
postgres | postgres | t | 204.246.162.36 | psql | client backend
(8 rows)
```
Para identificar a criptografia usada para sua conexão SSL, você pode consultar da seguinte forma:
```
postgres=> SELECT ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
```
Para saber mais sobre a opção `sslmode`, consulte [Funções de controle de conexão com o banco de dados](https://www.postgresql.org/docs/11/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) na *documentação do PostgreSQL*.
## Suítes de cifras SSL no RDS para PostgreSQL
O parâmetro de configuração do PostgreSQL, [ssl\$1ciphers](https://www.postgresql.org/docs/current/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SSL), especifica as categorias de suítes de cifras permitidas para conexões SSL com o banco de dados ao usar o TLS 1.2 e anterior.
No RDS para PostgreSQL 16 e versões posteriores, você pode modificar o parâmetro `ssl_ciphers` para usar valores específicos das suítes de cifras permitidas. Esse é um parâmetro dinâmico que não exige a reinicialização da instância do banco de dados. Para visualizar as suítes de cifras permitidas, use o console do Amazon RDS ou o seguinte comando da AWS CLI:
```
aws rds describe-db-parameters --db-parameter-group-name --region --endpoint-url --output json | jq '.Parameters[] | select(.ParameterName == "ssl_ciphers")'
```
A tabela a seguir lista as suítes de cifras padrão e as suítes de cifras permitidas para versões que aceitam configurações personalizadas.
| Versão do mecanismo PostgreSQL | Valores padrão da suíte de ssl\$1ciphers | Valores personalizados permitidos da suíte de ssl\$1ciphers |
| --- | --- | --- |
| 18 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 17 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 16 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 15 | HIGH:\$1aNULL:\$13DES | Não é possível usar ssl\$1ciphers personalizados |
| 14 | HIGH:\$1aNULL:\$13DES | Não é possível usar ssl\$1ciphers personalizados |
| 13 | HIGH:\$1aNULL:\$13DES | Não é possível usar ssl\$1ciphers personalizados |
| 12 | HIGH:\$1aNULL:\$13DES | Não é possível usar ssl\$1ciphers personalizados |
| 11.4 e versões secundárias posteriores | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | Não é possível usar ssl\$1ciphers personalizados |
| 11.1, 11.2 | HIGH:MEDIUM:\$13DES:\$1aNULL | Não é possível usar ssl\$1ciphers personalizados |
| 10.9 e versões secundárias posteriores | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | Não é possível usar ssl\$1ciphers personalizados |
| 10.7 e versões secundárias anteriores | HIGH:MEDIUM:\$13DES:\$1aNULL | Não é possível usar ssl\$1ciphers personalizados |
Para configurar todas as conexões de instância e usar a suíte de cifras `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`, modifique seu grupo de parâmetros conforme mostrado no seguinte exemplo:
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_ciphers',ParameterValue='TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384',ApplyMethod=immediate"
```
Este exemplo usa uma cifra ECDSA, que exige que sua instância use uma autoridade de certificação com criptografia de curva elíptica (ECC) para estabelecer uma conexão. Para obter informações sobre as autoridades de certificação oferecidas pelo Amazon RDS, consulte [Certificate authorities](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/singWithRDS.SSL.html#UsingWithRDS.SSL.RegionCertificateAuthorities).
Você pode verificar as cifras em uso por meio dos métodos descritos em [Determinar o status de conexão SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html#PostgreSQL.Concepts.General.SSL.Status).
As cifras podem ter nomes diferentes dependendo do contexto:
+ As cifras da lista de permissões que você pode configurar em seu grupo de parâmetros são referidas com o respectivo nome da Internet Assigned Numbers Authority (IANA).
+ Os banners de logon `sslinfo` e `psql` se referem às cifras usando o respectivo nome do OpenSSL.
Por padrão, o valor de `ssl_max_protocol_version` no RDS para PostgreSQL 16 e versões posteriores é TLS v1.3. Você deve definir o valor desse parâmetro como TLS v1.2, pois o TLS v1.3 não usa as configurações de cifra especificadas no parâmetro `ssl_ciphers`. Quando você define o valor como TLS v1.2, as conexões usam somente as cifras que você define em `ssl_ciphers`.
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_max_protocol_version',ParameterValue='TLSv1.2',ApplyMethod=immediate"
```
Para garantir que as conexões do banco de dados usem SSL, defina `rds.force_ssl parameter` como 1 no seu grupo de parâmetros. Para obter mais informações sobre parâmetros e grupos de parâmetros, consulte [Grupos de parâmetros para Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html).
# Atualizar aplicações para conexão com instâncias de banco de dados PostgreSQL usando novos certificados SSL/TLS
Os certificados usados para Secure Socket Layer ou TLS Transport Layer Security (SSL/TLS) geralmente têm uma vida útil definida. Quando os provedores de serviços atualizam seus certificados de Autoridade de Certificação (CA), os clientes devem atualizar suas aplicações para usar os novos certificados. A seguir, você pode encontrar informações sobre como determinar se suas aplicações cliente usam SSL/TLS para conectar-se à sua instância de banco de dados Amazon RDS for PostgreSQL. Você também pode encontrar informações sobre como conferir se essas aplicações verificam o certificado do servidor quando elas se conectam.
**nota**
Uma aplicação cliente configurada para verificar o certificado do servidor antes da conexão SSL/TLS deve ter um certificado válido de uma CA no repositório de confiança do cliente. Atualize o repositório de confiança do cliente quando houver novos certificados.
Depois de atualizar seus certificados de CA nos armazenamentos confiáveis do aplicativo cliente, você pode fazer o rodízio dos certificados nas suas instâncias de banco de dados. É altamente recomendável testar esses procedimentos em um ambiente não voltado à produção antes de implementá-los em seus ambientes de produção.
Para ter mais informações sobre a mudança de certificados, consulte [Alternar o certificado SSL/TLS](UsingWithRDS.SSL-certificate-rotation.md). Para ter mais informações sobre como fazer download de certificados, consulte [Usar SSL/TLS para criptografar uma conexão com uma instância ou um cluster de banco de dados](UsingWithRDS.SSL.md). Para obter informações sobre o uso de SSL/TLS com instâncias de bancos de dados PostgreSQL, consulte [Usar o SSL com uma instância de banco de dados PostgreSQL](PostgreSQL.Concepts.General.SSL.md).
**Topics**
+ [
## Determinar se as aplicações estão se conectando a instâncias de banco de dados PostgreSQL usando SSL
](#ssl-certificate-rotation-postgresql.determining-server)
+ [
## Determinar se um cliente requer verificação de certificado para se conectar
](#ssl-certificate-rotation-postgresql.determining-client)
+ [
## Atualizar o armazenamento confiável de aplicações
](#ssl-certificate-rotation-postgresql.updating-trust-store)
+ [
## Usar conexões SSL/TLS para diferentes tipos de aplicações
](#ssl-certificate-rotation-postgresql.applications)
## Determinar se as aplicações estão se conectando a instâncias de banco de dados PostgreSQL usando SSL
Verifique a configuração da instância de banco de dados para obter o valor do parâmetro `rds.force_ssl`. Por padrão, o parâmetro `rds.force_ssl` é definido como `0` (desativado) para instâncias de banco de dados usando versões do PostgreSQL anteriores à 15. Por padrão, `rds.force_ssl` é definido como `1` (ativo) para instâncias de banco de dados usando o PostgreSQL versão 15 e versões principais posteriores. Se o parâmetro `rds.force_ssl` estiver definido como `1` (ativado), os clientes serão obrigados a usar SSL/TLS para conexões. Para ter mais informações sobre parameter groups, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Se você estiver usando o RDS PostgreSQL versão 9.5 ou versão posterior principal e `rds.force_ssl` não estiver definido como `1` (ativado), consulte a visualização `pg_stat_ssl` para verificar conexões usando SSL. Por exemplo, a consulta a seguir retorna apenas conexões SSL e informações sobre os clientes que usam SSL.
```
SELECT datname, usename, ssl, client_addr
FROM pg_stat_ssl INNER JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid
WHERE ssl is true and usename<>'rdsadmin';
```
Somente as linhas que usarem conexões SSL/TLS serão exibidas com informações sobre a conexão. Esta é uma saída de exemplo.
```
datname | usename | ssl | client_addr
----------+---------+-----+-------------
benchdb | pgadmin | t | 53.95.6.13
postgres | pgadmin | t | 53.95.6.13
(2 rows)
```
Esta consulta exibe apenas as conexões atuais no momento da consulta. A ausência de resultados não indica que nenhum aplicativo esteja usando conexões SSL. Outras conexões SSL podem ser estabelecidas em um momento diferente.
## Determinar se um cliente requer verificação de certificado para se conectar
Quando um cliente, como psql ou JDBC, é configurado com suporte para SSL, primeiro ele tenta se conectar ao banco de dados via SSL por padrão. Se esse cliente não puder se conectar via SSL, ele voltará a se conectar sem SSL. O modo padrão `sslmode` utilizado para clientes baseados em libpq (como o psql) e o JDBC é definido como `prefer`. O certificado no servidor é verificado apenas quando `sslrootcert` é fornecido com `sslmode` definido como `verify-ca` ou `verify-full`. Um erro será lançado se o certificado for inválido.
Use `PGSSLROOTCERT` para verificar o certificado com a variável de ambiente `PGSSLMODE`, com `PGSSLMODE` definido como `verify-ca` ou `verify-full`.
```
PGSSLMODE=verify-full PGSSLROOTCERT=/fullpath/ssl-cert.pem psql -h pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com -U masteruser -d postgres
```
Use o argumento `sslrootcert` para verificar o certificado com `sslmode` no formato de string de conexão, com `sslmode` definido como `verify-ca` ou `verify-full` para verificar o certificado.
```
psql "host=pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com sslmode=verify-full sslrootcert=/full/path/ssl-cert.pem user=masteruser dbname=postgres"
```
Por exemplo, no caso anterior, se você estiver usando um certificado raiz inválido, verá um erro semelhante ao seguinte no seu cliente.
```
psql: SSL error: certificate verify failed
```
## Atualizar o armazenamento confiável de aplicações
Para obter informações sobre como atualizar o armazenamento de confiança para aplicações PostgreSQL, consulte [Secure TCP/IP connections with SSL](https://www.postgresql.org/docs/current/ssl-tcp.html) na documentação do PostgreSQL.
Para obter informações sobre como baixar o certificado raiz, consulte [Usar SSL/TLS para criptografar uma conexão com uma instância ou um cluster de banco de dados](UsingWithRDS.SSL.md).
Para obter exemplos de scripts que importam certificados, consulte [Script de exemplo para importar certificados para o seu armazenamento confiável](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script).
**nota**
Ao atualizar o armazenamento confiável, é possível reter certificados mais antigos, além de adicionar os novos certificados.
## Usar conexões SSL/TLS para diferentes tipos de aplicações
Veja a seguir informações sobre o uso de conexões SSL/TLS para diferentes tipos de aplicativos:
+ **psql**
O cliente é chamado da linha de comandos especificando opções como uma string de conexão ou como variáveis de ambiente. Para conexões SSL/TLS, as opções relevantes são `sslmode` (variável de ambiente `PGSSLMODE`), `sslrootcert` (variável de ambiente `PGSSLROOTCERT`).
Para conhecer a lista completa de opções, consulte [Palavras-chave de parâmetros](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS) na documentação do PostgreSQL. Para conhecer a lista completa de variáveis de ambiente, consulte [Variáveis de ambiente](https://www.postgresql.org/docs/current/libpq-envars.html) na documentação do PostgreSQL.
+ **pgAdmin**
Esse cliente baseado em navegador é uma interface mais amigável para conectar-se a um banco de dados PostgreSQL.
Para obter informações sobre como configurar conexões, consulte a [Documentação de pgAdmin](https://www.pgadmin.org/docs/pgadmin4/latest/server_dialog.html).
+ **JDBC**
O JDBC permite conexões de banco de dados com aplicativos Java.
Para obter informações gerais sobre como conectar-se a um banco de dados PostgreSQL com JDBC, consulte [Connecting to the database](https://jdbc.postgresql.org/documentation/use/#connecting-to-the-database) (Conectar-se ao banco de dados) na documentação do driver do PostgreSQL. Para obter informações sobre como conectar-se com SSL/TLS, consulte [Configuring the client](https://jdbc.postgresql.org/documentation/ssl/#configuring-the-client) (Configurar o cliente) na documentação do PostgreSQL.
+ **Python**
Uma biblioteca Python popular para conectar-se a bancos de dados PostgreSQL é `psycopg2`.
Para obter informações sobre como usar o `psycopg2`, consulte a [documentação de psycopg2](https://pypi.org/project/psycopg2/). Para um breve tutorial sobre como conectar-se a um banco de dados PostgreSQL, consulte [Tutorial sobre psycopg2](https://wiki.postgresql.org/wiki/Psycopg2_Tutorial). Você pode encontrar informações sobre as opções aceitas pelo comando de conexão em [O conteúdo do módulo psycopg2](http://initd.org/psycopg/docs/module.html#module-psycopg2).
**Importante**
Depois de determinar que suas conexões com o banco de dados usam SSL/TLS e ter atualizado o armazenamento confiável de aplicações, você poderá atualizar o banco de dados para usar os certificados rds-ca-rsa2048-g1. Para obter instruções, consulte a etapa 3 em [Atualizar o certificado CA modificando a instância ou o cluster de banco de dados](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating).
# Usar a autenticação Kerberos com o Amazon RDS para PostgreSQL
É possível usar o Kerberos para autenticar usuários quando eles se conectam à sua instância de banco de dados executando o PostgreSQL. Para fazer isso, configure sua instância de banco de dados para usar o AWS Directory Service for Microsoft Active Directory para autenticação Kerberos. O AWS Directory Service for Microsoft Active Directory também é chamado de AWS Managed Microsoft AD. É um recurso disponível com o Directory Service. Para saber mais, consulte [What is Directory Service?](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) (O que é o ?) no *Guia de administração do AWS Directory Service*.
Para iniciar, crie um diretório AWS Managed Microsoft AD para armazenar credenciais de usuário. Depois, forneça à instância de banco de dados PostgreSQL o domínio do Active Directory e outras informações. Quando os usuários são autenticados com a instância de banco de dados PostgreSQL, as solicitações de autenticação são encaminhadas para o diretório AWS Managed Microsoft AD.
Manter todas as suas credenciais no mesmo diretório pode economizar tempo e esforço. Há um lugar centralizado para armazenar e gerenciar credenciais para várias instâncias de banco de dados. O uso de um diretório também pode melhorar o perfil de segurança geral.
Além disso, é possível acessar credenciais de seu próprio Microsoft Active Directory on-premises. Para fazer isso, crie uma relação de domínio confiável para que o diretório AWS Managed Microsoft AD confie no Microsoft Active Directory on-premises. Dessa forma, seus usuários podem acessar as instâncias de do PostgreSQL com a mesma experiência de autenticação única (SSO) do Windows, como quando acessam workloads na sua rede on-premises.
Um banco de dados pode usar autenticação por senha ou autenticação por senha com autenticação do Kerberos ou do AWS Identity and Access Management (IAM). Para ter mais informações sobre a autenticação do IAM, consulte [Autenticação do banco de dados do IAMpara MariaDB, MySQL e PostgreSQL](UsingWithRDS.IAMDBAuth.md).
**nota**
O RDS para PostgreSQL não aceita a autenticação Kerberos para grupos do Active Directory.
**Topics**
+ [
## Disponibilidade de regiões e versões
](#postgresql-kerberos.RegionVersionAvailability)
+ [
## Visão geral da autenticação Kerberos para instâncias de banco de dados PostgreSQL
](#postgresql-kerberos-overview)
+ [
# Configurar a autenticação Kerberos para instâncias de banco de dados do PostgreSQL
](postgresql-kerberos-setting-up.md)
+ [
# Gerenciar uma instância de banco de dados do RDS para PostgreSQL em um domínio do Active Directory
](postgresql-kerberos-managing.md)
+ [
# Conectar-se ao PostgreSQL com a autenticação Kerberos
](postgresql-kerberos-connecting.md)
## Disponibilidade de regiões e versões
A disponibilidade e a compatibilidade de recursos variam entre versões específicas de cada mecanismo de banco de dados e entre Regiões da AWS. Para ter mais informações sobre a disponibilidade de versões e regiões do RDS para PostgreSQL com autenticação de Kerberos, consulte [Regiões e mecanismos de banco de dados compatíveis com a autenticação Kerberos no Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md).
## Visão geral da autenticação Kerberos para instâncias de banco de dados PostgreSQL
Para configurar a autenticação Kerberos para uma instância de banco de dados PostgreSQL, siga as etapas a seguir, descritas em mais detalhes posteriormente:
1. Use AWS Managed Microsoft AD para criar um diretório do AWS Managed Microsoft AD. É possível usar o Console de gerenciamento da AWS, a AWS CLI ou a API do Directory Service para criar o diretório. Certifique-se de abrir as portas de saída relevantes no grupo de segurança do diretório para que o diretório possa se comunicar com a instância.
1. Crie uma função que forneça ao Amazon RDS acesso para fazer chamadas para o diretório AWS Managed Microsoft AD. Para fazer isso, crie um perfil do AWS Identity and Access Management (IAM) que use a política gerenciada do IAM `AmazonRDSDirectoryServiceAccess`.
Para o perfil do IAM permitir acesso, o endpoint do AWS Security Token Service (AWS STS) deve estar ativado na região da AWS correta da conta da AWS. Os endpoints do AWS STS são ativados por padrão em todas as Regiões da AWS e é possível usá-los sem ter que tomar medidas adicionais. Para ter mais informações, consulte [Ativar e desativar o AWS STS em uma AWS região da ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate) no * Manual do usuário do IAM*.
1. Crie e configure usuários no diretório AWS Managed Microsoft AD usando as ferramentas do Microsoft Active Directory. Para ter mais informações sobre como criar usuários em seu Active Directory, consulte [Gerenciar usuários e grupos no Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) gerenciado pela AWS no*Guia de administração doDirectory Service*.
1. Se você planeja localizar o diretório e a instância de Bancos de Dados em contas da AWS ou nuvens privadas virtuais (VPCs) diferentes, configure o emparelhamento de VPCs. Para ter mais informações, consulte [O que é emparelhamento de VPC?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) no *Amazon VPC Peering Guide*.
1. Crie ou modifique uma instância de banco de dados PostgreSQL no console, na CLI ou na API do RDS usando um dos seguintes métodos:
+ [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md)
+ [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md)
+ [Restaurar uma instância de banco de dados](USER_RestoreFromSnapshot.md)
+ [Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS](USER_PIT.md)
É possível localizar a instância na mesma Amazon Virtual Private Cloud (VPC) que o diretório ou em uma conta da AWS ou VPC diferente. Ao criar ou modificar a instância de banco de dados PostgreSQL, faça o seguinte:
+ Forneça o identificador de domínio (identificador `d-*`) que foi gerado quando você criou seu diretório.
+ Forneça o nome do perfil do IAM criado.
+ Certifique-se de que o grupo de segurança da instância de banco de dados possa receber o tráfego de entrada do grupo de segurança do diretório.
1. Use as credenciais de usuário mestre do RDS para conectar-se à instância de de banco de dados PostgreSQL. Crie o usuário no PostgreSQL para ser identificado externamente. Usuários identificados externamente podem fazer login na instância de banco de dados PostgreSQL usando a autenticação Kerberos.
# Configurar a autenticação Kerberos para instâncias de banco de dados do PostgreSQL
Use o AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) para configurar a autenticação Kerberos para uma instância de banco de dados PostgreSQL. Para configurar a autenticação Kerberos, execute as etapas a seguir.
**Topics**
+ [
## Etapa 1: Criar um diretório usando o AWS Managed Microsoft AD
](#postgresql-kerberos-setting-up.create-directory)
+ [
## Etapa 2: (Opcional) Criar uma relação de confiança entre o Active Directory on-premises e o Directory Service
](#postgresql-kerberos-setting-up.create-trust)
+ [
## Etapa 3: Criar um perfil do IAM para que o Amazon RDS acesse o Directory Service
](#postgresql-kerberos-setting-up.CreateIAMRole)
+ [
## Etapa 4: Criar e configurar usuários
](#postgresql-kerberos-setting-up.create-users)
+ [
## Etapa 5: Ativar o tráfego entre VPCs entre o diretório e a instância de banco de dados
](#postgresql-kerberos-setting-up.vpc-peering)
+ [
## Etapa 6: Criar ou modificar uma instância de banco de dados PostgreSQL
](#postgresql-kerberos-setting-up.create-modify)
+ [
## Etapa 7: Criar usuários do PostgreSQL para suas entidades principais do Kerberos
](#postgresql-kerberos-setting-up.create-logins)
+ [
## Etapa 8: Configurar um cliente PostgreSQL
](#postgresql-kerberos-setting-up.configure-client)
## Etapa 1: Criar um diretório usando o AWS Managed Microsoft AD
O Directory Service cria um Active Directory totalmente gerenciado na Nuvem AWS. Quando você cria um diretório AWS Managed Microsoft AD, o Directory Service cria dois controladores de domínio e servidores DNS para você. Os servidores do diretório são criados em sub-redes diferentes em uma VPC. Essa redundância ajuda a garantir que o diretório permaneça acessível mesmo se ocorrer uma falha.
Ao criar um diretório AWS Managed Microsoft AD, o AWS Directory Service realiza as seguintes tarefas em seu nome:
+ Configura um Active Directory dentro da VPC.
+ Cria de uma conta de administrador do diretório com o nome de usuário `Admin` e a senha especificada. Use essa conta para gerenciar seu diretório.
**Importante**
Certifique-se de salvar essa senha. O Directory Service não armazena essa senha e não é possível recuperá-la ou redefini-la.
+ Cria um grupo de segurança para os controladores do diretório. O grupo de segurança deve permitir a comunicação com a instância de banco de dados PostgreSQL.
Quando você lança o AWS Directory Service for Microsoft Active Directory, a AWS cria uma Unidade organizacional (OU) que contém todos os objetos do diretório. Essa UO, que tem o nome de NetBIOS que você digitou ao criar o diretório, está localizada na raiz do domínio. A raiz do domínio é controlada e de propriedade da AWS.
A conta `Admin`, que foi criada com o diretório AWS Managed Microsoft AD, tem permissões para as atividades administrativas mais comuns da UO:
+ Criar, atualizar ou excluir usuários
+ Adicionar recursos ao domínio, como servidores de arquivos ou de impressão, e atribuir permissões para esses recursos aos usuários na UO
+ Criar OUs adicionais e contêineres
+ Delegar autoridade
+ Restaurar objetos excluídos da Lixeira do Active Directory
+ Execute os módulos Active Directory e Domain Name Service (DNS) para Windows PowerShell no Active Directory Web Service
A conta `Admin` também possui direitos para executar as seguintes atividades de domínio:
+ Gerenciar configurações de DNS (adicionar, remover ou atualizar registros, zonas e encaminhadores)
+ Visualizar logs de eventos de DNS
+ Visualizar logs de eventos de segurança
**Como criar um diretório com AWS Managed Microsoft AD**
1. No painel de navegação do [console do Directory Service](https://console.aws.amazon.com/directoryservicev2/), escolha **Directories (Diretórios)** e escolha **Set up directory (Configurar diretório)**.
1. Escolha **AWS Managed Microsoft AD**. O AWS Managed Microsoft AD é a única opção atualmente compatível para uso com o Amazon RDS.
1. Escolha **Next (Próximo)**.
1. Na página **Enter directory information (Inserir informações do diretório)**, forneça as seguintes informações:
**Edição**
Escolha a edição que atenda às suas necessidades.
**Nome do DNS do diretório**
O nome completo do diretório, como **corp.example.com**.
**Nome de NetBIOS do diretório**
O nome curto opcional do diretório, como `CORP`.
**Descrição do diretório**
Uma descrição opcional do diretório.
**Senha do Admin**
A senha do administrador do diretório. O processo de criação do diretório cria uma conta de administrador com o nome de usuário `Admin` e essa senha.
A senha do administrador do diretório não pode incluir a palavra "admin". A senha diferencia letras maiúsculas de minúsculas e deve ter entre 8 e 64 caracteres. Ela também precisa conter pelo menos um caractere de três das quatro categorias a seguir:
+ Letras minúsculas (a–z)
+ Letras maiúsculas (A–Z)
+ Números (0–9)
+ Caracteres não alfanuméricos (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
**Confirmar senha**
Digite a senha do administrador novamente.
Salve essa senha. O Directory Service não armazena essa senha e não é possível recuperá-la ou redefini-la.
1. Escolha **Next (Próximo)**.
1. Na página **Choose VPC and subnets (Selecionar VPC e sub-redes)**, forneça as seguintes informações:
**VPC**
Escolha a VPC do diretório. É possível criar a instância de banco de dados PostgreSQL nessa mesma VPC ou em outra VPC.
**Sub-redes**
Escolha as sub-redes para os servidores do diretório. As duas sub-redes deve estar em diferentes zonas de disponibilidade.
1. Escolha **Next (Próximo)**.
1. Analise as informações do diretório. Se alterações forem necessárias, escolha **Previous (Anterior)** e faça as alterações. Quando as informações estiverem corretas, escolha **Create directory (Criar diretório)**.
![\[Página de detalhes do diretório\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
A criação do diretório leva vários minutos. Depois que o diretório tiver sido criado com sucesso, o valor de **Status** muda para **Active (Ativo)**.
Para visualizar informações sobre o diretório, escolha o ID do diretório na listagem de diretórios. Anote o valor do **Directory ID (ID do diretório)**. Esse valor será necessário ao criar ou modificar a instância de banco de dados PostgreSQL.
![\[Imagem da página de detalhes\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
## Etapa 2: (Opcional) Criar uma relação de confiança entre o Active Directory on-premises e o Directory Service
Se você não planeja usar seu próprio Microsoft Active Directory on-premises, vá para [Etapa 3: Criar um perfil do IAM para que o Amazon RDS acesse o Directory Service](#postgresql-kerberos-setting-up.CreateIAMRole).
Para obter a autenticação Kerberos usando o Active Directory local, é necessário criar uma relação de domínio confiável usando uma confiança de floresta entre o Microsoft Active Directory on-premises e o diretório AWS Managed Microsoft AD (criado em [Etapa 1: Criar um diretório usando o AWS Managed Microsoft AD](#postgresql-kerberos-setting-up.create-directory)). A relação de confiança pode ser unidirecional, onde o diretório AWS Managed Microsoft AD confia no Microsoft Active Directory on-premises. A confiança também pode ser bidirecional, onde os dois Active Directories confiam um no outro. Para ter mais informações sobre como configurar confianças usando o Directory Service, consulte [Quando criar uma relação de confiança](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html) no *Guia de administração do AWS Directory Service*.
**nota**
Se você usar um Microsoft Active Directory on-premises, os clientes do Windows se conectam usando o nome de domínio do Directory Service no endpoint em vez de rds.amazonaws.com. Para saber mais, consulte [Conectar-se ao PostgreSQL com a autenticação Kerberos](postgresql-kerberos-connecting.md).
Verifique se o nome de domínio do Microsoft Active Directory on-premises inclui um roteamento de sufixo DNS que corresponde à relação de confiança recém-criada. A captura de tela a seguir mostra um exemplo.
![\[O roteamento de DNS corresponde à confiança criada\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/kerberos-auth-trust.png)
## Etapa 3: Criar um perfil do IAM para que o Amazon RDS acesse o Directory Service
Para que o Amazon RDS chame o Directory Service para você, sua conta da AWS precisa de um perfil do IAM que use a política gerenciada `AmazonRDSDirectoryServiceAccess` do IAM. Essa função permite que o Amazon RDS faça chamadas para o Directory Service.
Quando você cria uma instância de banco de dados usando o Console de gerenciamento da AWS e a conta do usuário do console tiver a permissão `iam:CreateRole`, o console criará o perfil do IAM necessário automaticamente. Nesse caso, o nome da função é `rds-directoryservice-kerberos-access-role`. Caso contrário, é necessário criar a função do IAM manualmente. Ao criar essa função do IAM, escolha `Directory Service` e associe a AWS política gerenciada da `AmazonRDSDirectoryServiceAccess` a ela.
Para ter mais informações sobre como criar funções do IAM para um serviço, consulte o tópico sobre como [Criar uma função para delegar permissões a um serviço da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html), no *Guia do usuário do IAM*.
**nota**
O perfil do IAM usado para a autenticação do Windows para RDS para Microsoft SQL Server não pode ser usado para o Amazon RDS para PostgreSQL.
Como alternativa ao uso da política gerenciada pelo `AmazonRDSDirectoryServiceAccess`, você pode criar políticas com as permissões exigidas. Nesse caso, o perfil do IAM deve ter a política de confiança do IAM a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.amazonaws.com",
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
A função também deve ter a política de perfil do IAM a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
Para as Regiões da AWS pelas quais você optou, use entidades principais de serviço específicas da região nas políticas de confiança de perfil do IAM. Ao criar uma política de confiança para serviços nessas regiões, especifique o código da região na entidade principal do serviço.
O seguinte exemplo mostra uma política de confiança que inclui entidades principais de serviço específicas da região:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.REGION-CODE.amazonaws.com",
"rds.REGION-CODE.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Substitua REGION-CODE pelo código da sua região específica. Por exemplo, use as seguintes entidades principais de serviço para a região Ásia-Pacífico (Melbourne):
```
"Service": [
"directoryservice.rds.ap-southeast-4.amazonaws.com",
"rds.ap-southeast-4.amazonaws.com"
]
```
## Etapa 4: Criar e configurar usuários
Você pode criar usuários com a ferramenta Usuários e computadores do Active Directory. Essa é uma das ferramentas do Active Directory Domain Services e do Active Directory Lightweight Directory Services. Para obter mais informações, consulte [Add Users and Computers to the Active Directory domain](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/create-an-active-directory-server#add-users-and-computers-to-the-active-directory-domain) (Adicionar usuários e computadores ao domínio do Active Directory) na documentação da Microsoft. Nesse caso, os usuários são indivíduos ou outras entidades, como seus computadores que fazem parte do domínio e cujas identidades estão sendo mantidas no diretório.
Para criar usuários em um diretório do Directory Service, é necessário estar conectado a uma instância do Amazon EC2 baseada no Windows que seja membro do diretório do Directory Service. Ao mesmo tempo, é necessário estar conectado como um usuário que tenha privilégios para criar usuários. Para obter mais informações, consulte [Criar um usuário](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_create_user.html) no *Guia de administração do AWS Directory Service*.
## Etapa 5: Ativar o tráfego entre VPCs entre o diretório e a instância de banco de dados
Se você planeja localizar o diretório e a instância de banco de dados na mesma VPC, ignore esta etapa e prossiga para [Etapa 6: Criar ou modificar uma instância de banco de dados PostgreSQL](#postgresql-kerberos-setting-up.create-modify).
Se você planejar localizar o diretório e a instância de Bancos de Dados em VPCs diferentes, configure o tráfego entre VPCs usando o emparelhamento de VPCs ou o [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html).
O procedimento a seguir habilita o tráfego entre VPCs usando o emparelhamento de VPCs. Siga as instruções em [O que é o emparelhamento de VPCs?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) no *Guia de emparelhamento do Amazon Virtual Private Cloud*.
**Como habilitar o tráfego entre VPCs usando o emparelhamento de VPCs**
1. Configure regras apropriadas de roteamento de VPC para garantir que o tráfego de rede possa fluir em ambos os sentidos.
1. Certifique-se de que o grupo de segurança da instância de banco de dados possa receber o tráfego de entrada do grupo de segurança do diretório.
1. Garanta que não há nenhuma regra na lista de controle de acesso (ACL) de rede para bloquear o tráfego.
Se uma conta diferente da AWS for proprietária do diretório, é necessário compartilhá-lo.
**Como compartilhar o diretório entre contas da AWS.**
1. Inicie o compartilhamento do diretório com a conta da AWS na qual a instância de Bancos de Dados será criada seguindo as instruções em [Tutorial: Compartilhar o diretório da AWS Managed Microsoft AD para ingresso perfeito no domínio do EC2](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html) no *Guia de administração do Directory Service*.
1. Faça login no console do Directory Service usando a conta para a instância de banco de dados e garanta que o domínio tenha o status `SHARED` antes de prosseguir.
1. Enquanto estiver conectado ao console do Directory Service usando a conta da instância de banco de dados, observe o valor do **Directory ID (ID do diretório)**. Use esse ID do diretório para associar a instância de banco de dados ao domínio.
## Etapa 6: Criar ou modificar uma instância de banco de dados PostgreSQL
Crie ou modifique uma instância de banco de dados PostgreSQL para usar com seu diretório. É possível usar o console, a CLI ou a API do RDS para associar uma instância de banco de dados a um diretório. Você pode fazer isso por meio de uma das seguintes maneiras:
+ Crie uma instância de banco de dados PostgreSQL usando o console, o comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) da CLI ou a operação de API [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) do RDS. Para obter instruções, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md).
+ Modifique uma instância de banco de dados PostgreSQL existente usando o console, o comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) da CLI ou a operação de API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) do RDS. Para obter instruções, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md).
+ Restaure uma instância de banco de dados PostgreSQL de um snapshot de banco de dados usando o console, o comando [ restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) da CLI ou a operação de API [ RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) do RDS. Para obter instruções, consulte [Restaurar uma instância de banco de dados](USER_RestoreFromSnapshot.md).
+ Restaure uma instância de banco de dados PostgreSQL em um determinado momento usando o console, o comando [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) da CLI ou a operação de API [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) do RDS. Para obter instruções, consulte [Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS](USER_PIT.md).
A autenticação Kerberos só é compatível com instâncias de de banco de dados PostgreSQL em uma VPC. A instância de banco de dados pode estar na mesma VPC do diretório ou em uma VPC diferente. A instância de banco de dados deve usar um grupo de segurança que permita entrada e saída na VPC do diretório para que a instância de banco de dados possa se comunicar com o diretório.
### Console
Ao usar o console para criar, modificar ou restaurar uma instância de banco de dados, escolha **Password and Kerberos authentication** (Senha e autenticação Kerberos) na seção **Database authentication** (Autenticação de banco de dados). Em seguida, escolha **Browse Directory** (Procurar diretório). Selecione o diretório ou escolha **Create a new directory** (Criar um novo diretório) para usar o Directory Service.
![\[Selecionar o Kerberos para autenticação e identificar o diretório a ser usado.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/rpg-authentication-use-kerberos.png)
### AWS CLI
Quando você usa a AWS CLI, são necessários os seguintes parâmetros para que a instância de banco de dados possa usar o diretório criado:
+ Para o parâmetro `--domain`, use o identificador de domínio (identificador "d-\$1") gerado quando o diretório foi criado.
+ Para o parâmetro `--domain-iam-role-name`, use a função criada que usa a política gerenciada `AmazonRDSDirectoryServiceAccess` do IAM.
Por exemplo, o comando da CLI a seguir modifica uma instância de banco de dados para usar um diretório.
```
aws rds modify-db-instance --db-instance-identifier mydbinstance --domain d-Directory-ID --domain-iam-role-name role-name
```
**Importante**
Se você modificar uma instância de banco de dados para habilitar a autenticação Kerberos, reinicialize a instância de banco de dados após a alteração.
## Etapa 7: Criar usuários do PostgreSQL para suas entidades principais do Kerberos
Nesse ponto, sua instância de banco de dados do RDS para PostgreSQL é unida ao domínio AWS Managed Microsoft AD. Os usuários que você criou no diretório em [Etapa 4: Criar e configurar usuários](#postgresql-kerberos-setting-up.create-users) precisam ser configurados como usuários do banco de dados do PostgreSQL e receber privilégios para fazer login no banco de dados. Você faz isso fazendo login como usuário do banco de dados com privilégios `rds_superuser`. Por exemplo, se você aceitou os padrões ao criar sua instância de banco de dados do PostgreSQL, use `postgres`, conforme mostrado nas etapas a seguir.
**Como criar usuários de banco de dados do PostgreSQL para entidades principais do Kerberos**
1. Use o `psql` para conectar-se ao endpoint da instância de banco de dados de seu RDS para PostgreSQL usando `psql`. O exemplo a seguir usa a conta `postgres` padrão para a função `rds_superuser`.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Crie um nome de usuário do banco de dados para cada entidade principal do Kerberos (nome de usuário do Active Directory) que você deseja que tenha acesso ao banco de dados. Use o nome de usuário canônico (identidade) conforme definido na instância do Active Directory, ou seja, uma letra minúscula `alias` (nome de usuário no Active Directory) e o nome em maiúscula do domínio do Active Directory para esse nome de usuário. O nome de usuário do Active Directory é um usuário autenticado externamente, portanto, use aspas ao redor do nome conforme mostrado a seguir.
```
postgres=> CREATE USER "username@CORP.EXAMPLE.COM" WITH LOGIN;
CREATE ROLE
```
1. Conceda a função `rds_ad` ao usuário do banco de dados.
```
postgres=> GRANT rds_ad TO "username@CORP.EXAMPLE.COM";
GRANT ROLE
```
Depois de concluir a criação de todos os usuários do PostgreSQL para suas identidades de usuário do Active Directory, os usuários podem acessar a instância de banco de dados do RDS para PostgreSQL usando suas credenciais do Kerberos.
É necessário que os usuários do banco de dados que se autenticam usando o Kerberos estejam fazendo isso nas máquinas cliente que sejam membros do domínio do Active Directory.
Os usuários do banco de dados aos quais foi concedida a função `rds_ad` não podem ter também a função `rds_iam`. Isso também se aplica a assinaturas aninhadas. Para obter mais informações, consulte [Autenticação do banco de dados do IAMpara MariaDB, MySQL e PostgreSQL](UsingWithRDS.IAMDBAuth.md).
## Etapa 8: Configurar um cliente PostgreSQL
Para configurar um cliente PostgreSQL, execute as seguintes etapas:
+ Crie um arquivo krb5.conf (ou equivalente) para apontar para o domínio.
+ Verifique se o tráfego pode fluir entre o host do cliente e o Directory Service. Use um utilitário de rede, como o Netcat, para o seguinte:
+ Verifique o tráfego pelo DNS da porta 53.
+ Verifique o tráfego pelo TCP/UDP da porta 53 e do Kerberos, que inclui as portas 88 e 464 do Directory Service.
+ Verifique se o tráfego pode fluir entre o host do cliente e a instância de banco de dados pela porta do banco de dados. Por exemplo, use psql para conectar e acessar o banco de dados.
Veja a seguir um exemplo de conteúdo krb5.conf para o AWS Managed Microsoft AD.
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
```
Veja a seguir um exemplo de conteúdo krb5.conf para o Microsoft Active Directory on-premises.
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
ONPREM.COM = {
kdc = onprem.com
admin_server = onprem.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
.onprem.com = ONPREM.COM
onprem.com = ONPREM.COM
.rds.amazonaws.com = EXAMPLE.COM
.amazonaws.com.rproxy.goskope.com.cn = EXAMPLE.COM
.amazon.com = EXAMPLE.COM
```
# Gerenciar uma instância de banco de dados do RDS para PostgreSQL em um domínio do Active Directory
É possível usar o console, a CLI ou a API do RDS para gerenciar a instância de banco de dados e suas relações com o Microsoft Active Directory. Por exemplo, é possível associar um Microsoft Active Directory para habilitar a autenticação Kerberos. Também é possível remover a associação de um Microsoft Active Directory para desabilitar a autenticação Kerberos. Também é possível mover uma instância de banco de dados para a autenticação externa por um Microsoft Active Directory para outro.
Por exemplo, usando a CLI, é possível fazer o seguinte:
+ Para tentar habilitar a autenticação Kerberos novamente para uma assinatura com falha, use o comando da CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) . Especifique o ID do diretório da associação atual para a opção `--domain`.
+ Para desabilitar a autenticação Kerberos em uma instância de banco de dados, use o comando da CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) . Especifique `none` para a opção `--domain`.
+ Para mover uma instância de banco de dados de um domínio para outro, use o comando da CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html). Especifique o identificador de domínio do novo domínio para a opção `--domain`.
## Compreensão da associação de domínio
Depois de criar ou modificar uma instância de banco de dados, as instâncias de banco de dados se tornam membrosele se torna membro do domínio. É possível visualizar o status da associação do domínio no console ou executando o comando da CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html). O status da instância de banco de dados pode ser um dos seguintes:
+ `kerberos-enabled` – a instância de banco de dados que tem a autenticação Kerberos habilitada.
+ `enabling-kerberos`: a AWS está no processo de habilitar a autenticação Kerberos nessa instância de bancos de dados.
+ `pending-enable-kerberos` – a habilitação da autenticação Kerberos está pendente nessa instância de banco de dados.
+ `pending-maintenance-enable-kerberos`: a AWS tentará habilitar a autenticação Kerberos na instância de bancos de dados durante a próxima janela de manutenção programada.
+ `pending-disable-kerberos` – a desabilitação da autenticação Kerberos está pendente nessa instância de banco de dados.
+ `pending-maintenance-disable-kerberos`: a AWS tentará desabilitar a autenticação Kerberos na instância de banco de dados durante a próxima janela de manutenção programada.
+ `enable-kerberos-failed`: um problema de configuração impediu que a AWS habilitasse a autenticação Kerberos na instância de banco de dados. Corrija o problema de configuração antes de emitir o comando novamente para modificar a instância de banco de dados.
+ `disabling-kerberos`: a AWS está no processo de desabilitar a autenticação Kerberos nessa instância de bancos de dados.
Uma solicitação para habilitar a autenticação Kerberos pode falhar por conta de um novo problema de conectividade de rede ou de um perfil do IAM incorreto. Em alguns casos, poderá haver falha na tentativa de habilitar a autenticação Kerberos quando você criar ou modificar uma instância de banco de dados. Nesse caso, verifique se você está usando o perfil do IAM correto e modifique a instância de banco de dados para ingressar no domínio.
**nota**
Somente a autenticação Kerberos com o RDS para PostgreSQL envia tráfego para os servidores DNS do domínio. Todas as outras solicitações de DNS são tratadas como acesso à rede de saída nas instâncias de banco de dados que executam o PostgreSQL. Para obter mais informações sobre o acesso à rede de saída com o RDS para PostgreSQL, consulte [Usar um servidor DNS personalizado para acesso à rede de saída](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md).
# Conectar-se ao PostgreSQL com a autenticação Kerberos
Você pode se conectar ao PostgreSQL com autenticação Kerberos com a interface pgAdmin ou com uma interface de linha de comando, como psql. Para obter mais informações sobre a conexão, consulte [Conectar a uma instância de banco de dados executando o mecanismo de banco de dados do PostgreSQL](USER_ConnectToPostgreSQLInstance.md) . Para saber como obter o endpoint, o número da porta e outros detalhes necessários para a conexão, consulte [Conectar-se à instância de banco de dados PostgreSQL](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md#CHAP_GettingStarted.Connecting.PostgreSQL).
**nota**
A autenticação e a criptografia GSSAPI no PostgreSQL são implementadas pela biblioteca Kerberos `libkrb5.so`. Recursos como `postgres_fdw` e `dblink` também dependem dessa mesma biblioteca para conexões de saída com autenticação ou criptografia Kerberos.
## pgAdmin
Para usar o pgAdmin para conectar-se ao PostgreSQL com autenticação Kerberos, execute as seguintes etapas:
1. Inicie a aplicação pgAdmin no computador cliente.
1. Na guia **Dashboard (Painel)**, escolha **Add New Server (Adicionar novo servidor)**.
1. Na caixa de diálogo **Criar - servidor**, insira um nome na guia **Geral** para identificar o servidor no pgAdmin.
1. Na guia **Connection** (Conexão), insira as seguintes informações do banco de dados do RDS para PostgreSQL.
+ Em **Host**, insira o endpoint da Instância de banco de dados do RDS para PostgreSQL. Um endpoint é semelhante ao seguinte:
```
RDS-DB-instance.111122223333.aws-region.rds.amazonaws.com
```
Para se conectar a um Microsoft Active Directory on-premises de um cliente Windows, use o nome de domínio do AWS Managed Active Directory em vez de `rds.amazonaws.com` no endpoint do host. Por exemplo, suponha que o nome de domínio do Managed Active Directory da AWS seja `corp.example.com`. Depois, em **Host**, o endpoint seria especificado da seguinte forma:
```
RDS-DB-instance.111122223333.aws-region.corp.example.com
```
+ Em **Porta**, insira a porta designada.
+ Em **Banco de dados de manutenção**, insira o nome do banco de dados inicial ao qual o cliente se conectará.
+ Em **Nome de usuário**, insira o nome de usuário que você inseriu para a autenticação Kerberos em [Etapa 7: Criar usuários do PostgreSQL para suas entidades principais do Kerberos](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins).
1. Escolha **Salvar**.
## Psql
Para usar o psql para conectar-se ao PostgreSQL com autenticação Kerberos, execute as seguintes etapas:
1. Em um prompt de comando, execute o comando a seguir.
```
kinit username
```
Substitua *`username`* pelo nome de usuário. No prompt, insira a senha armazenada no Microsoft Active Directory para o usuário.
1. Se a instância de banco de dados PostgreSQL estiver usando uma VPC acessível publicamente, coloque um endereço IP para o endpoint do da instância de banco de dados em seu arquivo `/etc/hosts` no cliente do EC2. Por exemplo, os comandos a seguir obtêm o endereço IP e o colocam no arquivo `/etc/hosts`.
```
% dig +short PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com
;; Truncated, retrying in TCP mode.
ec2-34-210-197-118.AWS-Region.compute.amazonaws.com.
34.210.197.118
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com" >> /etc/hosts
```
Se você estiver usando um Microsoft Active Directory on-premises de um cliente Windows, será necessário se conectar usando um endpoint especializado. Em vez de usar o domínio `rds.amazonaws.com` da Amazon no endpoint do host, use o nome de domínio do Managed Active Directory da AWS.
Por exemplo, suponha que o nome de domínio do Managed Active Directory da AWS seja `corp.example.com`. Use o formato `PostgreSQL-endpoint.AWS-Region.corp.example.com` para o endpoint e coloque-o no arquivo `/etc/hosts`.
```
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.corp.example.com" >> /etc/hosts
```
1. Use o comando psql a seguir para fazer login em uma instância de banco de dados PostgreSQL com integração ao Active Directory.
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com postgres
```
Para fazer login no cluster de banco de dados PostgreSQL de um cliente Windows usando um Active Directory on-premises, use o seguinte comando psql com o nome de domínio da etapa anterior (`corp.example.com`):
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.corp.example.com postgres
```
# Usar um servidor DNS personalizado para acesso à rede de saída
O RDS para PostgreSQL é compatível com o acesso à rede de saída nas instâncias de banco de dados e permite a resolução Domain Name Service (DNS) de um servidor DNS de propriedade do cliente. Você pode resolver apenas nomes de domínio totalmente qualificados a partir da sua instância de banco de dados do RDS para PostgreSQL por meio do seu servidor DNS personalizado.
**Topics**
+ [
## Ativar resolução DNS personalizada
](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Enable)
+ [
## Desativar resolução DNS personalizada
](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Disable)
+ [
## Configuração de um servidor DNS personalizado
](#Appendix.Oracle.CommonDBATasks.CustomDNS.Setup)
## Ativar resolução DNS personalizada
Para ativar a resolução DNS na VPC do cliente, primeiro associe um grupo de parâmetros de banco de dados personalizado à instância do RDS para PostgreSQL. Em seguida, ative o parâmetro `rds.custom_dns_resolution` definindo-o como 1 e reinicie a instância de banco de dados para que as alterações sejam aplicadas.
## Desativar resolução DNS personalizada
Para desativar a resolução de DNS na VPC do cliente, primeiro desative o parâmetro `rds.custom_dns_resolution` do grupo de parâmetros de banco de dados personalizado definindo-o como 0. Em seguida, reinicie a instância de banco de dados para que as alterações entrem em vigor.
## Configuração de um servidor DNS personalizado
Após a configuração do seu servidor de nomes DNS personalizado, demora até 30 minutos para propagar as alterações na sua instância de banco de dados. Depois que as alterações são propagadas para sua a instância de banco de dados, todo o tráfego de rede de saída que requer uma pesquisa de DNS consulta o servidor DNS por meio da porta 53.
**nota**
Se você não configurar um servidor DNS personalizado e se `rds.custom_dns_resolution` estiver definido como 1, os hosts serão resolvidos usando uma zona privada do Amazon Route 53. Para obter mais informações, consulte [Como trabalhar com zonas hospedadas privadas](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html).
**Para configurar um servidor DNS personalizado para a instância de banco de dados do RDS para PostgreSQL**
1. Nas opções de Protocolo de Configuração Dinâmica de Host (DHCP) anexadas à sua VPC, defina a opção `domain-name-servers` como o endereço IP do seu servidor de nomes DNS. Para obter mais informações, consulte [Conjuntos de opções de DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html).
**nota**
A opção `domain-name-servers` aceita até quatro valores, mas sua instância de banco de dados do Amazon RDS usa apenas o primeiro valor.
1. Certifique-se de que seu servidor DNS possa resolver todas as consultas de pesquisa, incluindo nomes DNS públicos, nomes DNS privados do Amazon EC2 e nomes DNS específicos do cliente. Se o tráfego de rede de saída contiver pesquisas de DNS que o seu servidor DNS não pode manipular, este deverá ter provedores de DNS upstream configurados.
1. Configure seu servidor DNS para produzir respostas de protocolo UDP de 512 bytes ou menos.
1. Configure seu servidor DNS para produzir respostas de protocolo TCP de 1.024 bytes ou menos.
1. Configure seu servidor DNS para permitir tráfego de entrada das suas instâncias de banco de dados do Amazon RDS pela porta 53. Se o seu servidor DNS estiver em uma Amazon VPC, esta deverá ter um grupo de segurança que contenha regras de entrada que permitam tráfego UDP e TCP na porta 53. Se o servidor DNS não estiver em uma Amazon VPC, ele deverá ter configurações de firewall apropriadas para permitir o tráfego de entrada UDP e TCP na porta 53.
Para obter mais informações, consulte [Grupos de segurança para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) e [Adição e remoção de regras](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules).
1. Configurar a VPC da sua instância de banco de dados do Amazon RDS para permitir o tráfego de saída por meio da porta 53. Sua VPC deve ter um grupo de segurança que contém regras de saída que permitem o tráfego TCP e UDP na porta 53.
Para obter mais informações, consulte [Grupos de segurança para a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) e [Adicionar e remover regras](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules) no *Guia do usuário da Amazon VPC*.
1. Certifique-se de que o caminho de roteamento entre a instância de banco de dados Amazon RDS e o servidor DNS esteja configurado corretamente para permitir o tráfego DNS.
Também, se a instância de banco de dados Amazon RDS e o servidor DNS não estiverem na mesma VPC, verifique se uma conexão de emparelhamento está configurada entre eles. Para obter mais informações, consulte [O que é emparelhamento de VPC?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) no *Guia de emparelhamento da Amazon VPC*.
# Atualizações do mecanismo de banco de dados do RDS para PostgreSQL
Há dois tipos de atualizações que você pode gerenciar para o banco de dados do PostgreSQL:
+ Atualizações de sistema operacionais: ocasionalmente, o Amazon RDS pode precisar atualizar o sistema operacional subjacente do banco de dados para aplicar correções de segurança ou alterações no sistema operacional. Decida quando o Amazon RDS aplicará atualizações de SO usando o console do RDS, a AWS Command Line Interface (AWS CLI) ou a API do RDS. Para obter mais informações sobre atualizações de SO, consulte [Aplicar atualizações para uma instânciade banco de dados](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades).
+ Atualizações de mecanismos de banco de dados: quando o Amazon RDS comporta uma nova versão de um mecanismo de banco de dados, você pode atualizar os de bancos de dados para essa nova versão.
Nesse contexto, *banco de dados* é uma instância de banco de dados do RDS para PostgreSQL ou um cluster de banco de dados multi-AZ.
Há dois tipos de atualizações do mecanismo de bancos de dados do PostgreSQL: de versão principal e de versão secundária.
**Atualizações de versão principal**
As *atualizações da versão principal* podem conter as alterações de banco de dados incompatíveis com os aplicativos existentes. Por isso, você deve realizar manualmente as atualizações de versões principais dos bancos de dados. Você pode iniciar uma atualização de versão principal modificando manualmente a instância de banco de dados ou o cluster de banco de dados multi-AZ. Antes de realizar uma atualização de versão principal, recomendamos seguir as etapas descritas em [Escolher uma versão principal para uma atualização do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
O Amazon RDS gerencia os upgrades de versões principais multi-AZ das seguintes formas:
+ **Implantação de instância de banco de dados multi-AZ**: o Amazon RDS faz upgrade simultaneamente da instância primária e de todas as instâncias de espera. O banco de dados pode ficar indisponível por vários minutos enquanto o upgrade é concluído.
+ **Implantação de cluster de banco de dados multi-AZ**: o Amazon RDS faz upgrade simultaneamente das instâncias de gravador e leitor. O banco de dados pode ficar indisponível por vários minutos enquanto o upgrade é concluído.
Se você fizer upgrade de uma instância de banco de dados com réplicas de leitura na região, o Amazon RDS fará upgrade das réplicas e da 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. Se você realizar uma atualização de versão principal de um cluster de banco de dados multi-AZ, o estado da replicação das réplicas de leitura mudará para **Encerrado**. Você deve excluir e recriar as réplicas de leitura manualmente após a conclusão da atualização.
É possível minimizar o tempo de inatividade necessário para a atualização da versão principal utilizando uma implantação azul/verde. Para obter mais informações, consulte [Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados](blue-green-deployments.md).
**Atualizações de versões secundárias**
Por outro lado, *atualizações de versões secundárias* incluem apenas alterações compatíveis com versões anteriores dos aplicativos existentes. Você pode iniciar uma atualização de versão secundária manualmente modificando o banco de dados. Ou é possível habilitar a opção **Upgrade automático de versões secundárias** ao criar ou modificar um banco de dados. Isso significa que o Amazon RDS atualiza automaticamente o banco de dados depois de testar e aprovar a nova versão.
O Amazon RDS gerencia os upgrades de versões secundárias multi-AZ das seguintes formas:
+ **Implantação de instância de banco de dados multi-AZ**: o Amazon RDS faz upgrade simultaneamente da instância primária e de todas as instâncias de espera. O banco de dados pode ficar indisponível por vários minutos enquanto o upgrade é concluído.
+ **Implantação de cluster de banco de dados multi-AZ**: o Amazon RDS faz upgrade das instâncias de banco de dados de leitor, uma por vez. Depois, uma das instâncias de banco de dados de leitor passa a ser a nova instância de banco de dados de gravador. Depois, o Amazon RDS atualiza a antiga instância de gravador (que agora é uma instância de leitor). Os clusters de banco de dados multi-AZ normalmente reduzem o tempo de inatividade de atualizações de versões secundárias para aproximadamente 35 segundos. Quando usado com o RDS Proxy, é possível reduzir ainda mais o tempo de inatividade para um segundo ou menos. Para obter mais informações, consulte [Amazon RDS Proxy](rds-proxy.md). Como alternativa, é possível usar um proxy de banco de dados de código aberto, como [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/), [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/) ou [driver avançado de encapsulamento JDBC da AWS](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/).
Se o banco de dados tiver réplicas de leitura, primeiro faça upgrade de todas elas antes de fazer upgrade da instância ou do cluster de origem.
Para obter mais informações, consulte [Atualizações automáticas da versão secundária para o RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.Minor.md). Para obter informações sobre como executar manualmente uma atualização de versão secundária, consulte [Atualizar manualmente a versão do mecanismo](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
Para ter mais informações sobre versões de mecanismos de banco de dados e a política de descontinuação dessas versões, consulte [Versões de mecanismos de banco de dados](https://aws.amazon.com/rds/faqs/#Database_Engine_Versions) nas Perguntas frequentes sobre o Amazon RDS.
**Topics**
+ [
## Considerações sobre atualizações do PostgreSQL
](#USER_UpgradeDBInstance.PostgreSQL.Considerations)
+ [
## Encontrar destinos de atualização válidos
](#USER_UpgradeDBInstance.PostgreSQL.FindingTargets)
+ [
# Números de versão do PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.VersionID.md)
+ [
# Números de versão do RDS no RDS para PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.rds.version.md)
+ [
# Escolher uma versão principal para uma atualização do RDS para PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
+ [
# Como atualizar a versão principal do RDS para PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)
+ [
# Atualizações automáticas da versão secundária para o RDS para PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.Minor.md)
+ [
# Atualizar extensões do PostgreSQL em bancos de dados do RDS para PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)
+ [
# Monitorar atualizações do mecanismo do RDS para PostgreSQL com eventos
](USER_UpgradeDBInstance.PostgreSQL.Monitoring.md)
## Considerações sobre atualizações do PostgreSQL
Para fazer a atualização dos bancos de dados com segurança, o Amazon RDS usa o utilitário `pg_upgrade`, descrito na [documentação do PostgreSQL](https://www.postgresql.org/docs/current/pgupgrade.html)
Se o período de retenção de backup for maior que 0, o Amazon RDS usará dois snapshots de banco de dados durante o processo de upgrade. O primeiro snapshot de banco de dados é do banco de dados antes de qualquer alteração de atualização ter sido feita. Se a atualização apresentar falha para seus bancos de dados, você poderá restaurar esse snapshot para criar um banco de dados que execute a versão antiga. O segundo snapshot de banco de dados é tirado após a conclusão do upgrade. Esses snapshots de banco de dados são excluídos automaticamente quando o período de retenção do backup expira.
**nota**
O Amazon RDS só tirará snapshots de banco de dados durante o processo de atualização se você tiver definido o período de retenção de backup para o banco de dados como um número maior que 0. Para modificar o período de retenção de backup para uma instância de banco de dados, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). Não é possível configurar um período de retenção de backup personalizado para um cluster de banco de dados multi-AZ.
Ao fazer uma atualização de versão principal de uma instância de banco de dados, qualquer réplica de leitura na região também será atualizada automaticamente. Após o início do fluxo de trabalho de atualização, as réplicas de leitura aguardam até que a `pg_upgrade` seja concluída com êxito na instância de banco de dados primária. Depois disso, 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ê enfrenta uma interrupção até que a atualização seja concluída. Quando você realiza uma atualização de versão principal de um cluster de banco de dados multi-AZ, o estado da replicação das réplicas de leitura muda para **Encerrado**.
Depois que uma atualização for concluída, não será possível reverter para a versão anterior do mecanismo de banco de dados. Se quiser retornar à versão anterior, restaure o snapshot de banco de dados que foi tirado antes da atualização para criar um banco de dados.
## Encontrar destinos de atualização válidos
Ao usar o Console de gerenciamento da AWS para atualizar um banco de dados, ele exibe os destinos de atualização válidos para o banco de dados. Também é possível usar o seguinte comando da AWS CLI para identificar os destinos de atualização válidos para um banco de dados:
Para Linux, macOS ou Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version version-number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Para Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version version-number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Por exemplo, para identificar os destinos de atualização válidos para um banco de dados PostgreSQL versão 16.1, execute o seguinte comando da AWS CLI:
Para Linux, macOS ou Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Para Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# Números de versão do PostgreSQL
A sequência de numeração da versão do mecanismo de banco de dados do PostgreSQL é a seguinte:
+ Para versões 10 e posteriores do PostgreSQL, o número da versão do mecanismo é no formato *major.minor*. O número da versão principal é a parte inteira do número da versão. O número da versão secundária é a parte fracionária do número da versão.
Uma atualização de versão principal aumenta a parte inteira do número da versão, como atualizar de 10.*minor* para 11.*minor*.
+ Para versões do PostgreSQL anteriores à 10, o número da versão do mecanismo é no formato *major.major.minor*. O número da versão principal do mecanismo é o número inteiro e a primeira parte fracionária do número da versão. Por exemplo, a 9.6 é uma versão principal. O número da versão secundária é a terceira parte do número da versão. Por exemplo, para a versão 9.6.12, 12 é o número da versão secundária.
Uma atualização de versão principal aumenta a parte principal do número da versão. Por exemplo, uma atualização de *9.6*.12 para 11.14 é uma atualização de versão principal, em que *9.6* e *11* são os números da versão principal.
Consulte informações sobre a numeração de versão do Suporte estendido do RDS em [Nomenclatura da versão do Suporte estendido do Amazon RDS](extended-support-versions.md#extended-support-naming).
# Números de versão do RDS no RDS para PostgreSQL
Os números de versão do RDS usam o esquema de nomenclatura `major.minor.patch`. Uma versão do patch do RDS inclui correções de bugs importantes adicionadas a uma versão secundária após o lançamento. Consulte informações sobre a numeração de versão do Suporte estendido do RDS em [Nomenclatura da versão do Suporte estendido do Amazon RDS](extended-support-versions.md#extended-support-naming).
Para identificar o número da versão do Amazon RDS do banco de dados, você deve primeiro criar a extensão `rds_tools` usando o seguinte comando:
```
CREATE EXTENSION rds_tools;
```
A partir do lançamento do PostgreSQL versão 15.2-R2, você pode descobrir o número de versão do RDS do banco de dados do RDS para PostgreSQL com a seguinte consulta SQL:
```
postgres=> SELECT rds_tools.rds_version();
```
Por exemplo, consultar um banco de dados do RDS para PostgreSQL 15.2 retorna o seguinte:
```
rds_version
----------------
15.2.R2
(1 row)
```
# Escolher uma versão principal para uma atualização do RDS para PostgreSQL
As atualizações para versões principais podem conter alterações incompatíveis com as versões anteriores do banco de dados. A nova funcionalidade pode fazer com que suas aplicações existentes parem de funcionar corretamente. Por esse motivo, o Amazon RDS não aplica atualizações para versões principais automaticamente. Para realizar uma atualização de versão principal, modifique manualmente o banco de dados. Teste completamente qualquer atualização para verificar se as aplicações funcionam corretamente antes de aplicá-la aos bancos de dados de produção. Ao fazer uma atualização de versão principal do PostgreSQL, recomendamos que você siga as etapas descritas em [Como atualizar a versão principal do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Ao atualizar a implantação de uma instância de banco de dados single-AZ ou multi-AZ do PostgreSQL para a próxima versão principal, todas as réplicas de leitura associadas ao banco de dados também serão atualizadas para a próxima versão principal. Em alguns casos, você pode pular para uma versão principal mais alta ao atualizar. Se a atualização ignorar uma versão principal, as réplicas de leitura também serão atualizadas para essa versão principal de destino. As atualizações para a versão 11 que ignoram outras versões principais têm certas limitações. Você pode encontrar os detalhes nas etapas descritas em [Como atualizar a versão principal do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
A maioria das extensões do PostgreSQL não é atualizada durante uma atualização de mecanismo do PostgreSQL. Elas devem ser atualizadas separadamente. Para obter mais informações, consulte [Atualizar extensões do PostgreSQL em bancos de dados do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
Você pode descobrir quais versões principais estão disponíveis para o banco de dados do RDS para PostgreSQL executando a seguinte consulta da AWS CLI:
```
aws rds describe-db-engine-versions --engine postgres --engine-version your-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
A tabela a seguir resume os resultados dessa consulta para todas as versões disponíveis. Um asterisco (\$1) no número da versão significa que ela foi descontinuada. Se a versão atual não for compatível, recomendamos que você atualize para o destino de atualização da versão secundária mais recente ou para um dos outros destinos de atualização disponíveis para essa versão.
| Versão de origem atual | Destinos de atualização |
| --- | --- |
| 17.6 | Nenhum |
| 17.5 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 17.4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) |
| 17.3\$1, 17.2 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) |
| 17.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) |
| 16.10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 16.9 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 16,8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) |
| 16.7\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.7 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.6 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.5\$1, 16.4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) |
| 16.3 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) |
| 16.2\$1, 16.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) |
| 15.14 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 15.13 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 15.12, 15.11\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) |
| 15.10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) |
| 15.9\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15.8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15.7 | [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version167), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version165), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) |
| 15.6\$1, 15.5\$1, 15.4\$1, 15.3\$1, 15.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) |
| 14.19 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 14.18 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 14.17, 14.16\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) |
| 14.15 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) |
| 14.14\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) |
| 14.13 | [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414) |
| 14.12 | [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) |
| 14.11\$1, 14.10\$1, 14.9\$1, 14.8\$1, 14.7\$1, 14.6\$1, 14.5\$1, 14.4\$1, 14.3\$1, 14.2\$1, 14.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) |
| 13.22 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 13.21 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) |
| 13.20, 13.19\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 13.18, 13.17\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) |
| 13.16 | [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317) |
| 13.15 | [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) |
| 13.16, 13.15, 13.14, 13.13, 13.12, 13.11, 13.10, 13.9, 13.8, 13.7, 13.6, 12.18, 12.17, 12.16, 12.15, 12.14, 12.13, 12.12, 12.11 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) |
| 12.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 12.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.22, 12.21\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.20\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.19\$1, 12.18\$1, 12.17\$1, 12.16\$1, 12.15\$1, 12.14\$1, 12.13\$1, 12.12\$1, 12.11\$1, 12.10\$1, 12.9\$1, 12.8\$1, 12.7\$1, 12.6\$1, 12.5\$1, 12.4\$1, 12.3\$1, 12.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22-rds.20240509 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808), [11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121), [11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220), [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22, 11.21\$1, 11.20\$1, 11.19\$1, 11.18\$1, 11.17\$1, 11.16\$1, 11.15\$1, 11.14\$1, 11.13\$1, 11.12\$1, 11.11\$1, 11.10\$1, 11.9\$1, 11.8\$1, 11.7\$1, 11.6\$1, 11.5\$1, 11.4\$1, 11.2\$1, 11.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240418](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240418), [11.22-rds.20240509](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240509), [11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808), [11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121), [11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220), [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
\$1 Esta versão não é mais compatível.
# 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:
1. **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 obter mais informações, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md) e [Trabalhar com grupos de parâmetros de clusters de banco de dados multi-AZ](USER_WorkingWithDBClusterParamGroups.md).
1. **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 obter mais informações, consulte [Mecanismos de banco de dados compatíveis para classes de instância de banco de dados](Concepts.DBInstanceClass.Support.md).
1. **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\$1** – Remova todos os usos dos tipos de dados *reg\$1* antes de tentar fazer uma atualização. Exceto por `regtype` e `regclass`, você não pode atualizar os tipos de dados *reg\$1*. 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\$1* 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');
```
1. **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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/appendix.postgresql.commondbatasks.autovacuumbehavior.html).
1. **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 WHERE slot_type NOT LIKE 'physical';
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 o RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
Na versão de origem 17 e posterior, os slots de replicação lógica em réplicas não lidas podem ser mantidos por meio de atualizações. Os slots de replicação lógica criados em réplicas de leitura não são retidos por meio de atualizações.
Antes de iniciar a atualização, verifique se todas as transações e mensagens de decodificação lógica foram consumidas do slot. Se houver arquivos de log de gravação antecipada (WAL) não consumidos mantidos por slots de replicação lógica, a atualização falhará e exibirá uma mensagem identificando os slots com problema. Para obter mais detalhes, consulte a [documentação do PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-upgrade.html).
Em clusters multi-AZ com versões de origem anteriores à 17.8 ou 18.2, garanta que `flow_control` esteja desabilitada. Para ter mais informações, consulte [Ativar e desativar o controle de fluxo para clusters de banco de dados multi-AZ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html#multi-az-db-clusters-concepts-replica-lag). Você pode desativar o controle de fluxo removendo a extensão do `shared_preload_libraries` e reinicializando sua instância de banco de dados.
1. **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 ter mais informações sobre réplicas de leitura, consulte [Trabalhar com réplicas de leitura do Amazon RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md).
1. **Manipular objetos grandes**: no PostgreSQL, objetos grandes (também conhecidos como BLOBs) são usados para armazenar e gerenciar objetos binários grandes (como arquivos, imagens, vídeos etc.) que são maiores do que o tamanho máximo permitido para tipos de dados de colunas regulares. Para acessar mais informações, consulte a [documentação sobre objetos grandes do PostgreSQL](https://www.postgresql.org/docs/current/largeobjects.html).
Uma atualização poderá ficar sem memória e falhar se houver milhões de objetos grandes, e a instância não puder manipulá-los durante uma atualização. O processo de atualização da versão principal do PostgreSQL compreende duas fases amplas: despejar o esquema via pg\$1dump e restaurá-lo por meio de pg\$1restore. Se seu banco de dados tiver milhões de objetos grandes, você precisará garantir que sua instância tenha memória suficiente para lidar com o pg\$1dump e o pg\$1restore durante uma atualização e escalá-la para um tipo de instância maior.
Antes de começar uma atualização, confira se seu banco de dados tem objetos grandes. O catálogo `pg_largeobject_metadata` contém metadados associados a objetos grandes. Os dados reais de objetos grandes são armazenados em `pg_largeobject`. Use a consulta a seguir para conferir se há objetos grandes:
```
SELECT count(*) FROM pg_largeobject_metadata;
```
Para limpar objetos grandes existentes ou objetos grandes órfãos, consulte [Gerenciar objetos grandes com o módulo lo](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_large_objects_lo_extension.html).
Ao planejar uma atualização de versão principal, recomendamos usar um tipo de instância com pelo menos 32 GB de memória se seu banco de dados contiver de 25 a 30 milhões de objetos grandes. Essa recomendação é baseada em nossos testes e pode variar dependendo da sua workload específica e da configuração do banco de dados. Se seu banco de dados incluir objetos adicionais (como tabelas, índices ou visões materializadas), recomendamos selecionar um tipo de instância maior a fim de garantir a performance ideal durante o processo de atualização.
1. **Gerencie as Integrações ETL zero**: se você tiver uma [Integração ETL zero](zero-etl.md) existente, [exclua-a](zero-etl.deleting.md) antes de realizar uma atualização de versão principal. Em seguida, ao concluir a atualização, recrie a integração.
Nas versões de origem posteriores à 17, a Integração ETL zero pode ser mantida por meio da atualização.
1. **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](Overview.DBInstance.Modifying.md) e [Modificar um cluster de banco de dados multi-AZ para o Amazon RDS](modify-multi-az-db-cluster.md).
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](USER_CreateSnapshot.md) e [Criar um snapshot do cluster de banco de dados multi-AZ para o Amazon RDS](USER_CreateMultiAZDBClusterSnapshot.md).
1. **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`
Você não pode atualizar diretamente para a versão 17 do PostgreSQL se estiver usando `rdkit` versão 4.6.0 e anterior e o PostgreSQL versão 16 e anterior, devido à incompatibilidade `rdkit`. Confira abaixo as opções de atualização:
+ Se você estiver usando a versão 13 ou anterior do PostgreSQL, precisará primeiro realizar uma atualização da versão principal para a versão 14.14 ou versões 14 posteriores, 15.9 ou versões 15 posteriores, ou 16.5 ou versões 16 posteriores e, em seguida, realizar a atualização para o PostgreSQL 17.
+ Se você estiver usando a versão 14, 15 ou 16 do PostgreSQL, precisará realizar uma atualização de versão secundária para 14.14 ou versões 14 posteriores, 15.9 ou versões 15 posteriores, ou 16.5 ou versões 16 posteriores e, em seguida, atualizar para a versão 17 do PostgreSQL.
Execute o comando a seguir para cada extensão que você está usando:
```
ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
```
Para obter mais informações, consulte [Atualizar extensões do PostgreSQL em bancos de dados do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md). Para saber mais sobre como fazer upgrade do PostGIS, consulte [Etapa 6: Atualize a extensão PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update).
1. **Elimine determinadas extensões antes da atualização da versão principal**: extensões não compatíveis na versão de destino devem ser descartadas; do contrário, a atualização falhará.
A extensão `plrust` é removida a partir do RDS para PostgreSQL 18. A extensão `postgis_topology` não está disponível nas versões 18.1 e 18.2 do RDS para PostgreSQL devido a problemas conhecidos [[1](https://trac.osgeo.org/postgis/ticket/5983)], [[2](https://trac.osgeo.org/postgis/ticket/6016)]. Essas extensões devem ser removidas antes da atualização.
Uma atualização que ignora uma versão principal e implementa a versão 11.x não permite a atualização da extensão `pgRouting`. A atualização 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](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md).
As extensões `tsearch2` e `chkpass` não são mais compatíveis com o PostgreSQL versões 11 ou posterior.
É possível verificar se uma extensão está instalada com a seguinte consulta:
```
SELECT * FROM pg_extension WHERE extname in ('extension_name');
```
1. **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';
```
1. **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](USER_RestoreFromSnapshot.md#USER_RestoreFromSnapshot.Restoring) ou [Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS](USER_PIT.md). Para clusters de banco de dados multi-AZ, consulte [Restaurar a partir de um snapshot para cluster de banco de dados multi-AZ](USER_RestoreFromMultiAZDBClusterSnapshot.Restoring.md) ou [Restaurar um cluster de banco de dados multi-AZ para um horário especificado](USER_PIT.MultiAZDBCluster.md).
Para obter detalhes sobre como realizar a atualização, consulte [Atualizar manualmente a versão do mecanismo](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
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](https://www.postgresql.org/docs/10/parallel-query.html) 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.
1. **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](USER_LogAccess.md).
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.
```
1. **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.
1. **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 obter mais informações, consulte [Atualizar manualmente a versão do mecanismo](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
1. 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](https://www.postgresql.org/docs/10/sql-analyze.html) na documentação do PostgreSQL.
Ao analisar tabelas específicas em vez de usar ANALYZE VERBOSE, execute o comando ANALYZE para cada tabela da seguinte forma:
```
ANALYZE table_name;
```
Para tabelas particionadas, sempre analise a tabela principal. Esse processo:
+ Examina as linhas por amostragem automaticamente em todas as partições.
+ Atualiza as estatísticas de cada partição recursivamente.
+ Mantém estatísticas essenciais de planejamento no nível da tabela principal.
Embora as tabelas principais não armazenem dados reais, analisá-las é vital para otimizar as consultas. Executar ANALYZE somente em partições individuais pode levar a um desempenho de consulta insatisfatório, pois o otimizador não terá as estatísticas abrangentes necessárias para um planejamento eficiente entre partições.
**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](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
+ 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](USER_LogAccess.md).
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](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs).
+ 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.
# Atualizações automáticas da versão secundária para o RDS para PostgreSQL
Se habilitar a opção **Upgrade automático de versões secundárias** ao criar ou modificar uma instância de banco de dados ou um cluster de banco de dados multi-AZ, o banco de dados poderá ser atualizado automaticamente.
O Amazon RDS também comporta a política de implementação de atualizações para gerenciar atualizações automáticas de versões secundárias em vários recursos de banco de dados e Contas da AWS. Para obter mais informações, consulte [Usar a política de implementação de atualização do AWS Organizations para atualizações automáticas de versões secundárias](RDS.Maintenance.AMVU.UpgradeRollout.md).
Para cada versão principal do RDS para PostgreSQL, uma versão secundária é designada pelo RDS como a versão de atualização automática. Depois que uma versão secundária foi testada e aprovada pelo Amazon RDS, a atualização de versão secundária ocorre automaticamente durante a janela de manutenção. O RDS não define automaticamente versões secundárias lançadas mais recentemente como a versão de atualização automática. Antes de o RDS designar uma versão de atualização automática, diversos critérios são considerados, como estes:
+ Problemas de segurança conhecidos
+ Bugs na versão de comunidade do PostgreSQL
+ Estabilidade geral de frota desde que a versão secundária foi lançada.
É possível utilizar o comando da AWS CLI a seguir para determinar a versão atual secundária de destino de atualização automática para determinada versão secundária do PostgreSQL em uma Região da AWS específica.
Para Linux, macOS ou Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version minor-version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Para Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version minor-version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
Por exemplo, o comando da AWS CLI a seguir determina o destino de atualização secundária automática para a versão 16.1 secundária do PostgreSQL na Região da AWS Leste dos EUA (Ohio) (us-east-2).
Para Linux, macOS ou Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Para Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
A saída é semelhante à seguinte.
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| False | 16.2 |
| True | 16.3 |
| False | 16.4 |
| False | 16.5 |
| False | 16.6 |
| False | 17.1 |
| False | 17.2 |
+--------------+-----------------+
```
Neste exemplo, o valor de `AutoUpgrade` é `True` para o PostgreSQL versão 16.3. Portanto, o destino de atualização secundária automática é o PostgreSQL versão 16.3, que está destacado na saída.
Um banco de dados do PostgreSQL será atualizado automaticamente durante a janela de manutenção, caso os seguintes critérios sejam atendidos:
+ O banco de dados tem a opção **Upgrade automático de versões secundárias** habilitada.
+ O banco de dados está executando uma versão de mecanismo de banco de dados secundária que é anterior à versão secundária de atualização automática.
Para obter mais informações, consulte [Atualizar automaticamente a versão do mecanismo espelho](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades).
**nota**
Uma atualização do PostgreSQL não atualiza extensões do PostgreSQL. Para atualizar extensões, consulte [Atualizar extensões do PostgreSQL em bancos de dados do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
# Atualizar extensões do PostgreSQL em bancos de dados do RDS para PostgreSQL
Uma atualização de mecanismo do PostgreSQL não atualiza a maior parte das extensão do PostgreSQL. Para atualizar uma extensão após uma atualização de versão, use o comando `ALTER EXTENSION UPDATE`.
**nota**
Para obter informações sobre como atualizar a extensão PostGIS, consulte [Gerenciar dados espaciais com a extensão PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md) ([Etapa 6: Atualize a extensão PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)).
Para atualizar a extensão `pg_repack`, solte a extensão e crie a versão no banco de dados atualizado. Para obter mais informações, consulte [a instalação do pg\$1repack](https://reorg.github.io/pg_repack/) na documentação do `pg_repack`.
Para atualizar uma extensão, use o seguinte comando.
```
ALTER EXTENSION extension_name UPDATE TO 'new_version';
```
Para obter a lista de versões com suporte das extensões do PostgreSQL, consulte [Versões de extensões do PostgreSQL compatíveis](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md).
Para listar as extensões instaladas no momento, use o catálogo [pg\$1extension](https://www.postgresql.org/docs/current/catalog-pg-extension.html) do PostgreSQL no comando a seguir.
```
SELECT * FROM pg_extension;
```
Para visualizar uma lista das versões de extensão específicas disponíveis para a instalação, use a visualização [ pg\$1available\$1extension\$1versions](https://www.postgresql.org/docs/current/view-pg-available-extension-versions.html) do PostgreSQL no comando a seguir.
```
SELECT * FROM pg_available_extension_versions;
```
# Monitorar atualizações do mecanismo do RDS para PostgreSQL com eventos
Quando você atualiza a versão do mecanismo de um banco de dados RDS para PostgreSQL, o Amazon RDS emite um evento específico durante cada fase do processo. Para acompanhar o progresso de uma atualização, você pode visualizar ou assinar esses eventos.
Para acessar mais informações sobre eventos do RDS, consulte [Monitorar eventos do Amazon RDS](working-with-events.md).
Para acessar informações detalhadas sobre um evento específico do Amazon RDS ocorrido durante a atualização do seu mecanismo, consulte [Categorias de eventos e mensagens de eventos ](USER_Events.Messages.md).
# Atualizar uma versão do mecanismo de snapshot de banco de dados PostgreSQL
Com o Amazon RDS, você pode criar um snapshot de banco de dados do volume de armazenamento de sua instância de banco de dados PostgreSQL. Quando você cria um snapshot de banco de dados, ele é baseado na versão do mecanismo usada pela instância do Amazon RDS. É possível fazer a atualização da versão do mecanismo para os snapshots de banco de dados.
Após restaurar um snapshot de banco de dados atualizado para uma nova versão do mecanismo, certifique-se de testar se a atualização foi bem-sucedida. Para obter mais informações sobre uma atualização de versão principal, consulte [Atualizações do mecanismo de banco de dados do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md). Para saber como restaurar um snapshot de banco de dados, consulte [Restaurar uma instância de banco de dados](USER_RestoreFromSnapshot.md).
Você pode atualizar snapshots de banco de dados manuais criptografados ou não.
Para visualizar as versões de mecanismo disponíveis para o snapshot de banco de dados do RDS para PostgreSQL, use o exemplo da AWS CLI a seguir.
```
aws rds describe-db-engine-versions --engine postgres --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text --include-all
```
Consulte mais informações sobre as versões de mecanismo disponíveis para snapshots de banco de dados do RDS para PostgreSQL em [Escolher uma versão principal para uma atualização do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
**nota**
Não é possível atualizar snapshots de banco de dados automatizados criados durante o processo de backup automatizado.
## Console
**Para atualizar um snapshot de banco de dados**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, selecione **Snapshots**.
1. Escolha o snapshot que você deseja atualizar.
1. Em **Actions (Ações)**, selecione **Upgrade snapshot (Atualizar snapshot)**. A página **Upgrade snapshot (Atualizar snapshot)** é exibida.
1. Escolha a opção **New engine version (Nova versão de mecanismo)** para a qual atualizar.
1. Escolha **Save changes (Salvar alterações)** para atualizar o snapshot.
Durante o processo de atualização, todas as ações do snapshot serão desabilitadas para esse snapshot de banco de dados. Além disso, o status do snapshot de banco de dados muda de **available (disponível)** para **upgrading (atualizando)** e muda para **active (ativo)** após a conclusão. Se não for possível atualizar o snapshot de banco de dados devido a problemas de corrupção do snapshot, o status mudará para **unavailable (indisponível)**. Não é possível recuperar o snapshot desse estado.
**nota**
Se a atualização do snapshot de banco de dados falhar, o snapshot será revertido para o estado original com a versão original.
## AWS CLI
Para atualizar um snapshot de banco de dados para uma nova versão do mecanismo de banco de dados, use o comando [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html) da AWS CLI.
**Parâmetros**
+ `--db-snapshot-identifier` – o identificador do snapshot de banco de dados a ser atualizado. O identificador deve ser um nome de recurso da Amazon (ARN) exclusivo. Para obter mais informações, consulte [Nomes de recurso da Amazon (ARNs) no Amazon RDS](USER_Tagging.ARN.md).
+ `--engine-version` – a versão do mecanismo para a qual será feita a atualização do snapshot de banco de dados.
**Example**
Para Linux, macOS ou Unix:
```
1. aws rds modify-db-snapshot \
2. --db-snapshot-identifier my_db_snapshot \
3. --engine-version new_version
```
Para Windows:
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
## API do RDS
Para atualizar um snapshot de banco de dados para uma nova versão do mecanismo de banco de dados, chame a operação [ModifyDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html) da API do Amazon RDS.
+ `DBSnapshotIdentifier` – o identificador do snapshot de banco de dados a ser atualizado. O identificador deve ser um nome de recurso da Amazon (ARN) exclusivo. Para obter mais informações, consulte [Nomes de recurso da Amazon (ARNs) no Amazon RDS](USER_Tagging.ARN.md).
+ `EngineVersion` – a versão do mecanismo para a qual será feita a atualização do snapshot de banco de dados.
# Trabalhar com réplicas de leitura do Amazon RDS para PostgreSQL
É possível escalar as leituras da instância de banco de dados do Amazon RDS para PostgreSQL adicionando réplicas de leitura à instância. Assim como acontece com outros mecanismos de banco de dados do Amazon RDS, o RDS para PostgreSQL usa os mecanismos de replicação nativos do PostgreSQL para manter as réplicas de leitura atualizadas com as alterações no banco de dados de origem. Para obter informações gerais sobre as réplicas de leitura e o Amazon RDS, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md).
A seguir, você pode encontrar informações específicas sobre como trabalhar com réplicas de leitura com o RDS para PostgreSQL.
## Limitações de réplicas de leitura com o PostgreSQL
As limitações de réplicas de leitura do PostgreSQL são as seguintes:
+ As réplicas de leitura do PostgreSQL são somente leitura. Embora uma réplica de leitura não seja uma instância de banco de dados gravável, é possível promovê-la para se tornar uma instância de banco de dados do RDS para PostgreSQL autônoma. No entanto, o processo é irreversível.
+ Não será possível criar uma réplica de leitura de outra réplica de leitura se a instância de banco de dados do RDS para PostgreSQL estiver executando uma versão do PostgreSQL anterior à 14.1. O RDS para PostgreSQL é compatível com réplicas de leitura em cascata somente no RDS para PostgreSQL versão 14.1 e versões superiores. Para obter mais informações, consulte [Usar réplicas de leitura em cascata com o RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Se você promover uma réplica de leitura do PostgreSQL, ela se tornará uma instância de banco de dados gravável. Ela deixa de receber arquivos de log de gravação antecipada (WAL) de uma instância de banco de dados de origem e não é mais uma instância somente leitura. É possível criar réplicas de leitura da instância de banco de dados promovida da mesma forma como você faz para qualquer instância de banco de dados do RDS para PostgreSQL. Para obter mais informações, consulte [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md).
+ Se você promover uma réplica de leitura do PostgreSQL de dentro de uma cadeia de replicação (uma série de réplicas de leitura em cascata), todas as réplicas de leitura posteriores existentes continuarão recebendo arquivos WAL da instância promovida, automaticamente. Para obter mais informações, consulte [Usar réplicas de leitura em cascata com o RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ A réplica de leitura do PostgreSQL associada mostrará um atraso de replicação de até 5 minutos se não houver nenhuma transação de usuário em execução na instância do banco de dados de origem. O atraso da réplica é calculado como `currentTime - lastCommitedTransactionTimestamp`, o que significa que quando nenhuma transação está sendo processada, o valor do atraso da réplica aumenta por um período até que o segmento do log de gravação antecipada (WAL) mude. Por padrão, o RDS para PostgreSQL alterna o segmento do WAL a cada 5 minutos, o que resulta em um registro de transação e uma diminuição no atraso relatado.
+ Não é possível ativar backups automatizados de réplicas de leitura do PostgreSQL de versões do RDS para PostgreSQL anteriores à 14.1. Os backups automatizados de réplicas de leitura são compatíveis apenas com o RDS para PostgreSQL 14.1 e versões superiores. Para o RDS para PostgreSQL 13 e versões anteriores, crie um instantâneo de uma réplica de leitura para criar um backup dele.
+ A recuperação a um ponto anterior no tempo (PITR) não é compatível com réplicas de leitura. Você pode usar PITR somente com uma instância primária (gravadora), não com uma réplica de leitura. Para saber mais, consulte [Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS](USER_PIT.md).
+ As réplicas de leitura para PostgreSQL versões 12 e anteriores são reiniciadas automaticamente durante a janela de manutenção de 60 a 90 dias para aplicar a rotação de senhas. Se a réplica perder a conexão com a origem antes da reinicialização programada, ela ainda será reinicializada para retomar a replicação. Para as versões 13 e posteriores do PostgreSQL, as réplicas de leitura podem sofrer breves desconexões e reconexões de replicação durante o processo de rotação de senhas.
# Configuração de réplica de leitura com o PostgreSQL
O RDS para PostgreSQL usa a replicação de streaming nativo do PostgreSQL para criar uma cópia somente leitura de uma instância de banco de dados de origem. Essa instância de banco de dados da réplica de leitura é uma replicação física criada assincronamente da instância de banco de dados de origem. Ela é criada por uma conexão especial que transmite dados de log de gravação antecipada (WAL) da instância de banco de dados de origem e a réplica de leitura. Para obter mais informações, consulte [Streaming Replication](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) (Replicação em streaming) na documentação do PostgreSQL.
O PostgreSQL faz streaming de forma assíncrona das alterações do banco de dados para essa conexão segura conforme são feitas na instância de banco de dados de origem. É possível criptografar comunicações de aplicações de clientes com a instância de banco de dados de origem ou qualquer réplica de leitura definindo o parâmetro `ssl` como `1`. Para obter mais informações, consulte [Usar o SSL com uma instância de banco de dados PostgreSQL](PostgreSQL.Concepts.General.SSL.md) .
O PostgreSQL usa um perfil de *replicação* para realizar a replicação em streaming. O perfil é privilegiado, mas não pode ser usado para modificar nenhum dado. O PostgreSQL usa um processo único para gerenciar a replicação.
É possível criar uma réplica de leitura do PostgreSQL sem afetar as operações ou os usuários da instância de banco de dados de origem. O Amazon RDS define os parâmetros e as permissões necessários na instância de banco de dados de origem e na réplica de leitura sem afetar o serviço. Um snapshot é criado da instância de banco de dados de origem, e esse snapshot é usado para criar a réplica de leitura. Se você excluir a réplica de leitura em algum momento futuro, não ocorrerá nenhuma interrupção.
Você pode criar até quinze réplicas de leitura de uma instância de banco de dados de origem na mesma região. Desde o RDS para PostgreSQL 14.1, também é possível criar até três níveis de réplica de leitura em uma cadeia (cascata) de uma instância de banco de dados de origem. Para obter mais informações, consulte [Usar réplicas de leitura em cascata com o RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). Em todos os casos, a instância de banco de dados de origem precisa ter backups automatizados configurados. Faça isso definindo o período de retenção do backup na instância de banco de dados como qualquer valor diferente de 0. Para obter mais informações, consulte [Como criar uma réplica de leitura](USER_ReadRepl.Create.md).
É possível criar réplicas de leitura para a instância de banco de dados do RDS para PostgreSQL na mesma Região da AWS que a instância de banco de dados de origem. Isso é conhecido como replicação *na região*. Não é possível criar uma réplica de leitura em uma Regiões da AWS diferente daquela da instância de banco de dados de origem. Isso é conhecido como Replicação *entre regiões*. Para obter mais informações sobre como configurar réplicas de leitura entre regiões, consulte [Criar uma réplica de leitura em uma diferente Região da AWS](USER_ReadRepl.XRgn.md). Os vários mecanismos compatíveis com o processo de replicação na região e entre regiões diferem ligeiramente de acordo com a versão do RDS para PostgreSQL, como explicado em [Como a replicação de streaming funciona para diferentes versões do RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md).
Para que a replicação funcione efetivamente, cada réplica de leitura deve ter a mesma quantidade de recursos de computação e de armazenamento que a instância de banco de dados de origem. Se você dimensionar a instância de banco de dados de origem, dimensione as réplicas de leitura também.
O Amazon RDS substituirá todos os parâmetros incompatíveis em uma réplica de leitura se eles impedirem que a réplica de leitura seja iniciada. Por exemplo, suponha que o valor do parâmetro `max_connections` seja mais alto na instância do banco de dados de origem do que na réplica de leitura. Nesse caso, o Amazon RDS atualiza o parâmetro na réplica de leitura para ser o mesmo valor que o da instância de banco de dados de origem.
As réplicas de leitura do RDS para PostgreSQL têm acesso a bancos de dados externos que estão disponíveis por meio de wrappers de dados externos (FDWs) na instância de banco de dados de origem. Por exemplo, suponha que sua instância de banco de dados do RDS para PostgreSQL esteja usando o wrapper do `mysql_fdw` para acessar dados do RDS para o MySQL. Nesse caso, as réplicas de leitura também podem acessar esses dados. Outros FDWs compatíveis incluem `oracle_fdw`, `postgres_fdw` e `tds_fdw`. Para obter mais informações, consulte [Trabalhar com os invólucros de dados externos compatíveis do Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
## Usar réplicas de leitura do RDS para PostgreSQL com configurações multi-AZ
É possível criar uma réplica de leitura de uma instância de banco de dados single-AZ ou multi-AZ. É possível usar implantações multi-AZ para melhorar a durabilidade e a disponibilidade de dados essenciais. Uma *réplica em espera* é uma réplica de leitura dedicada que pode assumir a workload em caso de falha do banco de dados de origem. Não é possível utilizar a réplica em espera para atender ao tráfego de leitura. No entanto, é possível criar réplicas de leitura de instâncias de banco de dados multi-AZ de alto tráfego para descarregar consultas somente leitura. Para saber mais sobre implantações multi-AZ, consulte [Implantações de instâncias de banco de dados multi-AZ para o Amazon RDS](Concepts.MultiAZSingleStandby.md).
Se a instância de banco de dados de origem de uma implantação multi-AZ sofrer failover sobre a de espera, todas as réplicas de leitura associadas passarão a usar a réplica de espera (não a primária) como a origem de replicação. As réplicas de leitura podem precisar de reinicialização, de acordo com a versão do RDS para PostgreSQL, da seguinte forma:
+ **PostgreSQL 13 e versões superiores**: a reinicialização não é necessária. As réplicas de leitura são sincronizadas automaticamente com a nova primária. No entanto, em alguns casos, a aplicação cliente pode armazenar os detalhes do DNS (Domain Name Service) em cache para suas réplicas de leitura. Nesse caso, defina o valor do tempo de vida (TTL) como menos de 30 segundos. Isso impede que a réplica de leitura se mantenha em um endereço IP obsoleto (e, portanto, impede que ela sincronize com a nova primária). Para saber mais sobre essa e outras práticas recomendadas, consulte [Diretrizes operacionais básicas do Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).
+ **PostgreSQL 12 e todas as versões anteriores**: as réplicas de leitura são reiniciadas automaticamente após um failover para a réplica em espera porque a em espera (agora primária) tem um endereço IP e um nome de instância diferentes. A reinicialização sincroniza a réplica de leitura com a nova primária.
Para saber mais sobre failover, consulte [Fazer failover de uma instância de banco de dados multi-AZ para o Amazon RDS](Concepts.MultiAZ.Failover.md). Para saber mais sobre como as réplicas de leitura funcionam em uma implantação multi-AZ, consulte [Trabalhar com réplicas de leitura de instância de banco de dados](USER_ReadRepl.md).
Para oferecer suporte a failover de uma réplica de leitura, é possível criar a réplica de leitura como uma instância de banco de dados multi-AZ para que o Amazon RDS crie uma em espera de sua réplica em outra zona de disponibilidade (AZ). Você pode criar a réplica de leitura como uma instância de banco de dados multi-AZ independentemente de o banco de dados de origem ser ou não uma instância de banco de dados multi-AZ.
# Decodificação lógica em uma réplica de leitura
O RDS para PostgreSQL comporta a replicação lógica em espera com o PostgreSQL 16.1. Isso permite criar uma decodificação lógica a partir de um modo de espera somente leitura que reduza a carga na instância de banco de dados primária. É possível ter maior disponibilidade para as aplicações que precisam sincronizar dados em vários sistemas. Esse recurso melhora a performance do data warehouse e da análise de dados.
Além disso, os slots de replicação em um modo de espera específico mantêm a promoção desse modo de espera para um primário. Isso significa que, no caso de um failover de uma instância de banco de dados primária ou da promoção de uma instância de espera para a nova primária, os slots de replicação serão mantidos e os antigos assinantes em espera não serão afetados.
**Como criar a decodificação lógica em uma réplica de leitura**
1. **Ativar a replicação lógica**: para criar a decodificação lógica em espera, é necessário ativar a replicação lógica na instância de banco de dados de origem e na réplica física. Para obter mais informações, consulte [Configuração de réplica de leitura com o PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md).
+ **Para ativar a replicação lógica para uma instância de banco de dados do RDS para PostgreSQL recém-criada**, crie um grupo de parâmetros de banco de dados personalizado e defina o parâmetro estático `rds.logical_replication` como `1`. Depois, associe esse grupo de parâmetros de banco de dados à instância de banco de dados de origem e à réplica de leitura física. Para obter mais informações, consulte [Associar um grupo de parâmetros de banco de dados a uma instância de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Associating.md).
+ **Para ativar a replicação lógica para uma instância de banco de dados do RDS para PostgreSQL existente**: modifique o grupo de parâmetros personalizado do banco de dados da instância de banco de dados de origem e à réplica de leitura física para definir o parâmetro estático `rds.logical_replication` como `1`. Para obter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
**nota**
É necessário reinicializar a instância de banco de dados para aplicar essas alterações de parâmetros.
É possível usar a consulta a seguir para verificar os valores para `wal_level` e `rds.logical_replication` na instância de banco de dados de origem e na réplica de leitura física.
```
Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
name | setting
-------------------------+---------
rds.logical_replication | on
wal_level | logical
(2 rows)
```
1. **Criar uma tabela no banco de dados de origem**: conecte-se ao banco de dados na instância de banco de dados de origem. Para obter mais informações, consulte [Conectar a uma instância de banco de dados executando o mecanismo de banco de dados do PostgreSQL](USER_ConnectToPostgreSQLInstance.md).
Use as seguintes consultas para criar uma tabela no banco de dados de origem e inserir valores:
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **Criar uma publicação para a tabela de origem**: use a consulta a seguir para criar uma publicação para a tabela na instância de banco de dados de origem.
```
Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION
```
Use uma consulta SELECT para verificar os detalhes da publicação que foi criada na instância de banco de dados de origem e na instância de réplica de leitura física.
```
Postgres=>SELECT * from pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
16429 | testpub | 16413 | f | t | t | t | t | f
(1 row)
```
1. **Criar uma assinatura a partir da instância de réplica lógica**: crie outra instância de banco de dados do RDS para PostgreSQL como a instância de réplica lógica. Verifique se a VPC está configurada corretamente para garantir que essa instância de réplica lógica possa acessar a instância de réplica de leitura física. Para obter mais informações, consulte [Amazon VPC e Amazon RDS](USER_VPC.md). Se a instância de banco de dados de origem estiver ociosa, poderão ocorrer problemas de conectividade e a primária não enviará os dados para o modo de espera.
```
Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port
dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE: created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
Use uma consulta SELECT para verificar os detalhes da assinatura na instância de réplica lógica.
```
Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16429 | testsub | t | testsub | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
count
-------
10000
(1 row)
```
1. **Inspecionar o estado do slot de replicação lógica**: somente é possível ver o slot de replicação física na instância de banco de dados de origem.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
---------------------------------------------+-----------+---------------------
rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical |
(1 row)
```
No entanto, na instância de réplica de leitura, é possível ver o slot de replicação lógica e o valor `confirmed_flush_lsn` muda à medida que a aplicação consome ativamente as alterações lógicas.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/500002F0
(1 row)
```
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/5413F5C0
(1 row)
```
# Usar réplicas de leitura em cascata com o RDS para PostgreSQL
Desde a versão 14.1, o RDS para PostgreSQL é compatível com réplicas de leitura em cascata. Com *réplicas de leitura em cascata*, é possível dimensionar leituras sem adicionar sobrecarga à instância de banco de dados do RDS para PostgreSQL de origem. As atualizações do log WAL não são enviadas pela instância de banco de dados de origem a cada réplica de leitura. Em vez disso, cada réplica de leitura em uma série em cascata envia atualizações de log WAL para a próxima réplica de leitura da série. Isso reduz a carga na instância de banco de dados de origem.
Com réplicas de leitura em cascata, a instância de banco de dados do RDS para PostgreSQL envia dados de WAL para a primeira réplica de leitura da cadeia. Essa réplica de leitura envia dados de WAL para a segunda réplica na cadeia e assim por diante. O resultado final é que todas as réplicas de leitura na cadeia têm as alterações da instância de banco de dados do RDS para PostgreSQL, mas sem a sobrecarga apenas na instância de banco de dados de origem.
É possível criar uma série de até três réplicas de leitura em uma cadeia de uma instância de banco de dados de origem do RDS para PostgreSQL. Por exemplo, suponha que você tenha uma instância de banco de dados do RDS para PostgreSQL 14.1, `rpg-db-main`. Você pode fazer o seguinte:
+ Começando com `rpg-db-main`, crie a primeira réplica de leitura na cadeia, `read-replica-1`.
+ Na `read-replica-1`, crie a próxima réplica de leitura na cadeia, `read-replica-2`.
+ Finalmente, na `read-replica-2`, crie a terceira réplica de leitura na cadeia, `read-replica-3`.
Não é possível criar outra réplica de leitura além dessa terceira réplica de leitura em cascata na série de `rpg-db-main`. Uma série completa de instâncias de uma instância de banco de dados de origem do RDS para PostgreSQL até o final de uma série de réplicas de leitura em cascata pode consistir em, no máximo, quatro instâncias de banco de dados.
Para que as réplicas de leitura em cascata funcionem, ative os backups automáticos no RDS para PostgreSQL. Crie a réplica de leitura primeiro e ative os backups automáticos na instância de banco de dados do RDS para PostgreSQL. O processo é igual ao de outros mecanismos de banco de dados do Amazon RDS. Para obter mais informações, consulte [Como criar uma réplica de leitura](USER_ReadRepl.Create.md).
Como em qualquer réplica de leitura, é possível promover uma réplica de leitura que faz parte de uma cascata. A promoção de uma réplica de leitura de uma cadeia de réplicas de leitura remove essa réplica da cadeia. Por exemplo, suponha que você queira mover parte da workload da instância de banco de dados `rpg-db-main` para uma nova instância para uso somente pelo departamento de contabilidade. Pressupondo a cadeia com três réplicas de leitura do exemplo, você decide promover `read-replica-2`. A cadeia é afetada da seguinte forma:
+ A promoção de `read-replica-2` a remove da cadeia de replicação.
+ Ela agora é uma instância de banco de dados de leitura/gravação completa.
+ Ela continua replicando para `read-replica-3`, da mesma forma como estava fazendo antes da promoção.
+ A `rpg-db-main` continua a replicar para a `read-replica-1`.
Para obter mais informações sobre como promover réplicas de leitura, consulte [Promoção de uma réplica de leitura a uma instância de banco de dados autônoma](USER_ReadRepl.Promote.md).
**nota**
O RDS para PostgreSQL não aceita atualizações de versão principal para réplicas em cascata. Antes de realizar uma atualização de versão principal, você precisa remover as réplicas em cascata. Você pode recriá-las depois de concluir a atualização na instância de banco de dados de origem e nas réplicas de primeiro nível.
Para réplicas de leitura em cascata, o RDS para PostgreSQL é compatível com quinze réplicas de leitura para cada instância de banco de dados de origem no primeiro nível de replicação e cinco réplicas de leitura para cada instância de banco de dados de origem no segundo e no terceiro níveis de replicação.
# Criar réplicas de leitura em cascata entre regiões com o RDS para PostgreSQL
O RDS para PostgreSQL é compatível com réplicas de leitura em cascata entre regiões. É possível criar uma réplica entre regiões com base na instância de banco de dados de origem e, depois, criar réplicas da mesma região com base nela. Você também pode criar uma réplica da mesma região com base na instância de banco de dados de origem e, depois, criar réplicas entre regiões com base nela.
**Criar uma réplica entre regiões e, depois, criar réplicas na mesma região**
É possível usar uma instância de banco de dados do RDS para PostgreSQL com a versão 14.1 ou posterior, `rpg-db-main`, para fazer o seguinte:
1. Comece com `rpg-db-main` (US-EAST-1) e crie a primeira réplica de leitura entre regiões na cadeia, `read-replica-1` (US-WEST-2).
1. Usando a primeira região cruzada `read-replica-1` (US-WEST-2), crie a segunda réplica de leitura na cadeia, `read-replica-2` (US-WEST-2).
1. Usando `read-replica-2`, crie a terceira réplica de leitura na cadeia, `read-replica-3` (US-WEST-2).
**Criar uma réplica na mesma região e, depois, criar réplicas entre regiões**
É possível usar uma instância de banco de dados do RDS para PostgreSQL com a versão 14.1 ou posterior, `rpg-db-main`, para fazer o seguinte:
1. Começando com `rpg-db-main` (US-EAST-1), crie a primeira réplica de leitura na cadeia, `read-replica-1` (US-EAST-1).
1. Usando `read-replica-1` (US-EAST-1), crie a primeira réplica de leitura entre regiões na cadeia, `read-replica-2` (US-WEST-2).
1. Usando `read-replica-2` (US-WEST-2), crie a terceira réplica de leitura na cadeia, `read-replica-3` (US-WEST-2).
**Limitações na criação de réplicas de leitura entre regiões**
+ Uma cadeia de réplicas de banco de dados em cascata entre regiões pode abranger no máximo duas regiões, com no máximo quatro níveis. Os quatro níveis incluem a origem do banco de dados e três réplicas de leitura.
**Vantagens de usar réplicas de leitura em cascata**
+ Melhor escalabilidade de leitura: ao distribuir consultas de leitura em várias réplicas, a replicação em cascata ajuda a equilibrar a carga. Isso melhora o desempenho, especialmente em aplicações com muita leitura, reduzindo a pressão sobre o banco de dados do gravador.
+ Distribuição geográfica: as réplicas em cascata podem estar em diferentes localizações geográficas. Isso reduz a latência para usuários localizados longe do banco de dados principal e fornece uma réplica de leitura local, aprimorando o desempenho e a experiência do usuário.
+ Alta disponibilidade e recuperação de desastres: no caso de uma falha no servidor primário, as réplicas podem ser promovidas para primárias, garantindo a continuidade. A replicação em cascata aprimora ainda mais isso fornecendo várias camadas de opções de failover, o que melhora a resiliência geral do sistema.
+ Flexibilidade e crescimento modular: à medida que o sistema cresce, novas réplicas podem ser adicionadas em diferentes níveis, sem exigir uma reconfiguração importante do banco de dados principal. Essa abordagem modular permite o crescimento escalável e gerenciável da configuração de replicação.
**Prática recomendada para usar réplicas de leitura entre regiões**
+ Antes de promover uma réplica, crie réplicas adicionais. Isso economizará tempo e proporcionará um processamento eficiente da workload.
# Como a replicação de streaming funciona para diferentes versões do RDS para PostgreSQL
Conforme discutido em [Configuração de réplica de leitura com o PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md), o RDS para PostgreSQL usa o protocolo de replicação de streaming nativo do PostgreSQL para enviar dados de WAL da instância de banco de dados de origem. Ele envia dados de WAL de origem para as réplicas de leitura na região e entre regiões. Com a versão 9.4, o PostgreSQL introduziu slots de replicação física como um mecanismo de suporte para o processo de replicação.
Um *slot de replicação física* impede que uma instância de banco de dados de origem remova dados de WAL antes que sejam consumidos por todas as réplicas de leitura. Cada réplica de leitura possui seu próprio slot físico na instância de banco de dados de origem. O slot monitora o WAL mais antigo (por número de sequência lógica, LSN) que pode ser necessário para a réplica. Depois que todos os slots e conexões de banco de dados progrediram além de um determinado WAL (LSN), esse LSN se torna um candidato para remoção no próximo ponto de verificação.
O Amazon RDS usa o Amazon S3 para arquivar dados de WAL. Para réplicas de leitura na região, é possível usar esses dados arquivados para recuperar a réplica de leitura quando necessário. Um exemplo de quando isso pode ser necessário é se a conexão entre o banco de dados de origem e a réplica de leitura for interrompida por qualquer motivo.
Na tabela a seguir, é possível encontrar um resumo das diferenças entre as versões do PostgreSQL e os mecanismos de suporte para réplicas de leitura na região e entre regiões usados pelo RDS para PostgreSQL.
| Versão | Na região | Entre regiões |
| --- | --- | --- |
| PostgreSQL 14.1 e versões posteriores | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 e versões anteriores | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
Para obter mais informações, consulte [Monitoração e ajuste do processo de replicação](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md).
## Noções básicas dos parâmetros que controlam a replicação do PostgreSQL
Os parâmetros a seguir afetam o processo de replicação e determinam como as réplicas de leitura permanecem atualizadas com a instância de banco de dados de origem:
**max\$1wal\$1senders**
O parâmetro `max_wal_senders` especifica o número máximo de conexões com as quais a instância de banco de dados de origem é compatível ao mesmo tempo por meio do protocolo de replicação de streaming.
O valor padrão varia para versões do RDS para PostgreSQL:
+ Para as versões 13, 14 e 15, o valor padrão é 20.
+ Para as versões 16 e posteriores, o valor padrão é 35.
Esse parâmetro deve ser definido como um número um pouco maior que o número real de réplicas de leitura. Se esse parâmetro for definido muito baixo para o número de réplicas de leitura, a replicação será interrompida.
Para obter mais informações, consulte [max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS) na documentação do PostgreSQL.
`max_wal_senders` é um parâmetro estático que requer a reinicialização da instância de banco de dados para que as alterações sejam aplicadas.
**wal\$1keep\$1segments**
O parâmetro `wal_keep_segments` especifica o número de arquivos de log de gravação antecipada (WAL) que a instância de banco de dados de origem mantém no diretório `pg_wal`. A configuração padrão é 32.
Se `wal_keep_segments` não estiver definido como um valor grande o suficiente para sua implantação, uma réplica de leitura poderá ficar tão distante que interromperá a replicação de streaming. Se isso acontecer, o Amazon RDS gerará um erro de replicação e iniciará a recuperação na réplica de leitura. Ele faz isso reproduzindo os dados de WAL arquivados da instância de banco de dados de origem no Amazon S3. Este processo de recuperação continua até que a réplica de leitura tenha alcançado o suficiente para continuar com a replicação de streaming. É possível ver esse processo em ação, conforme capturado pelo log do PostgreSQL em [Exemplo: como uma réplica de leitura se recupera de interrupções de replicaçãoExemplo: Recuperação de réplica de leitura de interrupções de replicação](#USER_PostgreSQL.Replication.example-how-it-works).
No PostgreSQL versão 13, o parâmetro `wal_keep_segments` é chamado de `wal_keep_size`. Ele atende ao mesmo propósito que `wal_keep_segments`, mas seu valor padrão é em megabytes (MB) (2048 MB) em vez do número de arquivos. Para obter mais informações, consulte [wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS) e [wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE) na documentação do PostgreSQL.
**max\$1slot\$1wal\$1keep\$1size**
O parâmetro `max_slot_wal_keep_size` controla a quantidade de dados de WAL que a instância de banco de dados do RDS para PostgreSQL retém no diretório `pg_wal` para atender a slots. Esse parâmetro é usado para configurações que usam slots de replicação. O valor padrão desse parâmetro é `-1`, o que significa que não há limite para a quantidade de dados de WAL mantidos na instância de banco de dados de origem. Para obter informações sobre como monitorar os slots de replicação, consulte [Monitorar os slots de replicação da instância de banco de dados do RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots).
Para obter mais informações sobre esse parâmetro, consulte [max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE) na documentação do PostgreSQL.
Quando a transmissão que fornece dados de WAL a uma réplica de leitura é interrompida, o PostgreSQL muda para o modo de recuperação. Ele restaura a réplica de leitura usando os dados de WAL arquivados no Amazon S3 ou usando dados de WAL associados ao slot de replicação. Quando esse processo é concluído, o PostgreSQL restabelece a replicação de streaming.
### Exemplo: como uma réplica de leitura se recupera de interrupções de replicação
No exemplo a seguir, você encontra os detalhes do log que demonstram o processo de recuperação de uma réplica de leitura. O exemplo é de uma instância de banco de dados do RDS para PostgreSQL que executa o PostgreSQL versão 12.9 na mesma Região da AWS que o banco de dados de origem, portanto, os slots de replicação não são usados. O processo de recuperação é o mesmo para outras instâncias de banco de dados do RDS para PostgreSQL que executam PostgreSQL anterior à versão 14.1 com réplicas de leitura na região.
Quando a réplica de leitura perde contato com a instância de banco de dados de origem, o Amazon RDS registra o problema no log como mensagem `FATAL: could not receive data from WAL stream`, junto com `ERROR: requested WAL segment ... has already been removed`. Conforme mostrado na linha em negrito, o Amazon RDS recupera a réplica reproduzindo um arquivo de WAL arquivado.
```
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR: requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG: restored log file "000000010000001A000000D3" from archive
```
Quando o Amazon RDS reproduz arquivos de WAL arquivados suficientes na réplica para recuperar o atraso, o streaming para a réplica de leitura pode começar novamente. Quando o streaming é retomado, o Amazon RDS grava uma entrada no arquivo de log, semelhante à mostrada a seguir.
```
2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1
```
## Definir os parâmetros que controlam a memória compartilhada
Os parâmetros que você define determinam o tamanho da memória compartilhada para rastrear IDs de transações, bloqueios e transações preparadas. **A estrutura de memória compartilhada de uma instância em espera deve ser igual ou maior que a de uma instância primária.** Isso garante que a primeira não fique sem memória compartilhada durante a recuperação. Se os valores dos parâmetros na réplica forem menores que os valores dos parâmetros na primária, o Amazon RDS ajustará automaticamente os parâmetros da réplica e reiniciará o mecanismo.
Os parâmetros afetados são:
+ max\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
Para evitar que o RDS reinicialize réplicas em decorrência de memória insuficiente, recomendamos aplicar as alterações de parâmetro como uma reinicialização contínua de cada réplica. Você deve aplicar as seguintes regras ao definir os parâmetros:
+ **Aumentar os valores dos parâmetros:**
+ Você deve sempre aumentar primeiro os valores dos parâmetros de todas as réplicas de leitura e realizar uma reinicialização contínua de todas as réplicas. Em seguida, aplique as alterações de parâmetro na instância primária e reinicialize.
+ **Diminuir os valores dos parâmetros:**
+ Primeiro, você deve diminuir os valores dos parâmetros da instância primária e realizar uma reinicialização. Em seguida, aplique as alterações de parâmetro a todas as réplicas de leitura correspondentes e execute uma reinicialização contínua.
# Monitoração e ajuste do processo de replicação
Convém monitorar rotineiramente a instância de banco de dados do RDS para PostgreSQL e as réplicas de leitura. Verifique se suas réplicas de leitura estão acompanhando as alterações na instância de banco de dados de origem. O Amazon RDS recupera suas réplicas de leitura de forma transparente quando ocorrem interrupções no processo de replicação. No entanto, é melhor evitar qualquer necessidade de recuperação. A recuperação que usa slots de replicação é mais rápida do que usar o arquivo do Amazon S3, mas qualquer processo de recuperação pode afetar a performance de leitura.
Para determinar como suas réplicas de leitura estão acompanhando a instância de banco de dados de origem, é possível fazer o seguinte:
+ **Verifique a quantidade de `ReplicaLag` entre a instância de banco de dados de origem e as réplicas.** *Atraso da réplica* refere-se ao tempo em milissegundos durante o qual uma réplica de leitura fica atrasada em relação à instância de banco de dados de origem. Essa métrica retorna o resultado a seguir.
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
O atraso de réplica é uma indicação de como uma réplica de leitura está acompanhando a instância de banco de dados de origem. É a quantidade de latência entre a instância de banco de dados de origem e uma instância de leitura específica. Um valor alto de atraso de réplica pode indicar uma incompatibilidade entre as classes ou os tipos de armazenamento (ou ambos) usados pela instância de banco de dados de origem e suas réplicas de leitura. A classe e os tipos de armazenamento da instância de banco de dados de origem e de todas as réplicas de leitura devem ser iguais.
O atraso de réplica também pode ser o resultado de problemas de conexão intermitentes. Você pode monitorar o atraso da replicação no Amazon CloudWatch visualizando a métrica `ReplicaLag` do Amazon RDS. Para saber mais sobre `ReplicaLag` e outras métricas do Amazon RDS, consulte [Métricas do Amazon CloudWatch para o Amazon RDS](rds-metrics.md).
+ **Verifique o log do PostgreSQL para obter informações que podem ser usadas para ajustar suas configurações.** Por exemplo, em cada ponto de verificação, o log do PostgreSQL captura o número de arquivos de log de transações reciclados, como mostrado no exemplo a seguir.
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
É possível usar essas informações para descobrir quantos arquivos de transação estão sendo reciclados em um determinado período de tempo. É possível alterar a configuração para `wal_keep_segments` se necessário. Por exemplo, suponha que o log do PostgreSQL em `checkpoint complete` exibe `35 recycled` por um intervalo de 5 minutos. Neste caso, o valor padrão de 32 de `wal_keep_segments` não é suficiente para acompanhar a atividade de streaming, e recomendamos aumentar o valor desse parâmetro.
+ **Use o Amazon CloudWatch para monitorar métricas que podem prever problemas de replicação.** Em vez de analisar diretamente o log do PostgreSQL, é possível usar o Amazon CloudWatch para verificar as métricas coletadas. Por exemplo, é possível verificar o valor da métrica `TransactionLogsGeneration` para ver quantos dados de WAL estão sendo gerados pela instância de banco de dados de origem. Em alguns casos, a workload em sua instância de banco de dados pode gerar uma grande quantidade de dados de WAL. Nesse caso, talvez seja necessário alterar a classe da instância de banco de dados de origem e das réplicas de leitura. Usar uma classe de instância com alta performance de rede (10 Gbps) pode reduzir o atraso de réplica.
## Monitorar os slots de replicação da instância de banco de dados do RDS para PostgreSQL
Todas as versões do RDS para PostgreSQL usam slots de replicação para réplicas de leitura entre regiões. O RDS para PostgreSQL 14.1 e versões superiores usam slots de replicação para réplicas de leitura na região. As réplicas de leitura na região também usam o Amazon S3 para arquivar dados de WAL. Em outras palavras, se sua instância de banco de dados e réplicas de leitura estiverem executando o PostgreSQL 14.1 ou superior, os slots de replicação e os arquivos do Amazon S3 estarão disponíveis para recuperar a réplica de leitura. Recuperar uma réplica de leitura usando seu slot de replicação é mais rápido do que recuperar do arquivo do Amazon S3. Portanto, convém monitorar os slots de replicação e as métricas relacionadas.
É possível visualizar os slots de replicação em suas instâncias de banco de dados do RDS para PostgreSQL consultando a visualização `pg_replication_slots` da forma a seguir.
```
postgres=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
O `wal_status` do valor `reserved` indica que a quantidade de dados de WAL mantidos pelo slot está dentro dos limites do parâmetro `max_wal_size`. Ou seja, o slot de replicação está dimensionado corretamente. Outros valores de status possíveis são os seguintes:
+ `extended`: o slot excede a configuração de `max_wal_size`, mas os dados de WAL estão retidos.
+ `unreserved`: o slot não tem mais todos os dados de WAL necessários. Alguns deles serão removidos no próximo ponto de verificação.
+ `lost`: alguns dados de WAL necessários foram removidos. O slot não é mais utilizável.
Os estados `unreserved` e `lost` do `wal_status` são vistos somente quando `max_slot_wal_keep_size` não é negativo.
A visualização `pg_replication_slots` mostra o estado atual dos slots de replicação. Para avaliar a performance dos slots de replicação, é possível usar o Amazon CloudWatch e monitorar as seguintes métricas:
+ **`OldestReplicationSlotLag`** – mostra a quantidade de dados do log de gravação antecipada (WAL) na origem que não foi consumida pela réplica mais atrasada.
+ **`TransactionLogsDiskUsage`** – Mostra quanto armazenamento está sendo usado para dados WAL. Quando uma réplica de leitura atrasa significativamente, o valor dessa métrica pode aumentar substancialmente.
Para saber mais sobre o uso do Amazon CloudWatch e suas métricas para o RDS para PostgreSQL, consulte [Monitorar métricas do Amazon RDS com o Amazon CloudWatch](monitoring-cloudwatch.md). Para obter mais informações sobre como monitorar a replicação de streaming em suas instâncias de bancos de dados do RDS para PostgreSQL, consulte [Práticas recomendadas para replicação do Amazon RDS para PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) no *Blog de banco de dados da AWS*.
# Configurar replicação atrasada com RDS para PostgreSQL
## Visão geral e benefícios
O recurso de replicação atrasada no RDS para PostgreSQL permite que você adie intencionalmente a replicação de alterações de dados do seu banco de dados principal para um ou mais servidores em espera (réplica de leitura). Esse recurso oferece uma proteção valiosa contra corrupção de dados, perda acidental de dados ou transações errôneas que, de outra forma, poderiam ser propagadas imediatamente para todas as réplicas.
A replicação atrasada é aceita nas seguintes versões do RDS para PostgreSQL:
+ 14.19 e versões 14 posteriores
+ 15.14 e versões 15 posteriores
+ 16.10 e versões 16 posteriores
+ 17.6 e versões 17 posteriores
Ao introduzir um intervalo de tempo no processo de replicação, você ganha uma janela de oportunidade para detectar e responder a incidentes relacionados a dados antes que eles afetem todo o seu cluster de banco de dados. Os principais benefícios da replicação atrasada incluem os seguintes:
+ Permite que você se recupere de exclusões acidentais, atualizações ou outros erros lógicos.
+ Fornece um buffer contra a disseminação de dados corrompidos em seu cluster de banco de dados.
+ Oferece uma opção adicional de ponto de recuperação para complementar suas estratégias tradicionais de backup.
+ Permite que você configure o período de atraso com base nas necessidades específicas da sua organização e na tolerância ao risco.
## Habilitar e configurar a replicação atrasada
Para habilitar a replicação atrasada em uma réplica de leitura do RDS para PostgreSQL, siga estas etapas:
**nota**
Para réplicas de leitura em cascata, use o mesmo parâmetro `recovery_min_apply_delay` e as etapas descritas abaixo.
**Como habilitar a replicação atrasada**
1. Crie um grupo de parâmetros personalizado ou modifique um existente. Para obter mais informações, consulte [Grupos de parâmetros de banco de dados para instâncias de banco de dados do Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
1. No grupo de parâmetros, configure o parâmetro `recovery_min_apply_delay`:
+ Defina o valor para o atraso desejado em milissegundos. Por exemplo, 3.600.000 para um atraso de 1 hora.
+ Intervalo permitido: 0 a 86.400.000 ms (0 a 24 horas).
+ Padrão: 0
1. Aplique o grupo de parâmetros à instância de réplica de leitura que você deseja configurar para replicação atrasada.
1. Reinicialize a instância de réplica de leitura para que as alterações tenham efeito.
**nota**
O parâmetro `recovery_min_apply_delay` é dinâmico. Se você modificar um grupo de parâmetros existente que já esteja anexado à instância, as alterações entrarão em vigor imediatamente sem a necessidade de reinicialização. No entanto, ao aplicar um novo grupo de parâmetros à instância, você deverá reinicializar para que as alterações entrem em vigor.
## Gerenciar a recuperação de replicação atrasada
A replicação atrasada é particularmente útil em cenários em que os métodos tradicionais de recuperação para um ponto no tempo podem ser insuficientes ou muito demorados.
Durante o período de replicação atrasada, você pode usar as seguintes funções do PostgreSQL para gerenciar o processo de recuperação:
+ `pg_wal_replay_pause()`: solicitação para pausar o processo de recuperação da réplica atrasada.
+ `pg_wal_replay_resume()`: reinicie o processo de recuperação se ele tiver sido pausado anteriormente.
+ `pg_is_wal_replay_paused()`: confira se o processo de recuperação está pausado no momento.
+ `pg_get_wal_replay_pause_state()`: recupere o estado atual do processo de recuperação (não pausado, pausa solicitada ou pausada).
Os usuários com o perfil `rds_superuser` têm privilégios EXECUTE em `pg_wal_replay_pause()` e `pg_wal_replay_resume()`. Se outros usuários do banco de dados precisarem acessar essas funções, você deverá conceder a eles o perfil `rds_superuser`. Para obter mais informações sobre a função `rds_superuser`, consulte [Noções básicas sobre o perfil rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
O acesso a outras funções, como `pg_is_wal_replay_paused()` e `pg_get_wal_replay_pause_state()`, não exige o perfil `rds_superuser`.
Você pode usar os parâmetros de destino de recuperação a seguir para controlar com precisão o momento em que a réplica atrasada é recuperada. Estes parâmetros são estáticos e exigem a reinicialização do banco de dados para aplicar as alterações:
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**Importante**
Você só pode especificar um parâmetro de destino de recuperação por vez. Configurar vários parâmetros de destino de recuperação no arquivo de configuração gera um erro.
## Considerações sobre planejamento
Pense no seguinte ao planejar uma replicação atrasada com o RDS para PostgreSQL:
+ Durante a alternância automática de credenciais `rdsrepladmin` (que ocorre a cada 90 dias), as réplicas de leitura atrasadas podem entrar temporariamente no estado `REPLICATION_ERROR`. Se a réplica atrasada tiver logs WAL suficientes para manter o atraso configurado, ela poderá pausar o processo do receptor WAL, causando o acúmulo de WAL na origem. Você deve monitorar o status da replicação na réplica e o consumo de armazenamento na origem para evitar que o armazenamento fique cheio.
+ Quando as réplicas de leitura atrasadas encontram eventos do sistema (como reinicialização ou reinicialização), elas entram no estado `REPLICATION_ERROR` em que o processo do receptor WAL permanece inativo até que o período de atraso configurado expire. Esse comportamento pode causar o acúmulo de WAL na instância de origem, podendo gerar o esgotamento do armazenamento. Pense nas seguintes medidas preventivas:
+ Configure os alarmes do CloudWatch para monitorar a utilização do armazenamento nas instâncias de origem.
+ Habilite o ajuste de escala automático do armazenamento para lidar com o crescimento inesperado do WAL.
+ Defina o parâmetro `max_slot_wal_keep_size` na instância de origem para limitar a retenção de WAL por slot de replicação.
+ Monitore regularmente o atraso na replicação e o status do slot.
+ Atrasos maiores aumentam os logs do WAL nas réplicas, consumindo mais armazenamento. Monitore o espaço de armazenamento usando os alarmes do CloudWatch, habilite o ajuste de escala automático ou acompanhe as réplicas quando necessário.
+ Ao promover uma réplica de leitura atrasada, o parâmetro `recovery_min_apply_delay` não é respeitado e todos os registros pendentes do WAL são aplicados imediatamente.
+ O parâmetro `recovery_min_apply_delay` é independente em cada nível de uma configuração de replicação em cascata. Definir um atraso em uma réplica não aumenta o atraso de nenhuma réplica em cascata.
Para acessar mais informações, consulte a [documentação de réplicas de leitura do RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) e a [documentação de recuperação de desastres do RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html).
## Noções básicas sobre limitações
O recurso de replicação atrasada do Amazon RDS para PostgreSQL tem as seguintes limitações:
+ As implantações azul/verde têm as seguintes limitações ao configurar a replicação atrasada:
+ **Instância de origem verde**: o `recovery_min_apply_delay parameter` é ignorado, mesmo se configurado no grupo de parâmetros. Nenhuma configuração de atraso na instância de origem verde entra em vigor.
+ **Instância de réplica verde**: o `recovery_min_apply_delay parameter` é totalmente aceito e aplicado ao arquivo de configuração do PostgreSQL. As configurações de atraso funcionam conforme o esperado durante o fluxo de trabalho de transição.
+ Implantações azul/verde do RDS para atualizações de versões principais
+ Durante as atualizações de versões principais, todas as réplicas de leitura atrasadas serão automaticamente encerradas para permitir que a instância de origem continue com o processo de atualização, a fim de garantir o mínimo de tempo de inatividade. Depois que a instância de origem concluir a atualização, você deverá recriar manualmente as réplicas atrasadas.
+ A replicação atrasada não é compatível com os recursos apresentados a seguir.
+ Replicação lógica do RDS para PostgreSQL
+ Clusters multi-AZ do RDS para PostgreSQL (incluindo replicação de entrada e saída)
+ Aurora PostgreSQL
# Solução de problemas da réplica de leitura do RDS para PostgreSQL
A seguir, é possível encontrar ideias de solução de alguns problemas comuns de réplicas de leitura do RDS para PostgreSQL.
**Encerrar a consulta que causa o atraso da réplica de leitura**
As transações ativas ou ociosas no estado de transação que estão sendo executadas por um longo tempo no banco de dados podem interferir no processo de replicação do WAL, aumentando assim o atraso na replicação. Portanto, monitore o tempo de execução dessas transações com a visualização `pg_stat_activity` do PostgreSQL.
Execute uma consulta na instância primária semelhante à seguinte para encontrar o ID do processo (PID) da consulta que está sendo executada por um longo tempo:
```
SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
```
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Depois de identificar o PID da consulta, você pode optar por encerrá-la.
Execute uma consulta na instância primária semelhante à seguinte para encerrar a consulta que está sendo executada por um longo tempo:
```
SELECT pg_terminate_backend(PID);
```
# Melhorar a performance das consultas para o RDS para PostgreSQL com leituras otimizadas pelo Amazon RDS
É possível acelerar o processamento de consultas para o RDS para PostgreSQL com leituras otimizadas pelo Amazon RDS. Uma instância de banco de dados ou um cluster de banco de dados multi-AZ do RDS para PostgreSQL que utiliza o recurso Leituras otimizadas pelo RDS pode alcançar um processamento de consultas até 50% mais rápido em comparação com uma instância ou um cluster não usa o recurso.
**Topics**
+ [
## Visão geral das leituras otimizadas pelo RDS no PostgreSQL
](#USER_PostgreSQL.optimizedreads-overview)
+ [
## Casos de uso para leituras otimizadas do RDS
](#USER_PostgreSQL.optimizedreads-use-cases)
+ [
## Práticas recomendadas para leituras otimizadas do RDS
](#USER_PostgreSQL.optimizedreads-best-practices)
+ [
## Utilizar leituras otimizadas do RDS
](#USER_PostgreSQL.optimizedreads-using)
+ [
## Monitorar instâncias de banco de dados que utilizam leituras otimizadas do RDS
](#USER_PostgreSQL.optimizedreads-monitoring)
+ [
## Limitações das leituras otimizadas pelo RDS no PostgreSQL
](#USER_PostgreSQL.optimizedreads-limitations)
## Visão geral das leituras otimizadas pelo RDS no PostgreSQL
As leituras otimizadas estão disponíveis por padrão no RDS para PostgreSQL versões 15.2 e posterior, 14.7 e posterior e 13.10 e posterior ao usar as classes de instância de banco de dados baseadas em NVMe. Consulte especificações de hardware que indicam quais instâncias usam o NVMe em [Especificações de hardware para classes de instância de banco de dados](Concepts.DBInstanceClass.Summary.md).
Quando você usa uma instância de banco de dados ou um cluster de banco de dados multi-AZ do RDS para PostgreSQL com o recurso Leituras otimizadas pelo RDS ativado, a instância ou o cluster alcança uma performance de consulta até 50% mais rápida por meio do armazenamento em bloco de unidade de estado sólido (SSD) local baseado em memória não volátil (NVMe). Você pode acelerar o processamento de consultas colocando as tabelas temporárias geradas pelo PostgreSQL no armazenamento local, o que reduz o tráfego para o Elastic Block Storage (EBS) pela rede.
No PostgreSQL, objetos temporários são atribuídos a um namespace temporário que é descartado automaticamente no final da sessão. O namespace temporário durante a eliminação remove todos os objetos que dependem da sessão, como objetos qualificados pelo esquema, por exemplo, tabelas, funções, operadores ou até mesmo extensões.
No RDS para PostgreSQL, o parâmetro `temp_tablespaces` é configurado para essa área de trabalho temporária em que os objetos temporários são armazenados.
As consultas a seguir retornam o nome do espaço de tabela e sua localização.
```
postgres=> show temp_tablespaces;
temp_tablespaces
---------------------
rds_temp_tablespace
(1 row)
```
O `rds_temp_tablespace` é um espaço de tabela configurado pelo RDS que aponta para o armazenamento local NVMe. Você sempre pode voltar para o armazenamento do Amazon EBS modificando esse parâmetro no `Parameter group` usando o Console de gerenciamento da AWS para apontar para qualquer espaço de tabela diferente de `rds_temp_tablespace`. Para ter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Você também pode usar o comando SET para modificar o valor do parâmetro `temp_tablespaces` para `pg_default` no nível da sessão usando o comando SET. A modificação do parâmetro redireciona a área de trabalho temporária para o Amazon EBS. Voltar para o Amazon EBS ajuda quando o armazenamento local de sua instância ou cluster do RDS não é suficiente para realizar uma operação SQL específica.
```
postgres=> SET temp_tablespaces TO 'pg_default';
SET
```
```
postgres=> show temp_tablespaces;
temp_tablespaces
------------------
pg_default
```
## Casos de uso para leituras otimizadas do RDS
Veja a seguir alguns casos de uso que podem se beneficiar das leituras otimizadas:
+ Consultas analíticas que incluem expressões de tabela comuns (CTEs), tabelas derivadas e operações de agrupamento.
+ Réplicas de leitura que lidam com as consultas não otimizadas de uma aplicação.
+ Consultas de relatórios dinâmicos ou sob demanda com operações complexas, como GROUP BY e ORDER BY, que nem sempre podem usar índices apropriados.
+ Outras workloads que usam tabelas temporárias internas.
+ Operações `CREATE INDEX` ou `REINDEX` de classificação.
## Práticas recomendadas para leituras otimizadas do RDS
Use as práticas recomendadas a seguir para leituras otimizadas do RDS:
+ Adicione uma lógica de repetição para consultas somente leitura caso elas falhem devido ao armazenamento de instância estar cheio durante a execução.
+ Monitore o espaço de armazenamento disponível no armazenamento de instâncias com a métrica do CloudWatch `FreeLocalStorage`. Se o armazenamento de instância estiver atingindo seu limite devido à workload na instância de banco de dados ou no cluster de banco de dados multi-AZ, modifique a instância ou o cluster para usar uma classe de instância de banco de dados maior.
## Utilizar leituras otimizadas do RDS
Quando você provisiona uma instância de banco de dados do RDS para PostgreSQL com uma das classes de instância de banco de dados baseada em NVMe em uma implantação de instância de banco de dados single-AZ, uma implantação de instância de banco de dados multi-AZ ou uma implantação de cluster de banco de dados multi-AZ, a instância de banco de dados utiliza automaticamente o recurso Leituras otimizadas pelo RDS.
Consulte mais informações sobre a implantação multi-AZ em [Configurar e gerenciar uma implantação multi-AZ para o Amazon RDS](Concepts.MultiAZ.md).
Para ativar as leituras otimizadas do RDS, execute um destes procedimentos:
+ Crie uma instância de banco de dados ou um cluster de banco de dados multi-AZ do RDS para PostgreSQL utilizando uma das classes de instância de banco de dados NVMe. Para ter mais informações, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md).
+ Modifique uma instância de banco de dados ou um cluster de banco de dados multi-AZ existente do RDS para PostgreSQL para utilizar uma das classes de instância de banco de dados baseada em NVMe. Para ter mais informações, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md).
O recurso Leituras otimizadas pelo RDS está disponível em todas as Regiões da AWS onde há suporte para uma ou mais dessas classes de instância de banco de dados com SSD NVMe local. Para ter mais informações, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md).
Para voltar para uma instância do RDS sem otimização de leituras, modifique a classe de instância de banco de dados de sua instância ou cluster do RDS para a classe de instância semelhante que só é compatível com o armazenamento do EBS para suas workloads de banco de dados. Por exemplo, se a classe de instância de banco de dados atual for db.r6gd.4xlarge, selecione db.r6g.4xlarge para voltar. Para ter mais informações, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md).
## Monitorar instâncias de banco de dados que utilizam leituras otimizadas do RDS
Você pode monitorar instâncias de banco de dados que usam leituras otimizadas pelo RDS com as seguintes métricas do CloudWatch:
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
Essas métricas fornecem dados sobre armazenamento de instâncias, IOPS e throughput. Para ter mais informações sobre essas métricas, consulte [Métricas específicas da instância do Amazon CloudWatch para Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
Para monitorar o uso atual do armazenamento local, faça login no banco de dados e execute a seguinte consulta:
```
SELECT
spcname AS "Name",
pg_catalog.pg_size_pretty(pg_catalog.pg_tablespace_size(oid)) AS "size"
FROM
pg_catalog.pg_tablespace
WHERE
spcname IN ('rds_temp_tablespace');
```
Para obter mais informações sobre os arquivos temporários e o uso, consulte [Gerenciar arquivos temporários com o PostgreSQL](PostgreSQL.ManagingTempFiles.md).
## Limitações das leituras otimizadas pelo RDS no PostgreSQL
A limitação a seguir se aplica ao recurso Leituras otimizadas pelo RDS no PostgreSQL:
+ As transações podem falhar quando o armazenamento de instância está cheio.
# Como importar dados no PostgreSQL do Amazon RDS
Vamos supor que você tenha uma implantação do PostgreSQL que deseja mover para o Amazon RDS. A complexidade da tarefa dependerá do tamanho do banco de dados e dos tipos de objetos de banco de dados a serem transferidos. Por exemplo, considere um banco de dados que contenha conjuntos de dados na ordem de gigabytes, juntamente com gatilhos e procedimentos armazenados. Esse banco de dados será mais complexo do que um banco de dados simples com apenas alguns megabytes de dados de teste e sem gatilhos e procedimentos armazenados.
Recomendamos que você use ferramentas nativas de migração do banco de dados PostgreSQL nas seguintes condições:
+ Quando há uma migração homogênea, em que você está migrando de um banco de dados com o mesmo mecanismo de banco de dados que o de destino.
+ Quando for migrar um banco de dados inteiro.
+ As ferramentas nativas permitirem que você migre o sistema com um tempo mínimo de inatividade.
Na maioria dos outros casos, executar uma migração de banco de dados usando o AWS Database Migration Service (AWS DMS) é a melhor abordagem. AWS O DMS pode migrar bancos de dados sem o tempo de inatividade e, para muitos mecanismos de banco de dados, continua a replicação contínua até que você esteja pronto para mudar para o banco de dados de destino. Você pode migrar para o mesmo mecanismo de banco de dados ou um mecanismo de banco de dados diferente usando o AWS DMS. Se você estiver migrando para um mecanismo de banco de dados diferente do seu banco de dados de origem, poderá usar a AWS Schema Conversion Tool (AWS SCT). Use o AWS SCT para migrar os objetos de esquema que não são migrados pelo AWS DMS. Para obter mais informações sobre como usar o AWS DMS, consulte [ O que é o AWS Database Migration Service?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html).
Modifique o grupo de parâmetros do banco de dados para incluir as seguintes configurações *somente na sua importação*. Você deve testar as configurações dos parâmetros para encontrar as que forem mais eficientes para o tamanho da instância do banco de dados. Você também precisará reverter esses parâmetros aos seus valores de produção após a conclusão da importação.
Modifique as configurações da instância de banco de dados da seguinte forma:
+ Desabilite os backups de instâncias de banco de dados (defina backup\$1retention como 0).
+ Desabilite o multi-AZ.
Modifique o grupo de parâmetros de banco de dados para incluir as seguintes configurações. Você só deve usar essas configurações para importar dados. Você deve testar as configurações dos parâmetros para encontrar as que forem mais eficientes para o tamanho da instância do banco de dados. Você também precisará reverter esses parâmetros aos seus valores de produção após a conclusão da importação.
| Parâmetro | Valor recomendado para importação | Descrição |
| --- | --- | --- |
| `maintenance_work_mem` | 524288, 1048576, 2097152 ou 4194304 (em KB). Essas configurações são comparáveis a 512 MB, 1 GB, 2 GB e 4 GB. | O valor desta configuração depende do tamanho do host. Este parâmetro é usado durante instruções CREATE INDEX e cada comando paralelo pode usar essa quantidade de memória. Calcule o valor mais apropriado para não ajustá-lo tão alto resultando na falta de memória. |
| `max_wal_size` | 256 (para a versão 9.6), 4096 (para as versões 10 e posteriores) | Tamanho máximo para deixar o WAL aumentar durante os pontos de verificação automáticos. Aumentar esse parâmetro pode aumentar a quantidade de tempo necessária para a recuperação de falhas. Esse parâmetro substitui `checkpoint_segments` para o PostgreSQL 9.6 e posteriores. Para o PostgreSQL versão 9.6, esse valor está em unidades de 16 MB. Para versões posteriores, o valor está em unidades de 1 MB. Por exemplo, na versão 9.6, 128 significa 128 blocos, cada um com tamanho de 16 MB. Na versão 12.4, 2048 significa 2048 blocos, cada um com tamanho de 1 MB. |
| `checkpoint_timeout` | 1800 | O valor desta configuração permite um revezamento menos frequente de WAL. |
| `synchronous_commit` | Desativado | Desabilite essa configuração para acelerar a gravação. Desativar esse parâmetro pode aumentar o risco de perda de dados em caso de uma falha no servidor (não desative o FSYNC) |
| `wal_buffers` | 8192 | Este valor está em unidades de 8 KB. Reforçando, isso ajuda na velocidade de geração WAL |
| `autovacuum` | 0 | Desative o parâmetro de autovacuum do PostgreSQL enquanto estiver carregando dados para que ele não use os recursos |
Use os comandos `pg_dump -Fc` (compactado) ou `pg_restore -j` (paralelo) com essas configurações.
**nota**
O comando do PostgreSQL `pg_dumpall` requer permissões de super\$1user que não são concedidas ao criar uma instância de banco de dados, por isso ele não pode ser usado para importação de dados.
**Topics**
+ [
# Importar um banco de dados PostgreSQL de uma instância do Amazon EC2
](PostgreSQL.Procedural.Importing.EC2.md)
+ [
# Uso do comando \$1copy para importar dados em uma tabela em uma instância de banco de dados PostgreSQL
](PostgreSQL.Procedural.Importing.Copy.md)
+ [
# Importar dados do Amazon S3 para uma instância de banco de dados do RDS para PostgreSQL
](USER_PostgreSQL.S3Import.md)
+ [
# Como transportar bancos de dados PostgreSQL entre instâncias de banco de dados
](PostgreSQL.TransportableDB.md)
# Importar um banco de dados PostgreSQL de uma instância do Amazon EC2
Se houver dados em um servidor do PostgreSQL em uma instância do Amazon EC2 e você quiser movê-los para uma instância de banco de dados do PostgreSQL, você poderá seguir este processo para migrar os dados.
1. Crie um arquivo usando o pg\$1dump que contenha os dados a serem carregados
1. Crie a instância de banco de dados de destino
1. Use o *psql* para criar o banco de dados na instância de banco de dados e carregá-los
1. Crie um snapshot de banco de dados da instância de banco de dados
As seções a seguir apresentam mais detalhes sobre cada etapa listada acima.
## Etapa 1: Criar um arquivo usando o pg\$1dump que contenha os dados a serem carregados
O utilitário `pg_dump` usa o comando COPY para criar um esquema e uma despejo de dados de um banco de dados PostgreSQL. O script de despejo gerado pelo `pg_dump` carrega os dados em um banco de dados com o mesmo nome e recreia as tabelas, os índices e as chaves externas. Você pode usar o comando `pg_restore` e o parâmetro `-d` para recuperar os dados em um banco de dados com um nome diferente.
Antes de criar o despejo de dados, você deve consultar as tabelas a serem despejadas para obter uma contagem de linhas, assim você pode confirmar a contagem na instância de banco de dados de destino.
O comando a seguir cria um arquivo de despejo denominado mydb2dump.sql para um banco de dados denominado mydb2.
```
prompt>pg_dump dbname=mydb2 -f mydb2dump.sql
```
## Etapa 2: crie a instância de banco de dados de destino
Crie a instância de banco de dados PostgreSQL de destino usando o console, a AWS CLI ou a API do Amazon RDS. Crie a instância com a configuração de retenção de backup definida como 0 e desative o multi-AZ. Isso permite uma importação de dados mais rápida. Você deve criar um banco de dados na instância antes de poder despejar os dados. O banco de dados pode ter o mesmo nome que o banco de dados que contém os dados de despejo. Se preferir, você pode criar um banco de dados com um nome diferente. Nesse caso, use o comando `pg_restore` e o parâmetro `-d` para restaurar os dados para o banco de dados recém-nomeado.
Por exemplo, os seguintes comandos podem ser usados para despejar, restaurar e renomear um banco de dados.
```
pg_dump -Fc -v -h [endpoint of instance] -U [master username] [database] > [database].dump
createdb [new database name]
pg_restore -v -h [endpoint of instance] -U [master username] -d [new database name] [database].dump
```
## Etapa 3: Usar o psql para criar o banco de dados na instância de banco de dados e carregá-los
É possível usar a mesma conexão que você usou para executar o comando pg\$1dump para se conectar à instância de banco de dados de destino e recriar o banco de dados. Com o *psql*, use o nome de usuário mestre e a senha mestre para criar o banco de dados na instância de banco de dados
O exemplo a seguir usa o *psql* e um arquivo de despejo denominado mydb2dump.sql para criar um banco de dados denominado mydb2 em uma instância de banco de dados PostgreSQL chamada mypginstance:
Para Linux, macOS ou Unix:
```
psql \
-f mydb2dump.sql \
--host mypginstance.555555555555.aws-region.rds.amazonaws.com \
--port 8199 \
--username myawsuser \
--password password \
--dbname mydb2
```
Para Windows:
```
psql ^
-f mydb2dump.sql ^
--host mypginstance.555555555555.aws-region.rds.amazonaws.com ^
--port 8199 ^
--username myawsuser ^
--password password ^
--dbname mydb2
```
**nota**
Especifique uma senha diferente do prompt mostrado aqui como prática recomendada de segurança.
## Etapa 4: crie um DB snapshot da instância de banco de dados
Após confirmar que os dados foram carregados na instância de banco de dados, recomendamos que você crie um snapshot de banco de dados da instância de banco de dados PostgreSQL de destino. Os snapshot de banco de dadoss são backups completos de sua instância de banco de dados que podem ser usados para restaurá-la em um estado conhecido. Um snapshot de banco de dados feito imediatamente após a carga evita que você tenha que carregar os dados novamente caso ocorra um problema. Você também pode usar esse snapshot para propagar as novas instâncias de banco de dados. Para obter informações sobre como criar um snapshot de banco de dados, consulte [Criar um snapshot de banco de dados para uma instância de banco de dados single-AZ para o Amazon RDS](USER_CreateSnapshot.md).
# Uso do comando \$1copy para importar dados em uma tabela em uma instância de banco de dados PostgreSQL
O comando `\copy` do PostgreSQL é um meta-comando disponível a partir da ferramenta cliente interativa `psql`. Você pode usar `\copy` para importar dados para uma tabela na instância de banco de dados do RDS para PostgreSQL Para usar o comando `\copy`, você precisa primeiro criar a estrutura da tabela na instância de banco de dados de destino para que `\copy` tenha um destino para os dados que estão sendo copiados.
Você pode usar `\copy` para carregar dados de um arquivo de valores separados por vírgulas (CSV), como um que foi exportado e salvo na estação de trabalho do cliente.
Para importar os dados CSV para a instância de banco de dados do RDS para PostgreSQL de destino, primeiro conecte-se à instância de banco de dados de destino usando `psql`.
```
psql --host=db-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=target-db
```
Você então executa `\copy` com os parâmetros a seguir para identificar o destino para os dados e seu formato.
+ `target_table` – O nome da tabela que deve receber os dados que estão sendo copiados do arquivo CSV.
+ `column_list` – Especificações da coluna para a tabela.
+ `'filename'` – O caminho completo para o arquivo CSV na estação de trabalho local.
```
\copy target_table from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV;
```
Se o arquivo CSV tiver informações de cabeçalho de coluna, você poderá usar esta versão do comando e dos parâmetros.
```
\copy target_table (column-1, column-2, column-3, ...)
from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV HEADER;
```
Se o comando `\copy` falhar, o PostgreSQL gera mensagens de erro.
Criar uma instância de banco de dados no comando `psql` do Ambiente de Pré-visualização do Banco de Dados com o metacomando `\copy`, conforme mostrado nos exemplos a seguir. Este exemplo usa *source-table* como o nome da tabela de origem, *source-table.csv* como o arquivo .csv e *target-db* como o banco de dados de destino:
Para Linux, macOS ou Unix:
```
$psql target-db \
-U \
-p \
-h \
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Para Windows:
```
$psql target-db ^
-U ^
-p ^
-h ^
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Para obter detalhes completos sobre o comando `\copy`, consulte a página [psql](http://www.postgresql.org/docs/current/static/app-psql.html) na documentação do PostgreSQL, na seção *Meta-comandos*.
# Importar dados do Amazon S3 para uma instância de banco de dados do RDS para PostgreSQL
Você pode importar dados que foram armazenados usando o Amazon Simple Storage Service em uma tabela em uma instância de banco de dados do RDS para PostgreSQL. Para fazer isso, primeiro instale a extensão `aws_s3` do RDS para PostgreSQL. Essa extensão fornece as funções usadas para importar dados de um bucket do Amazon S3. Um *bucket* é um contêiner do Amazon S3 para objetos e arquivos. Os dados podem estar em um arquivo de valores separados por vírgula (CSV), em um arquivo de texto ou em um arquivo compactado (gzip). Veja a seguir como instalar a extensão e importar dados do Amazon S3 para uma tabela.
Seu banco de dados deve estar executando o PostgreSQL versão 10.7 ou superior para importar do Amazon S3 para o RDS for PostgreSQL.
Se você não tiver dados armazenados no Amazon S3, crie um bucket e armazene os dados. Para ter mais informações, consulte os tópicos a seguir no *Guia do usuário do Amazon Simple Storage Service*.
+ [Criar um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)
+ [Adicionar um objeto a um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#uploading-an-object-bucket)
A importação entre contas do Amazon S3 é compatível. Para ter mais informações, consulte [Conceder permissões entre contas](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) no *Guia do usuário do Amazon Simple Storage Service*.
Você pode usar a chave gerenciada pelo cliente para criptografia ao importar dados do S3. Para ter mais informações, consulte [Chaves do KMS armazenadas no AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) no *Guia do usuário do Amazon Simple Storage Service*.
**Topics**
+ [
# Instalar a extensão aws\$1s3
](USER_PostgreSQL.S3Import.InstallExtension.md)
+ [
# Visão geral da importação de dados do Amazon S3
](USER_PostgreSQL.S3Import.Overview.md)
+ [
# Configurar o acesso a um bucket do Amazon S3
](USER_PostgreSQL.S3Import.AccessPermission.md)
+ [
# Importar dados do Amazon S3 para uma instância de banco de dados do RDS para PostgreSQL
](USER_PostgreSQL.S3Import.FileFormats.md)
+ [
# Referência de funções
](USER_PostgreSQL.S3Import.Reference.md)
# Instalar a extensão aws\$1s3
Antes de usar o Amazon S3 com a sua instância de banco de dados do RDS para PostgreSQL, você precisa instalar a extensão `aws_s3`. Essa extensão fornece as funções para importar dados do Amazon S3. Ela também fornece funções para exportar dados de uma instância de banco de dados do RDS para PostgreSQL para um bucket do Amazon S3. Para ter mais informações, consulte [Exportar dados de uma instância de banco de dados do RDS para PostgreSQL para o Amazon S3](postgresql-s3-export.md). A extensão `aws_s3` depende de algumas das funções auxiliares da extensão `aws_commons`, que é instalada automaticamente quando necessária.
**Como instalar a extensão `aws_s3`**
1. Use psql (ou pgAdmin) para se conectar à instância de banco de dados do RDS para PostgreSQL como um usuário que tem privilégios `rds_superuser`. Se você manteve o nome padrão durante o processo de configuração, se conectará como `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Para instalar a extensão, execute o comando a seguir.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Para verificar se a extensão está instalada, você pode usar o metacomando psql `\dx`.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
As funções para importar dados do Amazon S3 e exportar dados para o Amazon S3 agora estão disponíveis para uso.
# Visão geral da importação de dados do Amazon S3
**Para importar dados do S3 para o Amazon RDS do**
Primeiro, reúna os detalhes que você precisa fornecer à função. Isso inclui o nome da tabela na sua instância de banco de dados do RDS para PostgreSQL, e o nome do bucket, o caminho do arquivo, o tipo de arquivo e a Região da AWS em que os dados do Amazon S3 estão armazenados. Para ter mais informações, consulte [Visualizar um objeto](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) no *Guia do usuário do Amazon Simple Storage Service*.
**nota**
A importação de dados multipart do Amazon S3 não é compatível atualmente.
1. Obtenha o nome da tabela para a qual a função `aws_s3.table_import_from_s3` deverá importar os dados. Por exemplo, o comando a seguir cria uma tabela `t1` que pode ser utilizada em etapas posteriores.
```
postgres=> CREATE TABLE t1
(col1 varchar(80),
col2 varchar(80),
col3 varchar(80));
```
1. Veja os detalhes sobre o bucket do Amazon S3 e os dados a importar. Para fazer isso, abra o console do Amazon S3 em [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) e escolha **Buckets**. Encontre o bucket que contém seus dados na lista. Escolha o bucket, abra a página Object overview (Visão geral do objeto) e escolha Properties (Propriedades).
Anote o nome do bucket, o caminho, a Região da AWS e o tipo de arquivo. Posteriormente, você precisará do nome do recurso da Amazon (ARN) para configurar o acesso ao Amazon S3 por meio de um perfil do IAM. Para ter mais informações, consulte [Configurar o acesso a um bucket do Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md). A imagem a seguir mostra um exemplo.
![\[Imagem de um objeto de arquivo em um bucket do Amazon S3.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/aws_s3_import-export_s3_bucket-info.png)
1. Você pode verificar o caminho dos dados no bucket do Amazon S3 usando o comando `aws s3 cp` da AWS CLI. Se as informações estiverem corretas, esse comando baixará uma cópia do arquivo do Amazon S3.
```
aws s3 cp s3://amzn-s3-demo-bucket/sample_file_path ./
```
1. Configure permissões em sua instância de banco de dados do RDS para PostgreSQLpara permitir acesso ao arquivo no bucket do Amazon S3. Para fazer isso, use um perfil AWS Identity and Access Management (do IAM) ou credenciais de segurança. Para ter mais informações, consulte [Configurar o acesso a um bucket do Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md).
1. Forneça o caminho e outros detalhes do objeto do Amazon S3 coletados (consulte a etapa 2) para a função `create_s3_uri` a fim de construir um objeto URI do Amazon S3. Para saber mais sobre essa função, consulte [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri). Veja a seguir um exemplo de como construir esse objeto durante uma sessão psql.
```
postgres=> SELECT aws_commons.create_s3_uri(
'docs-lab-store-for-rpg',
'versions_and_jdks_listing.csv',
'us-west-1'
) AS s3_uri \gset
```
Na próxima etapa, passe esse objeto (`aws_commons._s3_uri_1`) para a função `aws_s3.table_import_from_s3` a fim de importar os dados para a tabela.
1. Invoque a função `aws_s3.table_import_from_s3` para importar os dados do Amazon S3 para a sua tabela. Para obter informações de referência, consulte [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3). Para obter exemplos, consulte [Importar dados do Amazon S3 para uma instância de banco de dados do RDS para PostgreSQL](USER_PostgreSQL.S3Import.FileFormats.md).
# Configurar o acesso a um bucket do Amazon S3
Para importar dados de um arquivo do Amazon S3, conceda à instância de banco de dados do RDS for PostgreSQL permissão para acessar o bucket do Amazon S3 no qual o arquivo se encontra. Conceda acesso a um bucket do Amazon S3 de uma das duas maneiras, conforme descrito nos tópicos a seguir.
**Topics**
+ [
## Usar uma função do IAM para acessar um bucket do Amazon S3
](#USER_PostgreSQL.S3Import.ARNRole)
+ [
## Usar credenciais de segurança para acessar um bucket do Amazon S3
](#USER_PostgreSQL.S3Import.Credentials)
+ [
## Solução de problemas de acesso ao Amazon S3
](#USER_PostgreSQL.S3Import.troubleshooting)
## Usar uma função do IAM para acessar um bucket do Amazon S3
Antes de carregar dados de um arquivo do Amazon S3, conceda à instância de banco de dados do RDS para PostgreSQL permissão para acessar o bucket do Amazon S3 no qual o arquivo está. Dessa forma, não é necessário gerenciar informações adicionais de credenciais ou fornecê-las na chamada da função [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Para fazer isso, crie uma política do IAM que conceda acesso ao bucket do Amazon S3. Crie uma função do IAM e associe a política a ela. Depois, atribua uma função do IAM à instância de banco de dados.
**Para oferecer ao Amazon S3 acesso a uma instância de banco de dados RDS for PostgreSQL do por meio de uma função do IAM**
1. Crie uma política do IAM.
Essa política concede ao bucket e ao objeto as permissões para que a instância de banco de dados do RDS para PostgreSQL acesse o Amazon S3.
Inclua na política as seguintes ações necessárias para permitir a transferência de arquivos de um bucket do Amazon S3 para o Amazon RDS do :
+ `s3:GetObject`
+ `s3:ListBucket`
Inclua na política os recursos a seguir para identificar o bucket e os objetos do Amazon S3 no bucket. Isso mostra o formato do nome de recurso da Amazon (ARN) para acessar o Amazon S3.
+ arn:aws:s3:::*amzn-s3-demo-bucket*
+ arn:aws:s3:::*amzn-s3-demo-bucket*/\$1
Para ter mais informações sobre como criar uma política do IAM para o RDS para PostgreSQL, consulte [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Consulte também [Tutorial: Criar e anexar sua primeira política gerenciada pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) no *Guia do usuário do IAM*.
O comando da AWS CLI a seguir cria uma política do IAM denominada `rds-s3-import-policy` com essas opções. Ele concede acesso a um bucket denominado *amzn-s3-demo-bucket*.
**nota**
Anote o nome do recurso da Amazon (ARN) da política que é retornado por esse comando. O ARN será necessário para uma etapa posterior, quando você anexar a política a um perfil do IAM.
**Example**
Para Linux, macOS ou Unix:
```
aws iam create-policy \
--policy-name rds-s3-import-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
Para Windows:
```
aws iam create-policy ^
--policy-name rds-s3-import-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Criar um perfil do IAM.
Faça isso para que o Amazon RDS possa assumir essa função do IAM para acessar os buckets do Amazon S3. Para ter mais informações, consulte [Criar um perfil para delegar permissões a um usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) no *Guia do usuário do IAM*.
Convém usar as chaves de contexto de condição global `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` e `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` em políticas baseadas em recursos para limitar as permissões do serviço a um recurso específico. Essa é a maneira mais eficiente de se proteger contra o [problema "confused deputy"](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
Se você utilizar ambas as chaves de contexto de condição global, e o valor `aws:SourceArn` contiver o ID da conta, o valor `aws:SourceAccount` e a conta no valor `aws:SourceArn` deverão utilizar o mesmo ID de conta quando utilizados na mesma instrução de política.
+ Use `aws:SourceArn` se quiser acesso entre serviços para um único recurso.
+ Use `aws:SourceAccount` se você quiser permitir que qualquer recurso nessa conta seja associado ao uso entre serviços.
Na política, certifique-se de usar a chave de contexto de condição global `aws:SourceArn` com o ARN completo do recurso. O exemplo a seguir mostra como fazer isso utilizando o comando da AWS CLI para criar uma função chamada `rds-s3-import-role`.
**Example**
Para Linux, macOS ou Unix:
```
aws iam create-role \
--role-name rds-s3-import-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Para Windows:
```
aws iam create-role ^
--role-name rds-s3-import-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Anexe a política do IAM que você criou ao perfil do IAM que você criou.
O comando da AWS CLI a seguir vincula a política criada na etapa anterior à função `rds-s3-import-role`. Substitua `your-policy-arn` pelo ARN da política que você anotou naquela ocasião.
**Example**
Para Linux, macOS ou Unix:
```
aws iam attach-role-policy \
--policy-arn your-policy-arn \
--role-name rds-s3-import-role
```
Para Windows:
```
aws iam attach-role-policy ^
--policy-arn your-policy-arn ^
--role-name rds-s3-import-role
```
1. Adicione o perfil do IAM à instância de banco de dados.
Faça isso usando o Console de gerenciamento da AWS ou a AWS CLI, conforme descrito a seguir.
### Console
**Para adicionar um perfil do IAM a uma instância de banco de dados do PostgreSQL usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha o nome da instância de de banco de dados do PostgreSQL para exibir os detalhes.
1. Na guia **Connectivity & security** (Conectividade e segurança), na seção **Manage IAM roles** (Gerenciar funções do IAM), escolha a função a ser adicionada sob **Add IAM roles to this instance** (Adicionar funções do IAM a este cluster/esta instância).
1. Em **Feature (Recurso)**, escolha **s3Import**.
1. Escolha **Add role (adicionar função)**.
### AWS CLI
**Para adicionar um perfil do IAM para uma instância de banco de dados do PostgreSQL usando a CLI**
+ Use o comando a seguir para adicionar a função à instância de banco de dados do PostgreSQL chamada `my-db-instance`. Substitua*`your-role-arn`* pelo ARN da função que você anotou em uma etapa anterior. Use `s3Import` para o valor da opção `--feature-name`.
**Example**
Para Linux, macOS ou Unix:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Import \
--role-arn your-role-arn \
--region your-region
```
Para Windows:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Import ^
--role-arn your-role-arn ^
--region your-region
```
### API do RDS
Para adicionar um perfil do IAM a uma instância de banco de dados do PostgreSQL utilizando a API do Amazon RDS, chame a operação [AddRoleToDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddRoleToDBInstance.html).
## Usar credenciais de segurança para acessar um bucket do Amazon S3
Se preferir, você poderá usar credenciais de segurança para conceder acesso a um bucket do Amazon S3 em vez de conceder acesso com uma função do IAM. Faça isso especificando o parâmetro `credentials` na chamada da função [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
O parâmetro `credentials` é uma estrutura do tipo `aws_commons._aws_credentials_1`, que contém credenciais da AWS. Use a função [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) para definir a chave de acesso e a chave secreta em uma estrutura `aws_commons._aws_credentials_1`, conforme mostrado a seguir.
```
postgres=> SELECT aws_commons.create_aws_credentials(
'sample_access_key', 'sample_secret_key', '')
AS creds \gset
```
Depois de criar a estrutura `aws_commons._aws_credentials_1 `, use a função [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) com o parâmetro `credentials` para importar os dados, conforme mostrado a seguir.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
:'creds'
);
```
Outra opção é incluir a chamada de função [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) em linha dentro da chamada de função `aws_s3.table_import_from_s3`.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
## Solução de problemas de acesso ao Amazon S3
Se você encontrar problemas de conexão ao tentar importar dados do Amazon S3, consulte o seguinte para obter recomendações:
+ [Solução de problemas de identidade e acesso do Amazon RDS](security_iam_troubleshoot.md)
+ [Solução de problemas do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) no *Guia do usuário do Amazon Simple Storage Service*
+ [Troubleshooting Amazon S3 and IAM (Solucionar problemas no Amazon S3 e no IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) no *Manual do usuário do IAM*
# Importar dados do Amazon S3 para uma instância de banco de dados do RDS para PostgreSQL
Importe dados do bucket do Amazon S3 usando a função `table_import_from_s3` da extensão aws\$1s3. Para obter informações de referência, consulte [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
**nota**
Os exemplos a seguir usam o método de perfil do IAM para conceder acesso ao bucket do Amazon S3. Assim, as chamadas de função do `aws_s3.table_import_from_s3` não incluem parâmetros de credenciais.
Veja a seguir um exemplo típico.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't1',
'',
'(format csv)',
:'s3_uri'
);
```
Os parâmetros são os seguintes:
+ `t1` – o nome da tabela na instância de banco de dados do PostgreSQL na qual os dados devem ser copiados.
+ `''` – uma lista opcional de colunas na tabela de banco de dados. É possível usar esse parâmetro para indicar quais colunas dos dados do S3 devem ser inseridos em quais colunas da tabela. Se nenhuma coluna for especificada, todas as colunas serão copiadas para a tabela. Para obter um exemplo de uso de uma lista de colunas, consulte [Importar um arquivo do Amazon S3 que usa um delimitador personalizado](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
+ `(format csv)` – argumentos COPY do PostgreSQL. O processo de cópia usa os argumentos e o formato do comando [COPY PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html) para importar os dados. As opções de formato incluem valores separados por vírgula (CSV), conforme mostrado neste exemplo, texto e binário. O padrão é texto.
+ `s3_uri` – uma estrutura que contém as informações que identificam o arquivo do Amazon S3. Para obter um exemplo de como usar a função [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) para criar uma estrutura `s3_uri`, consulte [Visão geral da importação de dados do Amazon S3](USER_PostgreSQL.S3Import.Overview.md).
Para ter mais informações sobre essa função, consulte [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
A função `aws_s3.table_import_from_s3` retorna texto. Para especificar outros tipos de arquivos para importação de um bucket do Amazon S3, veja um dos exemplos a seguir.
**nota**
Importar 0 byte causará um erro.
**Topics**
+ [
## Importar um arquivo do Amazon S3 que usa um delimitador personalizado
](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter)
+ [
## Importar um arquivo do Amazon S3 compactado (gzip)
](#USER_PostgreSQL.S3Import.FileFormats.gzip)
+ [
## Importar um arquivo do Amazon S3 codificado
](#USER_PostgreSQL.S3Import.FileFormats.Encoded)
## Importar um arquivo do Amazon S3 que usa um delimitador personalizado
O exemplo a seguir mostra como importar um arquivo que usa um delimitador personalizado. Ele também mostra como controlar onde colocar os dados na tabela de banco de dados usando o parâmetro `column_list` da função [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Para este exemplo, suponha que as informações a seguir estejam organizadas em colunas delimitadas por barras verticais no arquivo do Amazon S3.
```
1|foo1|bar1|elephant1
2|foo2|bar2|elephant2
3|foo3|bar3|elephant3
4|foo4|bar4|elephant4
...
```
**Como importar um arquivo que usa um delimitador personalizado**
1. Crie uma tabela no banco de dados para os dados importados.
```
postgres=> CREATE TABLE test (a text, b text, c text, d text, e text);
```
1. Use o seguinte formato da função [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) para importar dados do arquivo do Amazon S3.
Você pode incluir a chamada de função [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) em linha dentro da chamada de função `aws_s3.table_import_from_s3` para especificar o arquivo.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test',
'a,b,d,e',
'DELIMITER ''|''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'pipeDelimitedSampleFile', 'us-east-2')
);
```
Os dados estão agora na tabela nas colunas a seguir.
```
postgres=> SELECT * FROM test;
a | b | c | d | e
---+------+---+---+------+-----------
1 | foo1 | | bar1 | elephant1
2 | foo2 | | bar2 | elephant2
3 | foo3 | | bar3 | elephant3
4 | foo4 | | bar4 | elephant4
```
## Importar um arquivo do Amazon S3 compactado (gzip)
O exemplo a seguir mostra como importar um arquivo do Amazon S3 compactado com gzip. O arquivo que você importa precisa ter os seguintes metadados do Simple Storage Service (Amazon S3):
+ Chave: `Content-Encoding`
+ Valor:: `gzip`
Se você carregar o arquivo usando o Console de gerenciamento da AWS, os metadados geralmente são aplicados pelo sistema. Para obter informações sobre o carregamento de arquivos para o Simple Storage Service (Amazon S3) usando o Console de gerenciamento da AWS, a AWS CLI ou a API, consulte [Carregar objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) no *Guia do usuário do Amazon Simple Storage Service*.
Para ter mais informações sobre metadados do Simple Storage Service (Amazon S3) e detalhes sobre metadados fornecidos pelo sistema, consulte [Editar metadados de objeto no console do Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) no *Guia do usuário do Amazon Simple Storage Service*.
Importe o arquivo gzip para a sua instância de banco de dados do RDS for PostgreSQL do , conforme mostrado a seguir.
```
postgres=> CREATE TABLE test_gzip(id int, a text, b text, c text, d text);
postgres=> SELECT aws_s3.table_import_from_s3(
'test_gzip', '', '(format csv)',
'amzn-s3-demo-bucket', 'test-data.gz', 'us-east-2'
);
```
## Importar um arquivo do Amazon S3 codificado
O exemplo a seguir mostra como importar um arquivo do Amazon S3 que tenha codificação Windows-1252.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test_table', '', 'encoding ''WIN1252''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'SampleFile', 'us-east-2')
);
```
# Referência de funções
**Topics**
+ [
## aws\$1s3.table\$1import\$1from\$1s3
](#aws_s3.table_import_from_s3)
+ [
## aws\$1commons.create\$1s3\$1uri
](#USER_PostgreSQL.S3Import.create_s3_uri)
+ [
## aws\$1commons.create\$1aws\$1credentials
](#USER_PostgreSQL.S3Import.create_aws_credentials)
## aws\$1s3.table\$1import\$1from\$1s3
Importa dados do Amazon S3 para uma tabela doAmazon RDS do . A extensão `aws_s3` fornece a função `aws_s3.table_import_from_s3`. O valor de retorno é texto.
### Sintaxe
Os parâmetros necessários são `table_name`, `column_list` e `options`. Eles identificam a tabela do banco de dados e especificam como os dados são copiados nessa tabela.
Você também pode usar os seguintes parâmetros:
+ O parâmetro `s3_info` especifica o arquivo do Amazon S3 a ser importado. Quando você usa esse parâmetro, o acesso ao Amazon S3 é fornecido por uma função do IAM para a instância do de banco de dados do PostgreSQL.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1
)
```
+ O parâmetro `credentials` especifica as credenciais para acessar o Amazon S3. Ao usar esse parâmetro, você não usa uma função do IAM.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1,
credentials aws_commons._aws_credentials_1
)
```
### Parâmetros
*table\$1name*
Uma string de texto necessária contendo o nome da tabela de banco de dados PostgreSQL para a qual importar os dados.
*column\$1list*
Uma string de texto necessária contendo uma lista opcional das colunas da tabela de banco de dados PostgreSQL para a qual copiar os dados. Se a string estiver vazia, todas as colunas da tabela serão usadas. Para ver um exemplo, consulte [Importar um arquivo do Amazon S3 que usa um delimitador personalizado](USER_PostgreSQL.S3Import.FileFormats.md#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
*Opções do*
Uma string de texto necessária contendo argumentos para o comando PostgreSQL `COPY`. Esses argumentos especificam como os dados devem ser copiados para a tabela do PostgreSQL. Para obter mais detalhes, consulte [Documentação de COPY do PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
*s3\$1info*
Um tipo composto `aws_commons._s3_uri_1` contendo as seguintes informações sobre o objeto do S3:
+ `bucket` – O nome do Amazon S3 bucket que contém o arquivo.
+ `file_path` – o nome do Amazon S3 arquivo, incluindo o caminho do arquivo.
+ `region`: a região da AWS em que o arquivo se encontra. Para obter uma listagem de nomes de regiões da AWS e os valores associados, consulte [Regiões, zonas de disponibilidade e Local Zones](Concepts.RegionsAndAvailabilityZones.md).
*credenciais*
Um tipo composto `aws_commons._aws_credentials_1` contendo as seguintes credenciais a serem usadas para a operação de importação:
+ Chave de acesso
+ Chave secreta
+ Token de sessão
Para obter informações sobre como criar uma estrutura `aws_commons._aws_credentials_1` composta, consulte [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials).
### Sintaxe alternativa
Para ajudar nos testes, você pode usar um conjunto expandido de parâmetros em vez dos parâmetros `s3_info` e `credentials`. Veja a seguir as variações acionais da sintaxe da função `aws_s3.table_import_from_s3`.
+ Em vez de usar o parâmetro `s3_info` para identificar um arquivo do Amazon S3, use a combinação dos parâmetros `bucket`, `file_path` e `region`. Com essa forma da função, o acesso ao Amazon S3 é fornecido por uma função do IAM na instância de banco de dados do PostgreSQL.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text
)
```
+ Em vez de usar o parâmetro `credentials` para especificar o acesso ao Amazon S3, use a combinação dos parâmetros `access_key`, `session_key` e `session_token`.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text,
access_key text,
secret_key text,
session_token text
)
```
### Parâmetros alternativos
*Bucket de*
Uma string de texto contendo o nome do bucket do Amazon S3 que contém o arquivo.
*file\$1path*
Uma string de texto contendo o nome do arquivo do Amazon S3, incluindo o caminho do arquivo.
*region*
Uma string de texto que identifica a Região da AWS do arquivo. Para obter uma listagem de nomes de Região da AWS e os valores associados, consulte [Regiões, zonas de disponibilidade e Local Zones](Concepts.RegionsAndAvailabilityZones.md).
*access\$1key*
Uma string de texto contendo a chave de acesso a ser usada para a operação de importação. O padrão é NULL.
*secret\$1key*
Uma string de texto contendo a chave secreta a ser usada para a operação de importação. O padrão é NULL.
*session\$1token*
(Opcional) Uma string de texto contendo a chave de sessão a ser usada para a operação de importação. O padrão é NULL.
## aws\$1commons.create\$1s3\$1uri
Cria uma estrutura `aws_commons._s3_uri_1` para comportar informações do arquivo do Amazon S3. Use os resultados da função `aws_commons.create_s3_uri` no parâmetro `s3_info` da função [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3).
### Sintaxe
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```
### Parâmetros
*Bucket de*
Uma string de texto necessária contendo o nome do bucket do Amazon S3 para o arquivo.
*file\$1path*
Uma string de texto necessária contendo o nome do arquivo do Amazon S3, incluindo o caminho do arquivo.
*region*
Uma string de texto necessária que contém a Região da AWS na qual o arquivo se encontra. Para obter uma listagem de nomes de Região da AWS e os valores associados, consulte [Regiões, zonas de disponibilidade e Local Zones](Concepts.RegionsAndAvailabilityZones.md).
## aws\$1commons.create\$1aws\$1credentials
Define uma chave de acesso e uma chave secreta em uma estrutura `aws_commons._aws_credentials_1`. Use os resultados da função `aws_commons.create_aws_credentials` no parâmetro `credentials` da função [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3).
### Sintaxe
```
aws_commons.create_aws_credentials(
access_key text,
secret_key text,
session_token text
)
```
### Parâmetros
*access\$1key*
Uma string de texto necessária contendo a chave de acesso a ser usada para importar um arquivo do Amazon S3. O padrão é NULL.
*secret\$1key*
Uma string de texto necessária contendo a chave secreta a ser usada para importar um arquivo do Amazon S3. O padrão é NULL.
*session\$1token*
Uma string de texto opcional contendo o token de sessão a ser usado para importar um arquivo do Amazon S3. O padrão é NULL. Se você fornecer um `session_token` opcional, poderá usar credenciais temporárias.
# Como transportar bancos de dados PostgreSQL entre instâncias de banco de dados
Usando os bancos de dados PostgreSQL transportáveis para Amazon RDS, você pode mover um banco de dados PostgreSQL entre duas instâncias de banco de dados. Essa é uma maneira muito rápida de migrar bancos de dados grandes entre diferentes instâncias de banco de dados. Para usar essa abordagem, suas instâncias de banco de dados devem executar a mesma versão principal do PostgreSQL.
Esse recurso requer que você instale a extensão `pg_transport` nas instâncias de banco de dados de origem e de destino. A extensão `pg_transport` fornece um mecanismo de transporte físico que move os arquivos de banco de dados com o mínimo de processamento. Esse mecanismo move os dados muito mais rapidamente que os processos tradicionais de despejo e carregamento, com menos tempo de inatividade.
**nota**
Os bancos de dados PostgreSQL transportáveis estão disponíveis no RDS para PostgreSQL versões 11.5 e posteriores e 10.10 e posteriores.
Para transportar uma instância de banco de dados PostgreSQL de uma instância de banco de dados do RDS for PostgreSQL para outra, você primeiro configura as instâncias de origem e de destino, conforme detalhado em [ Configurar uma instância de banco de dados para transporte](PostgreSQL.TransportableDB.Setup.md). Em seguida, você pode transportar o banco de dados usando a função descrita em [ Como transportar um banco de dados PostgreSQL](PostgreSQL.TransportableDB.Transporting.md).
**Topics**
+ [
## O que acontece durante o transporte do banco de dados
](#PostgreSQL.TransportableDB.DuringTransport)
+ [
## Limitações para o uso de bancos de dados PostgreSQL transportáveis
](#PostgreSQL.TransportableDB.Limits)
+ [
# Configurar o transporte de um banco de dados PostgreSQL
](PostgreSQL.TransportableDB.Setup.md)
+ [
# Transportar um banco de dados PostgreSQL para o destino a partir da origem
](PostgreSQL.TransportableDB.Transporting.md)
+ [
# Referência de funções de bancos de dados transportáveis
](PostgreSQL.TransportableDB.transport.import_from_server.md)
+ [
# Referência de parâmetros de bancos de dados transportáveis
](PostgreSQL.TransportableDB.Parameters.md)
## O que acontece durante o transporte do banco de dados
O recurso de bancos de dados PostgreSQL transportáveis usa um modelo pull para importar o banco de dados da instância de banco de dados de origem para a de destino. A função `transport.import_from_server` cria o banco de dados em trânsito na instância de banco de dados de destino. O banco de dados em trânsito está inacessível na instância de banco de dados de destino durante o transporte.
Quando o transporte começa, todas as sessões atuais no banco de dados de origem são encerradas. Quaisquer bancos de dados que não sejam o banco de dados de origem na instância de banco de dados de origem não são afetados pelo transporte.
O banco de dados de origem é colocado em um modo somente leitura especial. Enquanto estiver nesse modo, você pode se conectar ao banco de dados de origem e executar consultas somente leitura. No entanto, as consultas habilitadas para gravação e alguns outros tipos de comandos estão bloqueados. Somente o banco de dados de origem específico que está sendo transportado é afetado por essas restrições.
Durante o transporte, você não pode restaurar a instância do banco de dados de destino em um determinado momento. Isso ocorre porque o transporte não é transacional e não usa o log de gravação antecipada do PostgreSQL para registrar as alterações. Se a instância de banco de dados de destino tiver backups automáticos ativados, um backup será feito automaticamente após a conclusão do transporte. As restaurações em um ponto anterior no tempo ficam disponíveis por algumas horas *após* a conclusão do backup.
Se o transporte falhar, a extensão `pg_transport` tenta desfazer todas as alterações nas instâncias de banco de dados de origem e destino. Isso inclui a remoção do banco de dados parcialmente transportado do destino. Dependendo do tipo de falha, o banco de dados de origem pode continuar a rejeitar consultas habilitadas para gravação. Se isso acontecer, use o comando a seguir para permitir consultas habilitadas para gravação.
```
ALTER DATABASE db-name SET default_transaction_read_only = false;
```
## Limitações para o uso de bancos de dados PostgreSQL transportáveis
Os bancos de dados transportáveis têm as seguintes limitações:
+ **Réplicas de leitura ** – não é possível usar bancos de dados transportáveis em réplicas de leitura nem em instâncias pai de réplicas de leitura.
+ **Tipos de coluna não compatíveis** – não é possível usar os tipos de dados `reg` em nenhuma tabela de banco de dados que você planeja transportar com esse método. Esses tipos dependem dos IDs de objeto (OIDs) do catálogo do sistema, que geralmente são alterados durante o transporte.
+ **Espaços de tabela** – todos os objetos do banco de dados de origem devem estar no espaço de tabela `pg_default` padrão.
+ **Compatibilidade** – as instâncias de banco de dados de origem e destino devem executar a mesma versão principal do PostgreSQL.
+ **Extensões**: a instância de banco de dados de origem pode ter apenas a extensão `pg_transport` instalada.
+ **Funções e ACLs** – os privilégios de acesso e as informações de propriedade do banco de dados de origem não são transferidos para o banco de dados de destino. Todos os objetos de banco de dados são criados e pertencentes ao usuário de destino local do transporte.
+ **Transportes simultâneos**: uma única instância de banco de dados pode aceitar até 32 transportes simultâneos, incluindo importações e exportações, se os processos do operador tiverem sido configurados corretamente.
+ **Somente para instâncias de banco de dados do RDS for PostgreSQL**: os bancos de dados transportáveis do PostgreSQL são compatíveis apenas com instâncias de banco de dados do RDS for PostgreSQL. Não é possível utilizá-los com bancos de dados locais ou bancos de dados em execução no Amazon EC2.
# Configurar o transporte de um banco de dados PostgreSQL
Antes de começar, certifique-se de que as instâncias de banco de dados do RDS for PostgreSQL atendam aos seguintes requisitos:
+ As instâncias de banco de dados do RDS for PostgreSQL para a origem e o destino devem ser executadas na mesma versão do PostgreSQL.
+ O banco de dados de destino não pode ter um banco de dados com o mesmo nome do banco de dados de origem que você deseja transportar.
+ A conta que você usa para executar o transporte precisa dos privilégios `rds_superuser` nos bancos de dados de origem e de destino.
+ O grupo de segurança da instância de banco de dados de origem deve permitir acesso de entrada da instância de banco de dados de destino. Isso pode já ser o caso se as instâncias de banco de dados de origem e de destino estiverem localizadas na VPC. Para obter mais informações sobre grupo de seguranças, consulte [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md).
O transporte de bancos de dados de uma instância de banco de dados de origem para uma instância de banco de dados de destino requer várias alterações no grupo de parâmetros de banco de dados associado a cada instância. Isso significa que você deve criar um grupo de parâmetros de banco de dados personalizado para a instância de banco de dados de origem e criar um grupo de parâmetros de banco de dados personalizado para a instância de banco de dados de destino.
**nota**
Se suas instâncias de banco de dados já estiverem configuradas usando grupos de parâmetros de banco de dados personalizados, você poderá começar com a etapa 2 no procedimento a seguir.
**Para configurar os parâmetros de grupos de banco de dados personalizados para o transporte de bancos de dados**
Para as etapas a seguir, use uma conta que tenha os privilégios `rds_superuser`.
1. Se as instâncias de banco de dados de origem e de destino usarem um grupo de parâmetros de banco de dados padrão, você precisará criar um grupo de parâmetros de banco de dados personalizado usando a versão apropriada para suas instâncias. Você faz isso para poder alterar valores para vários parâmetros. Para obter mais informações, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
1. No grupo de parâmetros de banco de dados personalizado, altere os valores dos seguintes parâmetros:
+ `shared_preload_libraries`: adicionar `pg_transport` à lista de bibliotecas.
+ `pg_transport.num_workers`: o valor padrão é 3. Aumente ou reduza esse valor conforme necessário para o banco de dados. Para um banco de dados de 200 GB, recomendamos não mais que 8. Tenha em mente que, se você aumentar o valor padrão desse parâmetro, você também deverá aumentar o valor de `max_worker_processes`.
+ `pg_transport.work_mem`: o valor padrão é 128 MB ou 256 MB, dependendo da versão do PostgreSQL. A configuração padrão geralmente pode ser deixada inalterada.
+ `max_worker_processes`: o valor desse parâmetro precisa ser definido usando o seguinte cálculo:
```
(3 * pg_transport.num_workers) + 9
```
Esse valor é obrigatório no destino para lidar com vários processos de operador em segundo plano envolvidos no transporte. Para saber mais sobre `max_worker_processes,` consulte [Consumo de recursos](https://www.postgresql.org/docs/current/runtime-config-resource.html) na documentação do PostgreSQL.
Para obter mais informações sobre parâmetros do `pg_transport`, consulte [Referência de parâmetros de bancos de dados transportáveis](PostgreSQL.TransportableDB.Parameters.md).
1. Reinicialize a instância de banco de dados do RDS for PostgreSQL de origem e a instância de destino para que as configurações dos parâmetros entrem em vigor.
1. Conecte-se à sua instância de banco de dados do RDS for PostgreSQL de origem.
```
psql --host=source-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Remova extensões estranhas do esquema público da instância de banco de dados. Somente a extensão `pg_transport` é permitida durante a operação de transporte real.
1. Instale a extensão `pg_transport` da seguinte forma:
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
1. Conecte-se à sua instância de banco de dados do RDS for PostgreSQL de destino. Remova qualquer extensão estranha e, em seguida, instale a extensão `pg_transport`.
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
# Transportar um banco de dados PostgreSQL para o destino a partir da origem
Depois de concluir o processo descrito em [Configurar o transporte de um banco de dados PostgreSQL](PostgreSQL.TransportableDB.Setup.md), você pode iniciar o transporte. Para fazer isso, execute a função `transport.import_from_server` na instância de banco de dados de destino. Na sintaxe a seguir, você pode encontrar os parâmetros da função.
```
SELECT transport.import_from_server(
'source-db-instance-endpoint',
source-db-instance-port,
'source-db-instance-user',
'source-user-password',
'source-database-name',
'destination-user-password',
false);
```
O valor `false` mostrado no exemplo diz à função que esta não é uma simulação. Para testar sua configuração de transporte, você pode especificar `true` para `dry_run` quando você chama a função, conforme mostrado a seguir:
```
postgres=> SELECT transport.import_from_server(
'docs-lab-source-db.666666666666aws-region.rds.amazonaws.com', 5432,
'postgres', '********', 'labdb', '******', true);
INFO: Starting dry-run of import of database "labdb".
INFO: Created connections to remote database (took 0.03 seconds).
INFO: Checked remote cluster compatibility (took 0.05 seconds).
INFO: Dry-run complete (took 0.08 seconds total).
import_from_server
--------------------
(1 row)
```
As linhas INFO são emitidas porque o parâmetro `pg_transport.timing` está definido como seu valor padrão, `true`. Defina `dry_run` para `false` quando você executa o comando e o banco de dados de origem é importado para o destino, conforme mostrado a seguir:
```
INFO: Starting import of database "labdb".
INFO: Created connections to remote database (took 0.02 seconds).
INFO: Marked remote database as read only (took 0.13 seconds).
INFO: Checked remote cluster compatibility (took 0.03 seconds).
INFO: Signaled creation of PITR blackout window (took 2.01 seconds).
INFO: Applied remote database schema pre-data (took 0.50 seconds).
INFO: Created connections to local cluster (took 0.01 seconds).
INFO: Locked down destination database (took 0.00 seconds).
INFO: Completed transfer of database files (took 0.24 seconds).
INFO: Completed clean up (took 1.02 seconds).
INFO: Physical transport complete (took 3.97 seconds total).
import_from_server
--------------------
(1 row)
```
Esta função requer que você forneça senhas de usuário do banco de dados. Portanto, recomendamos que você altere as senhas das funções de usuário usadas após a conclusão do transporte. Ou você pode usar variáveis de ligação do SQL para criar funções de usuário temporárias. Use essas funções temporárias para o transporte e descarte as funções posteriormente.
Quando o transporte não for bem-sucedido, talvez você veja uma mensagem de erro semelhante à seguinte:
```
pg_transport.num_workers=8 25% of files transported failed to download file data
```
A mensagem de erro “falha ao baixar dados do arquivo” indica que o número de processos de trabalho não está definido corretamente para o tamanho do banco de dados. Talvez seja necessário aumentar ou diminuir o valor definido para `pg_transport.num_workers`. Cada falha informa a porcentagem de conclusão, para que você possa ver o impacto de suas alterações. Por exemplo, alterar a configuração de 8 para 4 em um caso resultou no seguinte:
```
pg_transport.num_workers=4 75% of files transported failed to download file data
```
Lembre-se de que o parâmetro `max_worker_processes` também é levado em consideração durante o processo de transporte. Em outras palavras, talvez seja necessário modificar `pg_transport.num_workers` e `max_worker_processes` para transportar o banco de dados com êxito. O exemplo mostrado finalmente funcionou quando `pg_transport.num_workers` foi definido como 2:
```
pg_transport.num_workers=2 100% of files transported
```
Para obter mais informações sobre a função `transport.import_from_server` seus respectivos parâmetros de configuração, consulte [Referência de funções de bancos de dados transportáveis](PostgreSQL.TransportableDB.transport.import_from_server.md).
# Referência de funções de bancos de dados transportáveis
A função `transport.import_from_server` transporta um banco de dados PostgreSQL importando-o de uma instância de banco de dados de origem para uma instância de banco de dados de destino. Isso é feito usando um mecanismo de transporte de conexão de banco de dados físico.
Antes de iniciar o transporte, essa função verifica se as instâncias de banco de dados de origem e de destino são da mesma versão e são compatíveis com a migração. Também confirma que a instância de banco de dados de destino tem espaço suficiente para a origem.
**Sintaxe**
```
transport.import_from_server(
host text,
port int,
username text,
password text,
database text,
local_password text,
dry_run bool
)
```
**Valor de retorno**
Nenhum.
**Parâmetros**
Você pode encontrar descrições dos parâmetros da função `transport.import_from_server` na tabela a seguir.
****
| Parâmetro | Descrição |
| --- | --- |
| host | O endpoint da instância de banco de dados de origem. |
| port | Um número inteiro que representa a porta da instância de banco de dados de origem. As instâncias de banco de dados do PostgreSQL costumam usar a porta 5432. |
| username | O usuário da instância de banco de dados de origem. Este usuário deve ser um membro da função `rds_superuser`. |
| password | A senha da instância de banco de dados de origem. |
| database | O nome do banco de dados na instância do banco de dados de origem a ser transportada. |
| local\$1password | A senha local do usuário atual para a instância de banco de dados de destino. Este usuário deve ser um membro da função `rds_superuser`. |
| dry\$1run | Um valor booleano opcional que especifica se é necessário executar uma simulação. O padrão é `false`, o que significa que o transporte continua.Para confirmar a compatibilidade entre as instâncias de banco de dados de origem e destino sem executar o transporte real, configure dry\$1run como true. |
**Exemplo**
Para ver um exemplo, consulte [Transportar um banco de dados PostgreSQL para o destino a partir da origem](PostgreSQL.TransportableDB.Transporting.md).
# Referência de parâmetros de bancos de dados transportáveis
Vários parâmetros controlam o comportamento da extensão `pg_transport`. A seguir, você pode encontrar as descrições desses parâmetros.
**`pg_transport.num_workers`**
O número de operadores a serem usados para o processo de transporte. O padrão é 3. Os valores válidos são 1–32. Geralmente, mesmo os maiores transportes de banco de dados exigem menos de oito operadores. O valor dessa configuração na instância de banco de dados de destino é usada pelo destino e pela origem durante o transporte.
**`pg_transport.timing` **
Especifica se é necessário relatar informações de tempo durante o transporte. O padrão é `true`, o que significa que as informações de tempo são relatadas. Recomendamos deixar esse parâmetro definido como `true` para que você possa monitorar o progresso. Veja um exemplo de resultado em [Transportar um banco de dados PostgreSQL para o destino a partir da origem](PostgreSQL.TransportableDB.Transporting.md).
**`pg_transport.work_mem`**
A quantidade máxima de memória a ser alocada para cada operador. O padrão é 131.072 kilobytes (KB) ou 262.144 KB (256 MB), dependendo da versão do PostgreSQL. O valor mínimo é de 64 megabytes (65.536 KB). Os valores válidos estão em kilobytes (KBs) como unidades binárias de base 2, em que 1 KB = 1.024 bytes.
O transporte pode usar menos memória que o especificado neste parâmetro. Geralmente, mesmo transportes grandes de banco de dados exigem menos de 256 MB (262.144 KB) de memória por operador.
# Exportar dados de uma instância de banco de dados do RDS para PostgreSQL para o Amazon S3
Consulte dados em um RDS para PostgreSQL instância de banco de dados e exporte-os diretamente para arquivos armazenados em um bucket do Amazon S3. Para fazer isso, primeiro instale a extensão `aws_s3` do RDS para PostgreSQL. Essa extensão fornece as funções usadas para exportar os resultados de consultas para o Amazon S3. A seguir, é possível descobrir como instalar a extensão e exportar dados para o Amazon S3.
**nota**
A exportação entre contas não é compatível com o Amazon S3.
Todas as versões do RDS para PostgreSQL disponíveis no momento são compatíveis com a exportação de dados do Amazon Simple Storage Service. Para obter informações detalhadas sobre as versões, consulte [Atualizações do Amazon RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html) nas *Notas de lançamento do Amazon RDS para PostgreSQL*.
Se você não tiver um bucket configurado para sua exportação, consulte os tópicos a seguir no *Guia do usuário do Amazon Simple Storage Service*.
+ Configuração do Amazon S3
+ [Como criar um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)
Por padrão, os dados exportados do RDS para PostgreSQL ao Amazon S3 usam criptografia do lado do servidor com uma Chave gerenciada pela AWS. Se estiver usando a criptografia do bucket, o bucket do Amazon S3 deverá ser criptografado com uma chave do AWS Key Management Service (AWS KMS) (SSE-KMS). No momento, os buckets criptografados com chaves gerenciadas pelo Amazon S3 (SSE-S3) não são compatíveis.
**nota**
É possível salvar os dados do snapshot do banco de dados no Amazon S3 usando o Console de gerenciamento da AWS, a AWS CLI ou a API do Amazon RDS. Para obter mais informações, consulte [Exportação de dados de snapshot de banco de dados para o Amazon S3 para Amazon RDS](USER_ExportSnapshot.md).
**Topics**
+ [
## Instalar a extensão aws\$1s3
](#USER_PostgreSQL.S3Export.InstallExtension)
+ [
## Visão geral da exportação de dados para o Amazon S3
](#postgresql-s3-export-overview)
+ [
## Especificar o caminho do arquivo do Amazon S3 para o qual exportar
](#postgresql-s3-export-file)
+ [
# Configurar o acesso a um bucket do Amazon S3
](postgresql-s3-export-access-bucket.md)
+ [
# Exportar dados de consulta usando a função aws\$1s3.query\$1export\$1to\$1s3
](postgresql-s3-export-examples.md)
+ [
# Referência de funções
](postgresql-s3-export-functions.md)
+ [
# Solução de problemas de acesso ao Amazon S3
](postgresql-s3-export-troubleshoot.md)
## Instalar a extensão aws\$1s3
Antes de usar o Amazon Simple Storage Service com a sua instância de banco de dados do RDS para PostgreSQL, você precisa instalar a extensão `aws_s3`. Essa extensão fornece funções para exportar dados de uma instância de banco de dados do RDS para PostgreSQL para um bucket do Amazon S3. Também fornece as funções para importar dados do Amazon S3. Para obter mais informações, consulte [Importar dados do Amazon S3 para uma instância de banco de dados do RDS para PostgreSQL](USER_PostgreSQL.S3Import.md). A extensão `aws_s3` depende de algumas das funções auxiliares da extensão `aws_commons`, que é instalada automaticamente quando necessária.
**Como instalar a extensão `aws_s3`**
1. Use psql (ou pgAdmin) para se conectar à instância de banco de dados do RDS para PostgreSQL como um usuário que tem privilégios `rds_superuser`. Se você manteve o nome padrão durante o processo de configuração, se conectará como `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Para instalar a extensão, execute o comando a seguir.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Para verificar se a extensão está instalada, você pode usar o metacomando psql `\dx`.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
As funções para importar dados do Amazon S3 e exportar dados para o Amazon S3 agora estão disponíveis para uso.
### Confira se a sua versão do RDS para PostgreSQL permite exportações para o Amazon S3.
Você pode verificar se sua versão do RDS para PostgreSQL oferece suporte à exportação para o Amazon S3 usando o comando `describe-db-engine-versions`. O exemplo a seguir verifica a compatibilidade com a versão 10.14.
```
aws rds describe-db-engine-versions --region us-east-1
--engine postgres --engine-version 10.14 | grep s3Export
```
Se a saída incluir a string `"s3Export"`, o mecanismo é compatível com exportações do Amazon S3. Caso contrário, não há compatibilidade.
## Visão geral da exportação de dados para o Amazon S3
Para exportar dados armazenados em um banco de dados RDS para PostgreSQL para um bucket do Amazon S3, use o procedimento a seguir.
**Para exportar dados do RDS para PostgreSQL para o S3**
1. Identifique um caminho de arquivo do Amazon S3 a ser usado para exportar dados. Para obter detalhes sobre esse processo, consulte [Especificar o caminho do arquivo do Amazon S3 para o qual exportar](#postgresql-s3-export-file).
1. Conceda permissão para acessar o bucket do Amazon S3.
Para exportar dados para um arquivo do Amazon S3, forneça à instância de banco de dados do RDS para PostgreSQL permissão para acessar o bucket do Amazon S3 a ser usado para armazenamento pela exportação. Isso inclui as seguintes etapas:
1. Crie uma política do IAM que forneça acesso a um bucket do Amazon S3 para o qual você deseja exportar.
1. Crie uma função do IAM.
1. Anexe a política criada à função criada.
1. Adicione esse perfil do IAM à instância de banco de dados.
Para obter detalhes sobre esse processo, consulte [Configurar o acesso a um bucket do Amazon S3](postgresql-s3-export-access-bucket.md).
1. Identifique uma consulta de banco de dados para obter os dados. Exporte os dados da consulta chamando a função `aws_s3.query_export_to_s3`.
Após concluir as tarefas de preparação anteriores, use a função [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) para exportar os resultados da consulta para o Amazon S3. Para obter detalhes sobre esse processo, consulte [Exportar dados de consulta usando a função aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
## Especificar o caminho do arquivo do Amazon S3 para o qual exportar
Especifique as seguintes informações para identificar o local no Amazon S3 para o qual deseja exportar dados:
+ Nome do bucket – um *bucket* é um contêiner para objetos ou arquivos do Amazon S3.
Para ter mais informações sobre como armazenar dados com o Amazon S3, consulte [Criação de um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) e [Trabalhar com objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-downloading-objects.html) no *Guia do usuário do Amazon Simple Storage Service*.
+ Caminho do arquivo – o caminho do arquivo identifica onde a exportação é armazenada no bucket do Amazon S3. O caminho do arquivo consiste no seguinte:
+ Um prefixo de caminho opcional que identifica um caminho de pasta virtual.
+ Um prefixo de arquivo que identifica um ou mais arquivos a serem armazenados. Exportações maiores são armazenadas em vários arquivos, cada um com um tamanho máximo de aproximadamente 6 GB. Os nomes de arquivos adicionais têm o mesmo prefixo de arquivo, mas com o acréscimo de `_partXX`. O `XX` representa 2, depois 3 e assim por diante.
Por exemplo, um caminho de arquivo com uma pasta `exports` e um prefixo de arquivo `query-1-export` é `/exports/query-1-export`.
+ Região da AWS (opcional): a região da AWS onde o bucket do Amazon S3 está localizado. Se você não especificar um valor de região da AWS, o Amazon RDS salvará os arquivos no Amazon S3, na mesma região da AWS que o cluster de banco de dados de exportação.
**nota**
Atualmente, a região AWS deve ser a mesma que a região da instância de Bancos de Dados de exportação .
Para obter uma listagem de nomes de regiões da AWS e os valores associados, consulte [Regiões, zonas de disponibilidade e Local Zones](Concepts.RegionsAndAvailabilityZones.md).
Para manter as informações do arquivo do Amazon S3 sobre onde a exportação deve ser armazenada, você pode usar a função [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) para criar uma estrutura `aws_commons._s3_uri_1` composta da seguinte forma.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Posteriormente, você fornece esse valor de `s3_uri_1` como um parâmetro na chamada para a função [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). Para ver exemplos, consulte [Exportar dados de consulta usando a função aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
# Configurar o acesso a um bucket do Amazon S3
Para exportar dados ao Amazon S3, forneça à instância de banco de dados PostgreSQL permissão para acessar o bucket do Amazon S3 para o qual os arquivos serão enviados.
Para fazer isso, use o procedimento a seguir.
**Como conceder acesso a uma instância de banco de dados PostgreSQL ao Amazon S3 por meio de um perfil do IAM**
1. Crie uma política do IAM.
Essa política concede ao bucket e ao objeto as permissões para que a instância de banco de dados PostgreSQL acesse o Amazon S3.
Como parte da criação dessa política, execute as seguintes etapas:
1. Inclua na política as seguintes ações necessárias para permitir a transferência de arquivos da instância de banco de dados PostgreSQL para um bucket do Amazon S3:
+ `s3:PutObject`
+ `s3:AbortMultipartUpload`
1. Inclua o nome do recurso da Amazon (ARN) que identifica o bucket do Amazon S3 e os objetos no bucket. O formato do ARN para acessar o Amazon S3 é: `arn:aws:s3:::amzn-s3-demo-bucket/*`
Para obter mais informações sobre como criar uma política do IAM para o Amazon RDS para PostgreSQL, consulte [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Consulte também [Tutorial: criar e anexar sua primeira política gerenciada pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) no *Manual do usuário do IAM*.
O comando da AWS CLI a seguir cria uma política do IAM denominada `rds-s3-export-policy` com essas opções. Ele concede acesso a um bucket denominado *amzn-s3-demo-bucket*.
**Atenção**
Recomendamos configurar o banco de dados em uma VPC privada que tenha políticas de endpoint configuradas para acessar buckets específicos. Para obter mais informações, consulte [Usar políticas de endpoint para o Amazon S3](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-s3.html#vpc-endpoints-policies-s3) no Manual do usuário da Amazon VPC.
É altamente recomendável não criar uma política com acesso a todos os recursos. Esse acesso pode representar uma ameaça à segurança dos dados. Se você criar uma política que forneça o acesso `S3:PutObject` a todos os recursos usando `"Resource":"*"`, um usuário com privilégios de exportação poderá exportar dados para todos os buckets em sua conta. Além disso, o usuário poderá exportar dados para *qualquer bucket gravável publicamente dentro de sua região daAWS*.
Depois de criar a política, observe o nome do recurso da Amazon (ARN) da política. O ARN será necessário para uma etapa posterior, quando você anexar a política a um perfil do IAM.
```
aws iam create-policy --policy-name rds-s3-export-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3export",
"Action": [
"s3:PutObject*",
"s3:ListBucket",
"s3:GetObject*",
"s3:DeleteObject*",
"s3:GetBucketLocation",
"s3:AbortMultipartUpload"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Crie uma função do IAM.
Faça isso para que o Amazon RDS do possa assumir esse perfil do IAM em seu nome para acessar os buckets do Amazon S3. Para ter mais informações, consulte [Criar um perfil para delegar permissões a um usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) no *Guia do usuário do IAM*.
Convém usar as chaves de contexto de condição global `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` e `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` em políticas baseadas em recursos para limitar as permissões do serviço a um recurso específico. Essa é a maneira mais eficiente de se proteger contra o [problema "confused deputy"](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
Se você utilizar ambas as chaves de contexto de condição global, e o valor `aws:SourceArn` contiver o ID da conta, o valor `aws:SourceAccount` e a conta no valor `aws:SourceArn` deverão utilizar o mesmo ID de conta quando utilizados na mesma instrução de política.
+ Use `aws:SourceArn` se quiser acesso entre serviços para um único recurso.
+ Use `aws:SourceAccount` se você quiser permitir que qualquer recurso nessa conta seja associado ao uso entre serviços.
Na política, certifique-se de usar a chave de contexto de condição global `aws:SourceArn` com o ARN completo do recurso. O exemplo a seguir mostra como fazer isso utilizando o comando da AWS CLI para criar uma função chamada `rds-s3-export-role`.
**Example**
Para Linux, macOS ou Unix:
```
aws iam create-role \
--role-name rds-s3-export-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Para Windows:
```
aws iam create-role ^
--role-name rds-s3-export-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Anexe a política do IAM que você criou à função do IAM que você criou.
O comando da AWS CLI a seguir anexa a política criada anteriormente à função chamada `rds-s3-export-role.`. Substitua `your-policy-arn` pelo ARN da política que você anotou na etapa anterior.
```
aws iam attach-role-policy --policy-arn your-policy-arn --role-name rds-s3-export-role
```
1. Adicione o perfil do IAM à instância de banco de dados. Faça isso usando o Console de gerenciamento da AWS ou a AWS CLI, conforme descrito a seguir.
## Console
**Para adicionar um perfil do IAM a uma instância de banco de dados do PostgreSQL usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha o nome da instância de de banco de dados do PostgreSQL para exibir os detalhes.
1. Na guia **Connectivity & security (Conectividade e segurança)**, na seção **Manage IAM roles (Gerenciar perfis do IAM)**, escolha o perfil a ser adicionado em **Add IAM roles to this instance** (Adicionar perfis do IAM a essa instância).
1. Em **Feature (Recurso)**, escolha **s3Export**.
1. Escolha **Add role (adicionar função)**.
## AWS CLI
**Para adicionar um perfil do IAM para uma instância de banco de dados do PostgreSQL usando a CLI**
+ Use o comando a seguir para adicionar a função à instância de banco de dados do PostgreSQL chamada `my-db-instance`. Substitua*`your-role-arn`* pelo ARN da função que você anotou em uma etapa anterior. Use `s3Export` para o valor da opção `--feature-name`.
**Example**
Para Linux, macOS ou Unix:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Export \
--role-arn your-role-arn \
--region your-region
```
Para Windows:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Export ^
--role-arn your-role-arn ^
--region your-region
```
# Exportar dados de consulta usando a função aws\$1s3.query\$1export\$1to\$1s3
Exporte os dados do PostgreSQL para o Amazon S3 chamando a função [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3).
**Topics**
+ [
## Pré-requisitos
](#postgresql-s3-export-examples-prerequisites)
+ [
## Chamar aws\$1s3.query\$1export\$1to\$1s3
](#postgresql-s3-export-examples-basic)
+ [
## Exportar para um arquivo CSV que usa um delimitador personalizado
](#postgresql-s3-export-examples-custom-delimiter)
+ [
## Exportar para um arquivo binário com codificação
](#postgresql-s3-export-examples-encoded)
## Pré-requisitos
Antes de usar a função `aws_s3.query_export_to_s3`, verifique se você concluiu os seguintes pré-requisitos:
+ Instalar as extensões do PostgreSQL necessárias, conforme descrito em [Visão geral da exportação de dados para o Amazon S3](postgresql-s3-export.md#postgresql-s3-export-overview).
+ Determinar para onde exportar os dados para o Amazon S3, conforme descrito em [Especificar o caminho do arquivo do Amazon S3 para o qual exportar](postgresql-s3-export.md#postgresql-s3-export-file).
+ Verifique se a instância de banco de dados tem acesso ao Amazon S3 conforme descrito em [Configurar o acesso a um bucket do Amazon S3](postgresql-s3-export-access-bucket.md).
Os exemplos a seguir usam uma tabela de banco de dados chamada `sample_table`. Esses exemplos exportam os dados para um bucket chamado *amzn-s3-demo-bucket*. A tabela e os dados de exemplo são criados com as seguintes instruções SQL no psql.
```
psql=> CREATE TABLE sample_table (bid bigint PRIMARY KEY, name varchar(80));
psql=> INSERT INTO sample_table (bid,name) VALUES (1, 'Monday'), (2,'Tuesday'), (3, 'Wednesday');
```
## Chamar aws\$1s3.query\$1export\$1to\$1s3
Veja a seguir as formas básicas de chamar a função [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3).
Esses exemplos usam a variável `s3_uri_1` para identificar uma estrutura que contém as informações que identificam o arquivo do Amazon S3. Use a função [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) para criar a estrutura.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Embora os parâmetros variem para as duas chamadas de função `aws_s3.query_export_to_s3` a seguir, os resultados são os mesmos para esses exemplos. Todas as linhas da tabela `sample_table` são exportadas para um bucket chamado *amzn-s3-demo-bucket*.
```
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1');
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1', options :='format text');
```
Os parâmetros são descritos da seguinte forma:
+ `'SELECT * FROM sample_table'` – o primeiro parâmetro é uma string de texto necessária que contém uma consulta SQL. O mecanismo PostgreSQL executa essa consulta. Os resultados da consulta são copiados no bucket do S3 identificado em outros parâmetros.
+ `:'s3_uri_1'` – esse parâmetro é uma estrutura que identifica o arquivo do Amazon S3. Esse exemplo usa uma variável para identificar a estrutura criada anteriormente. Em vez disso, você pode criar a estrutura incluindo a chamada de função `aws_commons.create_s3_uri` em linha dentro da chamada de função `aws_s3.query_export_to_s3` da seguinte forma.
```
SELECT * from aws_s3.query_export_to_s3('select * from sample_table',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'sample-filepath', 'us-west-2')
);
```
+ `options :='format text'` – o parâmetro `options` é uma string de texto opcional que contém argumentos `COPY` do PostgreSQL. O processo de cópia usa os argumentos e o formato do comando [COPY PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
Se o arquivo especificado não existir no bucket do Amazon S3, ele será criado. Se o arquivo já existir, ele será substituído. A sintaxe para acessar os dados exportados no Amazon S3 é a seguinte.
```
s3-region://bucket-name[/path-prefix]/file-prefix
```
Exportações maiores são armazenadas em vários arquivos, cada um com um tamanho máximo de aproximadamente 6 GB. Os nomes de arquivos adicionais têm o mesmo prefixo de arquivo, mas com o acréscimo de `_partXX`. O `XX` representa 2, depois 3 e assim por diante. Por exemplo, suponha que você especifique o caminho onde armazena arquivos de dados como o seguinte.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
```
Se a exportação precisar criar três arquivos de dados, o bucket do Amazon S3 conterá os seguintes arquivos de dados.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part2
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part3
```
Para obter a referência completa para esta função e as formas adicionais de chamá-la, consulte [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). Para obter mais informações sobre como acessar arquivos no Amazon S3, consulte [Visualização de um objeto](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) no *Guia do usuário do Amazon Simple Storage Service*.
## Exportar para um arquivo CSV que usa um delimitador personalizado
O exemplo a seguir mostra como chamar a função [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) para exportar dados para um arquivo que usa um delimitador personalizado. O exemplo usa argumentos do comando [COPY do PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html) para especificar o formato de valor separado por vírgula (CSV) e um delimitador de dois pontos (:).
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format csv, delimiter $$:$$');
```
## Exportar para um arquivo binário com codificação
O exemplo a seguir mostra como chamar a função [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) para exportar dados para um arquivo binário que tenha a codificação Windows-1253.
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format binary, encoding WIN1253');
```
# Referência de funções
**Topics**
+ [
## aws\$1s3.query\$1export\$1to\$1s3
](#aws_s3.export_query_to_s3)
+ [
## aws\$1commons.create\$1s3\$1uri
](#aws_commons.create_s3_uri)
## aws\$1s3.query\$1export\$1to\$1s3
Exporta um resultado de consulta do PostgreSQL para um bucket do Amazon S3. A extensão `aws_s3` fornece a função `aws_s3.query_export_to_s3`.
Os dois parâmetros necessários são `query` e `s3_info`. Eles definem a consulta a ser exportada e identificam o bucket do Amazon S3 para o qual exportar. Um parâmetro opcional chamado `options` fornece a definição de vários parâmetros de exportação. Para obter exemplos de como usar a função `aws_s3.query_export_to_s3`, consulte [Exportar dados de consulta usando a função aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
**Sintaxe**
```
aws_s3.query_export_to_s3(
query text,
s3_info aws_commons._s3_uri_1,
options text,
kms_key text
)
```Parâmetros de entrada
*query*
Uma string de texto necessária que contém uma consulta SQL executada pelo mecanismo do PostgreSQL. Os resultados dessa consulta são copiados em um bucket do S3 identificado no parâmetro `s3_info`.
*s3\$1info*
Um tipo composto `aws_commons._s3_uri_1` contendo as seguintes informações sobre o objeto do S3:
+ `bucket` – o nome do bucket do Amazon S3 que deve conter o arquivo.
+ `file_path` – o nome e o caminho do arquivo do Amazon S3.
+ `region`: a região da AWS na qual o bucket se encontra. Para obter uma listagem de nomes de regiões da AWS e os valores associados, consulte [Regiões, zonas de disponibilidade e Local Zones](Concepts.RegionsAndAvailabilityZones.md).
Atualmente, esse valor deve ser a mesma região da AWS que a instância de Bancos de Dados de exportação . O padrão é a região da AWS para exportação da instância de Bancos de Dados .
Para criar uma estrutura `aws_commons._s3_uri_1` composta, consulte a função [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri).
*options*
Uma string de texto opcional que contém argumentos para o comando `COPY` do PostgreSQL. Esses argumentos especificam como os dados devem ser copiados quando exportados. Para obter mais detalhes, consulte [Documentação de COPY do PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
Uma string de texto opcional contendo a chave do KMS gerenciada pelo cliente do bucket do S3 para o qual exportar os dados.
### Parâmetros de entrada alternativos
Para ajudar nos testes, você pode usar um conjunto expandido de parâmetros em vez do parâmetro `s3_info`. Veja a seguir as variações adicionais de sintaxe da função `aws_s3.query_export_to_s3`.
Em vez de usar o parâmetro `s3_info` para identificar um arquivo do Amazon S3, use a combinação dos parâmetros `bucket`, `file_path` e `region`.
```
aws_s3.query_export_to_s3(
query text,
bucket text,
file_path text,
region text,
options text,
kms_key text
)
```
*query*
Uma string de texto necessária que contém uma consulta SQL executada pelo mecanismo do PostgreSQL. Os resultados dessa consulta são copiados em um bucket do S3 identificado no parâmetro `s3_info`.
*bucket*
Uma string de texto necessária que contém o nome do bucket do Amazon S3 que contém o arquivo.
*file\$1path*
Uma string de texto necessária contendo o nome do arquivo do Amazon S3, incluindo o caminho do arquivo.
*region*
Uma string de texto opcional que contém a região da AWS na qual o bucket se contra. Para obter uma listagem de nomes de regiões da AWS e os valores associados, consulte [Regiões, zonas de disponibilidade e Local Zones](Concepts.RegionsAndAvailabilityZones.md).
Atualmente, esse valor deve ser a mesma região da AWS que a instância de Bancos de Dados de exportação . O padrão é a região da AWS para exportação da instância de Bancos de Dados .
*options*
Uma string de texto opcional que contém argumentos para o comando `COPY` do PostgreSQL. Esses argumentos especificam como os dados devem ser copiados quando exportados. Para obter mais detalhes, consulte [Documentação de COPY do PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
Uma string de texto opcional contendo a chave do KMS gerenciada pelo cliente do bucket do S3 para o qual exportar os dados.
### Parâmetros de saída
```
aws_s3.query_export_to_s3(
OUT rows_uploaded bigint,
OUT files_uploaded bigint,
OUT bytes_uploaded bigint
)
```
*rows\$1uploaded*
O número de linhas da tabela que foram carregadas com êxito no Amazon S3 para a determinada consulta.
*files\$1uploaded*
O número de arquivos carregados no Amazon S3. Os arquivos são criados em tamanhos de aproximadamente 6 GB. Cada arquivo adicional criado tem `_partXX` acrescentado ao nome. O `XX` representa 2, depois 3 e assim por diante, conforme necessário.
*bytes\$1uploaded*
O número total de bytes carregados no Amazon S3.
### Exemplos
```
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2','format text');
```
## aws\$1commons.create\$1s3\$1uri
Cria uma estrutura `aws_commons._s3_uri_1` para comportar informações do arquivo do Amazon S3. Use os resultados da função `aws_commons.create_s3_uri` no parâmetro `s3_info` da função [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3). Para obter um exemplo de uso da função `aws_commons.create_s3_uri`, consulte [Especificar o caminho do arquivo do Amazon S3 para o qual exportar](postgresql-s3-export.md#postgresql-s3-export-file).
**Sintaxe**
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```Parâmetros de entrada
*Bucket de*
Uma string de texto necessária contendo o nome do bucket do Amazon S3 para o arquivo.
*file\$1path*
Uma string de texto necessária contendo o nome do arquivo do Amazon S3, incluindo o caminho do arquivo.
*region*
Uma string de texto necessária que contém a região da AWS na qual o arquivo se encontra. Para obter uma listagem de nomes de regiões da AWS e os valores associados, consulte [Regiões, zonas de disponibilidade e Local Zones](Concepts.RegionsAndAvailabilityZones.md).
# Solução de problemas de acesso ao Amazon S3
Se você encontrar problemas de conexão ao tentar exportar dados para o Amazon S3, primeiro confirme se as regras de acesso de saída para o grupo de segurança da VPC associado à sua instância de banco de dados permitem conectividade de rede. Especificamente, o grupo de segurança deve ter uma regra que permita que a instância de banco de dados envie tráfego TCP para a porta 443 e para todos os endereços IPv4 (0.0.0.0/0). Para obter mais informações, consulte [Fornecer acesso à instância de banco de dados na VPC criando um grupo de segurança](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
Veja também as seguintes recomendações:
+ [Solução de problemas de identidade e acesso do Amazon RDS](security_iam_troubleshoot.md)
+ [Solução de problemas do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) no *Guia do usuário do Amazon Simple Storage Service*
+ [Troubleshooting Amazon S3 and IAM (Solucionar problemas no Amazon S3 e no IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) no *Guia do usuário do IAM*
# Invocar uma função do AWS Lambda de uma instância de bancos de dados PostgreSQL do RDS
AWS LambdaO é um serviço computacional orientado a eventos que permite executar código sem o provisionamento ou gerenciamento de servidores. Está disponível para uso com muitos serviços da AWS, incluindo o RDS for PostgreSQL. Por exemplo, você pode usar funções Lambda para processar notificações de eventos de um banco de dados ou para carregar dados de arquivos sempre que um novo arquivo é carregado para o Simple Storage Service (Amazon S3). Para saber mais sobre o Lambda, consulte [O que é o AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) no *Guia do desenvolvedor do AWS Lambda.*
**nota**
A chamada de uma função AWS Lambda é aceita nas seguintes versões do RDS for PostgreSQL:
Todas as versões 18 do PostgreSQL
Todas as versões 17 do PostgreSQL
Todas as versões 16 do PostgreSQL
Todas as versões do PostgreSQL 15
PostgreSQL 14.1 e versões secundárias posteriores
PostgreSQL 13.2 e versões secundárias posteriores
PostgreSQL 12.6 e versões secundárias posteriores
Configurar o RDS for PostgreSQL para trabalhar com funções Lambda é um processo de várias etapas envolvendo o AWS Lambda, o IAM, sua VPC e sua instância de banco de dados do RDS for PostgreSQL. A seguir, você pode encontrar resumos das etapas necessárias.
Para obter mais informações sobre como criar uma função Lambda, consulte [Conceitos básicos do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) e [Tópicos essenciais do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-foundation.html) no *Guia do desenvolvedor do AWS Lambda*.
**Topics**
+ [
## Etapa 1: configurar o cluster de bancos de dados do a instância de banco de dados do RDS para PostgreSQL para conexões de saída para o AWS Lambda
](#PostgreSQL-Lambda-network)
+ [
## Etapa 2: configurar o IAM para a instância de banco de dados do RDS para PostgreSQL e o AWS Lambda
](#PostgreSQL-Lambda-access)
+ [
## Etapa 3: instalar a extensão `aws_lambda` para uma instância de banco de dados do RDS para PostgreSQL
](#PostgreSQL-Lambda-install-extension)
+ [
## Etapa 4: usar as funções Lambda auxiliares com a instância de banco de dados do RDS for PostgreSQL (opcional)
](#PostgreSQL-Lambda-specify-function)
+ [
## Etapa 5: invocar uma função Lambda da sua instância de banco de dados do RDS for PostgreSQL
](#PostgreSQL-Lambda-invoke)
+ [
## Etapa 6: Conceder a outros usuários permissão para invocar funções do Lambda
](#PostgreSQL-Lambda-grant-users-permissions)
+ [
# Exemplos: Invocar uma função do Lambda da instância de banco de dados do RDS for PostgreSQL
](PostgreSQL-Lambda-examples.md)
+ [
# Mensagens de erro da função Lambda
](PostgreSQL-Lambda-errors.md)
+ [
# Função do AWS Lambda e referência de parâmetros
](PostgreSQL-Lambda-functions.md)
## Etapa 1: configurar o cluster de bancos de dados do a instância de banco de dados do RDS para PostgreSQL para conexões de saída para o AWS Lambda
As funções do Lambda sempre são executadas dentro de uma Amazon VPC de propriedade do serviço AWS Lambda. O Lambda aplica regras de segurança e acesso à rede a essa VPC e mantém e monitora a VPC automaticamente. Sua instância de banco de dados do RDS para PostgreSQL envia tráfego de rede para a VPC do serviço Lambda. Como você configura isso depende se sua instância de banco de dados primária do é pública ou privada.
+ **Instância de banco de dados pública do RDS para PostgreSQL**: uma instância de banco de dados é pública se está localizada em uma sub-rede pública na VPC e se a propriedade “PubliclyAccessible” da instância é `true`. Para encontrar o valor dessa propriedade, você pode usar o comando da AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html). Ou, você pode usar o Console de gerenciamento da AWS para abrir a guia **Connectivity & security** (Conectividade e segurança) e verificar se **Publicly accessible** (Publicamente acessível) está definido como **Yes** (Sim). Para verificar se a instância está na sub-rede pública da VPC, use o Console de gerenciamento da AWS ou a AWS CLI.
Para configurar o acesso ao Lambda, use o Console de gerenciamento da AWS ou a AWS CLI para criar uma regra de saída no grupo de segurança da VPC. A regra de saída especifica que o TCP pode usar a porta 443 para enviar pacotes para qualquer endereço IPv4 (0.0.0.0/0).
+ **Instância de banco de dados privada do RDS para PostgreSQL**: nesse caso, a propriedade “PubliclyAccessible” da instância é `false` ou está em uma sub-rede privada. Para permitir que a instância funcione com o Lambda, use um gateway de conversão de endereços de rede (NAT). Para obter mais informações, consulte [Gateways de NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html). Ou configure sua VPC com um endpoint da VPC para o Lambda. Para obter mais informações, consulte [Endpoints da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) no *Guia do usuário da Amazon VPC*. O endpoint responde às chamadas feitas pela instância de banco de dados do RDS para PostgreSQL para suas funções do Lambda. O endpoint da VPC usa sua própria resolução DNS privada. O RDS for PostgreSQL não pode usar o endpoint da VPC do Lambda até que você altere o valor do `rds.custom_dns_resolution` de seu valor padrão 0 (não habilitado) para 1. Para fazer isso:
+ Crie um grupo de parâmetros de banco de dados personalizado.
+ Altere o valor do parâmetro `rds.custom_dns_resolution` de seu padrão `0` para `1`.
+ Modifique sua instância de banco de dados para aplicar seu grupo de parâmetros de banco de dados personalizado.
+ Reinicialize a instância de banco de dados para que a alteração do parâmetro tenha efeito.
Agora, sua VPC pode interagir com o VPC do AWS Lambda no nível da rede. Depois, configure as permissões usando o IAM.
## Etapa 2: configurar o IAM para a instância de banco de dados do RDS para PostgreSQL e o AWS Lambda
Invocar funções Lambda da sua instância de banco de dados do RDS for PostgreSQL requer certos privilégios. Para configurar os privilégios necessários, recomendamos que você crie uma política do IAM que permita chamar funções Lambda, atribuir essa política a uma função e, em seguida, aplicar a função ao à instância de banco de dados. Essa abordagem dá à instância de banco de dados privilégios para invocar a função Lambda especificada em seu nome. As etapas a seguir mostram como fazer isso usando a AWS CLI.
**Para configurar permissões do IAM para usar sua instância do Amazon RDS com o Lambda**
1. Use o comando [create-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-policy.html) da AWS CLI para criar uma política do IAM que permita que a sua instância de banco de dados do RDS para PostgreSQL invoque a função do Lambda especificada. (O ID da instrução (Sid) é uma descrição opcional para sua instrução de política e não tem efeito sobre o uso.) Esta política fornece à sua instância de banco de dados as permissões mínimas necessárias para invocar a função Lambda especificada.
```
aws iam create-policy --policy-name rds-lambda-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToExampleFunction",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:aws-region:444455556666:function:my-function"
}
]
}'
```
Você também pode usar a política `AWSLambdaRole` predefinida que permite invocar qualquer uma das suas funções Lambda. Para obter mais informações, consulte [Políticas do IAM baseadas em identidade para o Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html#access-policy-examples-aws-managed).
1. Use o comando da AWS CLI [create-role](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-role.html) para criar uma função do IAM que a política possa assumir em tempo de execução.
```
aws iam create-role --role-name rds-lambda-role --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
```
1. Anexe a política à função usando o comando da AWS CLI [attach-role-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-role-policy.html).
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::444455556666:policy/rds-lambda-policy \
--role-name rds-lambda-role --region aws-region
```
1. Aplique o perfil à sua instância de banco de dados do RDS para PostgreSQL usando o comando [add-role-to-db-instance](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/add-role-to-db-instance.html) AWS CLI. Esta última etapa permite que seus usuários de banco de dados de instâncias de banco de dados invoquem funções Lambda.
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-instance-name \
--feature-name Lambda \
--role-arn arn:aws:iam::444455556666:role/rds-lambda-role \
--region aws-region
```
Com a VPC e as configurações do IAM concluídas, agora você pode instalar a extensão `aws_lambda`. (Observe que você pode instalar a extensão a qualquer momento, mas até configurar o suporte à VPC e os privilégios do IAM corretos, a extensão `aws_lambda` não adiciona nada às capacidades da instância de banco de dados do RDS for PostgreSQL.)
## Etapa 3: instalar a extensão `aws_lambda` para uma instância de banco de dados do RDS para PostgreSQL
Para usar o AWS Lambda com a instância de banco de dados do RDS para PostgreSQL, adicione a extensão `aws_lambda` do PostgreSQL à instância de banco de dados do RDS para PostgreSQL. Esta extensão fornece a instância de banco de dados do RDS for PostgreSQL com a capacidade de chamar funções Lambda do PostgreSQL.
**Como instalar a extensão `aws_lambda` em uma instância de banco de dados do RDS para PostgreSQL**
Use a linha de comando `psql` do PostgreSQL ou a ferramenta pgAdmin para se conectar à sua instância de banco de dados do RDS for PostgreSQL.
1. Conecte-se à sua instância de banco de dados do RDS for PostgreSQL como usuário com privilégios `rds_superuser`. O usuário padrão `postgres` é mostrado no exemplo.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Instale a extensão `aws_lambda`. A extensão `aws_commons` também é necessária. Ela fornece funções auxiliares para `aws_lambda` e muitas outras extensões do Aurora para PostgreSQL. Se ainda não estiver na sua instância de banco de dados do RDS for PostgreSQL, ela é instalada com `aws_lambda` como mostrado a seguir.
```
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
A extensão `aws_lambda` está instalada em sua instância de banco de dados primária do . Agora você pode criar estruturas de conveniência para chamar suas funções Lambda.
## Etapa 4: usar as funções Lambda auxiliares com a instância de banco de dados do RDS for PostgreSQL (opcional)
Você pode usar as funções auxiliares na extensão `aws_commons` para preparar entidades que você pode invocar mais facilmente a partir do PostgreSQL. Para isso, você precisa ter as seguintes informações sobre suas funções Lambda:
+ **Nome da função** – O nome, nome do recurso da Amazon (ARN), versão ou apelido da função Lambda. A política do IAM criada em [Etapa 2: configurar o IAM para o cluster e o Lambda](#PostgreSQL-Lambda-access) requer o ARN, portanto, recomendamos que você use o ARN da sua função.
+ **Região da AWS** – (Opcional) A região da AWS onde a função Lambda está localizada se não estiver na mesma região que sua instância de banco de dados do RDS for PostgreSQL.
Para manter as informações do nome da função Lambda, você pode usar a função [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn). Esta função auxiliar cria uma estrutura composta `aws_commons._lambda_function_arn_1` com os detalhes necessários para a função de invocação. A seguir, você pode encontrar três abordagens alternativas para configurar essa estrutura composta.
```
SELECT aws_commons.create_lambda_function_arn(
'my-function',
'aws-region'
) AS aws_lambda_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'111122223333:function:my-function',
'aws-region'
) AS lambda_partial_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'arn:aws:lambda:aws-region:111122223333:function:my-function'
) AS lambda_arn_1 \gset
```
Qualquer um desses valores pode ser usado em chamadas para a função [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). Para obter exemplos, consulte [Etapa 5: invocar uma função Lambda da sua instância de banco de dados do RDS for PostgreSQL](#PostgreSQL-Lambda-invoke).
## Etapa 5: invocar uma função Lambda da sua instância de banco de dados do RDS for PostgreSQL
A função `aws_lambda.invoke` se comporta de forma síncrona ou assíncrona, dependendo do `invocation_type`. As duas alternativas para esse parâmetro são `RequestResponse` (o padrão) e `Event`, da seguinte forma:
+ **`RequestResponse`** – Este tipo de invocação é *síncrono*. É o comportamento padrão quando a chamada é feita sem especificar um tipo de invocação. A carga útil da resposta inclui os resultados da função `aws_lambda.invoke`. Use esse tipo de invocação de quando seu fluxo de trabalho exigir o recebimento de resultados da função Lambda antes de continuar.
+ **`Event`** – Este tipo de invocação é *assíncrono*. A resposta não inclui uma carga útil contendo resultados. Use esse tipo de invocação quando o fluxo de trabalho não precisar de um resultado da função Lambda para continuar o processamento.
Como um teste simples de sua configuração, você pode se conectar à sua instância de banco de dados usando `psql` e chamar uma função de exemplo a partir da linha de comando. Suponha que você tenha uma das funções básicas configuradas em seu serviço Lambda, como a função Python simples mostrada na captura de tela a seguir.
![\[Exemplo de função Lambda mostrada na AWS CLI pelo AWS Lambda\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/lambda_simple_function.png)
**Para invocar uma função de exemplo**
1. Conecte-se à sua instância de banco de dados usando `psql` ou pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Invoque a função usando seu ARN.
```
SELECT * from aws_lambda.invoke(aws_commons.create_lambda_function_arn('arn:aws:lambda:aws-region:444455556666:function:simple', 'us-west-1'), '{"body": "Hello from Postgres!"}'::json );
```
A resposta se parece com esta a seguir.
```
status_code | payload | executed_version | log_result
-------------+-------------------------------------------------------+------------------+------------
200 | {"statusCode": 200, "body": "\"Hello from Lambda!\""} | $LATEST |
(1 row)
```
Se sua tentativa de invocação não for bem-sucedida, consulte [Mensagens de erro da função Lambda](PostgreSQL-Lambda-errors.md).
## Etapa 6: Conceder a outros usuários permissão para invocar funções do Lambda
Neste ponto dos procedimentos, apenas você como `rds_superuser` pode invocar suas funções do Lambda. Para permitir que outros usuários invoquem quaisquer funções criadas por você, é necessário conceder permissão a eles.
**Como conceder a outros permissão para invocar funções do Lambda**
1. Conecte-se à sua instância de banco de dados usando `psql` ou pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Execute os seguintes comandos SQL:
```
postgres=> GRANT USAGE ON SCHEMA aws_lambda TO db_username;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA aws_lambda TO db_username;
```
# Exemplos: Invocar uma função do Lambda da instância de banco de dados do RDS for PostgreSQL
A seguir, você pode encontrar alguns exemplos de como chamar a função [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). A maioria dos exemplos usa a estrutura composta `aws_lambda_arn_1` que você cria em [Etapa 4: usar as funções Lambda auxiliares com a instância de banco de dados do RDS for PostgreSQL (opcional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) para simplificar a passagem dos detalhes da função. Para obter um exemplo de invocação assíncrona, consulte [Exemplo: invocação assíncrona (evento) de funções Lambda](#PostgreSQL-Lambda-Event). Todos os outros exemplos listados usam invocação síncrona.
Para saber mais sobre os tipos de invocação do Lambda, consulte [Invocação de funções Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html) no *Guia do desenvolvedor do AWS Lambda*. Para obter mais informações sobre o `aws_lambda_arn_1`, consulte [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn).
**Topics**
+ [
## Exemplo: invocação síncrona (RequestResponse) de funções Lambda
](#PostgreSQL-Lambda-RequestResponse)
+ [
## Exemplo: invocação assíncrona (evento) de funções Lambda
](#PostgreSQL-Lambda-Event)
+ [
## Exemplo: capturar o log de execução do Lambda em uma resposta de função
](#PostgreSQL-Lambda-log-response)
+ [
## Exemplo: incluir o contexto do cliente em uma função Lambda
](#PostgreSQL-Lambda-client-context)
+ [
## Exemplo: invocar uma versão específica de uma função Lambda
](#PostgreSQL-Lambda-function-version)
## Exemplo: invocação síncrona (RequestResponse) de funções Lambda
A seguir estão dois exemplos de uma invocação síncrona de função Lambda. Os resultados dessas chamadas de funções `aws_lambda.invoke` são os mesmos.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
```
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse');
```
Os parâmetros são descritos da seguinte forma:
+ `:'aws_lambda_arn_1'` – Este parâmetro identifica a estrutura composta criada em [Etapa 4: usar as funções Lambda auxiliares com a instância de banco de dados do RDS for PostgreSQL (opcional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function), com a função auxiliar `aws_commons.create_lambda_function_arn`. Você também pode criar essa estrutura em linha dentro da sua chamada `aws_lambda.invoke` da seguinte forma:
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function', 'aws-region'),
'{"body": "Hello from Postgres!"}'::json
);
```
+ `'{"body": "Hello from PostgreSQL!"}'::json` – A carga útil JSON para passar para a função Lambda.
+ `'RequestResponse'` – O Lambda tipo de invocação.
## Exemplo: invocação assíncrona (evento) de funções Lambda
Segue-se um exemplo de uma invocação de função Lambda assíncrona. O tipo de invocação `Event` agenda a invocação de função Lambda com a carga de entrada específica e retorna imediatamente. Use o tipo de invocação de `Event` em determinados fluxos de trabalho que não dependem dos resultados da função Lambda.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'Event');
```
## Exemplo: capturar o log de execução do Lambda em uma resposta de função
Você pode incluir os últimos 4 KB do log de execução na resposta da função usando o parâmetro `log_type` em sua chamada de função `aws_lambda.invoke`. Por padrão, esse parâmetro é definido como `None`, mas você pode especificar `Tail` para capturar os resultados do log de execução do Lambda na resposta, conforme mostrado a seguir.
```
SELECT *, select convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Defina o parâmetro [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) da função `log_type` para `Tail` incluir o log de execução na resposta. O valor padrão para o parâmetro `log_type` é `None`.
O `log_result` que é retornado é uma string codificada de `base64`. Você pode decodificar os conteúdos usando uma combinação das funções PostgreSQL `decode` e `convert_from`.
Para obter mais informações sobre o `log_type`, consulte [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Exemplo: incluir o contexto do cliente em uma função Lambda
A função `aws_lambda.invoke` tem um parâmetro `context` que você pode usar para passar informações separadas da carga útil, como mostrado a seguir.
```
SELECT *, convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Para incluir o contexto do cliente, use um objeto JSON para o parâmetro [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) da função`context`.
Para obter mais informações sobre os parâmetros do `context`, consulte a referência [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Exemplo: invocar uma versão específica de uma função Lambda
Você pode especificar uma determinada versão de uma função Lambda incluindo o parâmetro `qualifier` com a chamada `aws_lambda.invoke`. A seguir, você pode encontrar um exemplo que faz isso usando `'custom_version'` como um alias para a versão.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'None', NULL, 'custom_version');
```
Você também pode fornecer um qualificador de função Lambda com as informações de nome da função da forma a seguir.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function:custom_version', 'us-west-2'),
'{"body": "Hello from Postgres!"}'::json);
```
Para obter mais informações sobre `qualifier` e outros parâmetros, consulte a referência [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
# Mensagens de erro da função Lambda
Na lista a seguir, você pode encontrar informações sobre mensagens de erro, com possíveis causas e soluções.
+ **Problemas de configuração da VPC**
Problemas de configuração da VPC podem gerar as seguintes mensagens de erro ao tentar se conectar:
```
ERROR: invoke API failed
DETAIL: AWS Lambda client returned 'Unable to connect to endpoint'.
CONTEXT: SQL function "invoke" statement 1
```
Uma causa comum para esse erro é o grupo de segurança da VPC configurado incorretamente. É necessário ter uma regra de saída para TCP aberta na porta 443 para que o grupo de segurança de sua VPC possa se conectar à VPC do Lambda.
Se sua instância de banco de dados for privada, verifique a configuração DNS privada para sua VPC. Verifique se você definiu o parâmetro `rds.custom_dns_resolution` como 1 e configurou o AWSPrivateLink conforme descrito em [Etapa 1: configurar o cluster de bancos de dados do a instância de banco de dados do RDS para PostgreSQL para conexões de saída para o AWS Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-network). Para obter mais informações, consulte [Endpoints da VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns).
+ **Falta de permissões necessárias para invocar funções do Lambda**
Se você vir uma das seguintes mensagens de erro, isso significa que o usuário (função) que está invocando a função não tem as permissões adequadas.
```
ERROR: permission denied for schema aws_lambda
```
```
ERROR: permission denied for function invoke
```
Um usuário (função) deve receber concessões específicas para invocar funções do Lambda. Para obter mais informações, consulte [Etapa 6: Conceder a outros usuários permissão para invocar funções do Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-grant-users-permissions).
+ **Tratamento inadequado de erros em suas funções do Lambda**
Se uma função Lambda lança uma exceção durante o processamento da solicitação, `aws_lambda.invoke` terá um erro do PostgreSQL, como o seguinte.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
ERROR: lambda invocation failed
DETAIL: "arn:aws:lambda:us-west-2:555555555555:function:my-function" returned error "Unhandled", details: "".
```
Certifique-se de lidar com erros nas funções Lambda ou na aplicação PostgreSQL.
# Função do AWS Lambda e referência de parâmetros
Veja a seguir a referência para as funções e os parâmetros a serem usados para invocar o Lambda com o RDS para PostgreSQL.
**Topics**
+ [
## aws\$1lambda.invoke
](#aws_lambda.invoke)
+ [
## aws\$1commons.create\$1lambda\$1function\$1arn
](#aws_commons.create_lambda_function_arn)
+ [
## Parâmetros aws\$1lambda
](#aws_lambda.parameters)
## aws\$1lambda.invoke
Executa uma função do Lambda para uma instância de banco de dados do RDS for PostgreSQL.
Para obter mais detalhes sobre invocar funções Lambda, consulte também [Invocar](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) no *Guia do desenvolvedor do AWS Lambda.*
**Sintaxe**
------
#### [ JSON ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSON,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSON,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
------
#### [ JSONB ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSONB,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSONB,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT
)
```
------Parâmetros de entrada
**function\$1name**
O nome de identificação da função Lambda. O valor pode ser o nome da função, um ARN ou um ARN parcial. Para obter uma lista de formatos possíveis, consulte [Formatos de nome da função Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestParameters) no *Guia do desenvolvedor do AWS Lambda.*
*payload*
A entrada para a função Lambda. O formato pode ser JSON ou JSONB. Para obter mais informações, consulte [Tipos JSON](https://www.postgresql.org/docs/current/datatype-json.html) na documentação do PostgreSQL.
*região*
(Opcional) A Lambda Região da função. Por padrão, o RDS resolve a região da AWS a partir do ARN completo na `function_name` ou usa a região da instância de banco de dados RDS for PostgreSQL. Se este valor de região entrar em conflito com o fornecido no ARN de `function_name`, um erro será gerado.
*invocation\$1type*
O tipo de invocação da função do Lambda. O valor diferencia letras maiúsculas de minúsculas. Os valores possíveis incluem o seguinte:
+ `RequestResponse` – O padrão. Esse tipo de invocação para uma função Lambda é síncrona e retorna uma carga útil de resposta no resultado. Use o tipo de invocação de `RequestResponse` quando seu fluxo de trabalho depende de receber o resultado da função Lambda imediatamente.
+ `Event` – Esse tipo de invocação para uma função Lambda é assíncrono e retorna imediatamente sem uma carga devolvida. Use o tipo de invocação de`Event` quando não precisar de resultados da função Lambda antes de seu fluxo de trabalho prosseguir.
+ `DryRun` – Este tipo de invocação testa o acesso sem executar a função Lambda.
*log\$1type*
O tipo de log Lambda a ser retornado no parâmetro de saída de `log_result`. O valor diferencia letras maiúsculas de minúsculas. Os valores possíveis incluem o seguinte:
+ Cauda – O parâmetro de saída `log_result` devolvido incluirá os últimos 4 KB do log de execução.
+ Nenhuma – Nenhuma informação de log Lambda é devolvida.
*context*
Contexto do cliente no formato JSON ou JSONB. Os campos a serem usados incluem que `custom` e `env`.
*qualifier*
Um qualificador que identifica a versão de uma função Lambda a ser invocada. Se esse valor entrar em conflito com um fornecido no ARN do `function_name`, gera um erro.Parâmetros de saída
*status\$1code*
Um código de resposta de status HTTP. Para obter mais informações, consulte [Elementos de resposta de invocação do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseElements) no *Guia do desenvolvedor do AWS Lambda.*
*payload*
As informações devolvidas da função Lambda executada. O formato está em JSON ou JSONB.
*executed\$1version*
A versão da função Lambda executada.
*log\$1result*
As informações do log de execução devolvidas se o valor `log_type` é `Tail` quando a função Lambda for invocada. O resultado contém os últimos 4 KB do log de execução codificado em Base64.
## aws\$1commons.create\$1lambda\$1function\$1arn
Cria uma estrutura `aws_commons._lambda_function_arn_1` para manter as informações do nome da função Lambda. Você pode usar os resultados da função `aws_commons.create_lambda_function_arn` no parâmetro `function_name` da função [aws\$1lambda.invoke](#aws_lambda.invoke) aws\$1lambda.invoke.
**Sintaxe**
```
aws_commons.create_lambda_function_arn(
function_name TEXT,
region TEXT DEFAULT NULL
)
RETURNS aws_commons._lambda_function_arn_1
```Parâmetros de entrada
*function\$1name*
Uma string de texto necessária que contém o nome da função Lambda. O valor pode ser um nome de função, um ARN parcial ou um ARN completo.
*região*
Uma string de texto opcional que contém a região da AWS na qual a função Lambda está inserida. Para obter uma listagem de nomes de regiões da e os valores associados, consulte [Regiões, zonas de disponibilidade e Local Zones](Concepts.RegionsAndAvailabilityZones.md).
## Parâmetros aws\$1lambda
Na tabela, é possível encontrar parâmetros associados à função do `aws_lambda`.
| Parâmetro | Descrição |
| --- | --- |
| `aws_lambda.connect_timeout_ms` | É um parâmetro dinâmico e define o tempo máximo de espera durante a conexão com o AWS Lambda. O valor padrão é `1000`. Os valores permitidos para esse parâmetro são de 1 a 900000. |
| `aws_lambda.request_timeout_ms` | É um parâmetro dinâmico e define o tempo máximo de espera enquanto aguarda a resposta do AWS Lambda. O valor padrão é `3000`. Os valores permitidos para esse parâmetro são de 1 a 900000. |
| `aws_lambda.endpoint_override` | Especifica o endpoint que pode ser usado para se conectar ao AWS Lambda. Uma string vazia seleciona o endpoint padrão do AWS Lambda para a região. É necessário reiniciar o banco de dados para esse parâmetro ter efeito. |
# Tarefas comuns de DBA do Amazon RDS para PostgreSQL
Os administradores de banco de dados (DBAs) executam várias tarefas ao administrar uma instância de banco de dados Amazon RDS para PostgreSQL. Se você já é um DBA familiarizado com o PostgreSQL, esteja ciente sobre algumas das diferenças importantes entre a execução do PostgreSQL em seu hardware e do RDS para PostgreSQL. Por exemplo, por ser um serviço gerenciado, o Amazon RDS não permite acesso ao shell às suas instâncias de banco de dados. Isso significa que você não tem acesso direto a `pg_hba.conf` e a outros arquivos de configuração. Para o RDS para PostgreSQL, as alterações que normalmente são feitas no arquivo de configuração do PostgreSQL de uma instância on-premises são feitas em um grupo de parâmetros de banco de dados personalizado associado à instância de banco de dados do RDS para PostgreSQL. Para ter mais informações, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Você também não pode acessar arquivos de log da mesma forma que faz com uma instância do PostgreSQL on-premises. Para saber mais sobre registro em log, consulte [Arquivos de log do banco de dados RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
Como outro exemplo, não é possível ter acesso à conta `superuser` do PostgreSQL. No RDS para PostgreSQL, o perfil `rds_superuser` é o perfil mais privilegiado, e é concedido ao `postgres` ao configurar. Se você estiver familiarizado com o uso do PostgreSQL on-premises ou for completamente novo no RDS para PostgreSQL, recomendamos que você entenda o perfil `rds_superuser` e como trabalhar com perfis, usuários, grupos e permissões. Para ter mais informações, consulte[Noções básicas de perfis e permissões do PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
Veja a seguir algumas tarefas comuns do DBA para o RDS para PostgreSQL.
**Topics**
+ [
# Agrupamentos permitidos no RDS para PostgreSQL.
](PostgreSQL-Collations.md)
+ [
# Noções básicas de perfis e permissões do PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [
# Tratamento de conexões inativas no PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [
# Trabalhar com o autovacuum do PostgreSQL no Amazon RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [
# Gerenciar contagens altas de objeto no Amazon RDS para PostgreSQL
](PostgreSQL.HighObjectCount.md)
+ [
# Gerenciar a contenção de TOAST OID no Amazon RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [
## Trabalhar com os mecanismos de registro em log compatíveis com o RDS para PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [
# Gerenciar arquivos temporários com o PostgreSQL
](PostgreSQL.ManagingTempFiles.md)
+ [
## Uso de pgBadger para análise de logs com o PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [
## Usar o PGSnapper para monitorar o PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [
# Gerenciar conversões personalizadas no RDS para PostgreSQL
](PostgreSQL.CustomCasts.md)
+ [
# Práticas recomendadas para consultas paralelas no RDS para PostgreSQL
](PostgreSQL.ParallelQueries.md)
+ [
# Trabalhar com parâmetros na instância de banco de dados do RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Agrupamentos permitidos no RDS para PostgreSQL.
Agrupamentos são conjuntos de regras que determinam como as strings de caracteres armazenadas no banco de dados são classificadas e comparadas. Eles desempenham um papel fundamental no sistema de computador e são incluídos como parte do sistema operacional. Os agrupamentos mudam com o tempo quando novos caracteres são adicionados aos idiomas ou quando ocorrem alterações nas regras de ordenação.
As bibliotecas de agrupamentos definem regras e algoritmos específicos para um agrupamento. As bibliotecas de agrupamentos mais populares usadas no PostgreSQL são GNU C (glibc) e Componentes Internacionais para Unicode (ICU). Por padrão, o RDS para PostgreSQL usa o agrupamento glibc que inclui ordens de classificação de caracteres Unicode para sequências de caracteres de vários bytes.
Quando você cria uma instância de banco de dados no RDS para PostgreSQL, ele verifica o agrupamento disponível no sistema operacional. Os parâmetros do PostgreSQL `LC_COLLATE` e `LC_CTYPE` do comando `CREATE DATABASE` são usados para especificar um agrupamento, que representa o agrupamento padrão nesse banco de dados. Como alternativa, você também pode usar o parâmetro `LOCALE` em `CREATE DATABASE` para definir esses parâmetros. Isso determina o agrupamento padrão para strings de caracteres no banco de dados e as regras para classificar caracteres como letras, números ou símbolos. Você também pode escolher um agrupamento para usar em uma coluna, um índice ou uma consulta.
O RDS para PostgreSQL depende da biblioteca glibc no sistema operacional para oferecer suporte a agrupamentos. A instância do RDS para PostgreSQL é atualizada periodicamente com as versões mais recentes do sistema operacional. Essas atualizações às vezes incluem uma versão mais recente da biblioteca glibc. Em situações raras, as versões mais recentes da glibc alteram a ordem de classificação ou o agrupamento de alguns caracteres, o que pode fazer com que os dados sejam classificados de forma diferente ou produzam entradas de índice inválidas. Se você descobrir problemas na ordem de classificação para agrupamento durante uma atualização, poderá ser necessário recompilar os índices.
Para reduzir os possíveis impactos das atualizações da glibc, o RDS para PostgreSQL agora inclui uma biblioteca de agrupamentos padrão independente. Essa biblioteca de agrupamentos está disponível no RDS para PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23 e versões secundárias mais recentes. É compatível com glibc 2.26-59.amzn2 e oferece estabilidade da ordem de classificação para evitar resultados de consulta incorretos.
# Noções básicas de perfis e permissões do PostgreSQL
Ao criar uma instância de banco de dados do RDS para PostgreSQL usando o Console de gerenciamento da AWS, uma conta de administrador é criada ao mesmo tempo. Por padrão, o nome é `postgres`, conforme mostrado na captura de tela a seguir:
![\[A identidade de login padrão para credenciais na página Create database (Criar banco de dados) é postgres.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
É possível escolher outro nome em vez de aceitar esse padrão (`postgres`). Se você fizer isso, o nome escolhido deverá começar com uma letra e ter 1 a 16 caracteres alfanuméricos. Para simplificar, nós nos referimos a essa conta de usuário principal pelo seu valor padrão (`postgres`) ao longo deste guia.
Ao usar `create-db-instance` na AWS CLI em vez de usar o Console de gerenciamento da AWS, você cria o nome ao passá-lo com o parâmetro `master-username` no comando. Para obter mais informações, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md).
Se você usar o Console de gerenciamento da AWS, a AWS CLI ou a API do Amazon RDS e se usar o nome `postgres` padrão ou escolher um nome diferente, essa primeira conta de usuário do banco de dados será membro do grupo `rds_superuser` e terá privilégios de `rds_superuser`.
**Topics**
+ [
# Noções básicas sobre o perfil rds\$1superuser
](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [
# Controlar o acesso de usuários ao banco de dados PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [
# Delegar e controlar o gerenciamento de senhas de usuários
](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [
# Usar criptografia de senha SCRAM para PostgreSQL
](PostgreSQL_Password_Encryption_configuration.md)
# Noções básicas sobre o perfil rds\$1superuser
No PostgreSQL, um *perfil* pode definir um usuário, um grupo ou um conjunto de permissões específicas concedidas a um grupo ou usuário a vários objetos no banco de dados. Os comandos do PostgreSQL para `CREATE USER` e `CREATE GROUP` foram substituídos pelo comando mais geral `CREATE ROLE` com propriedades específicas para distinguir usuários de banco de dados. Um usuário de banco de dados pode ser considerado um perfil com o privilégio LOGIN.
**nota**
Os comandos `CREATE USER` e `CREATE GROUP` ainda podem ser usados. Para obter mais informações, consulte [Database Roles](https://www.postgresql.org/docs/current/user-manag.html) (Perfis de banco de dados) na documentação do PostgreSQL.
O usuário `postgres` é o usuário de banco de dados mais privilegiado na instância de banco de dados do RDS para PostgreSQL. Ele tem as características definidas pela seguinte instrução `CREATE ROLE`.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
As propriedades `NOSUPERUSER`, `NOREPLICATION`, `INHERIT` e `VALID UNTIL 'infinity'` são as opções padrão da instrução CREATE ROLE, a menos que especificado de outra forma.
Por padrão, `postgres` tem privilégios concedidos à função `rds_superuser` e permissões para criar funções e bancos de dados. O perfil `rds_superuser` permite que o usuário `postgres` faça o seguinte:
+ Adicione as extensões que estão disponíveis para uso com o Amazon RDS. Para obter mais informações, consulte [Trabalhar com recursos do PostgreSQL compatíveis com o Amazon RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Crie funções para usuários e conceda privilégios aos usuários. Para obter mais informações, consulte [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) e [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) na documentação do PostgreSQL.
+ Crie bancos de dados. Para obter mais informações, consulte [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) na documentação do PostgreSQL.
+ Conceda privilégios de `rds_superuser` a outras funções de usuário que não têm esses privilégios e revogue esses privilégios conforme necessário. Recomendamos que você conceda esse perfil somente aos usuários que executam tarefas de superusuário. Em outras palavras, você pode conceder esse perfil a administradores de banco de dados (DBAs) ou administradores de sistema.
+ Conceda (e revogue) o perfil `rds_replication` a usuários de banco de dados que não têm o perfil `rds_superuser`.
+ Conceda (e revogue) o perfil `rds_password` a usuários de banco de dados que não têm o perfil `rds_superuser`.
+ Obtenha informações de status sobre todas as conexões de banco de dados usando a visualização `pg_stat_activity`. Quando necessário, `rds_superuser` pode interromper qualquer conexão usando `pg_terminate_backend` ou `pg_cancel_backend`.
Na instrução `CREATE ROLE postgres...`, é possível ver que o perfil do usuário `postgres` não autoriza especificamente as permissões de `superuser` do PostgreSQL. O RDS para PostgreSQL é um serviço gerenciado, portanto, você não pode acessar o sistema operacional host nem se conectar usando a conta `superuser` do PostgreSQL. Muitas das tarefas que exigem o acesso de `superuser` em um PostgreSQL autônomo são gerenciadas automaticamente pelo Amazon RDS.
Para obter mais informações sobre como conceder privilégios, consulte [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) na documentação do PostgreSQL.
O perfil `rds_superuser` é um dos vários perfis *predefinidos* em um Instância de banco de dados do RDS para PostgreSQL.
**nota**
No PostgreSQL 13 e em versões anteriores, os perfis *predefinidos* são conhecidos como perfis *padrão*.
Na lista a seguir, você encontra alguns dos outros perfis predefinidos que são criados automaticamente para um novo Instância de banco de dados do RDS para PostgreSQL. Os perfis predefinidos e seus privilégios não podem ser alterados. Não é possível descartar, renomear ou modificar os privilégios desses perfis predefinidos. Qualquer tentativa de fazer isso gerará um erro.
+ **rds\$1password**: um perfil que pode alterar senhas e configurar restrições de senha para usuários de bancos de dados. O perfil `rds_superuser` recebe esse perfil por padrão e pode concedê-lo aos usuários do banco de dados. Para obter mais informações, consulte [Controlar o acesso de usuários ao banco de dados PostgreSQLControlar o acesso de usuários ao PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ Para versões do RDS para PostgreSQL anteriores à 14, o perfil `rds_password` pode alterar senhas e configurar restrições de senha para usuários de bancos de dados e usuários com o perfil `rds_superuser`. Para versões do RDS para PostgreSQL 14 e posteriores, o perfil `rds_password` pode alterar senhas e configurar restrições de senha somente para usuários de banco de dados. Somente usuários com o perfil `rds_superuser` podem realizar essas ações em outros usuários com o perfil `rds_superuser`.
+ **rdsadmin**: um perfil criado para lidar com muitas das tarefas de gerenciamento que o administrador com privilégios de `superuser` executaria em um banco de dados PostgreSQL autônomo. Esse perfil é usado internamente pelo RDS para PostgreSQL para várias tarefas de gerenciamento.
+ **rdstopmgr**: um perfil usado internamente pelo Amazon RDS para comportar implantações multi-AZ.
+ **rds\$1reserved**: função usada internamente pelo Amazon RDS para reservar conexões de banco de dados.
# Visualizar perfis e os respectivos privilégios
Você pode visualizar perfis predefinidos e os respectivos privilégios na instância de banco de dados do RDS para PostgreSQL usando comandos diferentes, dependendo da versão do PostgreSQL. Para ver todos os perfis predefinidos, você pode se conectar à sua instância de banco de dados do RDS para PostgreSQL e executar os comandos a seguir usando o `psql`.
**Para o `psql` 15 e versões anteriores**
Conecte-se à instância de banco de dados do RDS para PostgreSQL e use o comando `\du` no psql:
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Para o `psql` 16 e versões posteriores**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Para verificar a associação sem dependência de versão, você pode usar a seguinte consulta SQL:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
Na saída, é possível ver que `rds_superuser` não é um perfil de usuário de banco de dados (não pode fazer login), mas tem os privilégios de muitos outros perfis. Também é possível ver que esse usuário do banco de dados `postgres` é membro do perfil `rds_superuser`. Como mencionado anteriormente, `postgres` é o valor padrão na página **Create database** (Criar banco de dados) do console do Amazon RDS. Se você escolheu outro nome, esse nome será mostrado na lista de perfis.
# Controlar o acesso de usuários ao banco de dados PostgreSQL
Os novos bancos de dados no PostgreSQL são sempre criados com um conjunto padrão de privilégios no esquema `public` do banco de dados que permite que todos os usuários e perfis do banco de dados criem objetos. Esses privilégios permitem que os usuários do banco de dados se conectem ao banco de dados, por exemplo, e criem tabelas temporárias durante a conexão.
Para controlar melhor o acesso dos usuários às instâncias de bancos de dados que você cria na instância de banco de dados do RDS para PostgreSQL, recomendamos que você revogue esses privilégios de `public` padrão. Depois disso, conceda privilégios específicos aos usuários do banco de dados de forma mais granular, conforme mostrado no procedimento a seguir.
**Como configurar perfis e privilégios para uma nova instância de banco de dados**
Suponha que você esteja configurando um banco de dados em uma instância de banco de dados do RDS para PostgreSQL recém-criada para uso por vários pesquisadores que precisam de acesso de leitura-gravação ao banco de dados.
1. Use o `psql` (ou o pgAdmin) para se conectar à na instância de banco de dados do RDS para PostgreSQL:
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Insira sua senha quando for solicitado. O cliente `psql` conecta-se e exibe o banco de dados de conexão administrativa padrão, `postgres=>`, como o prompt.
1. Para evitar que os usuários do banco de dados criem objetos no esquema `public`, faça o seguinte:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Em seguida, crie uma nova instância de banco de dados:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Revogue todos os privilégios do esquema `PUBLIC` nesse novo banco de dados.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Crie um perfil para os usuários do banco de dados.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Permita que os usuários do banco de dados que têm esse perfil conectem-se ao banco de dados.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Conceda a todos os usuários com o perfil `lab_tech` todos os privilégios nesse banco de dados.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Crie os usuários do banco de dados, da seguinte forma:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Conceda a esses dois usuários os privilégios associados ao perfil lab\$1tech:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
Neste ponto, o `lab_user1` e o `lab_user2` podem conectar-se ao banco de dados `lab_db`. Este exemplo não segue as práticas recomendadas para uso corporativo, o que pode incluir a criação de várias instâncias de banco de dados, esquemas diferentes e concessão de permissões limitadas. Para obter informações mais completas e cenários adicionais, consulte [Managing PostgreSQL Users and Roles](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/) (Gerenciar usuários e perfis do PostgreSQL).
Para obter mais informações sobre privilégios nos bancos de dados PostgreSQL, consulte o comando [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) na documentação do PostgreSQL.
# Delegar e controlar o gerenciamento de senhas de usuários
Como DBA, talvez você queira delegar o gerenciamento de senhas de usuários. Ou talvez você queira impedir que os usuários do banco de dados alterem senhas ou reconfigurem restrições de senha, como o tempo de vida da senha. Para garantir que somente os usuários do banco de dados escolhidos possam alterar as configurações de senha, é possível ativar o recurso de gerenciamento restrito de senhas. Quando você ativa esse recurso, somente os usuários do banco de dados que receberam o perfil `rds_password` podem gerenciar senhas.
**nota**
Para usar o gerenciamento restrito de senhas, a instância de banco de dados do RDS para PostgreSQL deve estar executando o Amazon Aurora PostgreSQL 10.6 ou superior.
Por padrão, esse recurso está `off`, conforme mostrado a seguir:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Para ativar esse recurso, use um grupo de parâmetros personalizado e altere a configuração de `rds.restrict_password_commands` para 1. Reinicialize a instância de banco de dados do RDS para PostgreSQL para que a configuração entre em vigor.
Com esse recurso ativo, os privilégios de `rds_password` são necessários para os seguintes comandos SQL:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
A renomeação de um perfil (`ALTER ROLE myrole RENAME TO newname`) também será restrita se a senha usar o algoritmo de hash MD5.
Com esse recurso ativo, qualquer tentativa de executar um desses comandos SQL sem as permissões do perfil `rds_password` gerará o seguinte erro:
```
ERROR: must be a member of rds_password to alter passwords
```
Recomendamos conceder a `rds_password` a apenas alguns perfis usados exclusivamente para o gerenciamento de senhas. Se você conceder privilégios de `rds_password` a usuários de banco de dados que não têm privilégios de `rds_superuser`, também precisará conceder o atributo `CREATEROLE` a eles.
Verifique os requisitos de senha, como expiração e complexidade necessária, no lado do cliente. Se você usar seu próprio utilitário do lado do cliente para alterações relacionadas a senhas, o utilitário precisará ser membro de `rds_password` e ter privilégios de `CREATE ROLE`.
# Usar criptografia de senha SCRAM para PostgreSQL
O *Salted Challenge Response Authentication Mechanism (SCRAM)* é uma alternativa ao algoritmo de resumo de mensagens padrão (MD5) do PostgreSQL para senhas de criptografia. O mecanismo de autenticação SCRAM é considerado mais seguro que o MD5. Para saber mais sobre essas duas abordagens diferentes para proteger senhas, consulte [Autorização com senha](https://www.postgresql.org/docs/14/auth-password.html) na documentação do PostgreSQL.
Recomendamos que você use o SCRAM em vez de o MD5 como o esquema de criptografia de senha para seu Instância de banco de dados do RDS para PostgreSQL. É um mecanismo criptográfico de resposta a desafios que usa o algoritmo scram-sha-256 para autenticação e criptografia de senha.
Convém atualizar as bibliotecas das aplicações cliente para oferecer compatibilidade com o SCRAM. Por exemplo, versões do JDBC anteriores à 42.2.0 não são compatíveis com o SCRAM. Para obter mais informações, consulte [Driver JDBC do PostgreSQL](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) na documentação do driver JDBC do PostgreSQL. Para obter uma lista de outros drivers do PostgreSQL e compatibilidade com o SCRAM, consulte [Lista de drivers](https://wiki.postgresql.org/wiki/List_of_drivers) na documentação do PostgreSQL.
A versão 13.1 do RDS para PostgreSQL e versões posteriores são compatíveis com scram-sha-256. Essas versões também permitem configurar sua instância de banco de dados para exigir o SCRAM, conforme abordado nos procedimentos a seguir.
## Configurar a instância de banco de dados do RDS para PostgreSQL para exigir o SCRAM
você pode exigir que a instância de banco de dados do RDS para PostgreSQL aceite apenas senhas que usem o algoritmo scram-sha-256.
**Importante**
Para proxies RDS existentes com bancos de dados PostgreSQL, se você modificar a autenticação do banco de dados para usar somente `SCRAM`, o proxy ficará indisponível por até 60 segundos. Para evitar o problema, faça o seguinte:
O banco de dados deve permitir tanto a autenticação `SCRAM` quanto a `MD5`.
Para usar somente a autenticação `SCRAM`, crie um proxy, migre o tráfego da aplicação para o novo proxy e exclua o proxy anteriormente associado ao banco de dados.
Antes de fazer alterações em seu sistema, entenda o processo completo da seguinte forma:
+ Obtenha informações sobre todos os perfis e criptografia de senha para todos os usuários do banco de dados.
+ Confira novamente as configurações dos parâmetros da instância de banco de dados do RDS para PostgreSQL para verificar os parâmetros que controlam a criptografia de senha.
+ Se a instância de banco de dados do RDS para PostgreSQL usar um grupo de parâmetros padrão, será necessário criar um grupo de parâmetros de banco de dados personalizado e aplicá-lo à instância de banco de dados do RDS para PostgreSQL para poder modificar parâmetros quando necessário. Se sua instância de banco de dados do RDS para PostgreSQL usa um grupo de parâmetros personalizado, você poderá modificar os parâmetros necessários posteriormente no processo, conforme necessário.
+ Altere o parâmetro `password_encryption` para `scram-sha-256`.
+ Avise a todos os usuários do banco de dados que eles precisam atualizar as senhas. Faça o mesmo para a conta `postgres`. As novas senhas são criptografadas e armazenadas usando o algoritmo scram-sha-256.
+ Verifique se todas as senhas são criptografadas usando o tipo de criptografia.
+ Se todas as senhas utilizarem scram-sha-256, você poderá alterar o parâmetro de `rds.accepted_password_auth_method` para `md5+scram`.
**Atenção**
Depois de alterar `rds.accepted_password_auth_method` para scram-sha-256, os usuários (perfis) com senhas criptografadas com `md5` não conseguirão se conectar.
### Preparar-se para exigir o SCRAM para sua instância de banco de dados do RDS para PostgreSQL
Antes de fazer qualquer alteração em sua instância de banco de dados do RDS para PostgreSQL, confira todas as contas de usuário do banco de dados existentes. Além disso, verifique o tipo de criptografia usada para senhas. Você pode realizar essas tarefas usando a extensão `rds_tools`. Consulte quais versões do PostgreSQL são compatíveis com `rds_tools` em [Extension versions for Amazon RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
**Como obter uma lista de usuários (perfis) de banco de dados e métodos de criptografia de senha**
1. Use o `psql` para conectar-se à instância de banco de dados do RDS para PostgreSQL conforme mostrado a seguir.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Instale a extensão `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Obtenha uma lista de perfis e criptografias.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Você verá uma saída semelhante à seguinte.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Criar um grupo de parâmetros de banco de dados personalizado
**nota**
Se sua instância de banco de dados do RDS para PostgreSQL já usa um grupo de parâmetros personalizado, não é necessário criar outro.
Para obter uma visão geral dos grupos de parâmetros do Amazon RDS, consulte [Trabalhar com parâmetros na instância de banco de dados do RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
O tipo de criptografia de senha usada para senhas é definido em um parâmetro, `password_encryption`. A criptografia permitida pela instância de banco de dados do RDS para PostgreSQL é definida em outro parâmetro, `rds.accepted_password_auth_method`. Alterar qualquer um desses valores padrão exige que você crie um grupo de parâmetros de banco de dados personalizado e aplique-o à sua instância.
Você também pode usar o Console de gerenciamento da AWS ou a API do RDS para criar um grupo de parâmetros de banco de dados personalizado. Consulte mais informações em
Associe o grupo de parâmetros personalizado à sua instância de banco de dados.
**Como criar um grupo de parâmetros de banco de dados personalizado**
1. Use o comando `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` da CLI para criar o grupo de parâmetros de banco de dados personalizado. Este exemplo usa `postgres13` como a origem desse grupo de parâmetros personalizado.
Para Linux, macOS ou Unix:
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Para Windows:
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Use o comando `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` da CLI para aplicar esse grupo de parâmetros personalizado ao seu cluster de banco de dados do RDS para PostgreSQL.
Para Linux, macOS ou Unix:
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Para Windows:
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Para sincronizar novamente sua instância de banco de dados do RDS para PostgreSQL com seu grupo de parâmetros de cluster de banco de dados personalizado, você precisa reiniciar a instância primária e todas as outras instâncias do cluster. Programe para que isso ocorra durante sua janela de manutenção regular a fim de minimizar o impacto para os usuários.
### Configurar a criptografia de senha para usar o SCRAM
O mecanismo de criptografia de senha usado por uma instância de banco de dados do RDS para PostgreSQL é definido no grupo de parâmetros de banco de dados no parâmetro `password_encryption`. Os valores permitidos não estão definidos, `md5` ou `scram-sha-256`. O valor padrão depende da versão do RDS para PostgreSQL da seguinte forma:
+ RDS para PostgreSQL 14 e superior: o padrão é `scram-sha-256`
+ RDS para PostgreSQL 13: o padrão é `md5`
Com um grupo de parâmetros de banco de dados personalizado anexado à instância de banco de dados do RDS para PostgreSQL, é possível modificar valores do parâmetro de criptografia de senha.
![\[A seguir, o console do RDS mostra os valores padrão para os parâmetros password_encryption do RDS para PostgreSQL.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**Como alterar a configuração de criptografia de senha para scram-sha-256**
+ Altere o valor da criptografia de senha para scram-sha-256, conforme mostrado a seguir. A alteração pode ser aplicada imediatamente porque o parâmetro é dinâmico, portanto, não é necessário reiniciar para que a alteração seja implementada.
Para Linux, macOS ou Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Para Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Migrar senhas para funções de usuário para o SCRAM
Você pode migrar senhas de perfis de usuário para o SCRAM conforme descrito a seguir.
**Como migrar senhas de usuário (função) do banco de dados do MD5 para o SCRAM**
1. Faça login como usuário administrador (nome de usuário padrão, `postgres`) conforme mostrado a seguir.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Confira a configuração do parâmetro `password_encryption` em sua instância de banco de dados do RDS para PostgreSQL usando o comando a seguir.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Altere o valor desse parâmetro para scram-sha-256. Para obter mais informações, consulte [Configurar a criptografia de senha para usar o SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Confira o valor novamente para garantir que agora ele esteja definido como `scram-sha-256` da seguinte forma.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Avise a todos os usuários do banco de dados para alterar senhas. Altere também sua própria senha para a conta `postgres` (o usuário do banco de dados com privilégios de `rds_superuser`).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Repita o processo para todos os bancos de dados no Instância de banco de dados do RDS para PostgreSQL.
### Alterar o parâmetro para exigir o SCRAM
Esta é a etapa final do processo. Depois de fazer a alteração no procedimento a seguir, as contas de usuário (perfis) que ainda usam a criptografia `md5` para senhas não poderão fazer login no Instância de banco de dados do RDS para PostgreSQL.
O `rds.accepted_password_auth_method` especifica o método de criptografia que a instância de banco de dados do RDS para PostgreSQL aceita para uma senha de usuário durante o processo de login. O valor padrão é `md5+scram`, o que significa que qualquer método é aceito. Na imagem a seguir, você pode encontrar a configuração padrão para esse parâmetro.
![\[O console do RDS mostrando os valores padrão e permitidos para os parâmetros rds.accepted_password_auth_method.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
Os valores permitidos para esse parâmetro são `md5+scram` ou `scram`. Alterar esse valor de parâmetro para `scram` torna isso um requisito.
**Como alterar o valor do parâmetro para exigir autenticação SCRAM para senhas**
1. Verifique se todas as senhas de usuários para todos os bancos de dados na instância de banco de dados do RDS para PostgreSQL usam `scram-sha-256` para criptografia de senha. Para fazer isso, consulte `rds_tools` para obter o perfil (usuário) e o tipo de criptografia, da seguinte forma.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Repita a consulta para todas as instâncias de banco de dados em seu Instância de banco de dados do RDS para PostgreSQL.
Se todas as senhas usam scram-sha-256, você pode prosseguir.
1. Altere o valor da autenticação de senha aceita para scram-sha-256 da seguinte forma.
Para Linux, macOS ou Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Para Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Tratamento de conexões inativas no PostgreSQL
Conexões inativas ocorrem quando uma sessão de banco de dados permanece ativa no servidor mesmo que a aplicação cliente tenha sido abandonada ou encerrada de forma anormal. Essa situação geralmente ocorre quando os processos do cliente falham ou são encerrados inesperadamente sem fechar adequadamente as respectivas conexões de banco de dados ou cancelar solicitações em andamento.
O PostgreSQL identifica e limpa com eficiência as conexões inativas quando os processos do servidor estão ociosos ou tentam enviar dados aos clientes. No entanto, a detecção é um desafio para sessões que estão ociosas, aguardando a entrada do cliente ou executando consultas ativamente. Para lidar com esses cenários, o PostgreSQL oferece os parâmetros `tcp_keepalives_*`, `tcp_user_timeout` e `client_connection_check_interval`.
**Topics**
+ [
## Conceitos básicos sobre keepalive de TCP
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [
## Principais parâmetros de keepalive de TCP no RDS para PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [
## Casos de uso para configurações de keepalive de TCP
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [
## Práticas recomendadas
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Conceitos básicos sobre keepalive de TCP
O keepalive de TCP é um mecanismo em nível de protocolo que ajuda a manter e verificar a integridade da conexão. Cada conexão TCP mantém configurações em nível de kernel que controlam o comportamento de keepalive. Quando o temporizador de keepalive expira, o sistema realiza o seguinte:
+ Envia um pacote de sondagem sem dados e com o sinalizador ACK definido.
+ Espera uma resposta do endpoint remoto de acordo com as especificações de TCP/IP.
+ Gerencia o estado da conexão com base na resposta ou na falta dela.
## Principais parâmetros de keepalive de TCP no RDS para PostgreSQL
| Parameter | Descrição | Valores padrão |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Specifies number of seconds of inactivity before sending keepalive message. | 300 |
| tcp\$1keepalives\$1interval | Specifies number of seconds between retransmissions of unacknowledged keepalive messages. | 30 |
| tcp\$1keepalives\$1count | Maximum lost keepalive messages before declaring connection dead | 2 |
| tcp\$1user\$1timeout | Specifies how long (in Milliseconds) unacknowledged data can remain before forcibly closing the connection. | 0 |
| client\$1connection\$1check\$1interval | Sets the interval (in Milliseconds) for checking client connection status during long-running queries. This ensures quicker detection of closed connections. | 0 |
## Casos de uso para configurações de keepalive de TCP
### Manter as sessões ociosas ativas
Para evitar que conexões ociosas sejam encerradas por firewalls ou roteadores devido a inatividade:
+ Configure `tcp_keepalives_idle` para enviar pacotes de keepalive em intervalos regulares.
### Detectar conexões inativas
Para detectar conexões inativas imediatamente:
+ Ajuste `tcp_keepalives_idle`, `tcp_keepalives_interval` e `tcp_keepalives_count`. Por exemplo, com os padrões do Aurora PostgreSQL, a detecção de uma conexão inativa leva cerca de 1 minuto (2 sondagens × 30 segundos). Reduzir esses valores pode acelerar a detecção.
+ Use `tcp_user_timeout` para especificar o tempo máximo de espera para uma confirmação.
As configurações de keepalive de TCP ajudam o kernel a detectar conexões inativas, mas talvez o PostgreSQL não aja enquanto o soquete não for usado. Se uma sessão estiver executando uma consulta longa, as conexões inativas só poderão ser detectadas após a conclusão da consulta. No PostgreSQL 14 e versões posteriores, `client_connection_check_interval` pode acelerar a detecção de conexões inativas pesquisando periodicamente o soquete durante a execução da consulta.
## Práticas recomendadas
+ **Defina intervalos razoáveis de keepalive:** ajuste `tcp_user_timeout`, `tcp_keepalives_idle`, `tcp_keepalives_count` e `tcp_keepalives_interval` para contrabalançar a velocidade de detecção e o uso de recursos.
+ **Otimize para melhorar seu ambiente:** alinhe as configurações ao comportamento da rede, às políticas de firewall e às necessidades da sessão.
+ **Aproveite os recursos do PostgreSQL**: use `client_connection_check_interval` no PostgreSQL 14 e versões posteriores para realizar verificações de conexão eficientes.
# Trabalhar com o autovacuum do PostgreSQL no Amazon RDS para PostgreSQL
É altamente recomendável que você use o recurso de autovacuum para bancos de dados PostgreSQL a fim de manter a integridade de sua instância de banco de dados PostgreSQL. O autovacuum automatiza a execução dos comandos VACUUM e ANALYZE. Ele verifica as tabelas com um grande número de tuplas inseridas, atualizadas ou excluídas. Após essa verificação, ele recupera o armazenamento removendo dados obsoletos ou tuplas do banco de dados PostgreSQL.
Por padrão, o autovacuum é ativado nas instâncias de banco de dados do RDS para PostgreSQL que você cria usando qualquer um dos grupos de parâmetros de banco de dados padrão do PostgreSQL. Outros parâmetros de configuração associados ao recurso autovacuum também são definidos por padrão. Como esses padrões são genéricos, você pode se beneficiar do ajuste de alguns dos parâmetros associados ao recurso autovacuum para seu workload específico.
A seguir, você pode encontrar mais informações sobre o autovacuum e como ajustar alguns dos respectivos parâmetros em sua instância de banco de dados do RDS para PostgreSQL. Para ter informações gerais, consulte [Práticas recomendadas para trabalhar com PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [
## Alocar memória para autovacuum
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [
## Reduzir a probabilidade de conclusão de IDs de transação
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [
# Determinar se as tabelas no seu banco de dados precisam de vacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [
# Determinar quais tabelas são atualmente elegíveis para autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [
# Determinar se o autovacuum está em execução e por quanto tempo
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [
# Realização de um congelamento manual de vacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [
# Reindexação de uma tabela quando o autovacuum está em execução
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [
# Gerenciar o autovacuum com grandes índices
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [
# Outros parâmetros que afetam o autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [
# Definir parâmetros de autovacuum em nível de tabela
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [
# Registrar atividades do autovacuum e do vacuum em log
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [
# Noções básicas sobre o comportamento do autovacuum com bancos de dados inválidos
](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [
# Identificar e resolver bloqueadores de limpeza agressivos no RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Alocar memória para autovacuum
Um dos parâmetros mais importantes que influenciam a performance do autovacuum é o [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). No RDS para PostgreSQL versões 14 e anteriores, o parâmetro `autovacuum_work_mem` é definido como -1, indicando que a configuração de `maintenance_work_mem` é usada em vez disso. Para todas as outras versões, `autovacuum_work_mem` é determinado por GREATEST(\$1DBInstanceClassMemory/32768\$1, 65536).
As operações vacuum manuais sempre usam a configuração `maintenance_work_mem`, com uma configuração padrão de GREATEST(\$1DBInstanceClassMemory/63963136\$11024\$1, 65536), e também é possível fazer o ajuste no nível da sessão usando o comando `SET` para operações `VACUUM` manuais mais específicas.
O `autovacuum_work_mem` determina a memória do autovacuum para armazenar identificadores de tuplas mortas (`pg_stat_all_tables.n_dead_tup`) para índices de vacuum.
Ao executar cálculos para determinar o valor do parâmetro `autovacuum_work_mem`, esteja ciente do seguinte:
+ Se você definir o parâmetro com um valor muito baixo, o processo de vacuum talvez precise verificar a tabela várias vezes para concluir o trabalho. Essas várias verificações podem ter um impacto negativo sobre a performance. Para instâncias maiores, a configuração de `maintenance_work_mem` ou `autovacuum_work_mem` para pelo menos 1 GB pode melhorar o desempenho de vaccum nas tabelas com um grande número de tuplas mortas. No entanto, no PostgreSQL versões 16 e anteriores, o uso de memória do vacuum é limitado a 1 GB, o que é suficiente para processar aproximadamente 179 milhões de tuplas mortas em uma única passagem. Se uma tabela tiver mais tuplas mortas do que isso, o vacuum precisará fazer várias passagens pelos índices da tabela, aumentando significativamente o tempo necessário. A partir da versão 17 do PostgreSQL, não há um limite de 1 GB, e o autovacuum pode processar mais de 179 milhões de tuplas usando árvores radix.
Um identificador de tupla tem 6 bytes de tamanho. Para estimar a memória necessária para limpar um índice de uma tabela, consulte `pg_stat_all_tables.n_dead_tup` para encontrar o número de tuplas mortas e multiplique esse número por seis para determinar a memória necessária para realizar vacuum do índice em uma única passagem. Você pode usar a seguinte consulta:
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ O parâmetro `autovacuum_work_mem` funciona em conjunto com o parâmetro `autovacuum_max_workers`. Cada operador entre `autovacuum_max_workers` pode usar a memória que você alocar. Se você tiver muitas tabelas pequenas, aloque mais `autovacuum_max_workers` e menos `autovacuum_work_mem`. Se você tiver tabelas grandes (com mais de 100 GB), aloque mais memória e menos processos de operadores. Você precisa ter memória suficiente alocada para ter sucesso na sua maior tabela. Portanto, garanta que a combinação de processos de operadores e memória seja igual à memória total que deseja alocar.
## Reduzir a probabilidade de conclusão de IDs de transação
Em alguns casos, as configurações de grupos de parâmetros relacionadas ao autovacuum podem não ser agressivas o suficiente para evitar a conclusão de IDs de transação. Para resolver isso, o RDS para PostgreSQL oferece um mecanismo que adapta automaticamente os valores dos parâmetros de autovacuum. O *autovacuum adaptável* é um recurso do RDS para PostgreSQL. Uma explicação detalhada da [conclusão de TransactionID](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) encontra-se na documentação do PostgreSQL.
O autovacuum adaptável está ativado por padrão para instâncias do RDS para PostgreSQL com o parâmetro dinâmico `rds.adaptive_autovacuum` definido como ATIVADO. É altamente recomendável manter esse recurso ativado. No entanto, para desabilitar esse recurso, defina o parâmetro `rds.adaptive_autovacuum` como 0 ou OFF (desativado).
O wraparound de ID de transação ainda é possível mesmo quando o Amazon RDS ajusta os parâmetros de autovacuum. Nós encorajamos que você implemente um alarme do Amazon CloudWatch para a conclusão de IDs de transação. Para ter mais informações, consulte a postagem [Implement an early warning system for transaction ID wraparound in RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) (Implementar um sistema de alertas antecipados para conclusão de IDs de transação no RDS for PostgreSQL) no Blog de banco de dados da AWS.
Com o ajuste de parâmetros de autovacuum adaptável ativado, o Amazon RDS começa a ajustar parâmetros de autovacuum quando a métrica do CloudWatch `MaximumUsedTransactionIDs` atingir o valor do parâmetro `autovacuum_freeze_max_age` ou 500.000.000, o que for maior.
O Amazon RDS continuará a ajustar os parâmetros para o autovacuum se uma tabela continuar a tendência para a conclusão de IDs de transação. Cada um desses ajustes dedica mais recursos ao autovacuum para evitar o envolvimento. O Amazon RDS atualiza os seguintes parâmetros relacionados ao autovacuum:
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
O RDS modificará esses parâmetros somente se o novo valor tornar o autovacuum mais agressivo. Os parâmetros são modificados na memória na instância de banco de dados. Os valores no grupo de parâmetros não são alterados. Para visualizar as configurações atuais na memória, use o comando SQL [SHOW](https://www.postgresql.org/docs/current/sql-show.html) PostgreSQL.
Quando o Amazon RDS modifica qualquer um desses parâmetros de autovacuum, ele gera um evento para a instância de banco de dados afetada. Esse evento é visível no Console de gerenciamento da AWS e por meio da API do Amazon RDS. Depois que a métrica `MaximumUsedTransactionIDs` do CloudWatch volta a ficar abaixo do limite, o Amazon RDS redefine os parâmetros relacionados a autovacuum na memória de volta aos valores especificados no grupo de parâmetros. Em seguida, ele gera outro evento correspondente a essa alteração.
# Determinar se as tabelas no seu banco de dados precisam de vacuum
Você pode usar a consulta a seguir para mostrar o número de transações sem restrições em um banco de dados. A coluna `datfrozenxid` de uma linha `pg_database` do banco de dados é um limite inferior nos IDs de transação normais que aparecem nesse banco de dados. Essa coluna é o mínimo dos valores de `relfrozenxid` por tabela no banco de dados.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Por exemplo, os resultados da execução da consulta anterior podem ser os seguintes.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Quando a idade de um banco de dados atingir 2 bilhões de IDs de transação, ocorrerá a conclusão de IDs de transação (XID), e o banco de dados se tornará somente leitura. Use essa consulta para produzir uma métrica e execute-a algumas vezes por dia. Por padrão, o autovacuum é definido para manter a idade das transações como um máximo de 200,000,000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Uma estratégia de monitoramento de exemplo pode ser assim:
+ Defina o valor `autovacuum_freeze_max_age` como 200 milhões de transações.
+ Se uma tabela atingir 500 milhões de transações sem restrições, um alarme de baixa gravidade será disparado. Este não é um valor não razoável, mas pode indicar que o autovacuum não está dando conta.
+ Se uma tabela chegar a 1 bilhão, ela deverá ser tratada como um alarme que requer medidas. Em geral, convém manter as idades mais próximas de `autovacuum_freeze_max_age` por motivos de performance. Recomendamos que você investigue usando as recomendações a seguir.
+ Se uma tabela atingir 1,5 bilhões de transações sem vacuum, um alarme de alta gravidade será disparado. Dependendo da rapidez com que seu banco de dados usa IDs de transação, esse alarme pode indicar que o sistema está ficando sem tempo para executar o autovacuum. Nesse caso, recomendamos que você resolva isso imediatamente.
Se uma tabela estiver ultrapassando constantemente esses limiares, modifique ainda mais seus parâmetros de autovacuum. Por padrão, usar VACUUM manualmente (que tem atrasos baseados em custos desabilitados) é mais agressivo do que usar o autovacuum padrão, mas também é mais intrusivo para o sistema como um todo.
Recomendamos o seguinte:
+ Esteja ciente e ative um mecanismo de monitoramento para que você tenha conhecimento da idade das transações mais antigas.
Para obter informações sobre como criar um processo que avisa sobre a conclusão de IDs de transação, consulte a publicação do blog de banco de dados da AWS [Implement an early warning system for transaction ID wraparound no Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) (Implementar um sistema de alerta antecipado para conclusão de IDs de transação no Amazon RDS for PostgreSQL).
+ Para tabelas mais ocupadas, execute um congelamento de vacuum manual regularmente durante uma janela de manutenção além de depender do autovacuum. Para obter informações sobre a realização de um congelamento manual de vacuum, consulte [Realização de um congelamento manual de vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Determinar quais tabelas são atualmente elegíveis para autovacuum
Muitas vezes, uma ou duas tabelas precisam de vacuum. Tabelas cujo valor de `relfrozenxid` é maior que o número de transações em `autovacuum_freeze_max_age` são sempre visadas pelo autovacuum. Caso contrário, se o número de tuplas obsoletas desde o último VACUUM exceder o limite de vacuum, um vacuum será realizado na tabela.
O [limite de autovacuum](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) é definido como:
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
em que o `vacuum base threshold` é `autovacuum_vacuum_threshold`, o `vacuum scale factor` é `autovacuum_vacuum_scale_factor` e o `number of tuples` é `pg_class.reltuples`.
Enquanto você estiver conectado ao seu banco de dados, execute a consulta a seguir para ver uma lista de tabelas que o autovacuum considera elegíveis para o vacuum.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Determinar se o autovacuum está em execução e por quanto tempo
Se você precisa realizar vacuum em uma tabela manualmente, determine se o autovacuum está sendo executado. Se estiver, talvez seja necessário ajustar parâmetros para fazê-lo funcionar mais eficientemente ou desativar o autovacuum temporariamente para poder executar VACUUM manualmente.
Use a seguinte consulta para determinar se o autovacuum está sendo executado e por quanto tempo, e se ele está esperando por outra sessão.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Depois de executar a consulta, você deverá ver uma saída semelhante à seguinte:
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Vários problemas podem causar uma sessão de autovacuum de longa execução (ou seja, vários dias de duração). O problema mais comum é que o valor do seu parâmetro [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) está muito baixo para o tamanho da tabela ou a taxa de atualizações.
Recomendamos o uso da fórmula a seguir para definir o valor do parâmetro `maintenance_work_mem`.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
Sessões de autovacuum em execução por pouco tempo também podem indicar problemas:
+ Isso pode indicar que não há `autovacuum_max_workers` suficientes para sua workload. Neste caso, você precisa indicar o número de operadores.
+ Pode indicar que existe uma corrupção de índice (o autovacuum trava e reinicia na mesma relação, mas não faz nenhum progresso). Nesse caso, execute um `vacuum freeze verbose table` manual para ver a causa exata.
# Realização de um congelamento manual de vacuum
Você pode querer realizar um vacuum manual em uma tabela que tenha um processo de vacuum já em execução. Isso é útil se você identificou uma tabela com uma idade XID próxima de 2 bilhões de transações (ou acima de qualquer limite que você esteja monitorando).
As etapas a seguir são uma orientação com diversas variações no processo. Por exemplo, durante testes, suponha que você perceba que o valor do parâmetro [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) está muito baixo e que precisa tomar medidas imediatas em uma tabela. No entanto, talvez você não queira devolver a instância no momento. Usando as consultas nas seções anteriores, você determina qual tabela é o problema e observa uma sessão de autovacuum de longa execução. Você sabe que precisa alterar a configuração do parâmetro `maintenance_work_mem`, mas também precisa tomar medidas imediatas e evacuar a tabela em questão. O procedimento a seguir mostra o que fazer nessa situação.
**Para executar manualmente um congelamento de vacuum**
1. Abra duas sessões no banco de dados que contém a tabela em que você deseja realizar vacuum. Para a segunda sessão, use "screen" ou outro utilitário que mantenha a sessão se a conexão for encerrada.
1. Na sessão um, obtenha o “Process ID” (PID – ID de processo) da sessão de autovacuum em execução na tabela.
Execute a seguinte consulta para obter o PID da sessão de autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. Na sessão dois, calcule a quantidade de memória necessária para essa operação. Neste exemplo, determinamos que podemos usar até 2 GB de memória para essa operação e, portanto, definimos [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) da sessão atual como 2 GB.
```
SET maintenance_work_mem='2 GB';
SET
```
1. Na sessão dois, emita um comando `vacuum freeze verbose` para a tabela. A configuração detalhada é útil porque, embora não haja um relatório de andamento para isso no PostgreSQL, você pode ver as atividades.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. Na sessão um, se o autovacuum estava bloqueando a sessão de vacuum, `pg_stat_activity` mostrará que a espera é `T` para a sessão de vacuum. Nesse caso, encerre o processo de autovacuum da maneira a seguir.
```
SELECT pg_terminate_backend('the_pid');
```
**nota**
Algumas versões anteriores do Amazon RDS não podem encerrar um processo de autovacuum usando o comando anterior e falham com o seguinte erro: `ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`.
Nesse ponto, sua sessão começa. O autovacuum é reiniciado imediatamente, pois essa tabela é provavelmente a mais alta em sua lista de trabalho.
1. Inicie seu comando `vacuum freeze verbose` na sessão dois e depois termine o processo de autovacuum na sessão um.
# Reindexação de uma tabela quando o autovacuum está em execução
Se um índice se tornar corrompido, o autovacuum continuará processando a tabela e falhará. Se você tentar um vacuum manual nessa situação, receberá uma mensagem de erro semelhante à mostrada a seguir.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Quando o índice está corrompido e o autovacuum está tentando ser executado na tabela, você lutará com uma sessão de autovacuum já em execução. Ao emitir um comando [REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html), você remove um bloqueio exclusivo na tabela. As operações de gravação são bloqueadas, bem como as operações de leitura que usam esse índice específico.
**Para reindexar uma tabela quando o autovacuum está em execução nela**
1. Abra duas sessões no banco de dados que contém a tabela em que você deseja realizar vacuum. Para a segunda sessão, use "screen" ou outro utilitário que mantenha a sessão se a conexão for encerrada.
1. Na sessão um, obtenha o PID da sessão de autovacuum em execução na tabela.
Execute a seguinte consulta para obter o PID da sessão de autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. Na segunda sessão, emita o comando reindex.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. Na sessão um, se o autovacuum estava bloqueando o processo, você verá em `pg_stat_activity` que a espera é "T" para a sua sessão de vacuum. Nesse caso, você encerra o processo de autovacuum.
```
SELECT pg_terminate_backend('the_pid');
```
Nesse ponto, sua sessão começa. É importante observar que o autovacuum é reiniciado imediatamente, pois essa tabela é provavelmente a mais alta em sua lista de trabalho.
1. Inicie seu comando na sessão dois e depois termine o processo de autovacuum na sessão um.
# Gerenciar o autovacuum com grandes índices
Como parte de sua operação, o *autovacuum* executa várias [fases de aspiração](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) ao trabalhar em uma tabela. Antes de a tabela ser limpa, todos os seus índices são aspirados primeiro. Ao remover vários índices grandes, essa fase consome uma quantidade significativa de tempo e recursos. Portanto, como prática recomendada, controle o número de índices em uma tabela e elimine os índices não usados.
Para esse processo, primeiro confira o tamanho geral do índice. Depois, determine se há índices possivelmente não usados que podem ser removidos conforme mostrado nos exemplos a seguir.
**Como conferir o tamanho da tabela e os respectivos índices**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
Neste exemplo, o tamanho dos índices é maior do que a tabela. Essa diferença pode causar problemas de performance, pois os índices estão sobrecarregados ou não são usados, o que afeta as operações de autovacuum e de inserção.
**Como conferir índices não usados**
Usando a visualização [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW), você pode conferir com que frequência um índice é usado com a coluna `idx_scan`. No exemplo a seguir, os índices não usados têm o valor `idx_scan` de `0`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**nota**
Essas estatísticas são incrementais a partir do momento em que as estatísticas são redefinidas. Suponha que você tenha um índice usado apenas no final de um trimestre comercial ou apenas para um relatório específico. É possível que esse índice não tenha sido usado desde que as estatísticas foram redefinidas. Para ter mais informações, consulte [Funções de estatística](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS). Os índices usados para impor a exclusividade não terão verificações realizadas e não devem ser identificados como índices não usados. Para identificar os índices não usados, você deve ter um conhecimento profundo da aplicação e das respectivas consultas.
Para conferir quando as estatísticas foram redefinidas pela última vez em um banco de dados, use [ https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW]( https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Aspirar uma tabela o mais rápido possível
**RDS para PostgreSQL 12 e posterior**
Se você tiver muitos índices em uma tabela grande, a instância de banco de dados poderá estar se aproximando do encapsulamento de ID (XID), que é quando o contador XID chega a zero. Se não for conferida, essa situação poderá ocasionar perda de dados. No entanto, você pode aspirar rapidamente a tabela sem limpar os índices. No RDS para PostgreSQL 12 e posterior, você pode usar VACUUM com a cláusula [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html).
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Se uma sessão de autovacuum já estiver em execução, você deverá encerrá-la para iniciar a aspiração manual. Para ter informações sobre a realização de um congelamento manual de aspiração, consulte [Realização de um congelamento manual de vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**nota**
Ignorar a limpeza do índice regularmente causa sobrecarga no índice, o que diminui a performance geral da verificação. O índice retém as linhas inativas e a tabela retém os ponteiros das linhas inativas. Consequentemente, `pg_stat_all_tables.n_dead_tup` aumenta até que o autovacuum ou um VACUUM manual com limpeza de índice seja executado. Como prática recomendada, use esse procedimento somente para evitar o encapsulamento de ID.
**RDS para PostgreSQL 11 e versões mais antigas**
No entanto, no RDS para PostgreSQL 11 e versões anteriores, a única maneira de permitir que a aspiração seja concluída mais rapidamente é reduzir o número de índices em uma tabela. A eliminação de um índice pode afetar os planos de consulta. Recomendamos que você elimine primeiro os índices não usados e, depois, descarte os índices quando o encapsulamento XID estiver muito próximo. Depois que o processo de aspiração for concluído, você poderá recriar esses índices.
# Outros parâmetros que afetam o autovacuum
A consulta a seguir mostra os valores de alguns dos parâmetros que afetam diretamente o autovacuum e seu comportamento. Os [parâmetros de autovacuum](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) são descritos inteiramente na documentação do PostgreSQL.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
Enquanto todos estes afetem o autovacuum, alguns dos mais importantes são:
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Definir parâmetros de autovacuum em nível de tabela
Você pode definir [parâmetros de armazenamento](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS) relacionados ao autovacuum em nível de tabela, o que pode ser melhor do que alterar o comportamento do banco de dados inteiro. Para tabelas grandes, talvez você precise definir configurações agressivas e talvez você não queira que o autovacuum se comporte dessa maneira para todas as tabelas.
A consulta a seguir mostra quais tabelas atualmente têm opções em nível de tabela.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Um exemplo em que isso pode ser útil é em tabelas que são muito maiores do que o resto das suas tabelas. Suponha que você tenha uma tabela de 300 GB e outras 30 tabelas com menos de 1 GB. Nesse caso, você pode definir alguns parâmetros específicos para a sua tabela grande, para não alterar o comportamento de todo o sistema.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
Fazer isso desativará o atraso de autovacuum baseado em custos para essa tabela, mas aumentará o uso de recursos no seu sistema. Normalmente, o autovacuum faz uma pausa durante `autovacuum_vacuum_cost_delay` sempre que `autovacuum_cost_limit` é alcançado. Para obtert mais detalhes, consulte a documentação do PostgreSQL sobre [vacuum baseado no custo](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Registrar atividades do autovacuum e do vacuum em log
Informações sobre atividades de autovacuum são enviadas para `postgresql.log` com base no nível especificado no parâmetro `rds.force_autovacuum_logging_level`. A seguir estão os valores permitidos para esse parâmetro e as versões do PostgreSQL para as quais esse valor é a configuração padrão:
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL 13 e superior)
+ `error`, log, `fatal`, `panic`
A configuração `rds.force_autovacuum_logging_level` funciona com o parâmetro `log_autovacuum_min_duration`. O valor do parâmetro `log_autovacuum_min_duration` é o limite (em milissegundos) acima do qual as ações autovacuum são registradas em log. Uma configuração `-1` não registra nada em log, enquanto uma configuração 0 registra todas as ações em log. Como ocorre com `rds.force_autovacuum_logging_level`, os valores padrão de `log_autovacuum_min_duration` são dependentes da versão, da seguinte maneira:
+ `10000 ms`: PostgreSQL 14, PostgreSQL 13, PostgreSQL 12 e PostgreSQL 11
+ `(empty)`: nenhum valor padrão para PostgreSQL 10 e PostgreSQL 9.6
Recomendamos que você defina `rds.force_autovacuum_logging_level` como `WARNING`. Também recomendamos definir `log_autovacuum_min_duration` para um valor entre 1000 e 5000. Uma configuração 5000 registra em log a atividade que leva mais de 5.000 milissegundos. Qualquer configuração diferente de -1 também registrará mensagens se a ação autovacuum for ignorada devido a um bloqueio conflitante ou relações descartadas simultaneamente. Para ter mais informações, consulte [Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) (Aplicação automática do vacuum) na documentação do PostgreSQL.
Para solucionar problemas, você pode alterar o parâmetro `rds.force_autovacuum_logging_level` para um dos níveis de depuração, de `debug1` a `debug5`, para obter informações mais detalhadas. Recomendamos que você use as configurações de depuração por curtos períodos e apenas para fins de solução de problemas. Para saber mais, consulte [When to log](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) (Quando registrar em log) na documentação do PostgreSQL.
**nota**
O PostgreSQL permite que a conta `rds_superuser` visualize sessões de autovacuum em `pg_stat_activity`. Por exemplo, você pode identificar e encerrar uma sessão de autovacuum que esteja bloqueando a execução de um comando, ou executando de forma mais lenta do que um comando de vacuum emitido manualmente.
# Noções básicas sobre o comportamento do autovacuum com bancos de dados inválidos
Um novo valor `-2` é introduzido na coluna `datconnlimit` do catálogo `pg_database` para indicar bancos de dados que foram interrompidos no meio da operação DROP DATABASE como inválidos.
Esse novo valor está disponível nas seguintes versões do RDS para PostgreSQL:
+ 15.4 e todas as versões posteriores
+ 14.9 e versões posteriores
+ 13.12 e versões posteriores
+ 12.16 e versões posteriores
+ 11.21 e versões posteriores
Bancos de dados inválidos não afetam a capacidade do autovacuum de congelar a funcionalidade de bancos de dados válidos. O Autovacuum ignora bancos de dados inválidos. Consequentemente, as operações regulares de limpeza continuarão funcionando de forma adequada e eficiente em todos os bancos de dados válidos no ambiente do PostgreSQL.
**Topics**
+ [
## ID da transação de monitoramento
](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [
## Ajustar a consulta de monitoramento
](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [
## Resolver o problema de banco de dados inválido
](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## ID da transação de monitoramento
A função `age(datfrozenxid)` geralmente é usada para monitorar a idade do ID de transação (XID) dos bancos de dados para evitar o encapsulamento de IDs de transação.
Como bancos de dados inválidos são excluídos do autovacuum, seu contador de ID de transação (XID) pode atingir o valor máximo de `2 billion`, ser encapsulado em `- 2 billion` e continuar esse ciclo indefinidamente. Uma consulta típica para monitorar o encapsulamento de IDs de transação pode ser:
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
No entanto, com a introdução do valor -2 para `datconnlimit`, bancos de dados inválidos podem distorcer os resultados dessa consulta. Como esses bancos de dados não são válidos e não devem fazer parte das verificações de manutenção regulares, eles podem causar falsos positivos, levando você a acreditar que o `age(datfrozenxid)` é maior do que realmente é.
## Ajustar a consulta de monitoramento
Para garantir um monitoramento preciso, você deve ajustar sua consulta de monitoramento para excluir bancos de dados inválidos. Siga esta consulta recomendada:
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Essa consulta garante que somente bancos de dados válidos sejam considerados no cálculo `age(datfrozenxid)`, fornecendo um reflexo real da idade do ID da transação no ambiente do PostgreSQL.
## Resolver o problema de banco de dados inválido
Ao tentar se conectar a um banco de dados inválido, talvez seja exibida uma mensagem de erro semelhante à seguinte:
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
Além disso, se o parâmetro `log_min_messages` estiver definido como `DEBUG2` ou posterior, você poderá observar as seguintes entradas de log indicando que o processo de autovacuum está ignorando o banco de dados inválido:
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Para resolver o problema, siga a `HINT` fornecida durante a tentativa de conexão. Conecte-se a qualquer banco de dados válido usando sua conta principal do RDS ou uma conta de banco de dados com o perfil `rds_superuser` e elimine bancos de dados inválidos.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
# Identificar e resolver bloqueadores de limpeza agressivos no RDS para PostgreSQL
No PostgreSQL, a limpeza é vital para garantir a integridade do banco de dados, pois recupera o armazenamento e evita problemas de [conclusão do ID da transação.](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) No entanto, há momentos em que a limpeza pode ser impedida de operar conforme desejado, o que pode resultar em degradação do desempenho e sobrecarga do armazenamento e até mesmo afetar a disponibilidade da instância de banco de dados pelo wraparound de ID de transação. Portanto, identificar e resolver esses problemas é essencial para o desempenho e a disponibilidade ideais do banco de dados. Leia [Understanding autovacuum in Amazon RDS for PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) para saber mais sobre o autovacuum.
A função `postgres_get_av_diag()` ajuda a identificar problemas que impedem ou atrasam o progresso da limpeza agressiva. São fornecidas sugestões, que podem incluir comandos para resolver o problema onde ele é identificável ou orientações para diagnósticos adicionais quando o problema não é identificável. Bloqueadores de limpeza agressiva são relatados quando a idade excede o limite de [autovacuum adaptativo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) do RDS de 500 milhões de IDs de transação.
**Qual é a idade do ID da transação?**
A função `age()` para IDs de transação calcula o número de transações que ocorreram desde o ID de transação não congelado mais antigo de um banco de dados (`pg_database.datfrozenxid`) ou tabela (`pg_class.relfrozenxid`). Esse valor indica a atividade do banco de dados desde a última operação de limpeza agressiva e destaca a provável workload para os próximos processos de VACUUM.
**O que é uma limpeza agressiva?**
Uma operação VACUUM agressiva conduz uma varredura abrangente de todas as páginas em uma tabela, incluindo aquelas normalmente ignoradas durante operações VACUUM regulares. Essa verificação completa visa "congelar" os IDs de transação que se aproximam de sua idade máxima, evitando efetivamente uma situação conhecida como [conclusão de ID de transação](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
Para que `postgres_get_av_diag()` reporte bloqueadores, o bloqueador deve ter pelo menos 500 milhões de transações de idade.
**Topics**
+ [
# Instalar ferramentas de monitoramento e diagnóstico de autovacuum no RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [
# Funções de postgres\$1get\$1av\$1diag() no RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [
# Solucionar bloqueadores de limpeza identificáveis no RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [
# Solucionar bloqueadores de limpeza não identificáveis no RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [
# Resolver problemas de desempenho de limpeza no RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [
# Explicação das mensagens de AVISO no RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
# Instalar ferramentas de monitoramento e diagnóstico de autovacuum no RDS para PostgreSQL
No momento, a função `postgres_get_av_diag()` está disponível nas seguintes versões do RDS para PostgreSQL:
+ 17.2 e versões 17 posteriores
+ 16.7 e versões 16 posteriores
+ 15.11 e versões 15 posteriores
+ 14.16 e versões 14 posteriores
+ 13.19 e versões 13 posteriores
Para usar `postgres_get_av_diag()`, crie a extensão `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Para verificar se a extensão está instalada.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Verifique se a função foi criada.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
# Funções de postgres\$1get\$1av\$1diag() no RDS para PostgreSQL
A função `postgres_get_av_diag()` recupera informações de diagnóstico sobre processos de autovacuum que estão bloqueando ou atrasando em um banco de dados do RDS para PostgreSQL. A consulta precisa ser executada no banco de dados com o ID de transação mais antigo para obter resultados precisos. Para obter mais informações sobre como usar o banco de dados com o ID de transação mais antigo, consulte [Não conectado ao banco de dados com o ID de transação mais antigo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
A função `postgres_get_av_diag()` retorna uma tabela com as informações a seguir:
**blocker**
Especifica a categoria da atividade do banco de dados que está bloqueando o vacuum.
+ [Instrução ativa](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Ocioso na transação](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transação preparada](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Slot de replicação lógica](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Réplica de leitura com slot de replicação física](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Réplica de leitura com replicação de streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tabelas temporárias](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**banco de dados**
Especifica o nome do banco de dados, quando aplicável e suportado. Este é o banco de dados no qual a atividade está em andamento e bloqueia ou bloqueará o autovacuum. Este é o banco de dados ao qual você precisa se conectar e tomar ação.
**blocker\$1identifier**
Especifica o identificador da atividade que está bloqueando ou bloqueará o autovacuum. O identificador pode ser um ID de processo junto com uma instrução SQL, uma transação preparada, um endereço IP de uma réplica de leitura e o nome do slot de replicação, seja lógico ou físico.
**wait\$1event**
Especifica o [evento de espera](PostgreSQL.Tuning.md) da sessão de bloqueio e é aplicável para os seguintes bloqueadores:
+ Instrução ativa
+ Ocioso na transação
**autovacuum\$1lagging\$1by**
Especifica o número de transações que o autovacuum está atrasado no trabalho pendente por categoria.
**suggestion**
Especifica sugestões para resolver o bloqueador. Essas instruções incluem o nome do banco de dados no qual a atividade existe, quando aplicável, o ID do processo (PID) da sessão, quando aplicável, e a ação a ser tomada.
**suggested\$1action**
Sugere a ação que precisa ser tomada para resolver o bloqueador.
# Solucionar bloqueadores de limpeza identificáveis no RDS para PostgreSQL
O Autovacuum realiza limpezas agressivas e reduz a idade dos IDs de transação para abaixo do limite especificado pelo parâmetro `autovacuum_freeze_max_age` de sua instância do RDS. É possível rastrear essa idade usando a métrica `MaximumUsedTransactionIDs` do Amazon CloudWatch.
Para encontrar a configuração de `autovacuum_freeze_max_age` (que tem um padrão de 200 milhões de IDs de transação) da sua instância do Amazon RDS, use a seguinte consulta:
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Observe que `postgres_get_av_diag()` só verifica se há bloqueadores de limpeza agressiva quando a idade excede o limite de 500 milhões de IDs de transação do [autovacuum adaptativo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) do Amazon RDS. Para que `postgres_get_av_diag()` detecte bloqueadores, o bloqueador deve ter pelo menos 500 milhões de transações de idade.
A função `postgres_get_av_diag()` identifica os seguintes tipos de bloqueadores:
**Topics**
+ [
## Instrução ativa
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [
## Ocioso na transação
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [
## Transação preparada
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [
## Slot de replicação lógica
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [
## Réplicas de leitura
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [
## Tabelas temporárias
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Instrução ativa
No PostgreSQL, uma instrução ativa é uma instrução SQL que está sendo executada atualmente pelo banco de dados. Isso inclui consultas, transações ou quaisquer operações em andamento. Ao monitorar por meio do `pg_stat_activity`, a coluna de estado indica que o processo com o PID correspondente está ativo.
A função `postgres_get_av_diag()` exibe uma saída semelhante à saída a seguir quando identifica uma instrução que é uma instrução ativa.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Ação sugerida**
Seguindo as orientações na coluna `suggestion`, o usuário pode se conectar ao banco de dados em que a instrução ativa está presente e, conforme especificado na coluna `suggested_action`, é recomendável analisar cuidadosamente a opção de encerrar a sessão. Se o encerramento for seguro, use a função `pg_terminate_backend()` para encerrar a sessão. Essa ação pode ser executada por um administrador (como a conta mestra do RDS) ou por um usuário com o privilégio `pg_terminate_backend()` necessário.
**Atenção**
Uma sessão encerrada reverterá (`ROLLBACK`) as alterações feitas. Dependendo de seus requisitos, pode ser necessário executar a instrução novamente. No entanto, é recomendável fazer isso somente após o processo do autovacuum terminar a operação de limpeza agressiva.
## Ocioso na transação
Uma instrução ociosa na transação se refere a qualquer sessão que abriu uma transação explícita (como emitir uma instrução `BEGIN`), realizou algum trabalho e agora está esperando que o cliente passe mais trabalho ou sinalize o final da transação emitindo um `COMMIT`, `ROLLBACK` ou `END` (o que resultaria em um `COMMIT` implícito).
A função `postgres_get_av_diag()` exibe uma saída semelhante à saída a seguir quando identifica uma instrução `idle in transaction` como um bloqueador.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Ação sugerida**
Conforme indicado na coluna `suggestion`, conecte-se ao banco de dados em que a sessão ociosa na transação está presente e encerre a sessão usando a função `pg_terminate_backend()`. O usuário pode ser seu usuário administrador (conta mestra do RDS) ou um usuário com o privilégio `pg_terminate_backend()`.
**Atenção**
Uma sessão encerrada reverterá (`ROLLBACK`) as alterações feitas. Dependendo de seus requisitos, pode ser necessário executar a instrução novamente. No entanto, é recomendável fazer isso somente após o processo do autovacuum terminar a operação de limpeza agressiva.
## Transação preparada
O PostgreSQL permite transações que fazem parte de uma estratégia de confirmação bifásica chamada [transações preparadas](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). Elas são habilitadas ao definir o parâmetro `max_prepared_transactions` como um valor diferente de zero. As transações preparadas são projetadas para garantir que uma transação seja durável e permaneça disponível mesmo após falhas no banco de dados, reinicializações ou desconexões do cliente. Como as transações regulares, elas recebem um ID de transação e podem afetar o autovacuum. Se deixado em um estado preparado, o autovacuum não realiza o congelamento e isso pode levar à conclusão do ID da transação.
Quando as transações são deixadas no estado de preparação indefinidamente, sem serem resolvidas por um gerenciador de transações, elas se tornam transações preparadas órfãs. A única maneira de corrigir isso é confirmar ou reverter a transação usando os comandos `COMMIT PREPARED` ou `ROLLBACK PREPARED`, respectivamente.
**nota**
Esteja ciente de que um backup feito durante uma transação preparada ainda conterá essa transação após a restauração. Consulte as informações a seguir sobre como localizar e fechar essas transações.
A função `postgres_get_av_diag()` exibe a saída a seguir quando identifica um bloqueador que é uma transação preparada.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Ação sugerida**
Conforme mencionado na coluna de sugestões, conecte-se ao banco de dados em que a transação preparada está localizada. Com base na coluna `suggested_action`, analise cuidadosamente se deseja executar `COMMIT` ou `ROLLBACK`, e então execute a ação apropriada.
Para monitorar transações preparadas em geral, o PostgreSQL oferece uma visualização de catálogo chamada `pg_prepared_xacts`. Use a consulta a seguir para encontrar transações preparadas.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Slot de replicação lógica
O objetivo de um slot de replicação é manter as alterações não consumidas até que elas sejam replicadas em um servidor de destino. Consulte a página sobre [replicação lógica](https://www.postgresql.org/docs/current/logical-replication.html) do PostgreSQL para obter mais informações.
Existem dois tipos de slots de replicação lógica.
**Slots de replicação lógica inativa**
Quando a replicação é encerrada, os logs de transações não consumidos não podem ser removidos e o slot de replicação fica inativo. Embora um slot de replicação lógica inativo não seja usado atualmente por um assinante, ele permanece no servidor, levando à retenção de arquivos WAL e impedindo a remoção de logs de transações antigos. Isso pode aumentar o uso do disco e, especificamente, impedir que o autovacuum limpe as tabelas internas do catálogo, pois o sistema deve evitar que as informações do LSN sejam sobrescritas. Se não for resolvido, esse problema pode resultar em inchaço do catálogo, degradação do desempenho e aumento do risco de conclusão da limpeza, potencialmente causando tempo de inatividade das transações.
**Slots de replicação lógica ativos, mas lentos**
Às vezes, a remoção de tuplas inativas do catálogo é adiada devido à degradação do desempenho da replicação lógica. Esse atraso na replicação retarda a atualização do `catalog_xmin` e pode causar inchaço do catálogo e conclusão da limpeza.
A função `postgres_get_av_diag()` exibe uma saída semelhante à saída a seguir quando encontra um slot de replicação lógica como um bloqueador.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Ação sugerida**
Para resolver esse problema, verifique se há problemas com o esquema ou os dados de destino na configuração de replicação que possam estar encerrando o processo de aplicação. Os motivos mais comuns são:
+ Colunas ausentes
+ Tipos de dados incompatíveis
+ Incompatibilidade de dados
+ Tabela ausente
Se o problema estiver relacionado a questões de infraestrutura:
+ Problemas de rede: [Como resolver problemas com um banco de dados do Amazon RDS que está em um estado de rede incompatível?](https://repost.aws/knowledge-center/rds-incompatible-network).
+ O banco de dados ou a instância de banco de dados não está disponível devido aos seguintes motivos:
+ A instância da réplica está sem armazenamento: consulte [Como resolver problemas que ocorrem quando as instâncias de banco de dados do Amazon RDS ficam sem armazenamento?](https://repost.aws/knowledge-center/rds-out-of-storage) para obter informações sobre como adicionar armazenamento.
+ Parâmetros incompatíveis: consulte [Como corrijo uma instância de banco de dados do Amazon RDS que está presa no status de parâmetros incompatíveis?](https://repost.aws/knowledge-center/rds-incompatible-parameters) para obter mais informações sobre como resolver o problema.
Se sua instância estiver fora da rede da AWS ou no AWS EC2, consulte seu administrador sobre como resolver os problemas de disponibilidade ou problemas relacionados à infraestrutura.
**Descartar o slot inativo**
**Atenção**
Cuidado: antes de descartar um slot de replicação, verifique cuidadosamente se ele não tem nenhuma replicação em andamento, está inativo e está em um estado irrecuperável. Descartar um slot prematuramente pode interromper a replicação ou causar perda de dados.
Depois de confirmar que o slot de replicação não é mais necessário, descarte-o para permitir que o autovacuum continue. A condição `active = 'f'` garante que somente um slot inativo seja descartado.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Réplicas de leitura
Quando a configuração `hot_standby_feedback` está habilitada para [réplicas de leitura do Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), ela impede que o autovacuum no banco de dados primário remova linhas inativas que ainda podem ser necessárias para consultas executadas na réplica de leitura. Isso afeta todos os tipos de réplicas de leitura físicas, incluindo as que são gerenciadas com ou sem slots de replicação. Esse comportamento é necessário porque as consultas executadas na réplica em espera exigem que essas linhas permaneçam disponíveis no primário, evitando [conflitos de consultas](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) e cancelamentos.
**Réplica de leitura com slot de replicação física**
As réplicas de leitura com slots de replicação física aumentam significativamente a confiabilidade e a estabilidade da replicação no RDS para PostgreSQL. Esses slots garantem que o banco de dados primário retenha os arquivos essenciais do log de gravação antecipada até que a réplica os processe, mantendo a consistência de dados mesmo durante interrupções na rede.
A partir do RDS para PostgreSQL versão 14, todas as réplicas utilizam slots de replicação. Nas versões anteriores, somente réplicas entre regiões usavam slots de replicação.
A função `postgres_get_av_diag()` exibe uma saída semelhante à saída a seguir quando encontra uma réplica de leitura com slot de replicação física como um bloqueador.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Réplica de leitura com replicação de streaming**
O Amazon RDS permite configurar réplicas de leitura sem um slot de replicação física em versões mais antigas, até a versão 13. Essa abordagem reduz a sobrecarga ao permitir que o primário recicle arquivos WAL de forma mais agressiva, o que é vantajoso em ambientes com espaço em disco limitado e que podem tolerar ReplicaLag ocasional. No entanto, sem um slot, o standby deve permanecer sincronizado para evitar a perda de arquivos WAL. O Amazon RDS usa arquivos WAL arquivados para ajudar a réplica a se recuperar caso ela fique atrasada, mas esse processo exige monitoramento cuidadoso e pode ser lento.
A função `postgres_get_av_diag()` exibe uma saída semelhante à saída a seguir quando encontra uma réplica de leitura de streaming como um bloqueador.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Ação sugerida**
Conforme recomendado na coluna `suggested_action`, analise cuidadosamente essas opções para desbloquear o autovacuum.
+ **Encerrar a consulta**: seguindo as orientações na coluna de sugestões, é possível se conectar à réplica de leitura, conforme especificado na coluna suggested\$1action. É recomendável analisar cuidadosamente a opção de encerrar a sessão. Se o encerramento for considerado seguro, use a função `pg_terminate_backend()` para encerrar a sessão. Essa ação pode ser executada por um administrador (como a conta mestra do RDS) ou por um usuário com o privilégio pg\$1terminate\$1backend() necessário.
Execute o comando SQL a seguir na réplica de leitura para encerrar a consulta que está impedindo a limpeza das linhas antigas no primário. O valor de `backend_xmin` é reportado na saída da função:
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Desabilitar o feedback de standby a quente**: considere desabilitar o parâmetro `hot_standby_feedback` se ele estiver causando atrasos significativos na limpeza.
O parâmetro `hot_standby_feedback` permite que uma réplica de leitura informe o primário sobre sua atividade de consulta, impedindo que o primário faça a limpeza de tabelas ou linhas que estão em uso no standby. Embora isso garanta a estabilidade da consulta no standby, pode atrasar significativamente a limpeza no primário. Desabilitar esse recurso permite que o primário prossiga com a limpeza sem esperar que o standby se atualize. No entanto, isso pode levar a cancelamentos de consultas ou falhas no standby se ele tentar acessar linhas que foram removidas pela limpeza no primário.
+ **Excluir a réplica de leitura se não for necessária**: se a réplica de leitura não for mais necessária, você poderá exclui-la. Isso removerá a sobrecarga de replicação associada e permitirá que o primário recicle os logs de transações sem ser retido pela réplica.
## Tabelas temporárias
[Tabelas temporárias](https://www.postgresql.org/docs/current/sql-createtable.html), criadas usando a palavra-chave `TEMPORARY`, residem no esquema temporário, por exemplo pg\$1temp\$1xxx, e só podem ser acessadas pela sessão que as criou. As tabelas temporárias são removidas quando a sessão termina. No entanto, essas tabelas são invisíveis para o processo de autovacuum do PostgreSQL e devem ser limpas manualmente pela sessão que as criou. Tentar limpar a tabela temporária de outra sessão não tem efeito.
Em circunstâncias incomuns, uma tabela temporária pode existir sem uma sessão ativa que a possua. Se a sessão proprietária terminar inesperadamente devido a uma falha fatal, problemas de rede ou eventos do tipo, a tabela temporária pode não ser limpa, deixando-a como uma tabela "órfã". Quando o processo de autovacuum do PostgreSQL detecta uma tabela temporária órfã, ele registra em log a seguinte mensagem:
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
A função `postgres_get_av_diag()` exibe uma saída semelhante à saída a seguir quando identifica uma tabela temporária como um bloqueador. Para que a função exiba corretamente a saída relacionada às tabelas temporárias, ela precisa ser executada no mesmo banco de dados em que essas tabelas existem.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Ação sugerida**
Siga as instruções fornecidas na coluna `suggestion` da saída para identificar e remover a tabela temporária que está impedindo a execução do autovacuum. Use o comando a seguir para eliminar a tabela temporária reportada por `postgres_get_av_diag()`. Substitua o nome da tabela com base na saída fornecida pela função `postgres_get_av_diag()`.
```
DROP TABLE my_temp_schema.my_temp_table;
```
A seguinte consulta pode ser usada para identificar tabelas temporárias:
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
# Solucionar bloqueadores de limpeza não identificáveis no RDS para PostgreSQL
Esta seção explora razões adicionais que podem impedir o progresso da limpeza. Esses problemas atualmente não são diretamente identificáveis pela função `postgres_get_av_diag()`.
**Topics**
+ [
## Páginas inválidas
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [
## Inconsistência do índice
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [
## Taxa de transação excepcionalmente alta
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Páginas inválidas
Um erro de página inválida ocorre quando o PostgreSQL detecta uma incompatibilidade na soma de verificação de uma página ao acessá-la. O conteúdo é ilegível, impedindo que o autovacuum congele as tuplas. Isso efetivamente interrompe o processo de limpeza. O seguinte erro é registrado no log do PostgreSQL:
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Determinar o tipo de objeto**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
A partir da mensagem de erro, o caminho `base/16403/186752608` fornece as seguintes informações:
+ "base" é o nome do diretório sob o diretório de dados do PostgreSQL.
+ "16403" é o OID do banco de dados, que você pode consultar no catálogo do sistema `pg_database`.
+ "186752608" é o `relfilenode`, que você pode usar para pesquisar o esquema e o nome do objeto no catálogo do sistema `pg_class`.
Ao verificar a saída da consulta a seguir no banco de dados afetado, será possível determinar o tipo de objeto. A consulta a seguir recupera informações do objeto para oid: 186752608. Substitua o OID pelo relevante para o erro que você encontrou.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Para obter mais informações, consulte a documentação do PostgreSQL [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) para ver todos os tipos de objetos compatíveis, indicados pela coluna `relkind` em `pg_class`.
**Orientação**
A solução mais eficaz para esse problema depende da configuração da instância específica do Amazon RDS e do tipo de dados afetados pela página inconsistente.
**Se o tipo de objeto for um índice:**
É recomendável reconstruir o índice.
+ **Usar a opção `CONCURRENTLY`**: antes da versão 12 do PostgreSQL, a reconstrução de um índice exigia um bloqueio de tabela exclusivo, restringindo o acesso à tabela. Com a versão 12 e posteriores do PostgreSQL, a opção `CONCURRENTLY` permite o bloqueio em nível de linha, melhorando significativamente a disponibilidade da tabela. Este é o comando:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Embora `CONCURRENTLY` seja menos disruptivo, pode ser mais lento em tabelas acessadas com frequência. Considere construir o índice durante períodos de baixo tráfego, se possível.
Para obter mais informações, consulte a documentação [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) do PostgreSQL.
+ **Usar a opção `INDEX_CLEANUP FALSE`**: se os índices forem grandes e, segundo sua avaliação, exigirem muito tempo para serem concluídos, é possível desbloquear o autovacuum executando um `VACUUM FREEZE` manual ao excluir os índices. Essa funcionalidade está disponível na versão 12 e versões posteriores do PostgreSQL.
Ignorar os índices permitirá que você pule o processo de limpeza do índice inconsistente e mitigue o problema de conclusão. No entanto, isso não resolverá o problema subjacente da página inválida. Para abordar e resolver totalmente o problema da página inválida, ainda será necessário reconstruir o índice.
**Se o tipo de objeto for uma visão materializada:**
Se ocorrer um erro de página inválida em uma visão materializada, faça login no banco de dados afetado e atualize-a para resolver a página inválida:
Atualize a visão materializada.
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Se a atualização falhar, tente recriar:
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
Atualizar ou recriar a visão materializada a restaura sem afetar os dados da tabela subjacente.
**Para todos os outros tipos de objetos:**
Para todos os outros tipos de objetos, entre em contato com o AWS Support.
## Inconsistência do índice
Um índice logicamente inconsistente pode impedir que o autovacuum progrida. Os seguintes erros ou erros semelhantes são registrados em log durante a fase de limpeza do índice ou quando o índice é acessado por instruções SQL.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Orientação**
Reconstrua o índice ou pule índices usando `INDEX_CLEANUP` no manual `VACUUM FREEZE`. Para obter informações sobre como reconstruir o índice, consulte [Se o tipo de objeto for um índice](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Usar a opção CONCURRENTLY**: antes da versão 12 do PostgreSQL, a reconstrução de um índice exigia um bloqueio de tabela exclusivo, restringindo o acesso à tabela. Com a versão 12 e posteriores do PostgreSQL, a opção CONCURRENTLY permite o bloqueio em nível de linha, melhorando significativamente a disponibilidade da tabela. Este é o comando:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Embora CONCURRENTLY seja menos disruptivo, pode ser mais lento em tabelas acessadas com frequência. Considere construir o índice durante períodos de baixo tráfego, se possível. Para ter mais informações, consulte a documentação [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) do *PostgreSQL*.
+ **Usar a opção INDEX\$1CLEANUP FALSE**: se os índices forem grandes e, segundo sua avaliação, exigirem muito tempo para serem concluídos, é possível desbloquear o autovacuum executando um VACUUM FREEZE manual ao excluir os índices. Essa funcionalidade está disponível na versão 12 e versões posteriores do PostgreSQL.
Ignorar os índices permitirá que você pule o processo de limpeza do índice inconsistente e mitigue o problema de conclusão. No entanto, isso não resolverá o problema subjacente da página inválida. Para abordar e resolver totalmente o problema da página inválida, ainda será necessário reconstruir o índice.
## Taxa de transação excepcionalmente alta
No PostgreSQL, altas taxas de transação podem afetar significativamente o desempenho do autovacuum, levando a uma limpeza mais lenta das tuplas inativas e ao aumento do risco de conclusão do ID da transação. É possível monitorar a taxa de transação medindo a diferença em `max(age(datfrozenxid))` entre dois períodos, normalmente por segundo. Além disso, é possível usar as métricas de contador do Insights de Performance do RDS a seguir para medir a taxa de transação (a soma de xact\$1commit e xact\$1rollback), que é o número total de transações.
| Contador | Type | Unidade | Métrica |
| --- | --- | --- | --- |
| xact\$1commit | Transações | Confirmações por segundo | db.Transactions.xact\$1commit |
| xact\$1rollback | Transações | Reversões por segundo | db.Transactions.xact\$1rollback |
Um aumento rápido indica uma alta carga de transações, que pode sobrecarregar o autovacuum, causando sobrecarga, contenção de bloqueios e possíveis problemas de desempenho. Isso pode impactar negativamente o processo de autovacuum de duas maneiras:
+ **Atividade da tabela:** a tabela específica que está sendo limpa pode estar passando por um alto volume de transações, causando atrasos.
+ **Recursos do sistema:** o sistema geral pode estar sobrecarregado, dificultando que o autovacuum acesse os recursos necessários para funcionar com eficiência.
Considere as seguintes estratégias para permitir que o autovacuum opere com mais eficiência e acompanhe suas tarefas:
1. Reduza a taxa de transação, se possível. Considere agrupar transações semelhantes sempre que possível.
1. Defina tabelas atualizadas com frequência com a operação `VACUUM FREEZE` manual noturna, semanal ou quinzenal durante horários de baixo movimento.
1. Considere aumentar a escala verticalmente da classe de instância para alocar mais recursos do sistema para lidar com o alto volume de transações e o autovacuum.
# Resolver problemas de desempenho de limpeza no RDS para PostgreSQL
Esta seção discute os fatores que geralmente contribuem para um desempenho mais lento de limpeza e como resolvê-los.
**Topics**
+ [
## Limpeza em índices grandes
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [
## Muitas tabelas ou bancos de dados para limpar
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [
## A limpeza agressiva (para evitar conclusão) está em execução
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Limpeza em índices grandes
O VACUUM opera em fases sequenciais: inicialização, verificação do heap, índice e limpeza do heap, limpeza de índices, truncamento de heap e limpeza final. Durante a verificação do heap, o processo remove, desfragmenta e congela páginas. Depois que o heap é verificado, o VACUUM limpa os índices, devolve páginas vazias ao sistema operacional e realiza tarefas finais de limpeza, como limpar o mapa de espaço livre e atualizar as estatísticas.
A limpeza de índice pode exigir várias passagens quando `maintenance_work_mem` (ou `autovacuum_work_mem`) é insuficiente para processar o índice. No PostgreSQL 16 e anterior, um limite de memória de 1 GB para armazenar IDs de tuplas mortas geralmente forçava várias passagens em índices grandes. O PostgreSQL 17 introduz o `TidStore`, que aloca memória dinamicamente em vez de usar uma matriz de alocação única. Isso remove a restrição de 1 GB, usa a memória com maior eficiência e reduz a necessidade de várias verificações para cada índice.
Índices grandes ainda podem exigir várias passagens no PostgreSQL 17 se a memória disponível não for suficiente para o processamento completo do índice de uma só vez. Normalmente, os índices maiores contêm mais tuplas mortas que exigem várias passagens.
**Detectar operações de limpeza lentas**
A função `postgres_get_av_diag()` pode detectar quando a execução de operações de limpeza está lenta devido a memória insuficiente. Para ter mais informações sobre essa função, consulte [Instalar ferramentas de monitoramento e diagnóstico de autovacuum no RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
A função `postgres_get_av_diag()` emite os avisos a seguir quando a memória disponível não é suficiente para concluir a limpeza do índice em uma única passagem.
**`rds_tools` 1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools` 1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**nota**
A função `postgres_get_av_diag()` depende do `pg_stat_all_tables.n_dead_tup` para estimar a quantidade de memória necessária para a limpeza do índice.
Quando a função `postgres_get_av_diag()` identificar uma operação de limpeza lenta que requer várias verificações do índice devido a `autovacuum_work_mem` insuficiente, ela gerará a seguinte mensagem:
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Orientação**
Você pode aplicar as soluções alternativas a seguir usando o `VACUUM FREEZE` manual para acelerar o congelamento da tabela.
**Aumentar a memória para limpeza**
Conforme sugerido pela função `postgres_get_av_diag()`, é recomendável aumentar o parâmetro `autovacuum_work_mem` para lidar com possíveis restrições de memória no nível da instância. Embora `autovacuum_work_mem` seja um parâmetro dinâmico, é importante observar que, para que a nova configuração de memória entre em vigor, o daemon autovacuum precisa reiniciar seus processos. Para fazer isso:
1. Confirme se a nova configuração está em vigor.
1. Encerre os processos que estão executando o autovacuum.
Essa abordagem garante que a alocação de memória ajustada seja aplicada às novas operações do autovacuum.
Para obter resultados mais imediatos, considere realizar manualmente uma operação `VACUUM FREEZE` com uma configuração `maintenance_work_mem` maior em sua sessão:
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Se você estiver usando o Amazon RDS e notar que precisa de memória adicional para oferecer suporte a valores mais altos para `maintenance_work_mem` ou `autovacuum_work_mem`, considere fazer upgrade para uma classe de instância com mais memória. Isso pode fornecer os recursos necessários para aprimorar as operações de limpeza manuais e automáticas, levando a um melhor desempenho geral da limpeza e do banco de dados.
**Desativar INDEX\$1CLEANUP**
O `VACUUM` manual no PostgreSQL versão 12 e posteriores permite pular a fase de limpeza do índice, enquanto o autovacuum de emergência no PostgreSQL versão 14 e posteriores faz isso automaticamente com base no parâmetro [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE).
**Atenção**
Pular a etapa de limpeza do índice pode causar inchaço no índice e afetar negativamente o desempenho da consulta. Para mitigar isso, considere reindexar ou fazer limpeza nos índices afetados durante uma janela de manutenção.
Para obter orientação adicional sobre como lidar com índices grandes, consulte a documentação em [Gerenciar o autovacuum com grandes índices](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Limpeza paralelo de índices**
Desde o PostgreSQL 13, os índices podem ser limpos em paralelo por padrão usando o `VACUUM` manual, com um processo de operação de limpeza atribuído a cada índice. No entanto, para que o PostgreSQL determine se uma operação de limpeza se qualifica para execução paralela, critérios específicos devem ser atendidos:
+ Deve haver pelo menos dois índices.
+ O parâmetro `max_parallel_maintenance_workers` deve ser definido como no mínimo 2.
+ O tamanho do índice deve exceder o limite `min_parallel_index_scan_size`, que por padrão é 512 KB.
É possível ajustar a configuração `max_parallel_maintenance_workers` com base no número de vCPUs disponíveis na sua instância do Amazon RDS e no número de índices na tabela para otimizar o tempo de resposta da limpeza.
Para obter mais informações, consulte [Parallel vacuuming in Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Muitas tabelas ou bancos de dados para limpar
Conforme mencionado na documentação [The Autovacuum Daemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') do PostgreSQL, o daemon autovacuum é executado por meio de vários processos. Isso inclui um inicializador persistente de autovacuum, responsável por iniciar os processos de trabalho de autovacuum para cada banco de dados do sistema. O inicializador programa esses trabalhadores para iniciarem aproximadamente a cada `autovacuum_naptime` segundos por banco de dados.
Com 'N' bancos de dados, um novo trabalhador começa aproximadamente a cada [`autovacuum_naptime`/N segundos]. No entanto, o número total de trabalhadores simultâneos é limitado pela configuração `autovacuum_max_workers`. Se o número de bancos de dados ou tabelas que precisam ser limpos exceder esse limite, o próximo banco de dados ou tabela será processado assim que um trabalhador estiver disponível.
Quando muitas tabelas ou bancos de dados grandes precisam ser limpos simultaneamente, todos os trabalhadores de autovacuum disponíveis podem ficar ocupados por um longo período, atrasando a manutenção em outras tabelas e bancos de dados. Em ambientes com altas taxas de transação, esse gargalo pode aumentar rapidamente e potencialmente levar a problemas de conclusão de limpeza em sua instância do Amazon RDS.
Quando o `postgres_get_av_diag()` detecta um grande número de tabelas ou bancos de dados, ele fornece a seguinte recomendação:
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Orientação**
**Aumentar autovacuum\$1max\$1workers**
Para agilizar a limpeza, recomendamos ajustar o parâmetro `autovacuum_max_workers` para permitir mais trabalhadores simultâneos de autovacuum. Se os gargalos de desempenho persistirem, considere aumentar a escala verticalmente de sua instância do Amazon RDS para uma classe com mais vCPUs, o que pode melhorar ainda mais as capacidades de processamento paralelo.
## A limpeza agressiva (para evitar conclusão) está em execução
A idade do banco de dados (MaximumUsedTransactionIDs) no PostgreSQL só diminui quando uma limpeza agressiva (para evitar conclusão) é concluída com sucesso. Até que essa limpeza termine, a idade continuará aumentando dependendo da taxa de transação.
A função `postgres_get_av_diag()` gera o seguinte `NOTICE` quando detecta uma limpeza agressiva. No entanto, ela só aciona essa saída depois que a limpeza estiver ativa por pelo menos dois minutos.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Consulte [When an aggressive vacuum is already running](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md) para obter mais informações sobre a limpeza agressiva.
Use a seguinte consulta para verificar se uma limpeza agressiva está em andamento:
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
É possível determinar se é uma limpeza agressiva (para evitar conclusão) verificando a coluna de consulta na saída. A frase "para evitar conclusão" indica que se trata de uma limpeza agressiva.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Por exemplo, suponha que você tenha um bloqueador com idade de transação de 1 bilhão e uma tabela exigindo uma limpeza agressiva para evitar conclusão na mesma idade da transação. Além disso, há outro bloqueador com idade de transação de 750 milhões. Depois de eliminar o bloqueador com idade de transação de 1 bilhão, a idade de transação não cairá imediatamente para 750 milhões. Ela permanecerá alta até que a tabela que precise da limpeza agressiva ou qualquer transação com idade superior a 750 milhões seja concluída. Durante esse período, a idade das transações do cluster do PostgreSQL continuará aumentando. Quando o processo de limpeza for concluído, a idade da transação cairá para 750 milhões, mas começará a aumentar novamente até que a limpeza adicional seja concluída. Esse ciclo continuará enquanto essas condições persistirem, até que a idade da transação caia para o nível configurado na instância do Amazon RDS, especificado por `autovacuum_freeze_max_age`.
# Explicação das mensagens de AVISO no RDS para PostgreSQL
A função `postgres_get_av_diag()` fornece as seguintes mensagens de AVISO:
**Quando a idade ainda não atingiu o limite de monitoramento**
O limite de monitoramento de `postgres_get_av_diag()` para identificar bloqueadores é de 500 milhões de transações por padrão. Se `postgres_get_av_diag()` gerar o seguinte AVISO, isso indica que a idade da transação ainda não atingiu esse limite.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**Não conectado ao banco de dados com o ID de transação mais antigo**
A função `postgres_get_av_diag()` fornece a saída mais precisa quando conectada ao banco de dados com a idade de ID de transação mais antiga. O banco de dados com a idade de ID de transação mais antiga informada por `postgres_get_av_diag()` será diferente de “my\$1database” no seu caso. Se você não estiver conectado ao banco de dados correto, o seguinte AVISO será gerado:
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Conectar-se ao banco de dados com a idade de transação mais antiga é importante pelos seguintes motivos:
+ **Identificação de bloqueadores de tabelas temporárias:** como os metadados das tabelas temporárias são específicos de cada banco de dados, eles geralmente são encontrados no banco de dados em que foram criados. No entanto, se uma tabela temporária for o principal bloqueador e residir no banco de dados com a transação mais antiga, isso pode ser enganoso. A conexão com o banco de dados correto garante a identificação precisa do bloqueador de tabelas temporárias.
+ **Diagnóstico de vacuums lentos:** os metadados do índice e as informações de contagem de tabelas são específicos do banco de dados e necessários para diagnosticar problemas de vacuum lento.
**O banco de dados com a transação mais antiga por idade está em um banco de dados rdsadmin ou template0**
Em alguns casos, os bancos de dados `rdsadmin` ou `template0` podem ser identificados como o banco de dados com a idade de ID de transação mais antiga. Se isso acontecer, `postgres_get_av_diag()` emitirá o seguinte AVISO:
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Verifique se o bloqueador listado não é originário de nenhum desses dois bancos de dados. Se for relatado que o bloqueador está presente em `rdsadmin` ou `template0`, entre em contato com o suporte, pois esses bancos de dados não são acessíveis ao usuário e exigem intervenção.
É altamente improvável que o banco de dados `rdsadmin` ou `template0` contenha um bloqueador principal.
**Quando um vacuum agressivo já está em execução**
A função `postgres_get_av_diag()` foi projetada para relatar quando um processo de vacuum agressivo está em execução, mas ela só vai acionar essa saída depois que o vacuum estiver ativo por pelo menos 1 minuto. Esse atraso intencional ajuda a reduzir as chances de falsos positivos. Ao esperar, a função garante que somente vacuums efetivos e significativos sejam relatados, levando a um monitoramento mais preciso e confiável da atividade do vacuum.
A função `postgres_get_av_diag()` gera o seguinte AVISO quando detecta um ou mais vacuums agressivos em andamento.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Conforme indicado no AVISO, continue monitorando o desempenho do vacuum. Para obter mais informações sobre o vacuum agressivo, consulte [A limpeza agressiva (para evitar conclusão) está em execução](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Quando o autovacuum está desativado**
A função `postgres_get_av_diag()` vai gerar o seguinte AVISO se o autovacuum estiver desativado na instância de banco de dados:
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
O autovacuum é um recurso essencial da instância de banco de dados do RDS para PostgreSQL que garante uma operação tranquila do banco de dados. Ele remove automaticamente as versões antigas das linhas, recupera espaço de armazenamento e evita o inchaço das tabelas, ajudando a manter as tabelas e os índices eficientes para um desempenho ideal. Além disso, ele protege contra o wraparound de ID de transação, que pode interromper transações na instância do Amazon RDS. A desativação do autovacuum pode levar a quedas de longo prazo no desempenho e na estabilidade do banco de dados. Sugerimos que você o mantenha ativado sempre. Para ter mais informações, consulte [Understanding autovacuum in RDS for PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/).
O desligamento do autovacuum não impede os vacuums agressivos. Estes ainda ocorrerão quando as tabelas atingirem o limite de `autovacuum_freeze_max_age`.
**O número de transações restantes é criticamente baixo**
A função `postgres_get_av_diag()` gera o seguinte AVISO quando um vacuum wraparound é iminente. Este AVISO é emitido quando a instância do Amazon RDS está a 100 milhões de transações de possivelmente rejeitar novas transações.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Sua ação imediata é necessária para evitar tempo de inatividade do banco de dados. Você deve monitorar de perto suas operações de vacuum e considerar iniciar manualmente um `VACUUM FREEZE` no banco de dados afetado para evitar falhas nas transações.
# Gerenciar contagens altas de objeto no Amazon RDS para PostgreSQL
Embora as limitações do PostgreSQL sejam teóricas, ter contagens de objetos extremamente altas em um banco de dados causará um impacto perceptível no desempenho de várias operações. Esta documentação aborda vários tipos comuns de objeto que podem causar vários impactos possíveis quando a contagem total é alta.
A seguinte tabela apresenta um resumo dos tipos de objeto e dos possíveis impactos.
**Tipos de objeto e possíveis impactos**
| Tipo de objeto | Autovacuum | Replicação lógica | Atualização de versão principal | pg\$1dump/pg\$1restore | Desempenho geral | Reinicialização da instância |
| --- | --- | --- | --- | --- | --- | --- |
| [Relações](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [Tabelas temporárias](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Tabelas não registradas](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Partições](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [Arquivos temporários](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Sequências](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Objetos grandes](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Relações
Não há um limite rígido específico em relação ao número de tabelas em um banco de dados PostgreSQL. O limite teórico é extremamente alto, mas há outros limites práticos que precisam ser considerados na fase de design do banco de dados.
**Impacto: atraso do autovacuum**
O autovacuum pode ter dificuldade de acompanhar o aumento de IDs de transação ou o inchaço de tabela devido à falta de operadores em comparação à quantidade de trabalho.
**Ação recomendada:** há vários fatores que permitem ajustar o autovacuum para acompanhar adequadamente determinado número de tabelas e determinada workload. Consulte [Práticas recomendadas para trabalhar com o autovacuum do PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) para ver sugestões sobre como determinar as configurações apropriadas do autovacuum. Use o [utilitário postgres\$1get\$1av\$1diag utility](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html) para monitorar problemas de aumento de IDs de transação.
**Impacto: atualização da versão principal/pg\$1dump e pg\$1restore**
O Amazon RDS usa a opção “--link” durante a execução do pg\$1upgrade para evitar a necessidade de fazer cópias dos arquivos de dados. Os metadados do esquema ainda assim precisam ser restaurados na nova versão do banco de dados. Mesmo com o pg\$1restore paralelo, se houver um número significativo de relações, isso aumentará o tempo de inatividade.
**Impacto: degradação geral do desempenho**
Degradação geral do desempenho devido ao tamanho do catálogo. Cada tabela e as colunas correspondentes aumentarão as tabelas `pg_attribute`, `pg_class` e `pg_depend` que são frequentemente usadas em operações normais de banco de dados. Não haverá um evento de espera específico visível, mas a eficiência do buffer compartilhado será afetada.
**Ação recomendada:** verifique regularmente o inchaço dessas tabelas específicas e, ocasionalmente, execute `VACUUM FULL` nessas tabelas. Lembre-se de que `VACUUM FULL` nas tabelas de catálogo exigem um bloqueio `ACCESS EXCLUSIVE`, o que significa que nenhuma outra consulta poderá acessá-las enquanto a operação não for concluída.
**Impacto: esgotamento do descritor de arquivo**
Error: “out of file descriptors: Too many open files in system; release and retry”. O parâmetro `max_files_per_process` do PostgreSQL determina quantos arquivos cada processo pode abrir. Se houver um grande número de conexões unindo um grande número de tabelas, esse limite provavelmente será atingido.
**Ação recomendada:**
+ Reduzir o valor do parâmetro `max_files_per_process` pode ajudar a mitigar esse erro. Cada processo e subprocesso (por exemplo, consulta paralela) pode abrir essa quantidade de arquivos e, se as consultas estiverem unindo várias tabelas, esse limite provavelmente se esgotará.
+ Reduza o número de conexões e use um agrupador de conexões, como o [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) ou outras soluções, como o PgBouncer. Para saber mais, consulte o site do [PgBouncer](https://www.pgbouncer.org/).
**Impacto: esgotamento de inodes**
Error: “No space left on device”. Se isso for observado quando houver bastante espaço livre de armazenamento, a causa é a falta de inodes. O [Monitoramento aprimorado do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) oferece visibilidade sobre os inodes em uso e o número máximo disponível para o host.
**Limite aproximado:** [milhões](#PostgreSQL.HighObjectCount.Note).
## Tabelas temporárias
O uso de tabelas temporárias, que é útil para dados de teste ou resultados intermediários, é um padrão comum visto em muitos mecanismos de banco de dados. É necessário entender as implicações do uso intenso no PostgreSQL para evitar algumas das armadilhas. Cada tabela temporária criada e descartada adicionará linhas às tabelas de catálogo do sistema, o que causará problemas gerais de desempenho quando essas tabelas ficarem inchadas.
**Impacto: atraso do autovacuum**
As tabelas temporárias não são limpas pelo autovacuum. Elas ficarão atreladas aos IDs de transação enquanto existirem e poderão provocar wraparound se não forem removidas.
**Ação recomendada:** manter as tabelas temporárias durante a sessão que as criou ou eliminá-las manualmente. Evitar transações de longa duração com tabelas temporárias é uma prática recomendada que impedirá que essas tabelas contribuam para o aumento máximo de IDs de transação usados.
**Impacto: degradação geral do desempenho**
Degradação geral do desempenho devido ao tamanho do catálogo. Quando as sessões criam e eliminam continuamente tabelas temporárias, elas aumentam as tabelas `pg_attribute`, `pg_class` e `pg_depend` tabelas que são frequentemente usadas em operações normais de banco de dados. Não haverá um evento de espera específico visível, mas a eficiência do buffer compartilhado será afetada.
**Ação recomendada:**
+ Verifique regularmente o inchaço dessas tabelas específicas e, ocasionalmente, execute `VACUUM FULL` nessas tabelas. Lembre-se de que `VACUUM FULL` nas tabelas de catálogo exigem um bloqueio `ACCESS EXCLUSIVE`, o que significa que nenhuma outra consulta poderá acessá-las enquanto a operação não for concluída.
+ Se forem usadas muitas tabelas temporárias, é altamente recomendável executar `VACUUM FULL` nessas tabelas de catálogo específicas antes de uma atualização de versão principal para reduzir o tempo de inatividade.
**Práticas recomendadas gerais:**
+ Reduza o uso de tabelas temporárias utilizando expressões de tabela comuns para produzir resultados intermediários. Às vezes, isso pode complicar as consultas necessárias, mas eliminará os impactos listados acima.
+ Reutilize as tabelas temporárias usando o comando `TRUNCATE` para limpar o conteúdo em vez de executar as etapas de descartar/criar. Isso também eliminará o problema de aumento de IDs de transação provocado por tabelas temporárias.
**Limite aproximado:** [dezenas de milhares](#PostgreSQL.HighObjectCount.Note).
## Tabelas não registradas
Tabelas não registradas em log podem oferecer ganhos de desempenho, pois não geram nenhuma informação de registro em log com gravação antecipada (WAL). Visto que elas não oferecerão durabilidade durante a recuperação de falhas no banco de dados porque estarão truncadas, é necessário usá-las com cautela. Essa é uma operação cara no PostgreSQL, pois cada tabela não registrada e log é truncada em série. Embora essa operação seja rápida para um pequeno número de tabelas não registradas em log, quando o número atinge a casa de milhares, isso pode começar a causar um atraso notável durante a inicialização.
**Impacto: replicação lógica**
As tabelas não registradas em log geralmente não são incluídas na replicação lógica, inclusive em [implantações azuis/verde](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html), porque a replicação lógica depende do WAL para capturar e transferir alterações.
**Impacto: tempo de inatividade prolongado durante a recuperação**
Durante qualquer estado do banco de dados que envolva recuperação de falhas no banco de dados, como reinicialização multi-AZ com failover, recuperação para um ponto no tempo do Amazon RDS e atualização da versão principal do Amazon RDS, ocorrerá a operação serializada de truncamento das tabelas não registradas em log. Isso pode levar a uma experiência de tempo de inatividade bem maior do que o esperado.
**Ação recomendada:**
+ Minimize o uso de tabelas não registradas em log somente para dados que possam ser perdidos durante as operações de recuperação de falhas no banco de dados.
+ Minimize o uso de tabelas não registradas em log, pois o comportamento atual de truncamento em série pode aumentar significativamente o tempo de inicialização de um banco de dados.
**Práticas recomendadas gerais:**
+ As tabelas não registradas em log não são à prova de falhas. Iniciar uma recuperação para um ponto no tempo, o que envolve recuperação de falhas, leva um tempo significativo no PostgreSQL porque esse é um processo em série que trunca cada tabela.
**Limite aproximado:** [milhares](#PostgreSQL.HighObjectCount.Note).
## Partições
O particionamento pode aumentar o desempenho da consulta e oferecer uma organização lógica dos dados. Em cenários ideais, o particionamento é organizado para que a remoção de partições possa ser usada durante o planejamento e a execução da consulta. Usar muitas partições pode provocar impactos negativos no desempenho das consultas e na manutenção do banco de dados. A escolha de como particionar uma tabela deve ser feita com cuidado, pois o desempenho do planejamento e da execução da consulta pode ser afetado negativamente por um design ineficiente. Consulte a [documentação do PostgreSQL](https://www.postgresql.org/docs/current/ddl-partitioning.html) para obter detalhes sobre particionamento.
**Impacto: degradação geral do desempenho**
Algumas vezes os custos indiretos do tempo de planejamento aumentarão e a explicação dos planos referentes às consultas se tornarão mais complexa, dificultando a identificação de oportunidades de ajuste. Em versões do PostgreSQL anteriores à 18, muitas partições com alta workload podem provocar esperas `LWLock:LockManager`.
**Ação recomendada:** determine um número mínimo de partições que permita concluir a organização dos dados e, ao mesmo tempo, oferecer uma execução de consulta eficiente.
**Impacto: manutenção complexa**
Um número muito alto de partições provocará dificuldades de manutenção, como predefinição e remoção. O autovacuum tratará as partições como relações normais e deverá realizar uma limpeza regular, exigindo, portanto, operadores suficientes para concluir a tarefa.
**Ação recomendada:**
+ Predefina as partições para que a workload não seja bloqueada quando uma nova partição for necessária (por exemplo, partições mensais) e partições antigas forem removidas.
+ Garanta que haja operadores de autovacuum suficientes para realizar a manutenção de limpeza normal de todas as partições.
**Limite aproximado:**: [centenas](#PostgreSQL.HighObjectCount.Note).
## Arquivos temporários
Diferentemente das tabelas temporárias mencionadas acima, o PostgreSQL cria arquivos temporários na eventualidade de uma consulta complexa executar várias operações de classificação ou de hash simultaneamente e de cada uma dessas operações utilizar a memória da instância para armazenar resultados até o valor especificado no parâmetro `work_mem`. Quando a memória da instância não é suficiente, arquivos temporários são criados para armazenar os resultados. Consulte [Gerenciar arquivos temporários](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) para obter mais detalhes sobre arquivos temporários. Se a workload gerar um grande número desses arquivos, poderá haver vários impactos.
**Impacto: esgotamento do descritor de arquivo**
Error: “out of file descriptors: Too many open files in system; release and retry”. O parâmetro `max_files_per_process` do PostgreSQL determina quantos arquivos cada processo pode abrir. Se houver um grande número de conexões unindo um grande número de tabelas, esse limite provavelmente será atingido.
**Ação recomendada:**
+ Reduzir o valor do parâmetro `max_files_per_process` pode ajudar a mitigar esse erro. Cada processo e subprocesso (por exemplo, consulta paralela) pode abrir essa quantidade de arquivos e, se as consultas estiverem unindo várias tabelas, esse limite provavelmente se esgotará.
+ Reduza o número de conexões e use um agrupador de conexões, como o [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html), ou outras soluções, como o PgBouncer. Para saber mais, consulte o site do [PgBouncer](https://www.pgbouncer.org/).
**Impacto: esgotamento de inodes**
Error: “No space left on device”. Se isso for observado quando houver bastante espaço livre de armazenamento, a causa é a falta de inodes. O [Monitoramento aprimorado do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) oferece visibilidade sobre os inodes em uso e o número máximo disponível para o host.
**Práticas recomendadas gerais:**
+ Monitore o uso de arquivos temporários com o [Insights de Performance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
+ Ajuste as consultas que estão gerando arquivos temporários significativos para ver se é possível reduzir o número total de arquivos temporários.
**Limite aproximado:** [milhares](#PostgreSQL.HighObjectCount.Note).
## Sequências
As sequências são o objeto subjacente usado para acrescentar colunas automaticamente no PostgreSQL e oferecem exclusividade e uma chave para os dados. Elas podem ser usadas em tabelas individuais sem problemas durante operações normais, exceto na replicação lógica.
No momento, no PostgreSQL, a replicação lógica não replica o valor atual de uma sequência para nenhum assinante. Para saber mais, consulte a página [Restrictions na documentação do PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Impacto: tempo de transição estendido**
Se você planeja usar [implantações azuis/verdes do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) para qualquer tipo de alteração ou atualização de configuração, é importante entender o impacto de ter um grande número de sequências na transição. Uma das fases finais da transição sincronizará o valor atual das sequências e, se houver vários milhares, isso aumentará o tempo geral de transição.
**Ação recomendada:** se a workload do banco de dados permitir o uso de um UUID compartilhado em vez de uma abordagem de sequência por tabela, isso poderá reduzir a etapa de sincronização durante a transição.
**Limite aproximado:** [milhares](#PostgreSQL.HighObjectCount.Note).
## Objetos grandes
Objetos grandes são armazenados em uma única tabela do sistema chamada pg\$1largeobject. Cada objeto grande também tem uma entrada na tabela do sistema pg\$1largeobject\$1metadata. O processo de criação, modificação e limpeza desses objetos é bem diferente do utilizado nas relações padrão. Os objetos grandes não são processados pelo autovacuum e devem ser limpos periodicamente por meio de um processo separado, chamado vacuumlo. Consulte “Gerenciar objetos grandes com o módulo lo” para ver exemplos sobre como gerenciar objetos grandes.
**Impacto: replicação lógica**
No momento, não é possível replicar objetos grandes no PostgreSQL durante a replicação lógica. Para saber mais, consulte a página [Restrictions na documentação do PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). Em uma configuração [azul/verde](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html), isso significa que objetos grandes no ambiente azul não são replicados no ambiente verde.
**Impacto: atualização de versão principal**
Uma atualização poderá ficar sem memória e falhar se houver milhões de objetos grandes, e a instância não puder manipulá-los durante uma atualização. O processo de atualização da versão principal do PostgreSQL compreende duas fases amplas: despejar o esquema via pg\$1dump e restaurá-lo por meio de pg\$1restore. Se seu banco de dados tiver milhões de objetos grandes, você precisará garantir que sua instância tenha memória suficiente para lidar com o pg\$1dump e o pg\$1restore durante uma atualização e escalá-la para um tipo de instância maior.
**Práticas recomendadas gerais:**
+ Use regularmente o utilitário vacuumlo para remover qualquer objeto grande órfão que você possa ter.
+ Considere a possibilidade de usar o tipo de dados BYTEA para armazenar objetos grandes no banco de dados.
**Limite aproximado:** [milhões](#PostgreSQL.HighObjectCount.Note).
## Limites aproximados
Os limites aproximados mencionados neste tópico são usados somente para oferecer uma estimativa de até que ponto determinado recurso pode ser escalado. Eles representam o âmbito geral em que os impactos descritos se tornam mais prováveis, mas o comportamento real depende de fatores específicos, como workload, tamanho da instância e configuração. Embora seja possível exceder essas estimativas, é necessário seguir as operações de cuidado e manutenção para evitar os impactos listados.
# Gerenciar a contenção de TOAST OID no Amazon RDS para PostgreSQL
TOAST (The Oversized-Attribute Storage Technique) é um recurso do PostgreSQL projetado para lidar com grandes valores de dados que excedem o tamanho normal de blocos de banco de dados de 8 KB. O PostgreSQL não permite que linhas físicas abranjam vários blocos. O tamanho do bloco atua como um limite superior no tamanho da linha. O TOAST supera essa restrição dividindo grandes valores de campo em partes menores. Ele os armazena separadamente em uma tabela TOAST dedicada vinculada à tabela principal. Para acessar mais informações, consulte a [documentação de implementação e mecanismo de armazenamento TOAST do PostgreSQL](https://www.postgresql.org/docs/current/storage-toast.html).
**Topics**
+ [
## Noções básicas sobre operações TOAST
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [
## Identificar problemas de performance
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [
## Recomendações
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [
## Monitoramento
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## Noções básicas sobre operações TOAST
O TOAST executa a compactação e armazena grandes valores de campo fora da linha. O recurso atribui um OID (Identificador de Objeto) exclusivo a cada bloco de dados superdimensionados armazenado na tabela TOAST. A tabela principal armazena o ID do valor TOAST e o ID da relação na página para fazer referência à linha correspondente na tabela TOAST. Isso permite que o PostgreSQL localize e gerencie com eficiência esses fragmentos do TOAST. No entanto, à medida que a tabela TOAST cresce, o sistema corre o risco de esgotar os OIDs disponíveis, causando a degradação da performance e um possível tempo de inatividade devido ao esgotamento do OID.
### Identificadores de objetos no TOAST
Identificador de Objeto (OID) é um identificador exclusivo em todo o sistema usado pelo PostgreSQL para fazer referência a objetos de banco de dados, como tabelas, índices e funções. Esses identificadores desempenham um papel essencial nas operações internas do PostgreSQL, permitindo que o banco de dados localize e gerencie objetos com eficiência.
Para tabelas com conjuntos de dados elegíveis para toasting, o PostgreSQL atribui OIDs para identificar exclusivamente cada fragmento de dado excedente armazenado na tabela TOAST associada. O sistema associa cada fragmento a um `chunk_id`, o que ajuda o PostgreSQL a organizar e localizar esses fragmentos de forma eficiente na tabela TOAST.
## Identificar problemas de performance
O gerenciamento de OID do PostgreSQL depende de um contador global de 32 bits para que ele funcione depois de gerar 4 bilhões de valores exclusivos. Embora o cluster de banco de dados compartilhe esse contador, a alocação de OID envolve duas etapas durante as operações TOAST:
+ **Contador global para alocação**: o contador global atribui um novo OID em todo o cluster.
+ **Pesquisa local de conflitos**: a tabela TOAST garante que o novo OID não entre em conflito com os OIDs existentes já usados nessa tabela específica.
A degradação da performance pode ocorrer quando:
+ A tabela TOAST tem alta fragmentação ou uso denso de OID, causando atrasos na atribuição do OID.
+ O sistema frequentemente aloca e reutiliza OIDs em ambientes com alta rotatividade de dados ou tabelas amplas que usam o TOAST extensivamente.
Para acessar mais informações, consulte a [documentação de alocação de OID e limites de tamanho de tabelas TOAST do PostgreSQL](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit):
Um contador global gera os OIDs e envolve cada 4 bilhões de valores, para que, periodicamente, o sistema gere novamente um valor já usado. O PostgreSQL detecta isso e tenta novamente com o próximo OID. Um INSERT lento poderá ocorrer se houver uma série muito longa de valores de OID usados sem lacunas na tabela TOAST. Esses desafios se tornam mais pronunciados à medida que o espaço do OID é preenchido, causando inserções e atualizações mais lentas.
### Identificar o problema
+ Declarações `INSERT` simples demoram muito mais do que o normal de maneira inconsistente e aleatória.
+ Atrasos ocorrem somente para declarações `INSERT` e `UPDATE` envolvendo operações TOAST.
+ As seguintes entradas de log aparecem nos logs do PostgreSQL quando o sistema tem dificuldade para encontrar OIDs disponíveis nas tabelas TOAST:
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ O Insights de Performance indica um alto número médio de sessões ativas (AAS) associadas a eventos de espera `LWLock:buffer_io` e `LWLock:OidGenLock`.
Você pode executar a seguinte consulta SQL para identificar transações INSERT de longa duração com eventos de espera:
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Exemplos de resultado de consulta exibindo operações INSERT com tempos de espera estendidos:
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Isolar o problema
+ **Testar a inserção pequena**: insira um registro menor que o limite `toast_tuple_target`. Lembre-se de que a compactação é aplicada antes do armazenamento TOAST. Se isso funcionar sem problemas de performance, o problema está relacionado às operações TOAST.
+ **Testar nova tabela**: crie uma tabela com a mesma estrutura e insira um registro maior que `toast_tuple_target`. Se isso funcionar sem problemas, o problema estará localizado na alocação de OID da tabela original.
## Recomendações
As abordagens a seguir podem ajudar a resolver problemas de contenção do TOAST OID.
+ **Limpeza e arquivamento de dados**: analise e exclua quaisquer dados obsoletos ou desnecessários para liberar OIDs para uso futuro ou arquivar os dados. Considere as seguintes limitações:
+ Escalabilidade limitada, pois a limpeza futura nem sempre é possível.
+ Possível operação VACUUM de longa duração para remover as tuplas inativas resultantes.
+ **Gravar em uma nova tabela**: crie uma tabela para futuras inserções e use uma visualização `UNION ALL` para combinar dados antigos e novos para consultas. Essa visualização apresenta os dados combinados das tabelas antigas e novas, permitindo que as consultas os acessem como uma única tabela. Considere as seguintes limitações:
+ As atualizações na tabela antiga ainda podem causar o esgotamento de OIDs.
+ **Partição ou fragmento**: particione a tabela ou fragmente os dados para ter melhor escalabilidade e performance. Considere as seguintes limitações:
+ Maior complexidade na lógica de consulta e na manutenção, possível necessidade de alterações na aplicação para lidar corretamente com dados particionados.
## Monitoramento
### Usar tabelas do sistema
Você pode usar as tabelas do sistema do PostgreSQL para monitorar o crescimento do uso de OIDs.
**Atenção**
Dependendo do número de OIDs na tabela TOAST, pode levar algum tempo para ser concluído. Recomendamos que você agende o monitoramento fora do horário comercial para minimizar o impacto.
O bloco anônimo a seguir conta o número de OIDs distintos usados em cada tabela TOAST e exibe as informações da tabela principal:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Exemplo de saída exibindo estatísticas de uso de OIDs pela tabela TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
O bloco anônimo a seguir recupera o OID máximo atribuído para cada tabela TOAST não vazia:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Exemplo de saída exibindo o máximo de IDs de blocos para tabelas TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Usar o Performance Insights
Os eventos de espera `LWLock:buffer_io` e `LWLock:OidGenLock` aparecem no Insights de Performance durante operações que exigem a atribuição de novos identificadores de objetos (OIDs). As sessões ativas de alta média (AAS) para esses eventos geralmente apontam para contenção durante a atribuição de OIDs e o gerenciamento de recursos. Isso é particularmente comum em ambientes com alta rotatividade de dados, uso extensivo de grandes volumes de dados ou criação frequente de objetos.
#### LWLock:buffer\$1io
`LWLock:buffer_io` é um evento de espera que ocorre quando uma sessão do PostgreSQL aguarda a conclusão das operações de E/S em um buffer compartilhado. Isso geralmente acontece quando o banco de dados lê dados do disco para a memória ou grava páginas modificadas da memória para o disco. O evento de espera `BufferIO` garante a consistência ao impedir que vários processos acessem ou modifiquem o mesmo buffer enquanto as operações de E/S estão em andamento. Altas ocorrências desse evento de espera podem indicar gargalos no disco ou atividade excessiva de E/S na workload do banco de dados.
Durante as operações TOAST:
+ O PostgreSQL aloca OIDs para objetos grandes e garante sua exclusividade examinando o índice da tabela TOAST.
+ Índices TOAST grandes podem exigir o acesso a várias páginas para verificar a exclusividade do OID. Isso gera aumento de E/S de disco, principalmente quando o grupo de buffers não consegue armazenar em cache todas as páginas necessárias.
O tamanho do índice afeta diretamente o número de páginas de buffer que precisam ser acessadas durante essas operações. Mesmo que o índice não esteja inchado, seu tamanho pode aumentar a E/S do buffer, principalmente em ambientes de alta simultaneidade ou alta rotatividade. Para acessar mais informações, consulte o [Guia de solução de problemas com o evento de espera LWLock:BufferIO](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html).
#### LWLock:OidGenLock
`OidGenLock` é um evento de espera que ocorre quando uma sessão do PostgreSQL está aguardando para alocar um novo identificador de objeto (OID). Esse bloqueio garante que os OIDs sejam gerados sequencialmente e com segurança, permitindo que somente um processo gere OIDs por vez.
Durante as operações TOAST:
+ **Alocação de OID para blocos na tabela TOAST**: o PostgreSQL atribui OIDs a blocos nas tabelas TOAST ao gerenciar grandes registros de dados. Cada OID deve ser exclusivo para evitar conflitos no catálogo do sistema.
+ **Alta simultaneidade**: como o acesso ao gerador de OIDs é sequencial, quando várias sessões estão criando simultaneamente objetos que exigem OIDs, pode ocorrer contenção para `OidGenLock`. Isso aumenta a probabilidade de sessões esperando a conclusão da alocação de OIDs.
+ **Dependência do acesso ao catálogo do sistema**: a alocação de OIDs requer atualizações nas tabelas compartilhadas do catálogo do sistema, como `pg_class` e `pg_type`. Se essas tabelas apresentarem muita atividade (devido às operações frequentes de DDL), isso poderá aumentar a contenção de bloqueio para `OidGenLock`.
+ **Alta demanda de alocação de OIDs**: workloads intensas envolvendo TOAST com grandes registros de dados exigem alocação constante de OIDs, aumentando a contenção.
Fatores adicionais que aumentam a contenção de OIDs:
+ **Criação frequente de objetos**: workloads trabalho que frequentemente criam e descartam objetos, como tabelas temporárias, amplificam a contenção no contador global de OIDs.
+ **Bloqueio global do contador**: o contador global de OIDs é acessado em série para garantir a exclusividade, criando um único ponto de contenção em ambientes de alta simultaneidade.
## Trabalhar com os mecanismos de registro em log compatíveis com o RDS para PostgreSQL
Existem vários parâmetros, extensões e outros itens configuráveis que você pode definir para registrar em log as atividades que ocorrem na sua instância de banco de dados PostgreSQL. Incluindo o seguinte:
+ O parâmetro `log_statement` pode ser usado para registrar as atividades dos usuários no seu banco de dados PostgreSQL. Para saber mais sobre o registro em log do RDS para PostgreSQL e como monitorar os logs, consulte [Arquivos de log do banco de dados RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
+ O parâmetro `rds.force_admin_logging_level` registra na instância de banco de dados as ações do usuário interno do Amazon RDS (rdsadmin) nos bancos de dados. Ele grava a saída no log de erros do PostgreSQL. Os valores permitidos são `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, log,`fatal` e `panic`. O valor padrão é `disabled`.
+ O parâmetro `rds.force_autovacuum_logging_level` pode ser definido para capturar várias operações de autovacuum no log de erros do PostgreSQL. Para ter mais informações, consulte[Registrar atividades do autovacuum e do vacuum em log](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ A extensão do PostgreSQL Audit (pgAudit) pode ser instalada e configurada para capturar atividades no nível da sessão ou no nível do objeto. Para ter mais informações, consulte[Usar pgAudit para registrar a atividade do banco de dados](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ A extensão `log_fdw` possibilita que você acesse o log do mecanismo de banco de dados usando SQL. Para ter mais informações, consulte [Usar a extensão log\$1fdw para acessar o log de banco de dados usando SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
+ A biblioteca `pg_stat_statements` é especificada como padrão para o parâmetro `shared_preload_libraries` no RDS para PostgreSQL versão 10 e posteriores. É essa biblioteca que você pode usar para analisar consultas em execução. Certifique-se de que `pg_stat_statements` esteja definido no grupo de parâmetros de banco de dados. Para ter mais informações sobre o monitoramento da instância de banco de dados do RDS para PostgreSQL usando as informações fornecidas por essa biblioteca, consulte [Estatísticas SQL do RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ O parâmetro `log_hostname` captura no log o nome do host de cada conexão do cliente. Para RDS para PostgreSQL versão 12 e versões superiores, esse parâmetro é definido como `off` por padrão. Se você ativá-lo, monitore os tempos de conexão da sessão. Quando ativado, o serviço usa a solicitação de pesquisa reversa do sistema de Nomes de Domínio (DNS) para obter o nome do host do cliente que está fazendo a conexão e adicioná-lo ao log do PostgreSQL. Isso tem um impacto perceptível durante a conexão da sessão. Recomendamos que você ative esse parâmetro apenas para solução de problemas.
Em termos gerais, o objetivo do registro em log é possibilitar que o DBA monitore, ajuste a performance e solucione problemas. Muitos dos logs são carregados automaticamente no Amazon CloudWatch ou no Performance Insights. Aqui, eles são classificados e agrupados para fornecer métricas completas para sua instância de banco de dados. Para saber mais sobre o monitoramento e as métricas do Amazon RDS, consulte [Métricas de monitoramento em uma instância do Amazon RDS](CHAP_Monitoring.md).
# Gerenciar arquivos temporários com o PostgreSQL
No PostgreSQL, uma consulta complexa pode executar algumas operações de classificação ou de hash simultaneamente, com cada uma utilizando a memória da instância para armazenar resultados até o valor especificado no parâmetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Quando a memória da instância não é suficiente, arquivos temporários são criados para armazenar os resultados. Eles são gravados em disco para concluir a execução da consulta. Posteriormente, esses arquivos são removidos automaticamente após a conclusão da consulta. No RDS para PostgreSQL, esses arquivos são armazenados no Amazon EBS no volume de dados. Para obter mais informações, consulte Armazenamento de instâncias de banco de dados do Amazon RDS. Você pode monitorar a métrica `FreeStorageSpace` publicada no CloudWatch para garantir que a instância de banco de dados tenha espaço de armazenamento livre suficiente. Para obter mais informações, consulte [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm)
Recomendamos o uso de instâncias do Amazon RDS com otimização de memória para workloads com várias consultas simultâneas que aumentam o uso de arquivos temporários. Essas instâncias usam o armazenamento ao nível do bloco de unidade de estado sólido (SSD) local baseado em memória expressa não volátil (NVMe) para guardar os arquivos temporários. Para obter mais informações, consulte [Melhorar a performance das consultas para o RDS para PostgreSQL com leituras otimizadas pelo Amazon RDS](USER_PostgreSQL.optimizedreads.md).
Você pode usar os parâmetros e as funções a seguir para gerenciar os arquivos temporários em sua instância.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – esse parâmetro cancela qualquer consulta que exceda o tamanho de temp\$1files em KB. Esse limite impede que qualquer consulta seja executada indefinidamente e consuma espaço em disco com arquivos temporários. Você pode estimar o valor utilizando os resultados do parâmetro `log_temp_files`. Como prática recomendada, examine o comportamento da workload e defina o limite de acordo com a estimativa. O exemplo a seguir mostra como uma consulta é cancelada quando ela excede o limite.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – esse parâmetro envia mensagens ao postgresql.log quando os arquivos temporários de uma sessão são removidos. Esse parâmetro produz logs após a conclusão bem-sucedida de uma consulta. Portanto, isso pode não ajudar na solução de problemas de consultas ativas e de longa duração.
O exemplo a seguir mostra que, quando a consulta é concluída com êxito, as entradas são registradas no arquivo postgresql.log enquanto os arquivos temporários são limpos.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – essa função que está disponível no RDS para PostgreSQL 13 e versões posteriores oferece visibilidade sobre o uso atual de arquivos temporários. A consulta concluída não aparece nos resultados da função. No exemplo a seguir, você pode visualizar os resultados dessa função.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
O nome do arquivo inclui o ID de processamento (PID) da sessão que gerou o arquivo temporário. Uma consulta mais avançada, como no exemplo a seguir, executa uma soma dos arquivos temporários para cada PID.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – se você ativar o parâmetro pg\$1stat\$1statements, poderá visualizar o uso médio de arquivos temporários por chamada. Você pode identificar o query\$1id da consulta e usá-lo para examinar o uso do arquivo temporário, conforme mostrado no exemplo a seguir.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`**: no painel do Performance Insights, você pode visualizar o uso temporário de arquivos ativando as métricas **temp\$1bytes** e **temp\$1files**. Depois, você pode ver a média dessas duas métricas e como elas correspondem à workload da consulta. A exibição no Performance Insights não mostra especificamente as consultas que estão gerando os arquivos temporários. No entanto, ao combinar o Performance Insights com a consulta mostrada para `pg_ls_tmpdir`, você pode solucionar problemas, analisar e determinar as alterações em sua workload de consulta.
Para ter mais informações sobre como analisar as métricas e as consultas com o Insights de Performance, consulte [Análise de métricas usando o painel do Performance Insights](USER_PerfInsights.UsingDashboard.md).
Para ver um exemplo de como visualizar o uso de arquivos temporários com o Insights de Performance, consulte [Visualizar o uso de arquivos temporários com o Insights de Performance](PostgreSQL.ManagingTempFiles.Example.md).
# Visualizar o uso de arquivos temporários com o Insights de Performance
É possível usar o Insights de Performance para visualizar o uso de arquivos temporários ativando as métricas **temp\$1bytes** e **temp\$1files**. A visualização no Insights de Performance não mostra as consultas específicas que geram arquivos temporários, no entanto, ao combinar o Insights de Performance com a consulta mostrada para `pg_ls_tmpdir`, é possível solucionar problemas, analisar e determinar as alterações na workload de consulta.
1. No painel do Performance Insights, selecione **Gerenciar métricas**.
1. Escolha **Métricas de banco de dados** e selecione as métricas **temp\$1bytes** e **temp\$1files** como mostrado na imagem a seguir.
![\[Métricas serão exibidos no grafo.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. Na guia **Top SQL**, selecione o ícone **Preferências**.
1. Na janela **Preferências**, ative as estatísticas a seguir para serem exibidas na guia **Top SQL** e selecione **Continuar**.
+ Gravações temporárias/segundo
+ Leituras de temperatura/segundo
+ Gravação/chamada em bloco temporário
+ Leitura/chamada em bloco temporário
1. O arquivo temporário é dividido quando combinado com a consulta mostrada para `pg_ls_tmpdir`, conforme exibido no exemplo a seguir.
![\[Consulta que exibe o uso de arquivos temporários.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Os eventos `IO:BufFileRead` e `IO:BufFileWrite` ocorrem porque as principais consultas na workload geralmente criam arquivos temporários. Você pode usar o Insights de Performance para identificar as principais consultas que aguardam `IO:BufFileRead` e `IO:BufFileWrite` revisando “Média de sessões ativas (AAS)” nas seções “Carga do banco de dados” e “SQL principal”.
![\[IO:BufFileRead e IO:BufFileWrite no grafo.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Para obter mais informações sobre como usar o Insights de Performance para analisar as principais consultas e a carga por eventos de espera, consulte [Visão geral da guia Top SQL (SQL principal)](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL) Você deve identificar e ajustar as consultas que aumentam o uso de arquivos temporários e os eventos de espera correspondentes. Para ter mais informações sobre esses eventos de espera e a correção, consulte, [IO:BufFileRead e IO:BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html).
**nota**
O parâmetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) controla quando a operação de classificação fica sem memória e os resultados são gravados em arquivos temporários. Recomendamos que você não altere a configuração desse parâmetro acima do valor padrão, pois isso permitiria que cada sessão do banco de dados consumisse mais memória. Além disso, uma única sessão que executa junções e classificações complexas pode realizar operações paralelas nas quais cada operação consome memória.
Como prática recomendada, quando você tem um relatório grande com várias junções e classificações, defina esse parâmetro no nível da sessão usando o comando `SET work_mem`. Depois, a alteração é aplicada somente à sessão atual e não altera o valor globalmente.
## Uso de pgBadger para análise de logs com o PostgreSQL
Você pode usar um analisador de log, como o [pgBadger](http://dalibo.github.io/pgbadger/), para analisar logs do PostgreSQL. A documentação do pgBadger indica que o padrão %l (linha de log da sessão ou do processo) deve ser uma parte do prefixo. Contudo, se você fornecer o `log_line_prefix` atual do RDS como um parâmetro para pgBadger, isso ainda produzirá um relatório.
Por exemplo, o comando a seguir formata corretamente um arquivo de log do Amazon RDS para PostgreSQL com data de 04/02/2014 usando pgBadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## Usar o PGSnapper para monitorar o PostgreSQL
Você pode usar o PGSnapper para auxiliar na coleta periódica de estatísticas e métricas relacionadas à performance do Amazon RDS para PostgreSQL. Para ter mais informações, consulte [Monitorar a performance do Amazon RDS para PostgreSQL usando o PGSnapper](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/).
# Gerenciar conversões personalizadas no RDS para PostgreSQL
No PostgreSQL, a **conversão de tipo** refere-se ao processo de conversão de um valor de um tipo de dados em outro. O PostgreSQL oferece conversões integradas para várias conversões comuns, mas também é possível criar conversões personalizadas para definir como as conversões de tipos específicos devem se comportar.
Um conversão especifica como realizar uma conversão de um tipo de dados em outro. Por exemplo, converter texto `'123'` em número inteiro `123` ou numérico `45.67` em texto `'45.67'`.
Para ter informações abrangentes sobre os conceitos e a sintaxe de conversão do PostgreSQL, consulte [CREATE CAST na documentação do PostgreSQL](https://www.postgresql.org/docs/current/sql-createcast.html).
A partir das versões do RDS para PostgreSQL 13.23, 14.20, 15.15, 16.11, 17.7 e 18.1, é possível usar a extensão rds\$1casts para instalar outras conversões para tipos integrados e, ao mesmo tempo, criar conversões próprias para tipos personalizados
**Topics**
+ [
## Instalar e usar a extensão rds\$1casts
](#PostgreSQL.CustomCasts.Installing)
+ [
## Conversões compatíveis
](#PostgreSQL.CustomCasts.Supported)
+ [
## Criar ou eliminar conversões
](#PostgreSQL.CustomCasts.Creating)
+ [
## Criar conversões personalizadas com a estratégia de contexto adequada
](#PostgreSQL.CustomCasts.BestPractices)
## Instalar e usar a extensão rds\$1casts
Para criar a extensão `rds_casts`, conecte-se à sua instância de banco de dados do RDS para PostgreSQL como um `rds_superuser` e execute o seguinte comando:
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Conversões compatíveis
Crie a extensão em cada banco de dados em que você deseja usar conversões personalizadas. Depois de criar a extensão, use o seguinte comando para visualizar todas as conversões disponíveis:
```
SELECT * FROM rds_casts.list_supported_casts();
```
Essa função lista as combinações de conversão disponíveis (tipo de origem, tipo de destino, contexto de coerção e função de conversão). Por exemplo, se você quiser criar uma conversão de `text` em `numeric` como uma conversão `implicit`. É possível usar a seguinte consulta para descobrir se a conversão está disponível para criação:
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
A extensão rds\$1casts oferece dois tipos de função de conversão para cada conversão:
+ *\$1inout functions*: usam o mecanismo de conversão de E/S padrão do PostgreSQL, comportando-se de forma idêntica às conversões criadas com o método INOUT.
+ *\$1custom functions*: oferecem lógica de conversão aprimorada que lida com casos extremos, como converter strings vazias em valores NULL para evitar erros de conversão
As funções `inout` replicam o comportamento de conversão nativo do PostgreSQL, enquanto as funções `custom` estendem essa funcionalidade, lidando com cenários que as conversões INOUT padrão não conseguem atender, como converter strings vazias em números inteiros.
## Criar ou eliminar conversões
É possível criar e eliminar conversões compatíveis usando dois métodos:
### Criação de conversão
**Método 1: usar o comando nativo CREATE CAST**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Método 2: usar a função rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
A função `create_cast` obtém o ID da saída `list_supported_casts()`. Esse método é mais simples e garante o uso da combinação correta de função e contexto. Esse ID com certeza permanecerá o mesmo em diferentes versões do Postgres.
Para verificar se a conversão foi criada com êxito, consulte o catálogo de sistema pg\$1cast:
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
A coluna `castcontext` mostra: `e` para EXPLICIT, `a` para ASSIGNMENT ou `i` para IMPLICIT.
### Eliminar conversões
**Método 1: usar o comando DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Método 2: usar a função rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
A função `drop_cast` usa o mesmo ID usado ao criar a conversão. Esse método garante a eliminação da conversão exata que foi criada com o ID correspondente.
## Criar conversões personalizadas com a estratégia de contexto adequada
Ao criar várias conversões para tipos inteiros, erros de ambiguidade de operador poderão ocorrer se todas as conversões forem criadas como IMPLICIT. O seguinte exemplo demonstra esse problema criando duas conversões implícitas de texto em números inteiros com largura diferente:
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
O erro ocorre porque o PostgreSQL não consegue determinar qual conversão implícita usar ao comparar uma coluna de inteiros com um valor de texto. As conversões implícitas int4 e int8 são ambas candidatas válidas, o que cria ambiguidade.
Para evitar essa ambiguidade de operador, use o contexto ASSIGNMENT para inteiros com largura menor e o contexto IMPLICIT para inteiros com largura maior:
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
Com essa estratégia, somente a conversão int8 é implícita, possibilitando que o PostgreSQL determine de forma inequívoca qual conversão usar.
# Práticas recomendadas para consultas paralelas no RDS para PostgreSQL
A execução de consultas paralelas é um recurso do PostgreSQL que permite que uma única consulta SQL seja dividida em tarefas menores que são realizadas simultaneamente por vários processos de operador em segundo plano. Em vez de executar uma consulta inteiramente em um único processo de backend, o PostgreSQL pode distribuir partes da consulta, como verificações, junções, agregações ou classificações, em vários núcleos de CPU. O *processo líder* coordena essa execução e reúne os resultados dos *operadores paralelos*.
No entanto, para a maioria das workloads de produção, especialmente sistemas de processamento de transações on-line (OLTP) com alta simultaneidade, recomendamos desabilitar a execução automática de consultas paralelas. Embora o paralelismo possa acelerar as consultas em grandes conjuntos de dados em workloads de analytics ou geração de relatórios, ele apresenta riscos significativos que geralmente superam os benefícios em ambientes de produção movimentados.
A execução paralela também gera custos indiretos significativos. Cada operador paralelo é um processo completo de backend no PostgreSQL, que requer bifurcação (cópia de estruturas de memória e inicialização do estado do processo) e autenticação de processos (consumo de slots de conexão do limite de `max_connections`). Cada operador também consome sua própria memória, inclusive `work_mem` para operações de classificação e hash. Quando há vários operadores por consulta, o uso da memória se multiplica rapidamente (p. ex., 4 operadores × 64 MB de `work_mem` = 256 MB por consulta). Por isso, as consultas paralelas podem consumir consideravelmente mais recursos do sistema do que as consultas de processo único. Se elas não forem ajustadas adequadamente, poderá haver saturação da CPU (vários operadores consomem a capacidade de processamento disponível), aumento da troca de contexto (o sistema operacional alterna frequentemente entre vários processos de operador, aumentando os custos indiretos e reduzindo o throughput) ou exaustão da conexão (visto que cada operador paralelo consome um slot de conexão, uma única consulta com quatro operadores usa cinco conexões no total, uma líder \$1 quatro operadores, o que pode esgotar rapidamente o grupo de conexões quando há alta simultaneidade, impedindo novas conexões de cliente e causando falhas na aplicação). Esses problemas são particularmente graves em workloads com alta simultaneidade, nas quais várias consultas podem tentar a execução paralela simultaneamente.
O PostgreSQL decide se deve usar o paralelismo com base em estimativas de custo. Em alguns casos, o planejador pode mudar automaticamente para um plano paralelo se isso parecer mais barato, mesmo quando não for o ideal na prática. Isso pode ocorrer se as estatísticas do índice estiverem desatualizadas ou se o inchaço fizer com que as verificações sequenciais pareçam mais atrativas do que as pesquisas de índice. Devido a esse comportamento, os planos paralelos automáticos às vezes podem provocar regressões no desempenho da consulta ou na estabilidade do sistema.
Para extrair o máximo benefício das consultas paralelas no RDS para PostgreSQL, é importante testá-las e ajustá-las com base na workload, monitorar o impacto sobre o sistema e desabilitar a seleção automática de planos paralelos em favor do controle em nível de consulta.
## Parâmetros de configuração
O PostgreSQL usa vários parâmetros para controlar o comportamento e a disponibilidade de consultas paralelas. Compreendê-los e ajustá-los é fundamental para alcançar um desempenho previsível:
| Parâmetro | Descrição | Padrão |
| --- | --- | --- |
| max\$1parallel\$1workers | Número máximo de processos de operador em segundo plano que podem ser executados no total. | GREATEST(\$1DBInstanceVCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Número máximo de operadores por nó do plano de consulta (p. ex., por Gather). | 2 |
| parallel\$1setup\$1cost | Custo adicional do planejador para iniciar a infraestrutura de consulta paralela. | 1.000 |
| parallel\$1tuple\$1cost | Custo por tupla processada em modo paralelo (afeta a decisão do planejador). | 0,1 |
| force\$1parallel\$1mode | Força o planejador a testar planos paralelos (off, on, regress). | off |
### Considerações importantes
+ `max_parallel_workers` controla o conjunto total de operadores paralelos. Se definido com um valor muito baixo, algumas consultas podem voltar à execução em série.
+ `max_parallel_workers_per_gather` determina quantos operadores uma única consulta pode usar. Um valor maior aumenta a simultaneidade, mas também o uso de recursos.
+ `parallel_setup_cost` e `parallel_tuple_cost` afetam o modelo de custo do planejador. Reduzi-los pode aumentar a probabilidade de os planos paralelos serem escolhidos.
+ `force_parallel_mode` é útil para testes, mas não deve ser usado na produção, a menos que necessário.
**nota**
O valor padrão do `max_parallel_workers` parâmetro é calculado dinamicamente com base no tamanho da instância usando a fórmula`GREATEST($DBInstanceVCPU/2, 8)`. Isso significa que quando você escalar a computação de uma instância de banco de dados para um tamanho maior com mais vCPUs, o número máximo de operadores paralelos disponíveis aumentará automaticamente. Por isso, consultas que antes eram executadas em série ou com paralelismo limitado podem utilizar mais operadores paralelos de maneira repentina após uma operação de aumento da escala vertical e possivelmente provocar aumentos inesperados no uso da conexão, na utilização da CPU e no consumo de memória. É importante monitorar o comportamento da consulta paralela após qualquer evento de ajuste de escala da computação e, se necessário, ajustar `max_parallel_workers_per_gather` para manter o uso previsível dos recursos.
## Identificar o uso de consultas paralelas
As consultas podem mudar para planos paralelos com base na distribuição de dados ou nas estatísticas. Por exemplo:
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Essa consulta pode usar um índice para dados recentes, mas mudar para uma verificação sequencial paralela de dados históricos.
É possível registrar em log os planos de execução de consultas carregando o módulo `auto_explain`. Para saber mais, consulte [Como registrar em log planos de execução de consultas](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) no Centro de Conhecimento da AWS.
É possível monitorar eventos de espera no [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) relacionados à consulta paralela. Para saber mais sobre eventos de espera relacionados à consulta paralela, consulte [IPC: eventos de espera paralelos](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html).
A partir da versão 18 do PostgreSQL, é possível monitorar a atividade de operadores paralelos usando novas colunas em [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW) e [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html):
+ `parallel_workers_to_launch`: número de operadores paralelos que se pretende iniciar.
+ `parallel_workers_launched`: número de operadores paralelos realmente iniciados.
Essas métricas ajudam a identificar discrepâncias entre o paralelismo planejado e real, o que pode indicar restrições de recursos ou problemas de configuração. Use as seguintes consultas para monitorar a execução paralela:
Para métricas de operadores paralelos em nível de banco de dados:
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Para métricas de operadores paralelos em nível de consulta:
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Como controlar o paralelismo
Há várias maneiras de controlar o paralelismo de consultas, cada uma projetada para diferentes cenários e requisitos.
Para desabilitar o paralelismo automático globalmente, [modifique seu grupo de parâmetros](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html) para definir:
```
max_parallel_workers_per_gather = 0;
```
Para configurações persistentes e específicas do usuário, o comando ALTER ROLE oferece uma maneira para definir parâmetros que se aplicarão a todas as sessões futuras de determinado usuário.
Por exemplo:
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;` garante que, toda vez que esse usuário se conectar ao banco de dados, as respectivas sessões usarão essa configuração de operador paralelo quando necessário.
O controle em nível de sessão pode ser obtido usando o comando SET, que modifica os parâmetros durante a sessão atual do banco de dados. Isso é particularmente útil quando é necessário ajustar temporariamente as configurações sem afetar outros usuários ou sessões futuras. Depois de definidos, esses parâmetros permanecem em vigor até serem redefinidos explicitamente ou até que a sessão termine. Os comandos são simples:
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Para ter um controle ainda mais granular, o SET LOCAL permite modificar os parâmetros de uma única transação. Isso é ideal quando é necessário ajustar as configurações de um conjunto específico de consultas em uma transação e, após isso, reverter automaticamente as configurações para os valores anteriores. Essa abordagem ajuda a evitar efeitos indesejados em outras operações na mesma sessão.
## Diagnosticar o comportamento das consultas paralelas
Use `EXPLAIN (ANALYZE, VERBOSE)` para confirmar se uma consulta usou execução paralela:
+ Procure nós como `Gather`, `Gather Merge` ou `Parallel Seq Scan`.
+ Compare os planos com e sem paralelismo.
Para desabilitar temporariamente o paralelismo para comparação:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Trabalhar com parâmetros na instância de banco de dados do RDS para PostgreSQL
Em alguns casos, você pode criar uma instância de banco de dados do RDS para PostgreSQL sem especificar um grupo de parâmetros personalizado. Se for o caso, sua instância de banco de dados será criada usando o grupo de parâmetros padrão para a versão do PostgreSQL que você escolher. Por exemplo, suponha que você crie uma instância de banco de dados do RDS para PostgreSQL usando o PostgreSQL 13.3. Nesse caso, a instância de banco de dados é criada usando os valores no grupo de parâmetros para versões do PostgreSQL 13, `default.postgres13`.
Você também pode criar seus próprios grupos de parâmetros de banco de dados personalizados. Você precisará fazer isso se quiser modificar qualquer configuração da instância de banco de dados do RDS para PostgreSQL de seus valores padrão. Para saber como, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Você pode rastrear as configurações em sua instância de banco de dados do RDS para PostgreSQL de várias maneiras diferentes. Você pode usar o Console de gerenciamento da AWS, a AWS CLI ou a API do Amazon RDS. Você também pode consultar os valores `pg_settings` da tabela PostgreSQL da instância, conforme mostrado a seguir.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Para saber mais sobre os valores retornados dessa consulta, consulte [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) na documentação do PostgreSQL.
Tenha cuidado especial ao alterar as configurações para `max_connections` e `shared_buffers` em sua instância de banco de dados do RDS para PostgreSQL. Por exemplo, suponha que você modifique as configurações de `max_connections` ou `shared_buffers` e use valores muito altos para sua workload real. Nesse caso, sua instância de banco de dados do RDS para PostgreSQL não será iniciada. Se isso acontecer, você verá o erro a seguir no `postgres.log`.
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
No entanto, não é possível alterar nenhum valor das configurações contidas nos grupos de parâmetros de banco de dados padrão do RDS para PostgreSQL. Para alterar as configurações de qualquer parâmetro, primeiro crie um grupo de parâmetros de banco de dados personalizado. Em seguida, altere as configurações nesse grupo personalizado e, em seguida, aplique o grupo de parâmetros personalizado à sua instância de banco de dados do RDS para PostgreSQL. Para saber mais, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Existem dois tipos de parâmetro no RDS para PostgreSQL.
+ **Parâmetros estáticos** – Os parâmetros estáticos exigem que a instância de banco de dados do RDS para PostgreSQL seja reinicializada após uma alteração para que o novo valor possa entrar em vigor.
+ **Parâmetros dinâmicos** – Parâmetros dinâmicos não exigem uma reinicialização após alterar suas configurações.
**nota**
Se sua instância de banco de dados do RDS para PostgreSQL estiver usando seu próprio grupo de parâmetros de banco de dados personalizado, você poderá alterar os valores de parâmetros dinâmicos na instância de banco de dados em execução. Isso pode ser feito usando o Console de gerenciamento da AWS, a AWS CLI ou a API do Amazon RDS.
Você também poderá alterar valores de parâmetros se tiver os privilégios de segurança necessários para isso usando os comandos `ALTER DATABASE`, `ALTER ROLE` e `SET`.
## Lista de parâmetros de instância de banco de dados do RDS para PostgreSQL
A tabela a seguir lista alguns dos parâmetros (mas nem todos) disponíveis em uma instância de banco de dados do RDS para PostgreSQL. Para visualizar todos os parâmetros disponíveis, use o comando [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) da AWS CLI. Por exemplo, para obter a lista de todos os parâmetros disponíveis no grupo de parâmetros padrão do RDS para PostgreSQL versão 13, execute o seguinte.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
Você também pode usar o console. Selecione **Parameter groups** (Grupos de parâmetros) no menu do Amazon RDS e depois selecione o grupo de parâmetros dentre os disponíveis em sua Região da AWS.
| Nome do parâmetro | Apply\$1Type | Descrição |
| --- | --- | --- |
| `application_name` | Dinâmico | Define o nome da aplicação a ser informada em estatísticas e logs. |
| `archive_command` | Dinâmico | Define o comando shell que será chamado para arquivar um arquivo WAL. |
| `array_nulls` | Dinâmico | Permite entrada de elementos NULL em arrays. |
| `authentication_timeout` | Dinâmico | Define o tempo máximo permitido para concluir a autenticação de cliente. |
| `autovacuum` | Dinâmico | Inicia o subprocesso de autovacuum. |
| `autovacuum_analyze_scale_factor` | Dinâmico | Número de inserções, atualizações ou exclusões de tuplas anteriores à análise, como uma fração de reltuplas. |
| `autovacuum_analyze_threshold` | Dinâmico | Número mínimo de inserções, atualizações ou exclusões de tuplas antes da análise. |
| `autovacuum_freeze_max_age` | Estático | Idade na qual o autovacuum de uma tabela deve ocorrer para evitar a conclusão do ID de transação. |
| `autovacuum_naptime` | Dinâmico | Tempo de suspensão entre execuções de autovacuum. |
| `autovacuum_max_workers` | Estático | Define o número máximo de processos de trabalho de autovacuum em execução simultaneamente. |
| `autovacuum_vacuum_cost_delay` | Dinâmico | Atraso de custo de vacuum, em milissegundos, para autovacuum. |
| `autovacuum_vacuum_cost_limit` | Dinâmico | Valor do custo de vacuum disponível antes da suspensão, para autovacuum. |
| `autovacuum_vacuum_scale_factor` | Dinâmico | Número de atualizações ou exclusões de tuplas antes de vacuum, como uma fração de reltuplas. |
| `autovacuum_vacuum_threshold` | Dinâmico | Número mínimo de atualizações ou exclusões de tuplas antes de vacuum. |
| `backslash_quote` | Dinâmico | Define-se uma barra invertida (\$1) é permitida em literais de string. |
| `bgwriter_delay` | Dinâmico | Tempo de suspensão do gravador em segundo plano entre rodadas. |
| `bgwriter_lru_maxpages` | Dinâmico | Número máximo do gravador em segundo plano de páginas LRU para descarregamento por rodada. |
| `bgwriter_lru_multiplier` | Dinâmico | Múltiplo do uso médio do buffer para liberação por rodada. |
| `bytea_output` | Dinâmico | Define o formato da saída para bytes. |
| `check_function_bodies` | Dinâmico | Verifica corpos de funções durante CREATE FUNCTION. |
| `checkpoint_completion_target` | Dinâmico | Tempo gasto descarregando buffers sujos durante verificações, como uma fração do intervalo de verificação. |
| `checkpoint_segments` | Dinâmico | Define a distância máxima em segmentos de log entre verificações pontos de verificação WAL (write-ahead log)de log WAL automáticos. |
| `checkpoint_timeout` | Dinâmico | Define o tempo máximo entre verificações WAL automáticas. |
| `checkpoint_warning` | Dinâmico | Permite avisos se segmentos de verificação forem preenchidos mais frequentemente do que isso. |
| `client_connection_check_interval` | Dinâmico | Define o intervalo de tempo entre as verificações de desconexão durante a execução de consultas. |
| `client_encoding` | Dinâmico | Define a codificação do conjunto de caracteres do cliente. |
| `client_min_messages` | Dinâmico | Define os níveis de mensagem enviados ao cliente. |
| `commit_delay` | Dinâmico | Define o atraso em microssegundos entre a confirmação da transação e a liberação do WAL no disco. |
| `commit_siblings` | Dinâmico | Define o mínimo de transações simultâneas abertas antes de realizar commit\$1delay. |
| `constraint_exclusion` | Dinâmico | Permite que o planejador use restrições para otimizar consultas. |
| `cpu_index_tuple_cost` | Dinâmico | Define a estimativa do planejador sobre o custo do processamento de cada entrada de índice durante uma verificação de índice. |
| `cpu_operator_cost` | Dinâmico | Define a estimativa do planejador sobre o custo do processamento de cada operador ou chamada de função. |
| `cpu_tuple_cost` | Dinâmico | Define a estimativa do planejador sobre o custo do processamento de cada tupla (linha). |
| `cursor_tuple_fraction` | Dinâmico | Define a estimativa do planejador sobre a fração de linhas de um cursor que serão recuperadas. |
| `datestyle` | Dinâmico | Define o formato de exibição de valores de data e hora. |
| `deadlock_timeout` | Dinâmico | Define o tempo de espera em um bloqueio antes de verificar a existência de um deadlock. |
| `debug_pretty_print` | Dinâmico | Recua exibições de árvores de análise e plano. |
| `debug_print_parse` | Dinâmico | Registra a árvore de análise de cada consulta. |
| `debug_print_plan` | Dinâmico | Registra o plano de execução de cada consulta. |
| `debug_print_rewritten` | Dinâmico | Registra a árvore de análise regravada de cada consulta. |
| `default_statistics_target` | Dinâmico | Define o destino de estatísticas padrão. |
| `default_tablespace` | Dinâmico | Define o espaço de tabela padrão no qual criar tabelas e índices. |
| `default_transaction_deferrable` | Dinâmico | Define o status padrão postergável de novas transações. |
| `default_transaction_isolation` | Dinâmico | Define o nível de isolamento de transação de cada nova transação. |
| `default_transaction_read_only` | Dinâmico | Define o status padrão somente leitura de novas transações. |
| `default_with_oids` | Dinâmico | Cria tabelas com “Object IDs” (OIDs – IDs de objetos) por padrão. |
| `effective_cache_size` | Dinâmico | Define a pressuposição do planejador sobre o tamanho do cache de disco. |
| `effective_io_concurrency` | Dinâmico | Número de solicitações simultâneas que podem ser manipuladas de forma eficiente pelo subsistema de disco. |
| `enable_bitmapscan` | Dinâmico | Permite o uso do planejador de planos de verificação de bitmap. |
| `enable_hashagg` | Dinâmico | Permite o uso do planejador de planos de agregação em hash. |
| `enable_hashjoin` | Dinâmico | Permite o uso do planejador de planos de junção hash. |
| `enable_indexscan` | Dinâmico | Permite o uso do planejador de planos de verificação de índice. |
| `enable_material` | Dinâmico | Permite o uso do planejador da materialização. |
| `enable_mergejoin` | Dinâmico | Permite o uso do planejador de planos de junção de mesclagem. |
| `enable_nestloop` | Dinâmico | Permite o uso do planejador de planos de junção de loop aninhado. |
| `enable_seqscan` | Dinâmico | Permite o uso do planejador de planos de verificação sequencial. |
| `enable_sort` | Dinâmico | Permite o uso do planejador de etapas de classificação explícitas. |
| `enable_tidscan` | Dinâmico | Permite o uso do planejador de planos de verificação TID. |
| `escape_string_warning` | Dinâmico | Avisa sobre escapes de barra invertida (\$1) em literais de string comuns. |
| `extra_float_digits` | Dinâmico | Define o número de dígitos exibidos para valores de ponto flutuante. |
| `from_collapse_limit` | Dinâmico | Define o tamanho da lista FROM além do qual subconsultas não são recolhidas. |
| `fsync` | Dinâmico | Força a sincronização de atualizações no disco. |
| `full_page_writes` | Dinâmico | Grava páginas cheias no WAL ao serem modificadas pela primeira vez após uma verificação. |
| `geqo` | Dinâmico | Permite a otimização de consultas genéticas. |
| `geqo_effort` | Dinâmico | GEQO: esforço é usado para definir o padrão para outros parâmetros GEQO. |
| `geqo_generations` | Dinâmico | GEQO: número de iterações do algoritmo. |
| `geqo_pool_size` | Dinâmico | GEQO: número de indivíduos na população. |
| `geqo_seed` | Dinâmico | GEQO: propagação para seleção de caminho aleatório. |
| `geqo_selection_bias` | Dinâmico | GEQO: pressão seletiva dentro da população. |
| `geqo_threshold` | Dinâmico | Define o limite de itens FROM além do qual o GEQO é usado. |
| `gin_fuzzy_search_limit` | Dinâmico | Define o resultado máximo permitido para pesquisa exata por GIN. |
| `hot_standby_feedback` | Dinâmico | Determina se um standby a quente envia mensagens de comentários ao standby principal ou upstream. |
| `intervalstyle` | Dinâmico | Define o formato de exibição para valores de intervalo. |
| `join_collapse_limit` | Dinâmico | Define o tamanho da lista FROM além do qual constructos JOIN não são nivelados. |
| `lc_messages` | Dinâmico | Define o idioma em que as mensagens são exibidas. |
| `lc_monetary` | Dinâmico | Define a localidade para a formatação de valores monetários. |
| `lc_numeric` | Dinâmico | Define a localidade para a formatação de números. |
| `lc_time` | Dinâmico | Define a localidade para a formatação de valores de data e hora. |
| `log_autovacuum_min_duration` | Dinâmico | Define o tempo de execução mínimo acima do qual as ações de autovacuum serão registradas em log. |
| `log_checkpoints` | Dinâmico | Registra cada verificação. |
| `log_connections` | Dinâmico | Registra cada conexão bem-sucedida. |
| `log_disconnections` | Dinâmico | Registra o fim de uma sessão, incluindo a duração. |
| `log_duration` | Dinâmico | Registra a duração de cada instrução SQL concluída. |
| `log_error_verbosity` | Dinâmico | Define a verbosidade das mensagens registradas. |
| `log_executor_stats` | Dinâmico | Grava estatísticas de performance do executor no log do servidor. |
| `log_filename` | Dinâmico | Define o padrão de nome de arquivo para arquivos de log. |
| `log_file_mode` | Dinâmico | Define as permissões de arquivos de log. O valor padrão é 0644. |
| `log_hostname` | Dinâmico | Registra o nome do host nos logs de conexão. A partir do PostgreSQL 12 e versões posteriores, esse parâmetro está “desativado” por padrão. Quando ativada, a conexão usa a pesquisa reversa de DNS para obter o nome do host que é capturado nos logs de conexão. Se você ativar esse parâmetro, deverá monitorar o impacto que ele tem no tempo necessário para estabelecer conexões. |
| `log_line_prefix ` | Dinâmico | Controla informações prefixadas para cada linha de log. |
| `log_lock_waits` | Dinâmico | Registra esperas de bloqueio longas. |
| `log_min_duration_statement` | Dinâmico | Define o tempo de execução mínimo acima do qual as instruções serão registradas em log. |
| `log_min_error_statement` | Dinâmico | Faz com que todas as instruções que geram um erro igual ou acima desse nível sejam registradas. |
| `log_min_messages` | Dinâmico | Define os níveis de mensagem registrados. |
| `log_parser_stats` | Dinâmico | Grava estatísticas de performance do analisador no log do servidor. |
| `log_planner_stats` | Dinâmico | Grava estatísticas de performance do planejador no log do servidor. |
| `log_rotation_age` | Dinâmico | A rotação automática de arquivos de log ocorrerá depois de N minutos. |
| `log_rotation_size` | Dinâmico | A rotação automática de arquivos de log ocorrerá depois de N kilobytes. |
| `log_statement` | Dinâmico | Define o tipo de instruções registradas. |
| `log_statement_stats` | Dinâmico | Grava estatísticas de performance cumulativas no log do servidor. |
| `log_temp_files` | Dinâmico | Registra o uso de arquivos temporários maiores do que esse número de kilobytes. |
| `log_timezone` | Dinâmico | Define o fuso horário a ser usado em mensagens de log. |
| `log_truncate_on_rotation` | Dinâmico | Trunca os arquivos de log existentes com o mesmo nome durante a alternância do log. |
| `logging_collector` | Estático | Inicia um subprocesso para capturar a saída stderr e/ou csvlogs em arquivos de log. |
| `maintenance_work_mem` | Dinâmico | Define a memória máxima a ser usada para operações de manutenção. |
| `max_connections` | Estático | Define o número máximo de conexões simultâneas. |
| `max_files_per_process` | Estático | Define o número máximo de arquivos abertos simultaneamente para cada processo do servidor. |
| `max_locks_per_transaction` | Estático | Define o número máximo de bloqueios por transação. |
| `max_pred_locks_per_transaction` | Estático | Define o número máximo de bloqueios de predicado por transação. |
| `max_prepared_transactions` | Estático | Define o número máximo de transações simultaneamente preparadas. |
| `max_stack_depth` | Dinâmico | Define a profundidade máxima da pilha, em kilobytes. |
| `max_standby_archive_delay` | Dinâmico | Define o atraso máximo antes de cancelar consultas quando um servidor em standby a quente está processando dados WAL arquivados. |
| `max_standby_streaming_delay` | Dinâmico | Define o atraso máximo antes de cancelar consultas quando um servidor em standby a quente está processando dados do WAL em stream. |
| max\$1wal\$1size | Dinâmico | Define o tamanho do WAL (MB) que aciona o ponto de verificação. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Use o seguinte comando na instância de banco de dados do Amazon RDS para PostgreSQL para ver o valor atual:
SHOW max_wal_size;
|
| min\$1wal\$1size | Dinâmico | Define o tamanho mínimo até o qual diminuir o WAL. Para o PostgreSQL versão 9.6 e anterior, min\$1wal\$1size está em unidades de 16 MB. Para o PostgreSQL versão 10 e posterior, min\$1wal\$1size está em unidades de 1 MB. |
| `quote_all_identifiers` | Dinâmico | Adiciona aspas (") a todos os identificadores ao gerar fragmentos SQL. |
| `random_page_cost` | Dinâmico | Define a estimativa do planejador sobre o custo de uma página de disco não sequencialmente buscada. Esse parâmetro não tem valor, a menos que o gerenciamento do plano de consulta (QPM) esteja ativado. Quando o QPM está ativado, o valor padrão desse parâmetro é 4. |
| rds.adaptive\$1autovacuum | Dinâmico | Ajusta automaticamente os parâmetros de autovacuum sempre que os limites de ID de transação são excedidos. |
| rds.force\$1ssl | Dinâmico | Requer o uso de conexões SSL. O valor padrão é definido como 1 (ligado) para o RDS para PostgreSQL versão 15. Todas as outras versões principais do RDS para PostgreSQL 14 e anteriores têm o valor padrão definido como 0 (desativado). |
| `rds.local_volume_spill_enabled` | Estático | Permite gravar arquivos de despejo lógico no volume local. |
| `rds.log_retention_period` | Dinâmico | Define a retenção de logs para que o Amazon RDS exclua os logs do PostgreSQL com mais de n minutos. |
| rds.rds\$1superuser\$1reserved\$1connections | Estático | Define o número de slots de conexão reservados para rds\$1superusers. Esse parâmetro só está disponível nas versões 15 e posterior. Para ter mais informações, consulte [reserved\$1connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS) na documentação do PostgreSQL. |
| `rds.replica_identity_full` | Dinâmico | Quando você define esse parâmetro como `on`, ele substitui a configuração de identidade da réplica por `FULL` em todas as tabelas do banco de dados. Isso significa que todos os valores das colunas são gravados no log de gravação antecipada (WAL), independentemente das configurações de `REPLICA IDENTITY FULL`. A ativação desse parâmetro pode aumentar as IOPS da instância de banco de dados devido ao registro em log adicional com gravação antecipada (WAL). |
| rds.restrict\$1password\$1commands | Estático | Restringe quem gerencia senhas para usuários com a função rds\$1password. Defina esse parâmetro como 1 para habilitar a restrição de senha. O padrão é 0. |
| `search_path` | Dinâmico | Define a ordem de pesquisa do esquema de nomes que não são qualificados para esquema. |
| `seq_page_cost` | Dinâmico | Define a estimativa do planejador sobre o custo de uma página de disco sequencialmente buscada. |
| `session_replication_role` | Dinâmico | Define o comportamento de sessões para disparadores e regras de regravação. |
| `shared_buffers` | Estático | Define o número de buffers de memória compartilhada usados pelo servidor. |
| `shared_preload_libraries ` | Estático | Lista as bibliotecas compartilhadas a serem pré-carregadas na instância de banco de dados do RDS para PostgreSQL. Os valores compatíveis incluem auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler e plrust. |
| `ssl` | Dinâmico | Habilita conexões SSL. |
| `sql_inheritance` | Dinâmico | Faz com que subtabelas sejam incluídas por padrão em vários comandos. |
| `ssl_renegotiation_limit` | Dinâmico | Define a quantidade de tráfego para envio e recebimento antes da renegociação das chaves de criptografia. |
| `standard_conforming_strings` | Dinâmico | Faz com que strings ... tratem barras invertidas literalmente. |
| `statement_timeout` | Dinâmico | Define a duração máxima permitida de qualquer instrução. |
| `synchronize_seqscans` | Dinâmico | Permite varreduras sequenciais sincronizadas. |
| `synchronous_commit` | Dinâmico | Define o nível de sincronização de transações atual. |
| `tcp_keepalives_count` | Dinâmico | Número máximo de retransmissões de keepalives TCP. |
| `tcp_keepalives_idle` | Dinâmico | Tempo entre a emissão de keepalives TCP. |
| `tcp_keepalives_interval` | Dinâmico | Tempo entre retransmissões de keepalives TCP. |
| `temp_buffers` | Dinâmico | Define o número máximo de buffers temporários usado por cada sessão. |
| temp\$1file\$1limit | Dinâmico | Define o tamanho máximo em KB até o qual os arquivos temporários podem aumentar. |
| `temp_tablespaces` | Dinâmico | Define os espaços de tabela a serem usados para tabelas temporárias e arquivos de classificação. |
| `timezone` | Dinâmico | Define o fuso horário para exibir e interpretar carimbos de data/hora. A Internet Assigned Numbers Authority (IANA) publica novos fusos horários várias vezes por ano em [https://www.iana.org/time-zones](https://www.iana.org/time-zones). Toda vez que o RDS lança uma nova versão de manutenção secundária do PostgreSQL, ela vem com os dados de fuso horário mais recentes no momento do lançamento. Quando você usa as versões mais recentes do RDS para PostgreSQL, você tem dados de fuso horário recentes do RDS. Para garantir que sua instância de banco de dados tenha dados de fuso horário recentes, recomendamos atualizar para uma versão superior do mecanismo de banco de dados. Não é possível modificar manualmente as tabelas de fuso horário nas instâncias de banco de dados PostgreSQL. O RDS não modifica nem redefine os dados de fuso horário das instâncias de banco de dados em execução. Os novos dados de fuso horário são instalados somente quando você executa uma atualização da versão do mecanismo de banco de dados. |
| `track_activities` | Dinâmico | Coleta informações sobre a execução de comandos. |
| `track_activity_query_size` | Estático | Define o tamanho reservado para pg\$1stat\$1activity.current\$1query, em bytes. |
| `track_counts` | Dinâmico | Coleta estatísticas sobre a atividade do banco de dados. |
| `track_functions` | Dinâmico | Coleta estatísticas em nível de função sobre a atividade do banco de dados. |
| `track_io_timing` | Dinâmico | Coleta estatísticas de tempo sobre atividades de E/S do banco de dados. |
| `transaction_deferrable` | Dinâmico | Indica se uma transação serializável somente de leitura deve ser adiada até que ela possa ser iniciada sem falhas de serialização possíveis. |
| `transaction_isolation` | Dinâmico | Define o nível atual de isolamento de transações. |
| `transaction_read_only` | Dinâmico | Define o status somente leitura das transações atuais. |
| `transform_null_equals` | Dinâmico | Trata expr=NULL como expr IS NULL. |
| `update_process_title` | Dinâmico | Atualiza o título do processo para mostrar o comando SQL ativo. |
| `vacuum_cost_delay` | Dinâmico | Atraso de custo de vacuum, em milissegundos. |
| `vacuum_cost_limit` | Dinâmico | Valor do custo de vacuum disponível antes da suspensão. |
| `vacuum_cost_page_dirty` | Dinâmico | Custo de vacuum para uma página suja por vacuum. |
| `vacuum_cost_page_hit` | Dinâmico | Custo de vacuum para uma página encontrada no cache do buffer. |
| `vacuum_cost_page_miss` | Dinâmico | Custo de vacuum para uma página não encontrada no cache do buffer. |
| `vacuum_defer_cleanup_age` | Dinâmico | Número de transações pelas quais a limpeza vacuum e hot deve ser adiada, se houver. |
| `vacuum_freeze_min_age` | Dinâmico | Idade mínima na qual o vacuum deve congelar uma linha de tabela. |
| `vacuum_freeze_table_age` | Dinâmico | Idade na qual o vacuum deve varrer uma tabela inteira para congelar tuplas. |
| `wal_buffers` | Estático | Define o número de buffers da página de disco na memória compartilhada para WAL. |
| `wal_writer_delay` | Dinâmico | Tempo de suspensão do gravador WAL entre liberações do WAL. |
| `work_mem` | Dinâmico | Define o máximo de memória a ser usado para espaços de trabalho de consulta. |
| `xmlbinary` | Dinâmico | Define como valores binários devem ser codificados em XML. |
| `xmloption` | Dinâmico | Define se dados XML em operações de análise e serialização implícitas são considerados documentos ou fragmentos de conteúdo. |
O Amazon RDS usa as unidades padrão do PostgreSQL para todos os parâmetros. A tabela a seguir mostra a unidade padrão de cada parâmetro do PostgreSQL.
| Nome do parâmetro | Unidade |
| --- | --- |
| `archive_timeout` | s |
| `authentication_timeout` | s |
| `autovacuum_naptime` | s |
| `autovacuum_vacuum_cost_delay` | ms |
| `bgwriter_delay` | ms |
| `checkpoint_timeout` | s |
| `checkpoint_warning` | s |
| `deadlock_timeout` | ms |
| `effective_cache_size` | 8 KB |
| `lock_timeout` | ms |
| `log_autovacuum_min_duration` | ms |
| `log_min_duration_statement` | ms |
| `log_rotation_age` | minutos |
| `log_rotation_size` | KB |
| `log_temp_files` | KB |
| `maintenance_work_mem` | KB |
| `max_stack_depth` | KB |
| `max_standby_archive_delay` | ms |
| `max_standby_streaming_delay` | ms |
| `post_auth_delay` | s |
| `pre_auth_delay` | s |
| `segment_size` | 8 KB |
| `shared_buffers` | 8 KB |
| `statement_timeout` | ms |
| `ssl_renegotiation_limit` | KB |
| `tcp_keepalives_idle` | s |
| `tcp_keepalives_interval` | s |
| `temp_file_limit` | KB |
| `work_mem` | KB |
| `temp_buffers` | 8 KB |
| `vacuum_cost_delay` | ms |
| `wal_buffers` | 8 KB |
| `wal_receiver_timeout` | ms |
| `wal_segment_size` | B |
| `wal_sender_timeout` | ms |
| `wal_writer_delay` | ms |
| `wal_receiver_status_interval` | s |
# Ajustar com eventos de espera do RDS para PostgreSQL
Eventos de espera são uma ferramenta de ajuste importante do RDS para PostgreSQL. Se você puder descobrir por que as sessões estão aguardando recursos e o que elas estão fazendo, poderá reduzir melhor os gargalos. Use as informações nesta seção para encontrar possíveis causas e ações corretivas. Esta seção também aborda conceitos básicos de ajuste do PostgreSQL.
Os eventos de espera nesta seção são específicos do RDS para PostgreSQL.
**Topics**
+ [
# Conceitos essenciais para o ajuste do RDS para PostgreSQL
](PostgreSQL.Tuning.concepts.md)
+ [
# Eventos de espera do RDS para PostgreSQL
](PostgreSQL.Tuning.concepts.summary.md)
+ [
# Client:ClientRead
](wait-event.clientread.md)
+ [
# Client:ClientWrite
](wait-event.clientwrite.md)
+ [
# CPU
](wait-event.cpu.md)
+ [
# IO:BufFileRead and IO:BufFileWrite
](wait-event.iobuffile.md)
+ [
# IO:DataFileRead
](wait-event.iodatafileread.md)
+ [
# IO:WALWrite
](wait-event.iowalwrite.md)
+ [
# IPC: eventos de espera paralelos
](rpg-ipc-parallel.md)
+ [
# IPC:ProcArrayGroupUpdate
](apg-rpg-ipcprocarraygroup.md)
+ [
# Lock:advisory
](wait-event.lockadvisory.md)
+ [
# Lock:extend
](wait-event.lockextend.md)
+ [
# Lock:Relation
](wait-event.lockrelation.md)
+ [
# Lock:transactionid
](wait-event.locktransactionid.md)
+ [
# Lock:tuple
](wait-event.locktuple.md)
+ [
# LWLock:BufferMapping (LWLock:buffer\$1mapping)
](wait-event.lwl-buffer-mapping.md)
+ [
# LWLock:BufferIO (IPC:BufferIO)
](wait-event.lwlockbufferio.md)
+ [
# LWLock:buffer\$1content (BufferContent)
](wait-event.lwlockbuffercontent.md)
+ [
# LWLock:lock\$1manager (LWLock:lockmanager)
](wait-event.lw-lock-manager.md)
+ [
# LWLock:pg\$1stat\$1statements
](apg-rpg-lwlockpgstat.md)
+ [
# LWLock:SubtransSLRU (LWLock:SubtransControlLock)
](wait-event.lwlocksubtransslru.md)
+ [
# Tempo limite:PgSleep
](wait-event.timeoutpgsleep.md)
+ [
# Timeout:VacuumDelay
](wait-event.timeoutvacuumdelay.md)
# Conceitos essenciais para o ajuste do RDS para PostgreSQL
Antes de ajustar seu banco de dados do RDS para PostgreSQL, aprenda o que são eventos de espera e por que eles ocorrem. Reveja também a arquitetura básica de memória e disco do RDS para PostgreSQL. Para obter um diagrama de arquitetura útil, consulte o wikibook [PostgreSQL](https://en.wikibooks.org/wiki/PostgreSQL/Architecture).
**Topics**
+ [
# Eventos de espera do RDS para PostgreSQL
](PostgreSQL.Tuning.concepts.waits.md)
+ [
# Memória do RDS para PostgreSQL
](PostgreSQL.Tuning.concepts.memory.md)
+ [
# Processo do RDS para PostgreSQL
](PostgreSQL.Tuning.concepts.processes.md)
# Eventos de espera do RDS para PostgreSQL
Um *evento de espera* é uma indicação de que a sessão está aguardando um recurso. Por exemplo, o evento de espera `Client:ClientRead` ocorre quando o RDS para PostgreSQL está aguardando para receber dados do cliente. Normalmente, as sessões aguardam por recursos como os seguintes.
+ Acesso com thread único a um buffer, por exemplo, quando uma sessão está tentando modificar um buffer
+ Uma linha que está bloqueada por outra sessão
+ Uma leitura de arquivo de dados
+ Uma gravação em arquivo de log
Por exemplo, para satisfazer uma consulta, a sessão pode realizar uma varredura de tabela completa. Se esses dados ainda não estiverem na memória, a sessão aguardará a conclusão da E/S do disco. Quando os buffers são lidos na memória, talvez a sessão precise aguardar, pois outras sessões estão acessando os mesmos buffers. O banco de dados registra as esperas utilizando um evento de espera predefinido. Esses eventos estão agrupados em categorias.
Por si só, um único evento de espera não indica um problema de performance. Por exemplo, se os dados solicitados não estão na memória, é necessário ler dados do disco. Se uma sessão bloquear uma linha para uma atualização, outra sessão aguardará que essa linha seja desbloqueada para poder atualizá-la. Uma confirmação exige a conclusão da gravação em um arquivo de log. Esperas são componentes integrais do funcionamento normal de um banco de dados.
Por outro lado, uma série de eventos de espera geralmente mostra um problema de performance. Nesses casos, é possível utilizar os dados dos eventos de espera para determinar onde as sessões estão perdendo tempo. Por exemplo, se um relatório que é normalmente executado em minutos agora demora várias horas, é possível identificar os eventos de espera que mais contribuem para o tempo de espera total. Se você puder determinar as causas dos principais eventos de espera, às vezes pode aplicar alterações que melhoram a performance. Por exemplo, se a sua sessão está aguardando uma linha que foi bloqueada por outra sessão, é possível encerrar a sessão responsável pelo bloqueio.
# Memória do RDS para PostgreSQL
A memória do RDS para PostgreSQL está dividida em compartilhada e local.
**Topics**
+ [
## Memória compartilhada no RDS para PostgreSQL
](#PostgreSQL.Tuning.concepts.shared)
+ [
## Memória local no RDS para PostgreSQL
](#PostgreSQL.Tuning.concepts.local)
## Memória compartilhada no RDS para PostgreSQL
O RDS para PostgreSQL aloca memória compartilhada quando a instância é iniciada. A memória compartilhada está dividida em várias subáreas. As seções a seguir fornecem descrições das mais importantes.
**Topics**
+ [
### Buffers compartilhados
](#PostgreSQL.Tuning.concepts.buffer-pool)
+ [
### Buffers de log de gravação antecipada (WAL)
](#PostgreSQL.Tuning.concepts.WAL)
### Buffers compartilhados
O *grupo de buffer compartilhado* é uma área de memória do RDS para PostgreSQL que contém todas as páginas que estão ou estavam sendo utilizadas por conexões de aplicações. Uma *página* é a versão de memória de um bloco de disco. O grupo de buffer compartilhado armazena em cache os blocos de dados lidos do disco. O grupo reduz a necessidade de reler dados do disco, fazendo com que o banco de dados opere de maneira mais eficiente.
Cada tabela e índice são armazenados como uma matriz de páginas com tamanho fixo. Cada bloco contém várias tuplas, que correspondem a linhas. Uma tupla pode ser armazenada em qualquer página.
O grupo de buffer compartilhado possui memória finita. Se uma nova solicitação exigir uma página que não esteja na memória e não houver mais memória, o RDS para PostgreSQL removerá uma página utilizada com menos frequência para acomodar essa solicitação. A política de despejo é implementada por um algoritmo de varredura de relógio.
O parâmetro `shared_buffers` determina a quantidade de memória que o servidor dedica ao armazenamento em cache de dados. O valor padrão é definido como `{DBInstanceClassMemory/32768}` bytes, com base na memória disponível para a instância de banco de dados.
### Buffers de log de gravação antecipada (WAL)
Um *buffer de log de gravação antecipada (WAL)* mantém dados de transação que o RDS para PostgreSQL grava posteriormente no armazenamento persistente. Utilizando o mecanismo WAL, o RDS para PostgreSQL pode fazer o seguinte:
+ Recupere dados após uma falha
+ Reduzir a E/S de disco, evitando gravações frequentes em disco
Quando um cliente altera dados, o RDS para PostgreSQL grava as alterações no buffer de WAL. Quando o cliente emite um `COMMIT`, o processo gravador WAL grava dados de transação no arquivo de WAL.
O parâmetro `wal_level` determina quantas informações são gravadas no WAL, com valores possíveis como `minimal`, `replica` e `logical`.
## Memória local no RDS para PostgreSQL
Todo processo de backend aloca memória local para processamento de consultas.
**Topics**
+ [
### Área de memória de trabalho
](#PostgreSQL.Tuning.concepts.local.work_mem)
+ [
### Área de memória de trabalho para manutenção
](#PostgreSQL.Tuning.concepts.local.maintenance_work_mem)
+ [
### Área de buffer temporária
](#PostgreSQL.Tuning.concepts.temp)
### Área de memória de trabalho
A *área de memória de trabalho*contém dados temporários para consultas que executam classificações e hashes. Por exemplo, uma consulta com uma cláusula `ORDER BY` executa uma classificação. Consultas usam tabelas de hash em agregações e junções de hash.
O parâmetro `work_mem` é a quantidade de memória a ser utilizada por operações de classificação internas e tabelas de hash antes da gravação em arquivos de disco temporários, o que é medido em megabytes. O valor padrão é 4 MB. Várias sessões podem ser executadas simultaneamente, e cada uma pode executar operações de manutenção em paralelo. Por esse motivo, a memória de trabalho total utilizada pode ser múltiplos da configuração `work_mem`.
### Área de memória de trabalho para manutenção
A *área de memória de trabalho para manutenção* armazena dados em cache para operações de manutenção. Essas operações incluem aspiração, criação de índices e adição de chaves externas.
O parâmetro `maintenance_work_mem` especifica a quantidade máxima de memória a ser utilizada por operações de manutenção, o que é medido em megabytes. O valor padrão é 64 MB. Uma sessão de banco de dados apenas pode executar uma operação de manutenção de cada vez.
### Área de buffer temporária
A *área de buffer temporária* armazena tabelas temporárias em cache para cada sessão de banco de dados.
Cada sessão aloca buffers temporários conforme necessário até o limite especificado. Quando a sessão termina, o servidor limpa os buffers.
O parâmetro `temp_buffers` define o número máximo de buffers temporários utilizados por cada sessão, o que é medido em megabytes. O valor padrão é de 8 MB. Antes do primeiro uso de tabelas temporárias em uma sessão, é possível alterar o valor de `temp_buffers`.
# Processo do RDS para PostgreSQL
O RDS para PostgreSQL utiliza vários processos.
**Topics**
+ [
## Processo Postmaster
](#PostgreSQL.Tuning.concepts.postmaster)
+ [
## Processos de backend
](#PostgreSQL.Tuning.concepts.backend)
+ [
## Processos em segundo plano
](#PostgreSQL.Tuning.concepts.vacuum)
## Processo Postmaster
O *processo de postmaster* é o primeiro a ser iniciado quando você inicia o RDS para PostgreSQL. Ele tem as seguintes responsabilidades principais:
+ Bifurcar e monitorar processos em segundo plano
+ Receba solicitações de autenticação dos processos do cliente e autentique-as antes de permitir que o banco de dados atenda às solicitações
## Processos de backend
Se o postmaster autenticar uma solicitação de cliente, o postmaster bifurcará um novo processo de backend, também chamado de processo postgres. Um processo de cliente conecta-se exatamente a um processo de backend. O processo de cliente e o processo de backend se comunicam diretamente sem a intervenção do processo postmaster.
## Processos em segundo plano
O processo postmaster bifurca vários processos que realizam diferentes tarefas de backend. Alguns dos mais importantes incluem:
+ Gravador WAL
O RDS para PostgreSQL grava dados no buffer de WAL (gravação antecipada) nos arquivos de log. O princípio do registro em log de gravação antecipada determina que o banco de dados não pode gravar alterações nos arquivos de dados até que o banco de dados grave registros de log descrevendo essas alterações no disco. O mecanismo WAL reduz a E/S do disco e permite que o RDS para PostgreSQL utilize os logs para recuperar o banco de dados após uma falha.
+ Gravador em segundo plano
Esse processo grava periodicamente páginas sujas (modificadas) dos buffers de memória nos arquivos de dados. Uma página fica suja quando um processo de backend a modifica na memória.
+ Daemon autovacuum
O daemon consiste no seguinte:
+ O launcher de autovacuum
+ Os processos de operador de autovacuum
Quando o autovacuum está ativado, ele procura tabelas que tiveram um grande número de tuplas inseridas, atualizadas ou excluídas. Esse daemon tem as seguintes responsabilidades:
+ Recuperar ou reutilizar o espaço em disco ocupado por linhas atualizadas ou excluídas
+ Atualizar estatísticas utilizadas pelo planejador
+ Proteger contra a perda de dados antigos devido à recorrência de IDs de transação
O recurso e autovacuum automatiza a execução de comandos `VACUUM` e `ANALYZE`. `VACUUM` tem as seguintes variantes: padrão e completo. O vacuum padrão é executado em paralelo com outras operações de banco de dados. `VACUUM FULL` requer um bloqueio exclusivo na tabela em que está trabalhando. Portanto, ele não pode ser executado em paralelo com operações que acessam a mesma tabela. `VACUUM` cria uma quantidade substancial de tráfego de E/S, podendo piorar a performance para outras sessões ativas.
# Eventos de espera do RDS para PostgreSQL
A tabela a seguir lista os eventos de espera do RDS para PostgreSQL que indicam mais comumente problemas de performance e resume as causas e as medidas corretivas mais comuns.
| Eventos de espera | Definição |
| --- | --- |
| [Client:ClientRead](wait-event.clientread.md) | Esse evento ocorre quando o RDS para PostgreSQL está aguardando para receber dados do cliente. |
| [Client:ClientWrite](wait-event.clientwrite.md) | Esse evento ocorre quando o RDS para PostgreSQL está aguardando para gravar dados no cliente. |
| [CPU](wait-event.cpu.md) | Ocorre quando um thread está ativo na CPU ou está aguardando a CPU. |
| [IO:BufFileRead and IO:BufFileWrite](wait-event.iobuffile.md) | Esses eventos ocorrem quando o RDS para PostgreSQL cria arquivos temporários. |
| [IO:DataFileRead](wait-event.iodatafileread.md) | Esse evento ocorre quando uma conexão aguarda em um processo de backend para ler uma página necessária do armazenamento porque essa página não está disponível na memória compartilhada. |
| [IO:WALWrite](wait-event.iowalwrite.md) | Esse evento ocorre quando o RDS para PostgreSQL está aguardando os buffers do log de gravação antecipada (WAL) serem gravados em um arquivo WAL. |
| [Lock:advisory](wait-event.lockadvisory.md) | Esse evento ocorre quando uma aplicação PostgreSQL utiliza um bloqueio para coordenar as atividades em várias sessões. |
| [Lock:extend](wait-event.lockextend.md) | Esse evento ocorre quando um processo de backend está aguardando para bloquear uma relação com o objetivo de a estender, enquanto outro processo tem um bloqueio nessa relação para o mesmo objetivo. |
| [Lock:Relation](wait-event.lockrelation.md) | Esse evento ocorre quando uma consulta está aguardando para adquirir um bloqueio em uma tabela ou visualização que está atualmente bloqueada por outra transação. |
| [Lock:transactionid](wait-event.locktransactionid.md) | Esse evento ocorre quando uma transação está aguardando um bloqueio em nível de linha. |
| [Lock:tuple](wait-event.locktuple.md) | Esse evento ocorre quando um processo de backend está aguardando para adquirir um bloqueio em uma tupla. |
| [LWLock:BufferMapping (LWLock:buffer\$1mapping)](wait-event.lwl-buffer-mapping.md) | Esse evento ocorre quando uma sessão está aguardando para associar um bloco de dados a um buffer no grupo de buffer compartilhado. |
| [LWLock:BufferIO (IPC:BufferIO)](wait-event.lwlockbufferio.md) | Esse evento ocorre quando o RDS para PostgreSQL está aguardando que outros processos terminem suas operações de entrada/saída (E/S) ao tentarem acessar simultaneamente uma página. |
| [LWLock:buffer\$1content (BufferContent)](wait-event.lwlockbuffercontent.md) | Esse evento ocorre quando uma sessão aguarda para ler ou gravar uma página de dados na memória enquanto outra sessão fica com a página bloqueada para gravação. |
| [LWLock:lock\$1manager (LWLock:lockmanager)](wait-event.lw-lock-manager.md) | Esse evento ocorre quando o mecanismo do RDS para PostgreSQL mantém a área de memória do bloqueio compartilhado para alocar, conferir e desalocar um bloqueio nos casos em que um bloqueio de caminho rápido não é possível. |
| [LWLock:SubtransSLRU (LWLock:SubtransControlLock)](wait-event.lwlocksubtransslru.md) | Esse evento ocorre quando um processo está aguardando para acessar o cache simples menos recentemente utilizado (SLRU) para uma subtransação. |
| [Tempo limite:PgSleep](wait-event.timeoutpgsleep.md) | Esse evento ocorre quando um processo do servidor chama a função `pg_sleep` e está aguardando o tempo limite de suspensão expirar. |
| [Timeout:VacuumDelay](wait-event.timeoutvacuumdelay.md) | Esse evento indica que o processo de vácuo está inativo porque o limite de custo estimado foi atingido. |
# Client:ClientRead
O evento `Client:ClientRead` ocorre quando o RDS para PostgreSQL está aguardando receber dados do cliente.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.clientread.context.supported)
+ [
## Contexto
](#wait-event.clientread.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.clientread.causes)
+ [
## Ações
](#wait-event.clientread.actions)
## Versões compatíveis do mecanismo
Essas informações sobre eventos de espera são compatíveis com o RDS para PostgreSQL versão 10 e superiores.
## Contexto
Uma instância de banco de dados do RDS para PostgreSQL está aguardando para receber dados do cliente. A instância de banco de dados do RDS para PostgreSQL deve receber os dados do cliente para poder enviar mais dados ao cliente. O tempo de espera da instância antes de receber dados do cliente é um evento `Client:ClientRead`.
## Possíveis causas do maior número de esperas
Causas comuns do surgimento do evento `Client:ClientRead` nas principais esperas incluem:
**Maior latência de rede**
Pode haver maior latência de rede entre a instância de banco de dados do RDS para PostgreSQL e o cliente. A latência de rede mais alta aumenta o tempo necessário para a instância de banco de dados receber dados do cliente.
**Maior carga no cliente**
Pode haver pressão da CPU ou saturação da rede no lado do cliente. Um aumento na carga no cliente pode atrasar a transmissão de dados do cliente para a instância de banco de dados do RDS para PostgreSQL.
**Excesso de viagens de ida e volta na rede**
Um número elevado de viagens de ida e volta na rede entre a instância de banco de dados do RDS para PostgreSQL e o cliente pode atrasar a transmissão de dados do cliente para a instância do RDS para PostgreSQL.
**Operação de cópia extensa**
Durante uma operação de cópia, os dados são transferidos do sistema de arquivos do cliente para a instância de banco de dados do RDS para PostgreSQL. O envio de uma muitos dados para a instância de banco de dados pode atrasar a transmissão de dados do cliente para a instância de banco de dados.
**Desconexão de um cliente inativo**
Quando um cliente se conecta à instância de banco de dados do RDS para PostgreSQL em um estado `idle in transaction`, a instância de banco de dados pode esperar que o cliente envie mais dados ou emitir um comando. Uma conexão nesse estado pode resultar no aumento de eventos `Client:ClientRead`.
**PgBouncer utilizado para agrupamento de conexões**
PgBouncer tem uma configuração de rede de baixo nível chamada `pkt_buf` e que está definida como 4.096 por padrão. Se a workload estiver enviando pacotes de consulta maiores que 4.096 bytes por meio de PgBouncer, convém aumentar a configuração `pkt_buf` para 8.192. Se a nova configuração não diminuir o número de eventos `Client:ClientRead`, convém aumentar a configuração `pkt_buf` para valores maiores, como 16.384 ou 32.768. Se o texto da consulta for grande, a configuração maior pode ser particularmente útil.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [
### Colocar os clientes na mesma zona de disponibilidade e sub-rede da VPC que a instância
](#wait-event.clientread.actions.az-vpc-subnet)
+ [
### Escalar seu cliente
](#wait-event.clientread.actions.scale-client)
+ [
### Utilizar instâncias da geração atual
](#wait-event.clientread.actions.db-instance-class)
+ [
### Aumentar a largura de banda da rede
](#wait-event.clientread.actions.increase-network-bandwidth)
+ [
### Monitorar máximos de performance da rede
](#wait-event.clientread.actions.monitor-network-performance)
+ [
### Monitorar transações no estado de “inatividade em transação”
](#wait-event.clientread.actions.check-idle-in-transaction)
### Colocar os clientes na mesma zona de disponibilidade e sub-rede da VPC que a instância
Para reduzir a latência e aumentar o throughput da rede, coloque clientes na mesma zona de disponibilidade e na mesma sub-rede de nuvem privada virtual (VPC) que a instância de banco de dados do RDS para PostgreSQL. Os clientes devem estar o mais próximos possível da instância de banco de dados.
### Escalar seu cliente
Utilizando o Amazon CloudWatch ou outras métricas de host, determine se o cliente está atualmente restrito pela CPU ou pela largura de banda da rede, ou por ambas. Se o cliente estiver restrito, escale-o de acordo.
### Utilizar instâncias da geração atual
Em alguns casos, talvez você não esteja utilizando uma classe de instância de banco de dados que ofereça suporte a quadros jumbo. Se estiver executando sua aplicação no Amazon EC2, considere utilizar uma instância de geração atual para o cliente. Além disso, configure a MTU (unidade de transmissão máxima) no sistema operacional cliente. Essa técnica pode reduzir o número de idas e voltas pela rede e aumentar a taxa de transferência da rede. Consulte mais informações em [Frames jumbo (9001 MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) no *Guia do usuário do Amazon EC2*.
Para obter informações sobre classes de instância de banco de dados, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md). Para determinar a classe de instância de banco de dados equivalente a um tipo de instância do Amazon EC2, coloque `db.` antes do nome do tipo de instância do Amazon EC2. Por exemplo, a instância `r5.8xlarge` do Amazon EC2 é equivalente à classe de instância de banco de dados `db.r5.8xlarge`.
### Aumentar a largura de banda da rede
Utilize as métricas `NetworkReceiveThroughput` e `NetworkTransmitThroughput` do Amazon CloudWatch para monitorar o tráfego de rede de entrada e saída na instância de banco de dados. Essas métricas podem ajudar você a determinar se a largura de banda da rede é suficiente para a sua workload.
Se a largura de banda da rede não suficiente, aumente-a. Se o cliente AWS ou sua instância de banco de dados estiver atingindo os limites de largura de banda da rede, a única maneira de aumentar a largura de banda será ampliar o tamanho da instância de banco de dados. Para obter mais informações, consulte [Tipos de classe de instância de banco de dados](Concepts.DBInstanceClass.Types.md).
Para ter mais informações sobre métricas do CloudWatch, consulte [Métricas do Amazon CloudWatch para o Amazon RDS](rds-metrics.md).
### Monitorar máximos de performance da rede
Se você utiliza clientes do Amazon EC2, o Amazon EC2 fornece máximos para métricas de performance da rede, incluindo largura de banda de rede agregada de entrada e saída. Ele também fornece rastreamento de conexões para garantir que os pacotes sejam retornados conforme esperado e vinculem localmente o acesso para serviços como o Sistema de Nomes de Domínio (DNS). Para monitorar esses máximos, utilize um driver de rede avançado atual e monitore a performance de rede do seu cliente.
Consulte mais informações em [Monitorar a performance de rede de sua instância do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) no *Guia do usuário do Amazon EC2*.
### Monitorar transações no estado de “inatividade em transação”
Verifique se você tem um número cada vez maior de conexões `idle in transaction`. Para isso, monitore a coluna `state` na tabela `pg_stat_activity`. Talvez seja possível identificar a origem da conexão executando uma consulta semelhante à seguinte.
```
select client_addr, state, count(1) from pg_stat_activity
where state like 'idle in transaction%'
group by 1,2
order by 3 desc
```
# Client:ClientWrite
O evento `Client:ClientWrite` ocorre quando o RDS para PostgreSQL está aguardando para gravar dados no cliente.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.clientwrite.context.supported)
+ [
## Contexto
](#wait-event.clientwrite.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.clientwrite.causes)
+ [
## Ações
](#wait-event.clientwrite.actions)
## Versões compatíveis do mecanismo
Essas informações sobre eventos de espera são compatíveis com o RDS para PostgreSQL versão 10 e superiores.
## Contexto
Um processo de cliente deve ler todos os dados recebidos de um cluster de banco de dados do RDS para PostgreSQL para que o cluster possa enviar mais dados. O tempo de espera do cluster antes de enviar mais dados ao cliente é um evento `Client:ClientWrite`.
O throughput reduzido da rede entre a instância de banco de dados do RDS para PostgreSQL e o cliente pode causar esse evento. A pressão da CPU e a saturação da rede no cliente também podem causar esse evento. *Pressão da CPU* é quando a CPU está totalmente utilizada e existem tarefas aguardando o tempo da CPU. *Saturação de rede* é quando a rede entre o banco de dados e o cliente está transportando mais dados do que ela pode manipular.
## Possíveis causas do maior número de esperas
Causas comuns do surgimento do evento `Client:ClientWrite` nas principais esperas incluem:
**Maior latência de rede**
Pode haver maior latência de rede entre a instância de banco de dados do RDS para PostgreSQL e o cliente. A latência de rede mais alta aumenta o tempo necessário para o cliente receber os dados.
**Maior carga no cliente**
Pode haver pressão da CPU ou saturação da rede no lado do cliente. Um aumento na carga do cliente atrasa o recebimento de dados da instância de banco de dados do RDS para PostgreSQL.
**Grande volume de dados enviados ao cliente**
A instância de banco de dados do RDS para PostgreSQL pode estar enviando uma grande quantidade de dados ao cliente. É possível que um cliente não consiga receber os dados tão rápido quanto o cluster os está enviando. Atividades como cópias de tabelas grandes podem resultar no aumento de eventos `Client:ClientWrite`.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [
### Colocar os clientes na mesma zona de disponibilidade e sub-rede VPC que o cluster
](#wait-event.clientwrite.actions.az-vpc-subnet)
+ [
### Utilizar instâncias da geração atual
](#wait-event.clientwrite.actions.db-instance-class)
+ [
### Reduzir a quantidade de dados enviados ao cliente
](#wait-event.clientwrite.actions.reduce-data)
+ [
### Escalar seu cliente
](#wait-event.clientwrite.actions.scale-client)
### Colocar os clientes na mesma zona de disponibilidade e sub-rede VPC que o cluster
Para reduzir a latência e aumentar o throughput da rede, coloque clientes na mesma zona de disponibilidade e na mesma sub-rede de nuvem privada virtual (VPC) que a instância de banco de dados do RDS para PostgreSQL.
### Utilizar instâncias da geração atual
Em alguns casos, talvez você não esteja utilizando uma classe de instância de banco de dados que ofereça suporte a quadros jumbo. Se estiver executando sua aplicação no Amazon EC2, considere utilizar uma instância de geração atual para o cliente. Além disso, configure a MTU (unidade de transmissão máxima) no sistema operacional cliente. Essa técnica pode reduzir o número de idas e voltas pela rede e aumentar a taxa de transferência da rede. Consulte mais informações em [Frames jumbo (9001 MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) no *Guia do usuário do Amazon EC2*.
Para obter informações sobre classes de instância de banco de dados, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md). Para determinar a classe de instância de banco de dados equivalente a um tipo de instância do Amazon EC2, coloque `db.` antes do nome do tipo de instância do Amazon EC2. Por exemplo, a instância `r5.8xlarge` do Amazon EC2 é equivalente à classe de instância de banco de dados `db.r5.8xlarge`.
### Reduzir a quantidade de dados enviados ao cliente
Quando possível, ajuste a aplicação para reduzir a quantidade de dados que a instância de banco de dados do RDS para PostgreSQL envia ao cliente. Fazer esses ajustes alivia a contenção da CPU e da rede no lado do cliente.
### Escalar seu cliente
Utilizando o Amazon CloudWatch ou outras métricas de host, determine se o cliente está atualmente restrito pela CPU ou pela largura de banda da rede, ou por ambas. Se o cliente estiver restrito, escale-o de acordo.
# CPU
Ocorre quando um thread está ativo na CPU ou está aguardando a CPU.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.cpu.context.supported)
+ [
## Contexto
](#wait-event.cpu.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.cpu.causes)
+ [
## Ações
](#wait-event.cpu.actions)
## Versões compatíveis do mecanismo
Essas informações de evento de espera são relevantes para todas as versões do RDS para PostgreSQL.
## Contexto
A *unidade de processamento central (CPU)* é o componente de um computador que executa instruções. Por exemplo, instruções de CPU realizam operações aritméticas e trocam dados na memória. Se uma consulta aumentar o número de instruções que ela executa por meio do mecanismo de banco de dados, o tempo gasto na execução dessa consulta aumentará. *Programação da CPU* refere-se a alocar tempo de CPU a um processo. A programação é orquestrada pelo kernel do sistema operacional.
**Topics**
+ [
### Como saber quando essa espera ocorre
](#wait-event.cpu.when-it-occurs)
+ [
### Métrica DBLoadCPU
](#wait-event.cpu.context.dbloadcpu)
+ [
### Métricas os.cpuUtilization
](#wait-event.cpu.context.osmetrics)
+ [
### Provável causa da programação da CPU
](#wait-event.cpu.context.scheduling)
### Como saber quando essa espera ocorre
Esse evento de espera `CPU` indica que um processo de backend está ativo na CPU ou aguardando a CPU. É possível determinar que isso está ocorrendo quando uma consulta mostra as seguintes informações:
+ A coluna `pg_stat_activity.state` tem o valor `active`.
+ As colunas `wait_event_type` e `wait_event` em `pg_stat_activity` são ambas `null`.
Para ver os processos de backend que estão utilizando ou aguardando CPU, execute a seguinte consulta.
```
SELECT *
FROM pg_stat_activity
WHERE state = 'active'
AND wait_event_type IS NULL
AND wait_event IS NULL;
```
### Métrica DBLoadCPU
A métrica do Performance Insights para CPU é `DBLoadCPU`. O valor de `DBLoadCPU` pode diferir do valor da métrica `CPUUtilization` do Amazon CloudWatch. A última métrica é coletada do HyperVisor para uma instância de banco de dados.
### Métricas os.cpuUtilization
As métricas do Performance Insights para o sistema operacional fornecem informações detalhadas sobre a utilização da CPU. Por exemplo, é possível exibir as seguintes métricas:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
O Performance Insights relata o uso da CPU pelo mecanismo de banco de dados como `os.cpuUtilization.nice.avg`.
### Provável causa da programação da CPU
O kernel do sistema operacional (SO) lida com agendamento para a CPU. Quando a CPU está *ativa*, talvez um processo precise esperar para ser agendado. A CPU está ativa enquanto executa cálculos. Também está ativa enquanto está com um thread ocioso que não está em execução, ou seja, um thread ocioso que está aguardando a E/S de memória. Esse tipo de E/S domina a workload típica de banco de dados.
É provável que os processos aguardem para serem programados em uma CPU quando as seguintes condições forem atendidas:
+ A métrica `CPUUtilization` do CloudWatch está próxima dos 100%.
+ A carga média é maior que o número de vCPUs, indicando uma carga pesada. Você pode encontrar a métrica `loadAverageMinute` na seção de métricas do sistema operacional do Performance Insights.
## Possíveis causas do maior número de esperas
Quando o evento de espera de CPU ocorre mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
**Topics**
+ [
### Possíveis causas de picos súbitos
](#wait-event.cpu.causes.spikes)
+ [
### Possíveis causas de alta frequência a longo prazo
](#wait-event.cpu.causes.long-term)
+ [
### Casos excepcionais
](#wait-event.cpu.causes.corner-cases)
### Possíveis causas de picos súbitos
As causas mais prováveis de picos súbitos são as seguintes:
+ Sua aplicação abriu muitas conexões simultâneas com o banco de dados. Esse cenário é conhecido como “tempestade de conexões”.
+ A workload da sua aplicação foi alterada de qualquer uma das seguintes maneiras:
+ Novas consultas
+ Um aumento no tamanho do conjunto de dados
+ Manutenção ou criação de índices
+ Novas funções
+ Novos operadores
+ Um aumento na execução de consultas paralelas
+ Seus planos de execução de consultas foram modificados. Em certos casos, uma alteração pode causar um aumento nos buffers. Por exemplo, a consulta agora está utilizando uma varredura sequencial quando utilizava anteriormente um índice. Nesse caso, ela precisa de mais CPU para atingir o mesmo objetivo.
### Possíveis causas de alta frequência a longo prazo
As causas mais prováveis de eventos que se repetem por um longo período são:
+ Muitos processos de backend estão em execução simultaneamente na CPU. Esses processos podem ser operadores paralelos.
+ Consultas estão sendo executadas com performance abaixo do ideal porque precisam de um grande número de buffers.
### Casos excepcionais
Se nenhuma das causas prováveis revelarem ser causas reais, as seguintes situações podem estar ocorrendo:
+ A CPU está alternando processos para dentro e para fora.
+ A CPU poderá estar gerenciando as entradas da tabela de páginas se o recurso de *páginas enormes* estiver desativado. Esse recurso de gerenciamento de memória é ativado por padrão para todas as classes de instância de banco de dados que não sejam classes de instância de banco de dados micro, pequenas e médias. Para obter mais informações, consulte [Páginas grandes para RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md).
## Ações
Se o evento de espera `CPU` domina a atividade do banco de dados, isso não indica necessariamente um problema de performance. Responda a esse evento somente quando a performance diminuir.
**Topics**
+ [
### Investigar se o banco de dados está causando o aumento da CPU
](#wait-event.cpu.actions.db-CPU)
+ [
### Determinar se o número de conexões aumentou
](#wait-event.cpu.actions.connections)
+ [
### Responder a alterações de workload
](#wait-event.cpu.actions.workload)
### Investigar se o banco de dados está causando o aumento da CPU
Examine a métrica `os.cpuUtilization.nice.avg` no Performance Insights. Se esse valor for muito menor que o uso da CPU, processos que não são do banco de dados são os principais colaboradores para a CPU.
### Determinar se o número de conexões aumentou
Examine a métrica `DatabaseConnections` no Amazon CloudWatch. Sua ação depende se o número aumentou ou diminuiu durante o período de maior número de eventos de espera de CPU.
#### As conexões aumentaram
Se o número de conexões aumentou, compare o número de processos de backend que consumem CPU com o número de vCPUs. Os cenários a seguir são possíveis:
+ O número de processos de backend que consomem CPU é menor que o número de vCPUs.
Nesse caso, o número de conexões não é um problema. Porém, você ainda pode tentar reduzir a utilização da CPU.
+ O número de processos de backend que consomem CPU é maior que o número de vCPUs.
Nesse caso, considere as opções a seguir:
+ Diminua o número de processos de backend conectados ao banco de dados. Por exemplo, implemente uma solução de agrupamento de conexões, como o RDS Proxy. Para saber mais, consulte [Amazon RDS Proxy](rds-proxy.md).
+ Atualize o tamanho da sua instância para obter um número maior de vCPUs.
+ Se aplicável, redirecione algumas workloads somente leitura para nós de leitor.
#### As conexões não aumentaram
Examine as métricas `blks_hit` no Performance Insights. Procure uma correlação entre um aumento em `blks_hit` e o uso da CPU. Os cenários a seguir são possíveis:
+ O uso da CPU e `blks_hit` estão correlacionados.
Nesse caso, encontre as principais instruções SQL vinculadas ao uso da CPU e procure modificações no plano. Você pode usar uma das seguintes técnicas:
+ Explicar os planos manualmente e compare-os com o plano de execução esperado.
+ Procurar um aumento nos acertos de bloco por segundo e nos acertos de blocos locais por segundo. Na seção **Top SQL** (SQL principal) do painel do Performance Insights, escolha **Preferences** (Preferências).
+ O uso da CPU e `blks_hit` não estão correlacionados.
Nesse caso, determine se alguma das seguintes situações ocorre:
+ A aplicação está se conectando e se desconectando rapidamente ao/do banco de dados.
Diagnostique esse comportamento ativando `log_connections` e `log_disconnections` e analisando os logs do PostgreSQL. Considere utilizar o analisador de logs `pgbadger`. Para obter mais informações, consulte [https://github.com/darold/pgbadger](https://github.com/darold/pgbadger).
+ O sistema operacional está sobrecarregado.
Nesse caso, o Performance Insights mostra que processos de backend estão consumindo CPU por mais tempo que o normal. Procure evidências nas métricas `os.cpuUtilization` do Performance Insights ou na métrica `CPUUtilization` do CloudWatch. Se o sistema operacional estiver sobrecarregado, consulte as métricas de monitoramento avançado para aprofundar o diagnóstico. Especificamente, observe a lista de processos e a porcentagem de CPU consumida por cada um.
+ As principais instruções SQL estão consumindo muita CPU.
Examine instruções que estão vinculadas ao uso da CPU para verificar se elas podem utilizar menos CPU. Execute um comando `EXPLAIN` e concentre-se nos nós do plano que têm o maior impacto. Considere utilizar um visualizador de plano de execução do PostgreSQL. Para experimentar essa ferramenta, consulte [http://explain.dalibo.com/](http://explain.dalibo.com/).
### Responder a alterações de workload
Se a sua workload mudou, procure os seguintes tipos de alterações:
Novas consultas
Verifique se novas consultas são esperadas. Em caso positivo, verifique se os planos de execução dessas consultas e o número de execuções por segundo são os esperados.
Um aumento no tamanho do conjunto de dados
Determine se o particionamento, caso ainda não esteja implementado, pode ajudar. Essa estratégia é capaz de reduzir o número de páginas que uma consulta precisa recuperar.
Manutenção ou criação de índices
Verifique se a programação de manutenção é a esperada. Uma prática recomendada é agendar atividades de manutenção fora das atividades de pico.
Novas funções
Confirme se essas funções são executadas conforme o esperado durante o teste. Especificamente, confira se o número de execuções por segundo é o esperado.
Novos operadores
Verifique se eles funcionam conforme o esperado durante os testes.
Um aumento na execução de consultas paralelas
Determine se alguma das situações a seguir ocorreu:
+ As relações ou os índices envolvidos cresceram de repente a ponto de diferirem significativamente de `min_parallel_table_scan_size` ou `min_parallel_index_scan_size`.
+ Alterações recentes foram feitas em `parallel_setup_cost` ou `parallel_tuple_cost`.
+ Alterações recentes foram feitas em `max_parallel_workers` ou `max_parallel_workers_per_gather`.
# IO:BufFileRead and IO:BufFileWrite
Os eventos `IO:BufFileRead` e `IO:BufFileWrite` ocorrem quando o RDS para PostgreSQL cria arquivos temporários. Quando as operações requerem mais memória do que os parâmetros de memória de trabalho definidos atualmente, elas gravam dados temporários no armazenamento persistente. Essa operação é chamada às vezes de *derramamento no disco*. Para obter mais informações sobre os arquivos temporários e o uso, consulte [Gerenciar arquivos temporários com o PostgreSQL](PostgreSQL.ManagingTempFiles.md).
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.iobuffile.context.supported)
+ [
## Contexto
](#wait-event.iobuffile.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.iobuffile.causes)
+ [
## Ações
](#wait-event.iobuffile.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Contexto
`IO:BufFileRead` e `IO:BufFileWrite` estão relacionados à área de memória de trabalho e a área de memória de trabalho de manutenção. Para obter mais informações sobre essas áreas de memória local, consulte [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) (Consumo de recursos) na documentação do PostgreSQL.
O valor padrão para `work_mem` é 4 MB. Se uma sessão executar operações em paralelo, cada operador que lidar com o paralelismo usará 4 MB de memória. Por essa razão, defina `work_mem` com cautela. Se você aumentar demais esse valor, um banco de dados que execute muitas sessões poderá consumir muita memória. Se você definir um valor muito baixo, o RDS para PostgreSQL criará arquivos temporários no armazenamento local. A E/S de disco desses arquivos temporários pode reduzir a performance.
Se você observar a seguinte sequência de eventos, é possível que seu banco de dados esteja gerando arquivos temporários:
1. Redução súbita e acentuada na disponibilidade
1. Recuperação rápida para o espaço livre
Você também pode observar um padrão de “motosserra”. Esse padrão pode indicar que o banco de dados está criando arquivos pequenos constantemente.
## Possíveis causas do maior número de esperas
Em geral, esses eventos de espera são causados por operações que consomem mais memória do que é alocado pelos parâmetros `work_mem` ou `maintenance_work_mem`. Para compensar isso, as operações gravam em arquivos temporários. Causas comuns dos eventos `IO:BufFileRead` e `IO:BufFileWrite` incluem:
**Consultas que necessitam de mais memória do que existe na área de memória de trabalho**
Consultas com as seguintes características utilizam a área de memória de trabalho:
+ Junções de hash
+ `ORDER BY`Cláusula
+ `GROUP BY`Cláusula
+ `DISTINCT`
+ Funções de janela
+ `CREATE TABLE AS SELECT`
+ Atualização de visualizações materializadas
**Instruções que necessitam de mais memória do que existe na área de memória do trabalho de manutenção**
As seguintes instruções usam a área de memória do trabalho de manutenção:
+ `CREATE INDEX`
+ `CLUSTER`
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [
### Identificar o problema
](#wait-event.iobuffile.actions.problem)
+ [
### Examinar suas consultas de junção
](#wait-event.iobuffile.actions.joins)
+ [
### Examinar suas consultas ORDER BY e GROUP BY
](#wait-event.iobuffile.actions.order-by)
+ [
### Evite utilizar a operação DISTINCT
](#wait-event.iobuffile.actions.distinct)
+ [
### Considere utilizar funções de janela em vez de funções GROUP BY
](#wait-event.iobuffile.actions.window)
+ [
### Investigar visualizações materializadas e instruções CTAS
](#wait-event.iobuffile.actions.mv-refresh)
+ [
### Utilizar pg\$1repack ao recriar índices
](#wait-event.iobuffile.actions.pg_repack)
+ [
### Aumentar maintenance\$1work\$1mem ao agrupar tabelas
](#wait-event.iobuffile.actions.cluster)
+ [
### Ajustar a memória para evitar IO:BufFileRead e IO:BufFileWrite
](#wait-event.iobuffile.actions.tuning-memory)
### Identificar o problema
Você pode visualizar o uso de arquivos temporários diretamente no Insights de Performance. Para obter mais informações, consulte [Visualizar o uso de arquivos temporários com o Insights de Performance](PostgreSQL.ManagingTempFiles.Example.md). Quando o Insights de Performance está desabilitado, é possível observar um aumento nas operações `IO:BufFileRead` e `IO:BufFileWrite`.
Para identificar a origem do problema, você pode definir o parâmetro `log_temp_files` para registrar todas as consultas que geram mais do que o limite especificado de KB de arquivos temporários. Por padrão,`log_temp_files` está definido como `-1`, o que desativa esse recurso de registro em log. Se você definir esse parâmetro como `0`, o RDS para PostgreSQL registrará todos os arquivos temporários. Se você defini-lo como `1024`, o RDS para PostgreSQL registrará todas as consultas que geram arquivos temporários maiores que 1 MB. Para obter mais informações sobre `log_temp_files`, consulte o tópico sobre [Relatórios de erros e registro em log](https://www.postgresql.org/docs/current/runtime-config-logging.html), na documentação do PostgreSQL.
### Examinar suas consultas de junção
É provável que sua consulta use junções. Por exemplo, a consulta a seguir une quatro tabelas.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = order.customer_id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
Uma causa possível dos picos no uso temporário de arquivos é um problema na própria consulta. Por exemplo, uma cláusula quebrada talvez não esteja filtrando as junções corretamente. Considere a segunda junção interna no exemplo a seguir.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = customer.id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
A consulta anterior junta `customer.id` com `customer.id` por engano, gerando um produto cartesiano entre cada cliente e cada pedido. Esse tipo de junção acidental gera arquivos temporários grandes. Dependendo do tamanho das tabelas, uma consulta cartesiana pode até mesmo lotar o armazenamento. Sua aplicação pode ter junções cartesianas quando as seguintes condições são atendidas:
+ Você percebe reduções grandes e acentuadas na disponibilidade do armazenamento, seguidas de uma rápida recuperação.
+ Nenhum índice está sendo criado.
+ Nenhuma instrução `CREATE TABLE FROM SELECT` está sendo emitida.
+ Nenhuma visualização materializada está sendo atualizada.
Para verificar se as tabelas estão sendo unidas utilizando as chaves apropriadas, inspecione suas diretivas de mapeamento de consultas e objetos relacionais. Lembre-se de que certas consultas da sua aplicação não são chamadas o tempo todo e que algumas consultas são geradas dinamicamente.
### Examinar suas consultas ORDER BY e GROUP BY
Em alguns casos, uma cláusula `ORDER BY` pode resultar no excesso de arquivos temporários. Considere as seguintes diretrizes:
+ Inclua somente colunas em uma cláusula `ORDER BY` quando elas precisarem ser ordenadas. Essa orientação é especialmente importante para consultas que retornam milhares de linhas e especificam muitas colunas na cláusula `ORDER BY`.
+ Considere criar índices para acelerar cláusulas `ORDER BY` quando elas correspondem a colunas que tenham a mesma ordem crescente ou decrescente. Índices parciais são preferíveis, pois são menores. Índices menores são lidos e percorridos com mais rapidez.
+ Se você criar índices para colunas que podem aceitar valores nulos, considere se deseja que esses valores nulos sejam armazenados no final ou no início dos índices.
Se possível, reduza o número de linhas que precisam ser ordenadas, filtrando o conjunto de resultados. Se você usar instruções de cláusula `WITH` ou subconsultas, lembre-se de que uma consulta interna gera um conjunto de resultados e o transmite à consulta externa. Quanto mais linhas uma consulta puder remover, menos ordenação ela precisará fazer.
+ Se não precisar obter o conjunto completo de resultados, utilize a cláusula `LIMIT`. Por exemplo, se quiser apenas as cinco principais linhas, uma consulta utilizando a cláusula `LIMIT` não continuará gerando resultados. Dessa forma, essa consulta requer menos memória e arquivos temporários.
Uma consulta que usa uma cláusula `GROUP BY` também pode exigir arquivos temporários. Consultas `GROUP BY` resumem valores utilizando funções como as seguintes:
+ `COUNT`
+ `AVG`
+ `MIN`
+ `MAX`
+ `SUM`
+ `STDDEV`
Para ajustar consultas `GROUP BY`, siga as recomendações para consultas `ORDER BY`.
### Evite utilizar a operação DISTINCT
Se possível, evite utilizar a operação `DISTINCT` para remover linhas duplicadas. Quanto mais linhas desnecessárias e duplicadas sua consulta retornar, mais cara a operação `DISTINCT` se tornará. Se possível, adicione filtros à cláusula `WHERE` mesmo que você utilize os mesmos filtros para tabelas diferentes. Filtrar a consulta e a junção corretamente melhora a performance e reduz o uso de recursos. Isso também evita relatórios e resultados incorretos.
Se precisar usar `DISTINCT` para várias linhas de uma mesma tabela, considere criar um índice composto. O agrupamento de várias colunas em um índice pode melhorar o tempo para avaliar linhas distintas. Além disso, se utilizar o RDS para PostgreSQL versão 10 ou superior, você poderá correlacionar estatísticas entre várias colunas utilizando o comando `CREATE STATISTICS`.
### Considere utilizar funções de janela em vez de funções GROUP BY
Usando `GROUP BY`, você altera o conjunto de resultados e, em seguida, recupera o resultado agregado. Usando funções de janela, você agrega dados sem modificar o conjunto de resultados. Uma função de janela usa a cláusula `OVER` para fazer cálculos entre os conjuntos definidos pela consulta, correlacionando uma linha com outra. Você pode utilizar todas as funções `GROUP BY` em funções de janela, mas também utilizar funções como as seguintes:
+ `RANK`
+ `ARRAY_AGG`
+ `ROW_NUMBER`
+ `LAG`
+ `LEAD`
Para minimizar o número de arquivos temporários gerados por uma função de janela, remova duplicatas do mesmo conjunto de resultados quando precisar de duas agregações distintas. Considere a seguinte consulta.
```
SELECT sum(salary) OVER (PARTITION BY dept ORDER BY salary DESC) as sum_salary
, avg(salary) OVER (PARTITION BY dept ORDER BY salary ASC) as avg_salary
FROM empsalary;
```
Você pode reescrever essa consulta com a cláusula `WINDOW` da seguinte maneira.
```
SELECT sum(salary) OVER w as sum_salary
, avg(salary) OVER w as_avg_salary
FROM empsalary
WINDOW w AS (PARTITION BY dept ORDER BY salary DESC);
```
Por padrão, o planejador de execução do RDS para PostgreSQL consolida nós semelhantes para que ele não duplique operações. No entanto, utilizando uma declaração explícita para o bloco de janelas, é possível manter a consulta com mais facilidade. Também é possível melhorar a performance ao evitar a duplicação.
### Investigar visualizações materializadas e instruções CTAS
Quando uma visualização materializada é atualizada, ela executa uma consulta. Essa consulta pode conter uma operação como `GROUP BY`, `ORDER BY` ou `DISTINCT`. Durante uma atualização, é possível observar um grande número de arquivos temporários e os eventos de espera `IO:BufFileWrite` e `IO:BufFileRead`. Da mesma forma, quando você cria uma tabela com base em uma instrução `SELECT`, a instrução `CREATE TABLE` executa uma consulta. Para reduzir os arquivos temporários necessários, otimize a consulta.
### Utilizar pg\$1repack ao recriar índices
Quando você cria um índice, o mecanismo ordena o conjunto de resultados. À medida que o tamanho das tabelas aumenta e à medida que os valores na coluna indexada se tornam mais diversificados, os arquivos temporários exigem mais espaço. Na maioria dos casos, não é possível impedir a criação de arquivos temporários para tabelas grandes sem modificar a área de memória do trabalho de manutenção. Para obter mais informações sobre `maintenance_work_mem`, consulte [https://www.postgresql.org/docs/current/runtime-config-resource.html](https://www.postgresql.org/docs/current/runtime-config-resource.html) na documentação do PostgreSQL.
Uma possível solução alternativa ao recriar um índice grande é utilizar a extensão pg\$1repack. Para obter mais informações, consulte o tópico sobre como [Reorganizar tabelas em bancos de dados PostgreSQL com bloqueios mínimos](https://reorg.github.io/pg_repack/), na documentação de pg\$1repack. Para obter informações sobre como configurar a extensão em sua instância de banco de dados do RDS para PostgreSQL, consulte [Reduzir o inchaço em tabelas e índices com a extensão pg\$1repack](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md).
### Aumentar maintenance\$1work\$1mem ao agrupar tabelas
O comando `CLUSTER` agrupa a tabela especificada por *table\$1name* com base em um índice existente especificado por *index\$1name*. O RDS para PostgreSQL recria fisicamente a tabela para corresponder à ordem de um determinado índice.
Quando o armazenamento magnético era predominante, o agrupamento era comum, pois a taxa de transferência de armazenamento era limitada. Agora que o armazenamento baseado em SSD é comum, o agrupamento tornou-se menos popular. No entanto, se você agrupar tabelas, ainda poderá aumentar a performance ligeiramente, dependendo do tamanho da tabela, do índice, da consulta e assim por diante.
Se você executar o comando `CLUSTER` e observar os eventos de espera `IO:BufFileWrite` e `IO:BufFileRead`, ajuste `maintenance_work_mem`. Aumente o tamanho da memória para uma quantidade relativamente grande. Um valor alto significa que o mecanismo pode utilizar mais memória para a operação de agrupamento.
### Ajustar a memória para evitar IO:BufFileRead e IO:BufFileWrite
Em algumas situações, você precisa ajustar a memória. Seu objetivo é equilibrar a memória nas seguintes áreas de consumo usando os parâmetros apropriados, da forma a seguir.
+ O valor `work_mem`
+ A memória restante após descontar o valor `shared_buffers`
+ As conexões máximas abertas e em uso, o que é limitado por `max_connections`
Para obter mais informações sobre ajuste da memória, consulte [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) (Consumo de recursos) na documentação do PostgreSQL.
#### Aumentar o tamanho da área de memória de trabalho
Em algumas situações, a única opção é aumentar a memória utilizada pela sessão. Se as consultas estiverem gravadas corretamente e utilizando as chaves corretas para junções, considere aumentar o valor de `work_mem`.
Para descobrir quantos arquivos temporários são gerados por uma consulta, defina `log_temp_files` como `0`. Se você aumentar o valor de `work_mem` para o valor máximo identificado nos logs, impedirá que a consulta gere arquivos temporários. No entanto, `work_mem` define o máximo por nó de plano para cada conexão ou operador paralelo. Se o banco de dados tiver 5.000 conexões e cada uma utilizar 256 MiB de memória, o mecanismo precisará de 1,2 TiB de RAM. Portanto, sua instância pode ficar sem memória.
#### Reservar memória suficiente para o grupo de buffer compartilhado
Seu banco de dados usa áreas de memória, como o grupo de buffer compartilhado, e não apenas a área de memória de trabalho. Considere os requisitos dessas áreas de memória adicionais antes de aumentar `work_mem`.
Por exemplo, suponha que sua classe de instância do RDS para PostgreSQL seja db.r5.2xlarge. Essa classe tem 64 GiB de memória. Por padrão, 25% da memória são reservados para o grupo de buffer compartilhado. Depois de subtrair a quantidade alocada à área de memória compartilhada, permanecem 16.384 MB. Não aloque a memória restante exclusivamente à área de memória de trabalho, pois o sistema operacional e o mecanismo também precisam de memória.
A memória que é possível alocar a `work_mem` depende da classe da instância. Se você utilizar uma classe de instância maior, mais memória estará disponível. No entanto, no exemplo anterior, não é possível utilizar mais de 16 GiB. Caso contrário, sua instância estará indisponível quando ficar sem memória. Para recuperar a instância e retirá-la do estado indisponível, os serviços de automação do RDS para PostgreSQL são reiniciados automaticamente.
#### Gerenciar o número de conexões
Imagine que a sua instância de banco de dados tenha 5.000 conexões simultâneas. Cada conexão usa pelo menos 4 MiB de `work_mem`. O alto consumo de memória das conexões provavelmente diminuirá a performance. Em resposta, existem as seguintes opções:
+ Faça upgrade para uma classe de instância maior.
+ Diminua o número de conexões de banco de dados simultâneas utilizando um proxy de conexão ou pooler.
Para proxies, considere o Amazon RDS Proxy, o pgBouncer ou um pooler de conexão baseado na sua aplicação. Essa solução alivia a carga da CPU. Ela também reduz o risco quando todas as conexões exigem a área de memória de trabalho. Quando há menos conexões de banco de dados, é possível aumentar o valor de `work_mem`. Dessa forma, você reduz a ocorrência dos eventos de espera `IO:BufFileRead` e `IO:BufFileWrite`. Além disso, as consultas que aguardam a área de memória de trabalho são aceleradas significativamente.
# IO:DataFileRead
O evento `IO:DataFileRead` ocorre quando uma conexão aguarda em um processo de backend para ler uma página necessária do armazenamento porque essa página não está disponível na memória compartilhada.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.iodatafileread.context.supported)
+ [
## Contexto
](#wait-event.iodatafileread.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.iodatafileread.causes)
+ [
## Ações
](#wait-event.iodatafileread.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Contexto
Todas as consultas e operações de manipulação de dados (DML) acessam páginas no grupo de buffer. Instruções que podem induzir leituras incluem `SELECT`, `UPDATE` e `DELETE`. Por exemplo, um `UPDATE` pode ler páginas de tabelas ou índices. Se a página que está sendo solicitada ou atualizada não estiver no grupo de buffer compartilhado, essa leitura poderá gerar o evento `IO:DataFileRead`.
Como o grupo de buffer compartilhado é finito, ele pode ficar lotado. Nesse caso, solicitações de páginas que não estão na memória forçam o banco de dados a ler blocos do disco. Se o evento `IO:DataFileRead` ocorre com frequência, o grupo de buffer compartilhado pode ser pequeno demais para acomodar sua workload. Esse problema é grave para consultas `SELECT` que fazem a leitura de um grande número de linhas que não cabem no grupo de buffer. Para obter mais informações sobre o grupo de buffer, consulte [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) (Consumo de recursos) na documentação do PostgreSQL.
## Possíveis causas do maior número de esperas
As causas comuns do evento `IO:DataFileRead` incluem:
**Picos de conexão**
Você pode encontrar várias conexões gerando o mesmo número de eventos de espera IO:DatafileRead. Nesse caso, pode ocorrer um pico (aumento súbito e grande) em eventos `IO:DataFileRead`.
**Instruções SELECT e DML realizando varreduras sequenciais**
Sua aplicação pode estar executando uma nova operação. Ou uma operação existente pode mudar por conta de um novo plano de execução. Nesses casos, procure tabelas (particularmente grandes) que tenham um valor de `seq_scan` maior. Encontre-as consultando `pg_stat_user_tables`. Para rastrear consultas que estão gerando mais operações de leitura, utilize a extensão `pg_stat_statements`.
**CTAS e CREATE INDEX para conjuntos de dados grandes**
Um *CTAS* é uma instrução `CREATE TABLE AS SELECT`. Se você executar um CTAS utilizando um conjunto de dados grande como fonte ou criar um índice em uma tabela grande, o evento `IO:DataFileRead` poderá ocorrer. Quando você cria um índice, talvez o banco de dados precise ler o objeto inteiro utilizando uma varredura sequencial. Um CTAS gera leituras de `IO:DataFile` quando as páginas não estão na memória.
**Vários operadores de vacuum em execução ao mesmo tempo**
Operadores de vacuum podem ser acionados manual ou automaticamente. Convém adotar uma estratégia de vacuum agressiva. No entanto, quando uma tabela possui muitas linhas atualizadas ou excluídas, as esperas de `IO:DataFileRead` aumentam. Depois que o espaço é recuperado, o tempo de vacuum gasto em `IO:DataFileRead` diminui.
**Ingestão de grandes quantidades de dados**
Quando a aplicação ingere grandes quantidades de dados, operações `ANALYZE` podem ocorrer com mais frequência. O processo `ANALYZE` pode ser acionado por um launcher de autovacuum ou chamado manualmente.
A operação `ANALYZE` lê um subconjunto da tabela. O número de páginas que devem ser varridas é calculado multiplicando-se 30 pelo valor de `default_statistics_target`. Para obter mais informações, consulte a [Documentação do PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET). O parâmetro `default_statistics_target` aceita valores entre 1 e 10.000, em que o padrão é 100.
**Inanição de recursos**
Se a largura de banda ou a CPU da rede da instância forem consumidas, o evento `IO:DataFileRead` poderá ocorrer com mais frequência.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [
### Verificar filtros de predicados em busca de consultas que geram esperas
](#wait-event.iodatafileread.actions.filters)
+ [
### Minimizar o efeito de operações de manutenção
](#wait-event.iodatafileread.actions.maintenance)
+ [
### Responder a um alto número de conexões
](#wait-event.iodatafileread.actions.connections)
### Verificar filtros de predicados em busca de consultas que geram esperas
Suponha que você identifique consultas específicas que estão gerando eventos de espera `IO:DataFileRead`. É possível identificá-los utilizando as seguintes técnicas:
+ Insights de Performance
+ Visualizações de catálogo, como a fornecida pela extensão `pg_stat_statements`
+ A visualização de catálogo `pg_stat_all_tables`, se ela mostrar periodicamente um número mais alto de leituras físicas
+ A visualização `pg_statio_all_tables`, se ela mostrar que os contadores de `_read` estão aumentando
Convém determinar quais filtros são utilizados no predicado (cláusula `WHERE`) dessas consultas. Siga estas diretrizes:
+ Execute o comando `EXPLAIN`. Na saída, identifique quais tipos de varreduras são utilizados. Uma varredura sequencial não indica necessariamente um problema. Consultas que utilizam varreduras sequenciais naturalmente produzem mais eventos `IO:DataFileRead` quando comparados a consultas que utilizam filtros.
Descubra se a coluna listada na cláusula `WHERE` é indexada. Caso contrário, considere criar um índice para essa coluna. Essa abordagem evita varreduras sequenciais e reduz eventos `IO:DataFileRead`. Se uma consulta tiver filtros restritivos e ainda produzir varreduras sequenciais, avalie se os índices adequados estão sendo utilizados.
+ Descubra se a consulta está acessando uma tabela muito grande. Em alguns casos, o particionamento de uma tabela pode melhorar a performance, permitindo que a consulta leia apenas as partições necessárias.
+ Observe a cardinalidade (número total de linhas) das suas operações de junção. Observe o quão restritivos são os valores que você está transmitindo nos filtros para a sua cláusula `WHERE`. Se possível, ajuste sua consulta para reduzir o número de linhas que são transmitidas em cada etapa do plano.
### Minimizar o efeito de operações de manutenção
Operações de manutenção, como `VACUUM` e `ANALYZE`, são importantes. Recomendamos que você não as desative ao encontrar eventos de espera `IO:DataFileRead` relacionados a essas operações de manutenção. As abordagens a seguir podem minimizar o efeito dessas operações:
+ Execute operações de manutenção manualmente fora do horário de pico. Essa técnica impede que o banco de dados atinja o limite para operações automáticas.
+ Considere particionar tabelas muito grandes. Essa técnica reduz a sobrecarga das operações de manutenção. O banco de dados somente acessa as partições que exigem manutenção.
+ Ao ingerir grandes quantidades de dados, considere desativar o recurso de análise automática.
O recurso de autovacuum é acionado automaticamente para uma tabela quando a seguinte fórmula é verdadeira.
```
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
```
A visualização `pg_stat_user_tables` e o catálogo `pg_class` têm várias linhas. Uma linha pode corresponder a uma linha na sua tabela. Essa fórmula pressupõe que os `reltuples` sejam para uma tabela específica. Os parâmetros `autovacuum_vacuum_scale_factor` (0,20 por padrão) e `autovacuum_vacuum_threshold` (50 tuplas por padrão) geralmente são definidos globalmente para toda a instância. Porém, é possível definir valores diferentes para uma tabela específica.
**Topics**
+ [
#### Localizar tabelas que consomem espaço desnecessariamente
](#wait-event.iodatafileread.actions.maintenance.tables)
+ [
#### Localizar índices que consomem espaço desnecessariamente
](#wait-event.iodatafileread.actions.maintenance.indexes)
+ [
#### Localizar tabelas elegíveis qualificadas para receber autovacuum
](#wait-event.iodatafileread.actions.maintenance.autovacuumed)
#### Localizar tabelas que consomem espaço desnecessariamente
Para encontrar tabelas que consomem espaço desnecessariamente, você pode usar funções da extensão `pgstattuple` do PostgreSQL. Essa extensão (módulo) está disponível por padrão em todas as instâncias de banco de dados do RDS para PostgreSQL e pode ser instanciada na instância com o comando a seguir.
```
CREATE EXTENSION pgstattuple;
```
Para obter mais informações sobre essa extensão, consulte [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html) na documentação do PostgreSQL.
É possível verificar se há sobrecarga na tabela e no índice em sua aplicação. Para obter mais informações, consulte [Diagnosticar a sobrecarga na tabela e no índice](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html).
#### Localizar índices que consomem espaço desnecessariamente
Para encontrar índices inchados e estimar a quantidade de espaço consumida desnecessariamente nas tabelas para as quais você tem privilégios de leitura, é possível executar a consulta a seguir.
```
-- WARNING: rows with is_na = 't' are known to have bad statistics ("name" type is not supported).
-- This query is compatible with PostgreSQL 8.2 and later.
SELECT current_database(), nspname AS schemaname, tblname, idxname, bs*(relpages)::bigint AS real_size,
bs*(relpages-est_pages)::bigint AS extra_size,
100 * (relpages-est_pages)::float / relpages AS extra_ratio,
fillfactor, bs*(relpages-est_pages_ff) AS bloat_size,
100 * (relpages-est_pages_ff)::float / relpages AS bloat_ratio,
is_na
-- , 100-(sub.pst).avg_leaf_density, est_pages, index_tuple_hdr_bm,
-- maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, sub.reltuples, sub.relpages
-- (DEBUG INFO)
FROM (
SELECT coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)/(4+nulldatahdrwidth)::float)), 0
-- ItemIdData size + computed avg size of a tuple (nulldatahdrwidth)
) AS est_pages,
coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)*fillfactor/(100*(4+nulldatahdrwidth)::float))), 0
) AS est_pages_ff,
bs, nspname, table_oid, tblname, idxname, relpages, fillfactor, is_na
-- , stattuple.pgstatindex(quote_ident(nspname)||'.'||quote_ident(idxname)) AS pst,
-- index_tuple_hdr_bm, maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, reltuples
-- (DEBUG INFO)
FROM (
SELECT maxalign, bs, nspname, tblname, idxname, reltuples, relpages, relam, table_oid, fillfactor,
( index_tuple_hdr_bm +
maxalign - CASE -- Add padding to the index tuple header to align on MAXALIGN
WHEN index_tuple_hdr_bm%maxalign = 0 THEN maxalign
ELSE index_tuple_hdr_bm%maxalign
END
+ nulldatawidth + maxalign - CASE -- Add padding to the data to align on MAXALIGN
WHEN nulldatawidth = 0 THEN 0
WHEN nulldatawidth::integer%maxalign = 0 THEN maxalign
ELSE nulldatawidth::integer%maxalign
END
)::numeric AS nulldatahdrwidth, pagehdr, pageopqdata, is_na
-- , index_tuple_hdr_bm, nulldatawidth -- (DEBUG INFO)
FROM (
SELECT
i.nspname, i.tblname, i.idxname, i.reltuples, i.relpages, i.relam, a.attrelid AS table_oid,
current_setting('block_size')::numeric AS bs, fillfactor,
CASE -- MAXALIGN: 4 on 32bits, 8 on 64bits (and mingw32 ?)
WHEN version() ~ 'mingw32' OR version() ~ '64-bit|x86_64|ppc64|ia64|amd64' THEN 8
ELSE 4
END AS maxalign,
/* per page header, fixed size: 20 for 7.X, 24 for others */
24 AS pagehdr,
/* per page btree opaque data */
16 AS pageopqdata,
/* per tuple header: add IndexAttributeBitMapData if some cols are null-able */
CASE WHEN max(coalesce(s.null_frac,0)) = 0
THEN 2 -- IndexTupleData size
ELSE 2 + (( 32 + 8 - 1 ) / 8)
-- IndexTupleData size + IndexAttributeBitMapData size ( max num filed per index + 8 - 1 /8)
END AS index_tuple_hdr_bm,
/* data len: we remove null values save space using it fractionnal part from stats */
sum( (1-coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 1024)) AS nulldatawidth,
max( CASE WHEN a.atttypid = 'pg_catalog.name'::regtype THEN 1 ELSE 0 END ) > 0 AS is_na
FROM pg_attribute AS a
JOIN (
SELECT nspname, tbl.relname AS tblname, idx.relname AS idxname,
idx.reltuples, idx.relpages, idx.relam,
indrelid, indexrelid, indkey::smallint[] AS attnum,
coalesce(substring(
array_to_string(idx.reloptions, ' ')
from 'fillfactor=([0-9]+)')::smallint, 90) AS fillfactor
FROM pg_index
JOIN pg_class idx ON idx.oid=pg_index.indexrelid
JOIN pg_class tbl ON tbl.oid=pg_index.indrelid
JOIN pg_namespace ON pg_namespace.oid = idx.relnamespace
WHERE pg_index.indisvalid AND tbl.relkind = 'r' AND idx.relpages > 0
) AS i ON a.attrelid = i.indexrelid
JOIN pg_stats AS s ON s.schemaname = i.nspname
AND ((s.tablename = i.tblname AND s.attname = pg_catalog.pg_get_indexdef(a.attrelid, a.attnum, TRUE))
-- stats from tbl
OR (s.tablename = i.idxname AND s.attname = a.attname))
-- stats from functional cols
JOIN pg_type AS t ON a.atttypid = t.oid
WHERE a.attnum > 0
GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9
) AS s1
) AS s2
JOIN pg_am am ON s2.relam = am.oid WHERE am.amname = 'btree'
) AS sub
-- WHERE NOT is_na
ORDER BY 2,3,4;
```
#### Localizar tabelas elegíveis qualificadas para receber autovacuum
Para localizar tabelas qualificadas para receber autovacuum, execute a seguinte consulta.
```
--This query shows tables that need vacuuming and are eligible candidates.
--The following query lists all tables that are due to be processed by autovacuum.
-- During normal operation, this query should return very little.
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold
FROM pg_settings WHERE name = 'autovacuum_vacuum_threshold')
, vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor
FROM pg_settings WHERE name = 'autovacuum_vacuum_scale_factor')
, fma AS (SELECT setting AS autovacuum_freeze_max_age
FROM pg_settings WHERE name = 'autovacuum_freeze_max_age')
, sto AS (SELECT opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value
FROM (SELECT oid opt_oid, unnest(reloptions) setting FROM pg_class) opt)
SELECT
'"'||ns.nspname||'"."'||c.relname||'"' as relation
, pg_size_pretty(pg_table_size(c.oid)) as table_size
, age(relfrozenxid) as xid_age
, coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age
, (coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
as autovacuum_vacuum_tuples
, n_dead_tup as dead_tuples
FROM pg_class c
JOIN pg_namespace ns ON ns.oid = c.relnamespace
JOIN pg_stat_all_tables stat ON stat.relid = c.oid
JOIN vbt on (1=1)
JOIN vsf ON (1=1)
JOIN fma on (1=1)
LEFT JOIN sto cvbt ON cvbt.param = 'autovacuum_vacuum_threshold' AND c.oid = cvbt.opt_oid
LEFT JOIN sto cvsf ON cvsf.param = 'autovacuum_vacuum_scale_factor' AND c.oid = cvsf.opt_oid
LEFT JOIN sto cfma ON cfma.param = 'autovacuum_freeze_max_age' AND c.oid = cfma.opt_oid
WHERE c.relkind = 'r'
AND nspname <> 'pg_catalog'
AND (
age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
or
coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples <= n_dead_tup
-- or 1 = 1
)
ORDER BY age(relfrozenxid) DESC;
```
### Responder a um alto número de conexões
Ao monitorar o Amazon CloudWatch, você pode descobrir que a métrica `DatabaseConnections` atinge picos. Esse aumento indica um número maior de conexões com o seu banco de dados. Recomendamos a seguinte abordagem:
+ Limite o número de conexões que a aplicação pode abrir com cada instância. Se a aplicação tiver um recurso de grupo de conexões incorporado, defina um número razoável de conexões. Baseie o número no que as vCPUs na instância podem paralelizar de maneira eficiente.
Se a aplicação não utilizar um recurso de grupo de conexões, considere utilizar o Amazon RDS Proxy ou uma alternativa. Essa abordagem permite que a aplicação abra várias conexões com o balanceador de carga. O balanceador pode então abrir um número restrito de conexões com o banco de dados. À medida que menos conexões são executadas em paralelo, sua instância de banco de dados realiza menos alternâncias de contexto no kernel. As consultas devem progredir com mais rapidez, resultando em menos eventos de espera. Para obter mais informações, consulte [Amazon RDS Proxy](rds-proxy.md).
+ Sempre que possível, aproveite réplicas de leitura para o RDS para PostgreSQL. Quando sua aplicação executar uma operação somente leitura, envie essas solicitações às réplicas de leitura. Essa técnica reduz a pressão de E/S no nó primário (gravador).
+ Considere aumentar a escala vertical da sua instância de banco de dados. Uma classe de instância com maior capacidade fornece mais memória, o que dá ao RDS para PostgreSQL um grupo de buffer compartilhado maior para conter páginas. O tamanho maior também dá à instância de banco de dados mais vCPUs para lidar com conexões. Mais vCPUs são particularmente úteis quando as operações que estão gerando eventos de espera `IO:DataFileRead` são gravações.
# IO:WALWrite
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.iowalwrite.context.supported)
+ [
## Contexto
](#wait-event.iowalwrite.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.iowalwrite.causes)
+ [
## Ações
](#wait-event.iowalwrite.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL 10 e posteriores.
## Contexto
A atividade no banco de dados que está gerando dados de log de gravação antecipada preenche primeiro os buffers do WAL e depois grava no disco, de forma assíncrona. O evento de espera `IO:WALWrite` é gerado quando a sessão SQL aguarda a conclusão da gravação dos dados do WAL no disco para que ela possa liberar a chamada COMMIT da transação.
## Possíveis causas do maior número de esperas
Se esse evento de espera ocorrer com frequência, você deve revisar sua workload, o tipo de atualização que ela executa e sua frequência. Especificamente, procure os tipos de atividade a seguir.
**Atividade intensa de DML**
A alteração de dados nas tabelas do banco de dados não acontece instantaneamente. Uma inserção em uma tabela pode precisar aguardar uma inserção ou uma atualização para a mesma tabela de outro cliente. As instruções da linguagem de manipulação de dados (DML) para alterar valores de dados (INSERT, UPDATE, DELETE, COMMIT, ROLLBACK TRANSACTION) podem ocasionar contenções que fazem com que o arquivo de registro de gravação antecipada aguarde a liberação dos buffers. Essa situação é capturada nas métricas a seguir do Insights de Performance do Amazon RDS, que indicam atividade intensa de DML.
+ `tup_inserted`
+ `tup_updated`
+ `tup_deleted`
+ `xact_rollback`
+ `xact_commit`
Para ter mais informações sobre essas métricas, consulte [Contadores do Performance Insights para o Amazon RDS para PostgreSQL](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.PostgreSQL).
**Atividade frequente no ponto de verificação**
Pontos de verificação frequentes contribuem para um maior número de arquivos WAL. No RDS para PostgreSQL, as gravações de página inteira estão sempre “ativadas”. As gravações de página inteira ajudam a proteger contra a perda de dados. No entanto, quando a verificação ocorre com muita frequência, o sistema pode sofrer problemas gerais de performance. Isso é especialmente verdadeiro em sistemas com intensa atividade de DML. Em alguns casos, você pode encontrar mensagens de erro em seu `postgresql.log` afirmando que “os pontos de verificação estão ocorrendo com muita frequência”.
Recomendamos que, ao ajustar os pontos de verificação, você equilibre cuidadosamente a performance com o tempo esperado de recuperação no caso de um desligamento anormal.
## Ações
Recomendamos as ações a seguir para reduzir os números desse evento de espera.
**Topics**
+ [
### Reduza o número de confirmações
](#wait-event.iowalwrite.actions.problem)
+ [
### Monitorar os pontos de verificação
](#wait-event.iowalwrite.actions.monitor)
+ [
### Aumentar a escala de E/S verticalmente
](#wait-event.iowalwrite.actions.scale-io)
+ [
### Volume de log dedicado (DLV)
](#wait-event.iowalwrite.actions.dlv)
### Reduza o número de confirmações
Para reduzir o número de confirmações, você pode combinar instruções em blocos de transações. Utilize o Insights de Performance do Amazon RDS para examinar o tipo de consulta que está sendo executada. Você também pode transferir grandes operações de manutenção para o horário de pico. Por exemplo, crie índices ou use operações `pg_repack` fora do horário de produção.
### Monitorar os pontos de verificação
Há dois parâmetros que você pode monitorar para ver com que frequência sua instância de banco de dados do RDS para PostgreSQL está gravando no arquivo WAL para pontos de verificação.
+ `log_checkpoints`: por padrão, esse parâmetro está ativado. Isso faz com que uma mensagem seja enviada ao log do PostgreSQL para cada ponto de verificação. Essas mensagens de log incluem o número de buffers gravados, o tempo gasto para gravá-los e o número de arquivos WAL adicionados, removidos ou reciclados para determinado ponto de verificação.
Para obter mais informações sobre esse parâmetro, consulte [Error Reporting and Logging](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-CHECKPOINTS) (Relatórios de erros e registro em log) na documentação do PostgreSQL.
+ `checkpoint_warning`: esse parâmetro define um valor limite (em segundos) para a frequência do ponto de verificação acima da qual um aviso é gerado. Por padrão, esse parâmetro não é definido no RDS para PostgreSQL. Você pode definir o valor desse parâmetro para receber um aviso quando as alterações do banco de dados em sua instância de banco de dados do RDS para PostgreSQL forem gravadas a uma taxa para a qual os arquivos WAL não estão dimensionados para serem manipulados. Por exemplo, digamos que você definiu esse parâmetro como 30. Se sua instância do RDS para PostgreSQL precisar gravar alterações com maior frequência do que a cada 30 segundos, o aviso de que “pontos de verificação estão ocorrendo com muita frequência” será enviado ao log do PostgreSQL. Isso pode indicar que seu valor `max_wal_size` deve ser aumentado.
Para obter mais informações, consulte [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS) (Log de gravação antecipada) na documentação do PostgreSQL.
### Aumentar a escala de E/S verticalmente
Esse tipo de evento de espera de entrada/saída (IO) pode ser corrigido escalando as operações de entrada e saída por segundo (IOPs) para fornecer uma E/S mais rápida. Escalar a E/S é preferível a escalar a CPU, porque escalar a CPU pode ocasionar ainda mais contenção de E/S, pois a CPU aumentada pode lidar com mais trabalho e, assim, piorar ainda mais o gargalo de E/S. Em geral, recomendamos que você considere ajustar sua workload antes de realizar operações de escalabilidade.
### Volume de log dedicado (DLV)
Use um volume de log dedicado (DLV) para uma instância de banco de dados que usa o armazenamento de IOPS provisionadas (PIOPS) utilizando o console do Amazon RDS, AWS CLI a ou a API do Amazon RDS. Um DLV move os logs de transações do banco de dados do PostgreSQL para um volume de armazenamento separado do volume que contém as tabelas do banco de dados. Para ter mais informações, consulte [Volume de log dedicado (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).
# IPC: eventos de espera paralelos
Os seguintes `IPC:parallel wait events` indicam que uma sessão está aguardando a comunicação entre processos relacionada às operações de execução paralela de consultas.
+ `IPC:BgWorkerStartup`: um processo está aguardando um processo de operador concluir sua sequência de inicialização. Isso acontece ao inicializar operadores para execução paralela de consultas.
+ `IPC:BgWorkerShutdown`: um processo está aguardando um processo de operador concluir sua sequência de shutdown. Isso ocorre durante a fase de limpeza da execução paralela da consulta.
+ `IPC:ExecuteGather`: um processo está aguardando para receber dados de processos de operador paralelos durante a execução da consulta. Isso ocorre quando o processo líder precisa coletar resultados de seus operadores.
+ `IPC:ParallelFinish`: um processo está aguardando operadores paralelos terminarem sua execução e relatarem seus resultados finais. Isso acontece durante a fase de conclusão da execução paralela da consulta.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#rpg-ipc-parallel-context-supported)
+ [
## Contexto
](#rpg-ipc-parallel-context)
+ [
## Possíveis causas do maior número de esperas
](#rpg-ipc-parallel-causes)
+ [
## Ações
](#rpg-ipc-parallel-actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera têm suporte para todas as versões do Aurora PostgreSQL.
## Contexto
A execução paralela de consultas no PostgreSQL envolve vários processos trabalhando juntos para processar uma única consulta. Quando uma consulta é determinada como adequada para paralelização, um processo líder se coordena com um ou mais processos de operador paralelos com base na configuração de parâmetros `max_parallel_workers_per_gather`. O processo líder divide o trabalho entre os operadores, cada um processa sua parte dos dados de forma independente e os resultados são reunidos de volta ao processo líder.
**nota**
Cada operador paralelo opera como um processo separado com requisitos de recursos semelhantes a uma sessão completa de usuário. Isso significa que uma consulta paralela com 4 operadores pode consumir até 5 vezes mais recursos (CPU, memória, largura de banda de E/S) em comparação com uma consulta não paralela, pois tanto o processo líder quanto cada processo de operador mantêm suas próprias alocações de recursos. Por exemplo, configurações como `work_mem` são aplicadas individualmente a cada operador, potencialmente multiplicando o uso total de memória em todos os processos.
A arquitetura de consulta paralela consiste em três componentes principais:
+ Processo líder: o processo principal que inicia a operação paralela, divide a workload e coordena com os processos de operador.
+ Processos de operador: processos em segundo plano que executam partes da consulta em paralelo.
+ Fusão Gather/Gather: operações que combinam resultados de vários processos de operador de volta ao líder
Durante a execução paralela, os processos precisam se comunicar entre si por meio de mecanismos de comunicação entre processos (IPC). Esses eventos de espera do IPC ocorrem durante diferentes fases:
+ Inicialização do operador: quando operadores paralelos estão sendo inicializados
+ Troca de dados: quando os operadores estão processando dados e enviando resultados para o líder
+ Encerramento do operador: quando a execução paralela é concluída e os operadores estão sendo encerrados
+ Pontos de sincronização: quando os processos precisam se coordenar ou esperar que outros processos concluam suas tarefas
Compreender esses eventos de espera é crucial para diagnosticar problemas de desempenho relacionados à execução paralela de consultas, especialmente em ambientes de alta concorrência, nos quais várias consultas paralelas podem ser executadas simultaneamente.
## Possíveis causas do maior número de esperas
Vários fatores podem contribuir para um aumento nos eventos de espera do IPC relacionados ao paralelismo:
**Alta concorrência de consultas paralelas**
Quando muitas consultas paralelas são executadas simultaneamente, isso pode levar à contenção de recursos e ao aumento do tempo de espera para operações de IPC. Isso é particularmente comum em sistemas com altos volumes de transações ou workloads analíticas.
**Planos de consulta paralela subótimos**
Se o planejador de consultas escolher planos paralelos ineficientes, isso poderá resultar em paralelização desnecessária ou má distribuição do trabalho entre os operadores. Isso pode levar ao aumento das esperas de IPC, especialmente para eventos `IPC:ExecuteGather` e `IPC:ParallelFinish`. Esses problemas de planejamento geralmente resultam de estatísticas desatualizadas e do inchaço da tabela/índice.
**Inicialização e encerramento frequentes de operadores paralelos**
Consultas de curta duração que frequentemente iniciam e encerram operadores paralelos podem causar um aumento nos eventos `IPC:BgWorkerStartup` e `IPC:BgWorkerShutdown`. Isso geralmente é visto em workloads OLTP com muitas consultas pequenas e paralelizáveis.
**Restrições de recursos**
A capacidade limitada de CPU, memória ou E/S pode causar gargalos na execução paralela, levando ao aumento do tempo de espera em todos os eventos de IPC. Por exemplo, se a CPU estiver saturada, os processos de operador podem levar mais tempo para iniciar ou processar sua parte do trabalho.
**Estruturas complexas de consulta**
Consultas com vários níveis de paralelismo (por exemplo, junções paralelas seguidas por agregações paralelas) podem levar a padrões de IPC mais complexos e a tempos de espera potencialmente maiores, especialmente para eventos `IPC:ExecuteGather`.
**Conjuntos de resultados grandes**
Consultas que produzem grandes conjuntos de resultados podem causar maiores tempos de espera `IPC:ExecuteGather`, pois o processo líder passa mais tempo coletando e processando resultados dos processos de operador.
Entender esses fatores pode ajudar a diagnosticar e resolver problemas de desempenho relacionados à execução paralela de consultas no Aurora PostgreSQL.
## Ações
Quando você vê esperas relacionadas à consulta paralela, isso normalmente significa que um processo de backend está coordenando ou aguardando processos de operador paralelos. Essas esperas são comuns durante a execução de planos paralelos. Você pode investigar e mitigar o impacto dessas esperas monitorando o uso de operadores paralelos, revisando as configurações de parâmetros e ajustando a execução da consulta e a alocação de recursos.
**Topics**
+ [
### Analisar planos de consulta para paralelismo ineficiente
](#rpg-ipc-parallel-analyze-plans)
+ [
### Monitorar o uso de consultas paralelas
](#rpg-ipc-parallel-monitor)
+ [
### Revisar e ajustar as configurações de consulta paralela
](#rpg-ipc-parallel-adjust-settings)
+ [
### Otimizar a alocação de recursos
](#rpg-ipc-parallel-optimize-resources)
+ [
### Investigar o gerenciamento de conexão
](#rpg-ipc-parallel-connection-management)
+ [
### Revisar e otimizar as operações de manutenção
](#rpg-ipc-parallel-maintenance)
### Analisar planos de consulta para paralelismo ineficiente
A execução paralela de consultas pode frequentemente levar à instabilidade do sistema, picos de CPU e variações imprevisíveis no desempenho da consulta. É crucial analisar minuciosamente se o paralelismo realmente melhora sua workload específica. Use EXPLAIN ANALYZE para revisar os planos de execução de consultas paralelas.
Desative temporariamente o paralelismo no nível da sessão para comparar a eficiência do plano:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
```
Reative o paralelismo e compare:
```
RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE ;
```
Se a desativação do paralelismo produzir resultados melhores ou mais consistentes, desative-o para consultas específicas no nível da sessão usando os comandos SET. Para um impacto mais amplo, você pode querer desabilitar o paralelismo no nível da instância ajustando os parâmetros relevantes em seu grupo de parâmetros do banco de dados. Para obter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Monitorar o uso de consultas paralelas
Use as consultas a seguir para obter visibilidade da atividade e da capacidade de consultas paralelas:
Verifique os processos de operador paralelos ativos:
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
Esta consulta mostra o número de processos de operador paralelos ativos. Um valor alto pode indicar que seu `max\$1parallel\$1workers` está configurado com um valor alto e você pode querer reduzi-lo.
Verifique as consultas paralelas simultâneas:
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
Essa consulta retorna o número de processos líderes distintos que iniciaram consultas paralelas. Um número alto aqui indica que várias sessões estão executando consultas paralelas simultaneamente, o que pode aumentar a demanda de CPU e memória.
### Revisar e ajustar as configurações de consulta paralela
Analise os seguintes parâmetros para garantir que estejam alinhados à sua workload:
+ `max_parallel_workers`: número total de workers paralelos em todas as sessões.
+ `max_parallel_workers_per_gather`: máximo de workers por consulta.
Para workloads OLAP, aumentar esses valores pode melhorar o desempenho. Para workloads OLTP, valores mais baixos geralmente são preferidos.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Otimizar a alocação de recursos
Monitore a utilização da CPU e ajuste o número de vCPUs se for consistentemente alto e se seu aplicativo se beneficiar de consultas paralelas. Verifique se há memória adequada disponível para operações paralelas.
+ Use as métricas do Performance Insights para determinar se o sistema está limitado pela CPU.
+ Cada operador paralelo usa o seu próprio `work_mem`. Verifique se o uso total da memória está dentro dos limites da instância.
As consultas paralelas podem consumir substancialmente mais recursos do que as consultas não paralelas, porque cada processo de operador é completamente separado que tem aproximadamente o mesmo impacto no sistema que uma sessão de usuário adicional. Isso deve ser levado em consideração ao escolher um valor para essa configuração, bem como ao definir outras configurações que controlam a utilização de recursos, como `work_mem`. Para obter mais informações, consulte a [Documentação do PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Limites de recursos, como `work_mem`, são aplicados individualmente a cada operador, o que significa que a utilização total pode ser muito maior em todos os processos do que normalmente seria em qualquer processo único.
Aumente as vCPUs ou ajuste os parâmetros de memória se sua workload estiver altamente paralelizada.
### Investigar o gerenciamento de conexão
Se estiver experimentando esgotamento de conexões, revise as estratégias de pool de conexões do aplicativo. Implemente o pool de conexões no nível do aplicativo, se ainda não estiver em uso.
### Revisar e otimizar as operações de manutenção
Coordene a criação de índices e outras tarefas de manutenção para evitar a contenção de recursos. Agende essas operações fora do horário de pico. Evite agendar manutenções pesadas (por exemplo, construções paralelas de índices) durante períodos de alta carga de consultas do usuário. Essas operações podem consumir workers paralelos e impactar o desempenho de consultas regulares.
# IPC:ProcArrayGroupUpdate
O evento `IPC:ProcArrayGroupUpdate` ocorre quando uma sessão está aguardando o líder do grupo atualizar o status da transação ao final dessa operação. Embora o PostgreSQL geralmente associe eventos de espera do tipo IPC a operações de consulta paralela, esse evento de espera determinado não é específico de consultas paralelas.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#apg-rpg-ipcprocarraygroup.supported)
+ [
## Contexto
](#apg-rpg-ipcprocarraygroup.context)
+ [
## Possíveis causas do maior número de esperas
](#apg-rpg-ipcprocarraygroup.causes)
+ [
## Ações
](#apg-rpg-ipcprocarraygroup.actions)
## Versões compatíveis do mecanismo
As informações sobre esse evento de espera são aceitas em todas as versões do RDS para PostgreSQL.
## Contexto
**Noções básicas sobre a matriz do processo**: a matriz do processo (proc) é uma estrutura de memória compartilhada no PostgreSQL. Ela contém informações sobre todos os processos em execução, incluindo detalhes da transação. Durante a conclusão da transação (`COMMIT` ou `ROLLBACK`), o ProcArray precisa ser atualizado para refletir a alteração e limpar o ID da transação da matriz. A sessão que tenta concluir sua transação deve adquirir um bloqueio exclusivo no ProcArray. Isso impede que outros processos tenham bloqueios compartilhados ou exclusivos.
**Mecanismo de atualização de grupo**: ao executar um COMMIT ou ROLLBACK, se um processo de backend não conseguir recuperar um ProcArrayLock no modo exclusivo, ele atualizará um campo especial chamado ProcArrayGroupMember. Isso adiciona a transação à lista de sessões que pretendem terminar. Esse processo de backend então é suspenso, e o tempo de suspensão é instrumentado como o evento de espera ProcArrayGroupUpdate. O primeiro processo no ProcArray com o procArrayGroupMember, conhecido como processo líder, adquire o ProcArrayLock no modo exclusivo. Depois, ele limpa a lista de processos que aguardam a limpeza do transactionID do grupo. Quando isso é concluído, o líder libera o ProcArrayLock e, depois, ativa todos os processos dessa lista, notificando-os de que a transação foi concluída.
## Possíveis causas do maior número de esperas
Quanto mais processos estiverem em execução, mais tempo um líder manterá um procArrayLock no modo exclusivo. Consequentemente, quanto mais transações de gravação ocorrerem, maior a chance de entrarem em um cenário de atualização em grupo, causando um possível acúmulo de processos aguardando o evento de espera `ProcArrayGroupUpdate`. Na visualização Top SQL do Database Insights, você verá que COMMIT é a declaração com a maior parte desse evento de espera. Isso é esperado, mas exigirá uma investigação mais profunda do SQL de gravação específico que está sendo executado para determinar qual ação apropriada realizar.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Identifique eventos `IPC:ProcArrayGroupUpdate` utilizando o Insights de Performance do Amazon RDS ou consultando a visualização `pg_stat_activity` do sistema PostgreSQL.
**Topics**
+ [
### Monitorar operações de confirmação e reversão de transações
](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [
### Reduzir a simultaneidade
](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [
### Implementar o agrupamento de conexões
](#apg-rpg-ipcprocarraygroup.actions.pooling)
+ [
### Usar um armazenamento mais rápido
](#apg-rpg-ipcprocarraygroup.actions.storage)
### Monitorar operações de confirmação e reversão de transações
**Monitorar confirmações e reversões**: um número maior de confirmações e reversões pode aumentar a pressão sobre o ProcArray. Por exemplo, se uma instrução SQL começar a falhar devido ao aumento das violações de chaves duplicadas, você poderá observar um aumento nas reversões, o que pode aumentar a contenção do ProcArray e o inchaço da tabela.
O Amazon RDS Database Insights fornece as métricas `xact_commit` e `xact_rollback` do PostgreSQL e relata o número de confirmações e reversões por segundo.
### Reduzir a simultaneidade
**Transações em lote**: sempre que possível, agrupe operações em transações únicas para reduzir as operações de confirmação/reversão.
**Limitar a simultaneidade**: reduza o número de transações ativas simultaneamente para aliviar a contenção de bloqueios no ProcArray. Embora isso exija alguns testes, reduzir o número total de conexões simultâneas pode reduzir a contenção e manter o throughput.
### Implementar o agrupamento de conexões
**Soluções de agrupamento de conexões**: use o grupo de conexões para gerenciar conexões de banco de dados com eficiência, reduzindo o número total de backends e, portanto, a workload no ProcArray. Embora isso exija alguns testes, reduzir o número total de conexões simultâneas pode reduzir a contenção e manter o throughput.
**Reduzir os surtos de conexão**: da mesma forma, um padrão de criação e encerramento frequentes de conexões causa pressão adicional no ProcArray. Ao reduzir esse padrão, a contenção geral é reduzida.
### Usar um armazenamento mais rápido
**Volume de log dedicado**: se o evento de espera `IPC:ProcArrayGroupUpdate` for acompanhado por eventos de alta espera `IO:WALWrite`, a configuração de um volume de logs dedicado poderá reduzir o gargalo de gravação no WAL. Por sua vez, isso melhora a performance das confirmações.
Para acessar mais informações, consulte [Volume de logs dedicado](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.dlv.html).
# Lock:advisory
O evento `Lock:advisory` ocorre quando uma aplicação PostgreSQL utiliza um bloqueio para coordenar as atividades em várias sessões.
**Topics**
+ [
## Versões de mecanismos relevantes
](#wait-event.lockadvisory.context.supported)
+ [
## Contexto
](#wait-event.lockadvisory.context)
+ [
## Causas
](#wait-event.lockadvisory.causes)
+ [
## Ações
](#wait-event.lockadvisory.actions)
## Versões de mecanismos relevantes
As informações sobre eventos de espera são relevantes para o RDS para PostgreSQL versão 9.6 e versões superiores.
## Contexto
Bloqueios consultivos do PostgreSQL são bloqueios cooperativos em nível de aplicação, feitos explicitamente e desfeitos pelo código da aplicação do usuário. Uma aplicação pode utilizar bloqueios consultivos do PostgreSQL para coordenar atividades em várias sessões. Ao contrário de bloqueios regulares, ou em nível de objeto ou linha, a aplicação tem controle total ao longo da vida útil do bloqueio. Para obter mais informações, consulte o tópico sobre [Bloqueios consultivos](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) na documentação do PostgreSQL.
Bloqueios consultivos podem ser liberados antes que uma transação termine ou podem ser mantidos por uma sessão em todas as transações. Isso não é válido para bloqueios implícitos aplicados pelo sistema, como um bloqueio exclusivo de acesso em uma tabela adquirida por uma instrução `CREATE INDEX`.
Para obter uma descrição das funções utilizadas para adquirir (bloquear) e liberar (desbloquear) bloqueios consultivos, consulte o tópico sobre [Funções de bloqueios consultivos](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS), na documentação do PostgreSQL.
Bloqueios consultivos são implementados sobre o sistema de bloqueio regular do PostgreSQL e ficam visíveis na visualização do sistema `pg_locks`.
## Causas
Esse tipo de bloqueio é controlado exclusivamente por uma aplicação que o utiliza explicitamente. Bloqueios consultivos que são adquiridos para cada linha como parte de uma consulta podem causar um aumento nos bloqueios ou um acúmulo a longo prazo.
Esses efeitos acontecem quando a consulta é executada de uma maneira que adquire bloqueios em mais linhas do que as retornadas pela consulta. A aplicação deve eventualmente liberar todos os bloqueios, mas, se eles forem adquiridos em linhas que não são retornadas, a aplicação não poderá localizar todos os bloqueios.
O exemplo a seguir foi extraído do tópico [Bloqueios consultivos](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) na documentação do PostgreSQL.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
Nesse exemplo, a cláusula `LIMIT` apenas pode interromper a saída da consulta depois que as linhas já foram selecionadas internamente e seus valores de ID estão bloqueados. Isso pode acontecer repentinamente quando um volume de dados crescente faz com que o planejador escolha um plano de execução diferente que não foi testado durante o desenvolvimento. O acúmulo nesse caso acontece porque a aplicação chama explicitamente `pg_advisory_unlock` para cada valor de ID bloqueado. No entanto, nesse caso, não é possível encontrar o conjunto de bloqueios adquiridos em linhas que não foram retornadas. Como os bloqueios são adquiridos em nível de sessão, eles não são liberados automaticamente no final da transação.
Outra possível causa para picos em tentativas de bloqueio bloqueadas são conflitos não intencionais. Nesses conflitos, partes não relacionadas da aplicação compartilham o mesmo espaço de ID de bloqueio por engano.
## Ações
Revise o uso da aplicação de bloqueios consultivos e detalhe onde e quando no fluxo de aplicação cada tipo de bloqueio consultivo é adquirido e liberado.
Determine se uma sessão está adquirindo muitos bloqueios ou se uma sessão de longa execução não está liberando bloqueios cedo o suficiente, resultando em um acúmulo lento de bloqueios. Você pode corrigir um acúmulo lento de bloqueios em nível de sessão encerrando a sessão com `pg_terminate_backend(pid)`.
Um cliente que aguarda um bloqueio de consultoria aparece em `pg_stat_activity` com `wait_event_type=Lock` e `wait_event=advisory`. É possível obter valores de bloqueio específicos consultando a visualização do sistema `pg_locks` em busca do mesmo `pid`, procurando `locktype=advisory` e `granted=f`.
Em seguida, identifique a sessão de bloqueio consultando `pg_locks` em busca do mesmo bloqueio consultivo que possui `granted=t`, conforme mostrado no exemplo a seguir.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
Todas as funções de API de bloqueio consultivo têm dois conjuntos de argumentos, um argumento `bigint` ou dois argumentos `integer`:
+ Para as funções de API com um único argumento `bigint`, os 32 bits superiores estão em `pg_locks.classid` e os 32 bits inferiores estão em `pg_locks.objid`.
+ Para as funções da API com dois argumentos `integer`, o primeiro argumento é `pg_locks.classid` e o segundo é `pg_locks.objid`.
O valor `pg_locks.objsubid` indica qual formato de API foi utilizado: `1` significa um argumento `bigint`; `2`significa dois argumentos `integer`.
# Lock:extend
O evento `Lock:extend` ocorre quando um processo de backend está aguardando para bloquear uma relação com o objetivo de a estender, enquanto outro processo tem um bloqueio nessa relação para o mesmo objetivo.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.lockextend.context.supported)
+ [
## Contexto
](#wait-event.lockextend.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.lockextend.causes)
+ [
## Ações
](#wait-event.lockextend.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Contexto
O evento `Lock:extend` indica que um processo de backend está aguardando para estender uma relação na qual outro processo de backend mantém um bloqueio enquanto estende essa relação. Como apenas um processo por vez pode estender uma relação, o sistema gera um evento de espera `Lock:extend`. Operações `INSERT`, `COPY` e `UPDATE` podem gerar esse evento.
## Possíveis causas do maior número de esperas
Quando o evento `Lock:extend` aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
**Surto de inserções simultâneas ou atualizações na mesma tabela **
Pode haver um aumento no número de sessões simultâneas com consultas que inserem ou atualizam a mesma tabela.
**Largura de banda da rede insuficiente**
É possível que a largura de banda da rede na instância de banco de dados para as necessidades de comunicação de armazenamento da workload atual. Isso pode contribuir para a latência de armazenamento que causa um aumento em eventos `Lock:extend`.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [
### Reduzir inserções e atualizações simultâneas para a mesma relação
](#wait-event.lockextend.actions.action1)
+ [
### Aumentar a largura de banda da rede
](#wait-event.lockextend.actions.increase-network-bandwidth)
### Reduzir inserções e atualizações simultâneas para a mesma relação
Primeiro, determine se há um aumento nas métricas `tup_inserted` e `tup_updated` e um aumento acompanhante nesse evento de espera. Em caso afirmativo, verifique quais relações estão em alta disputa por operações de inserção e atualização. Para determinar isso, consulte a visualização `pg_stat_all_tables` para os valores nos campos `n_tup_ins` e `n_tup_upd`. Para obter mais informações sobre a visualização `pg_stat_all_tables`, consulte [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) na documentação do PostgreSQL.
Para obter mais informações sobre bloqueio e consultas bloqueadas, consulte `pg_stat_activity` como no exemplo a seguir:
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
Depois de identificar relações que contribuem para o aumento dos eventos `Lock:extend`, utilize as seguintes técnicas para reduzir a contenção:
+ Descubra se é possível utilizar o particionamento para reduzir a contenção para a mesma tabela. Separar tuplas inseridas ou atualizadas em partições diferentes pode reduzir a contenção. Para obter informações sobre particionamento, consulte [Gerenciar partições do PostgreSQL com a extensão pg\$1partman](PostgreSQL_Partitions.md).
+ Se o evento de espera for principalmente devido a atividades de atualização, reduza o valor do fator de preenchimento da relação. Isso pode reduzir as solicitações de novos bloqueios durante a atualização. O fator de preenchimento é um parâmetro de armazenamento de uma tabela que determina o espaço máximo para empacotar uma página de tabela. Ele é expresso como uma porcentagem do espaço total de uma página. Para obter mais informações sobre o parâmetro de fator de preenchimento, consulte [CREATE TABLE](https://www.postgresql.org/docs/13/sql-createtable.html) na documentação do PostgreSQL.
**Importante**
É altamente recomendável testar seu sistema se você alterar o fator de preenchimento, pois isso pode afetar negativamente a performance dependendo da workload.
### Aumentar a largura de banda da rede
Para ver se há um aumento na latência de gravação, verifique a métrica `WriteLatency` no CloudWatch. Se houver, use as métricas `WriteThroughput` e `ReadThroughput` do Amazon CloudWatch para monitorar o tráfego relacionado ao armazenamento na instância de banco de dados. Essas métricas podem ajudar a determinar se a largura de banda da rede é suficiente para a atividade de armazenamento da sua workload.
Se a largura de banda da rede não suficiente, aumente-a. Se a sua instância de banco de dados estiver atingindo os limites de largura de banda da rede, a única maneira de aumentar a largura de banda será ampliar o tamanho da instância de banco de dados.
Para obter mais informações sobre métricas do CloudWatch, consulte [Métricas específicas da instância do Amazon CloudWatch para Amazon RDS](rds-metrics.md#rds-cw-metrics-instance). Para obter informações sobre a performance de rede de cada classe de instância de banco de dados, consulte [Métricas específicas da instância do Amazon CloudWatch para Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
# Lock:Relation
O evento `Lock:Relation` ocorre quando uma consulta está aguardando para adquirir um bloqueio em uma tabela ou visualização (relação) que está atualmente bloqueada por outra transação.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.lockrelation.context.supported)
+ [
## Contexto
](#wait-event.lockrelation.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.lockrelation.causes)
+ [
## Ações
](#wait-event.lockrelation.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Contexto
A maioria dos comandos PostgreSQL utiliza bloqueios implicitamente para controlar o acesso simultâneo aos dados em tabelas. Também é possível utilizar esses bloqueios explicitamente no código da aplicação com o comando `LOCK`. Vários modos de bloqueio não são compatíveis entre si e podem bloquear transações quando tentam acessar o mesmo objeto. Quando isso acontece, o RDS para PostgreSQL gera um evento `Lock:Relation`. Veja a seguir alguns exemplos comuns:
+ Bloqueios exclusivos, como `ACCESS EXCLUSIVE`, podem bloquear todo o acesso simultâneo. Operações de linguagem de definição de dados (DDL), como `DROP TABLE`, `TRUNCATE`, `VACUUM FULL` e `CLUSTER`, adquirem bloqueios `ACCESS EXCLUSIVE` implicitamente. `ACCESS EXCLUSIVE` também é o modo de bloqueio padrão para instruções `LOCK TABLE` que não especificam um modo explicitamente.
+ Usar `CREATE INDEX (without CONCURRENT)` em uma tabela gera conflito com instruções de linguagem de manipulação de dados (DML) `UPDATE`, `DELETE` e `INSERT`, que adquirem bloqueios `ROW EXCLUSIVE`.
Para obter mais informações sobre bloqueios em nível da tabela e modos de bloqueio conflitantes, consulte o tópico sobre [Bloqueio explícito](https://www.postgresql.org/docs/13/explicit-locking.html) na documentação do PostgreSQL.
Normalmente, o bloqueio de consultas e transações é liberado de uma das seguintes maneiras:
+ Consulta de bloqueio: a aplicação pode cancelar a consulta ou o usuário pode encerrar o processo. O mecanismo também pode forçar a finalização da consulta devido a um tempo limite de declaração de uma sessão ou um mecanismo de detecção de deadlock.
+ Transação de bloqueio: uma transação para de bloquear quando executa uma instrução `ROLLBACK` ou `COMMIT`. Reversões também acontecem automaticamente quando as sessões são desconectadas por um cliente ou por problemas de rede, ou quando são encerradas. As sessões podem ser encerradas quando o mecanismo de banco de dados é desligado, quando o sistema está sem memória e assim por diante.
## Possíveis causas do maior número de esperas
Quando o evento `Lock:Relation` ocorre com maior frequência do que o normal, pode indicar um problema de performance. As causas típicas incluem:
**Maior número de sessões simultâneas com bloqueios de tabela conflitantes**
Pode haver um aumento no número de sessões simultâneas com consultas que bloqueiam a mesma tabela com modos de bloqueio conflitantes.
**Operações de manutenção**
Operações de manutenção de integridade, como `VACUUM` e `ANALYZE`, podem aumentar significativamente o número de bloqueios conflitantes. `VACUUM FULL` adquire um bloqueio `ACCESS EXCLUSIVE` e `ANALYSE` adquire um bloqueio `SHARE UPDATE EXCLUSIVE`. Ambos os tipos de bloqueios podem causar um evento de espera `Lock:Relation`. Operações de manutenção de dados de aplicações, como atualizar uma visualização materializada, também podem aumentar as consultas e transações bloqueadas.
**Bloqueios em instâncias de leitor**
Pode haver um conflito entre os bloqueios de relação mantidos pelo gravador e os leitores. No momento, só bloqueios de relação do `ACCESS EXCLUSIVE` são replicados para instâncias do leitor. No entanto, o bloqueio de relação do `ACCESS EXCLUSIVE` entrará em conflito com qualquer bloqueio de relação do `ACCESS SHARE` mantido pelo leitor. Isso pode causar um aumento nos eventos de espera de relação de bloqueio no leitor.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [
### Reduzir o impacto do bloqueio de instruções SQL
](#wait-event.lockrelation.actions.reduce-blocks)
+ [
### Minimizar o efeito de operações de manutenção
](#wait-event.lockrelation.actions.maintenance)
### Reduzir o impacto do bloqueio de instruções SQL
Para reduzir o impacto do bloqueio de instruções SQL, modifique o código da aplicação sempre que possível. Veja a seguir duas técnicas comuns para reduzir bloqueios:
+ Usar a opção `NOWAIT`: alguns comandos SQL, como instruções `SELECT` e `LOCK`, oferecem suporte a essa opção. A diretiva `NOWAIT` cancela a consulta de solicitação de bloqueio quando o bloqueio não pode ser adquirido imediatamente. Essa técnica pode evitar que uma sessão de bloqueio cause um empilhamento de sessões bloqueadas por detrás dela.
Por exemplo: suponha que a transação A esteja aguardando um bloqueio mantido pela transação B. Se B solicitar um bloqueio em uma tabela bloqueada pela transação C, a transação A poderá ser bloqueada até a conclusão da transação C. Porém, se a transação B utilizar um `NOWAIT` quando solicitar o bloqueio em C, ela pode falhar rapidamente e garantir que a transação A não precise aguardar indefinidamente.
+ Usar `SET lock_timeout`: defina um valor de `lock_timeout` para limitar o tempo de espera de uma instrução SQL para adquirir um bloqueio em uma relação. Se o bloqueio não for adquirido dentro do tempo limite definido, a transação que o está solicitando será cancelada. Defina o valor no nível da sessão.
### Minimizar o efeito de operações de manutenção
Operações de manutenção, como `VACUUM` e `ANALYZE`, são importantes. Recomendamos que você não as desative ao encontrar eventos de espera `Lock:Relation` relacionados a essas operações de manutenção. As abordagens a seguir podem minimizar o efeito dessas operações:
+ Execute operações de manutenção manualmente fora do horário de pico.
+ Para reduzir esperas `Lock:Relation` causadas por tarefas de autovacuum, realize qualquer ajuste de autovacuum necessário. Para obter mais informações sobre ajuste de autovacuum, consulte [Trabalhar com o autovacuum do PostgreSQL no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html), no *Guia do usuário do Amazon RDS*.
# Lock:transactionid
O evento `Lock:transactionid` ocorre quando uma transação está aguardando um bloqueio em nível de linha.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.locktransactionid.context.supported)
+ [
## Contexto
](#wait-event.locktransactionid.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.locktransactionid.causes)
+ [
## Ações
](#wait-event.locktransactionid.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Contexto
O evento `Lock:transactionid` ocorre quando uma transação está tentando adquirir um bloqueio em nível de linha já concedido a uma transação que está sendo executada simultaneamente. A sessão que mostra o evento de espera `Lock:transactionid` está bloqueada devido a esse bloqueio. Depois que a transação de bloqueio terminar em uma instrução `COMMIT` ou `ROLLBACK`, a transação bloqueada pode continuar.
A semântica de controle de simultaneidade de várias versões do RDS para PostgreSQL garante que os leitores não bloqueiem gravadores e que os gravadores não bloqueiem os leitores. Para que ocorram conflitos em nível de linha, transações de bloqueio e bloqueadas devem emitir instruções conflitantes dos seguintes tipos:
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
A instrução `SELECT … FOR KEY SHARE` é um caso especial. O banco de dados usa a cláusula `FOR KEY SHARE` para otimizar a performance da integridade referencial. Um bloqueio em nível de linha em uma linha pode bloquear comandos `INSERT`, `UPDATE` e `DELETE` em outras tabelas que fazem referência à linha.
## Possíveis causas do maior número de esperas
Quando esse evento aparece mais do que o normal, a causa geralmente envolve instruções `UPDATE`, `SELECT … FOR UPDATE` ou `SELECT … FOR KEY SHARE` combinadas com as seguintes condições.
**Topics**
+ [
### Alta simultaneidade
](#wait-event.locktransactionid.concurrency)
+ [
### Ocioso na transação
](#wait-event.locktransactionid.idle)
+ [
### Transações de longa execução
](#wait-event.locktransactionid.long-running)
### Alta simultaneidade
O RDS para PostgreSQL pode utilizar semântica de bloqueio granular em nível de linha. A probabilidade de conflitos em nível de linha aumenta quando as condições a seguir são atendidas:
+ Uma workload altamente simultânea controla as mesmas linhas.
+ A simultaneidade aumenta.
### Ocioso na transação
Às vezes, a coluna `pg_stat_activity.state` mostra o valor `idle in transaction`. Esse valor aparece para sessões que iniciaram uma transação, mas ainda não emitiram um `COMMIT` ou `ROLLBACK`. Se o valor de `pg_stat_activity.state` não for `active`, a consulta mostrada em `pg_stat_activity` será a mais recente a terminar a execução. A sessão de bloqueio não está processando uma consulta ativamente porque uma transação aberta está mantendo um bloqueio.
Se uma transação ociosa adquiriu um bloqueio em nível de linha, talvez ela esteja impedindo que outras sessões o adquiram. Essa condição leva à ocorrência frequente do evento de espera `Lock:transactionid`. Para diagnosticar o problema, examine a saída proveniente de `pg_stat_activity` e `pg_locks`.
### Transações de longa execução
Transações executadas por um longo tempo recebem bloqueios por um longo tempo. Esses bloqueios de longa duração podem impedir que outras transações sejam executadas.
## Ações
O bloqueio de linhas é um conflito entre instruções `UPDATE`, `SELECT … FOR UPDATE` ou `SELECT … FOR KEY SHARE`. Antes de tentar uma solução, descubra quando essas instruções estão sendo executadas na mesma linha. Use essas informações para escolher uma estratégia descrita nas seguintes seções.
**Topics**
+ [
### Responder a alta simultaneidade
](#wait-event.locktransactionid.actions.problem)
+ [
### Responder a transações ociosas
](#wait-event.locktransactionid.actions.find-blocker)
+ [
### Responder a transações de longa duração
](#wait-event.locktransactionid.actions.concurrency)
### Responder a alta simultaneidade
Se a simultaneidade for o problema, tente uma das seguintes técnicas:
+ Reduza a simultaneidade na aplicação. Por exemplo, reduza o número de sessões ativas.
+ Implemente um pool de conexões. Para saber como agrupar conexões com o RDS Proxy, consulte [Amazon RDS Proxy](rds-proxy.md).
+ Projete a aplicação ou o modelo de dados para evitar a contenção de instruções `UPDATE` e `SELECT … FOR UPDATE`. Também é possível diminuir o número de chaves estrangeiras acessadas por instruções `SELECT … FOR KEY SHARE`.
### Responder a transações ociosas
Se `pg_stat_activity.state` mostrar `idle in transaction`, utilize as seguintes estratégias:
+ Ative a confirmação automática sempre que possível. Essa abordagem impede que transações bloqueiem outras transações enquanto aguardam `COMMIT` ou `ROLLBACK`.
+ Procure caminhos de código que não contenham `COMMIT`, `ROLLBACK` ou `END`.
+ Assegure-se de que a lógica de tratamento de exceções na seu aplicação sempre tenha um caminho para um válido `end of transaction`.
+ Assegure-se de que a sua aplicação processe os resultados da consulta depois de encerrar a transação com `COMMIT` ou `ROLLBACK`.
### Responder a transações de longa duração
Se transações de longa duração estiverem causando a ocorrência frequente de `Lock:transactionid`, tente as estratégias a seguir:
+ Mantenha os bloqueios de linha fora de transações de longa execução.
+ Limite o comprimento das consultas implementando a confirmação automática sempre que possível.
# Lock:tuple
O evento `Lock:tuple` ocorre quando um processo de backend está aguardando para adquirir um bloqueio em uma tupla.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.locktuple.context.supported)
+ [
## Contexto
](#wait-event.locktuple.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.locktuple.causes)
+ [
## Ações
](#wait-event.locktuple.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Contexto
O evento `Lock:tuple` indica que um backend está aguardando para adquirir um bloqueio em uma tupla enquanto outro backend mantém um bloqueio conflitante na mesma tupla. A tabela a seguir ilustra um cenário em que as sessões geram o evento `Lock:tuple`.
| Tempo | Sessão 1 | Sessão 2 | Sessão 3 |
| --- | --- | --- | --- |
| t1 | Inicia uma transação. | | |
| t2 | Atualiza a linha 1. | | |
| t3 | | Atualiza a linha 1. A sessão adquire um bloqueio exclusivo na tupla e aguarda a sessão 1 liberar esse bloqueio via confirmação ou reversão. | |
| t4 | | | Atualiza a linha 1. A sessão aguarda a sessão 2 liberar o bloqueio exclusivo na tupla. |
Outra alternativa é simular esse evento de espera utilizando a ferramenta de benchmarking `pgbench`. Configure um número elevado de sessões simultâneas para atualizar a mesma linha em uma tabela com um arquivo SQL personalizado.
Para saber mais sobre modos de bloqueio conflitantes, consulte o tópico sobre [Bloqueio explícito](https://www.postgresql.org/docs/current/explicit-locking.html), na documentação do PostgreSQL. Para saber mais sobre `pgbench`, consulte [pgbench](https://www.postgresql.org/docs/current/pgbench.html) na documentação do PostgreSQL.
## Possíveis causas do maior número de esperas
Quando esse evento aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
+ Um número elevado de sessões simultâneas está tentando adquirir um bloqueio conflitante para a mesma tupla executando instruções `UPDATE` ou `DELETE`.
+ Sessões altamente simultâneas estão executando uma instrução `SELECT` utilizando os modos de bloqueio `FOR UPDATE` ou `FOR NO KEY UPDATE`.
+ Diversos fatores fazem com que grupos de aplicações ou conexões abram mais sessões para executar as mesmas operações. À medida que novas sessões estão tentando modificar as mesmas linhas, a carga de banco de dados pode atingir picos e `Lock:tuple` pode surgir.
Para obter mais informações, consulte o tópico sobre [Bloqueios em nível de linha](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS), na documentação do PostgreSQL.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [
### Investigar a lógica da sua aplicação
](#wait-event.locktuple.actions.problem)
+ [
### Localizar a sessão bloqueadora
](#wait-event.locktuple.actions.find-blocker)
+ [
### Reduzir a simultaneidade quando ela estiver elevada
](#wait-event.locktuple.actions.concurrency)
+ [
### Solucionar problemas de gargalos
](#wait-event.locktuple.actions.bottlenecks)
### Investigar a lógica da sua aplicação
Descubra se uma sessão bloqueadora está no estado `idle in transaction` por muito tempo. Em caso positivo, considere encerrar a sessão bloqueadora como uma solução de curto prazo. Também é possível utilizar a função `pg_terminate_backend`. Para obter mais informações sobre essa função, consulte [Funções de sinalização de servidor](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL), na documentação do PostgreSQL.
Para uma solução de longo prazo, faça o seguinte:
+ Ajuste a lógica da aplicação.
+ Use o parâmetro `idle_in_transaction_session_timeout`. Esse parâmetro encerra qualquer sessão com uma transação aberta que tenha ficado ociosa por um tempo maior que o especificado. Para obter mais informações, consulte o tópico sobre [Padrões de conexão de clientes](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT), na documentação do PostgreSQL.
+ Use a confirmação automática o máximo possível. Para obter mais informações, consulte [SET AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html), na documentação do PostgreSQL.
### Localizar a sessão bloqueadora
Enquanto o evento de espera `Lock:tuple` está ocorrendo, identifique a sessão bloqueadora e a sessão bloqueada descobrindo quais bloqueios dependem um do outro. Para obter mais informações, consulte o tópico sobre [Informações de dependências de bloqueios](https://wiki.postgresql.org/wiki/Lock_dependency_information), na wiki do PostgreSQL.
O exemplo a seguir consulta todas as sessões, filtrando em `tuple` e ordenando por `wait_time`.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
### Reduzir a simultaneidade quando ela estiver elevada
O evento `Lock:tuple` pode ocorrer constantemente, especialmente em um tempo de workload ocupado. Nessa situação, considere reduzir a simultaneidade elevada para linhas muito ocupadas. Várias vezes, apenas algumas linhas controlam uma fila ou a lógica booleana, o que torna essas linhas muito ocupadas.
Você pode reduzir a simultaneidade utilizando diferentes abordagens com base no seu requisito de negócios, na lógica da aplicação e no tipo de workload. Por exemplo, você pode fazer o seguinte:
+ Reformule sua tabela e a lógica de dados para reduzir a simultaneidade elevada.
+ Altere a lógica da aplicação para reduzir a simultaneidade elevada no nível da linha.
+ Aproveite e reformule consultas com bloqueios em nível de linha.
+ Use a cláusula `NOWAIT` com operações de novas tentativas.
+ Considere utilizar o controle de simultaneidade lógico otimista e bloqueio híbrido.
+ Considere modificar o nível de isolamento do banco de dados.
### Solucionar problemas de gargalos
O `Lock:tuple` pode ocorrer com gargalos, como falta de CPU ou uso máximo da largura de banda do Amazon EBS. Para diminuir gargalos, considere as seguintes abordagens:
+ Aumente a escala do seu tipo de classe de instância na vertical.
+ Otimize consultas que consomem muitos recursos.
+ Altere a lógica da aplicação.
+ Arquive dados acessados raramente.
# LWLock:BufferMapping (LWLock:buffer\$1mapping)
Esse evento ocorre quando uma sessão está aguardando para associar um bloco de dados a um buffer no grupo de buffer compartilhado.
**nota**
Esse evento é denominado `LWLock:BufferMapping` para o RDS para PostgreSQL versão 13 e posteriores. No caso do RDS para PostgreSQL versão 12 e posteriores, esse evento é denominado `LWLock:buffer_mapping`.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.lwl-buffer-mapping.context.supported)
+ [
## Contexto
](#wait-event.lwl-buffer-mapping.context)
+ [
## Causas
](#wait-event.lwl-buffer-mapping.causes)
+ [
## Ações
](#wait-event.lwl-buffer-mapping.actions)
## Versões compatíveis do mecanismo
As informações de eventos de espera são relevantes para o RDS para PostgreSQL versão 9.6 e posteriores.
## Contexto
O *grupo de buffer compartilhado* é uma área de memória do PostgreSQL que contém todas as páginas que estão ou estavam sendo utilizadas por processos. Quando um processo precisa de uma página, ele lê a página no grupo de buffer compartilhado. O parâmetro `shared_buffers` define o tamanho do buffer compartilhado e reserva uma área de memória para armazenar a tabela e as páginas de índice. Se você alterar esse parâmetro, reinicie o banco de dados.
O evento de espera `LWLock:buffer_mapping` ocorre nos seguintes cenários:
+ Um processo pesquisa a tabela de buffer em busca de uma página e adquire um bloqueio de mapeamento de buffer compartilhado.
+ Um processo carrega uma página no grupo de buffer e adquire um bloqueio exclusivo de mapeamento de buffer.
+ Um processo remove uma página do grupo e adquire um bloqueio exclusivo de mapeamento de buffer.
## Causas
Quando esse evento aparece mais do que o normal, possivelmente indicando um problema de performance, o banco de dados está paginando dentro e fora do grupo de buffer compartilhado. As causas típicas incluem:
+ Consultas grandes
+ Índices e tabelas inchados
+ Varreduras completas de tabelas
+ Um tamanho de grupo compartilhado menor que o conjunto de trabalho
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [
### Monitorar métricas relacionadas ao buffer
](#wait-event.lwl-buffer-mapping.actions.monitor-metrics)
+ [
### Avaliar sua estratégia de indexação
](#wait-event.lwl-buffer-mapping.actions.indexes)
+ [
### Diminuir o número de buffers que devem ser alocados rapidamente
](#wait-event.lwl-buffer-mapping.actions.buffers)
### Monitorar métricas relacionadas ao buffer
Quando as esperas `LWLock:buffer_mapping` atingirem picos, investigue a taxa de acertos de buffer. É possível utilizar essas métricas para entender melhor o que está acontecendo no cache de buffer. Examine as métricas a seguir:
`blks_hit`
Essa métrica de contador do Performance Insights indica o número de bloqueios que foram recuperados do grupo de buffer compartilhado. Após o surgimento do evento de espera `LWLock:buffer_mapping`, é possível observar um pico em `blks_hit`.
`blks_read`
Essa métrica de contador do Performance Insights indica o número de bloqueios que exigiram a leitura da E/S no grupo de buffer compartilhado. Você pode observar um pico em `blks_read` em preparação para o evento de espera `LWLock:buffer_mapping`.
### Avaliar sua estratégia de indexação
Para confirmar que sua estratégia de indexação não está diminuindo a performance, verifique o seguinte:
Inchaço de índice
Assegure-se de que o índice e o inchaço da tabela não estejam fazendo com que páginas desnecessárias sejam lidas no buffer compartilhado. Se as suas tabelas contiverem linhas não utilizadas, considere arquivar os dados e remover as linhas das tabelas. Em seguida, você poderá reconstruir os índices para as tabelas redimensionadas.
Índices para consultas utilizadas com frequência
Para determinar se você tem os índices ideais, monitore as métricas do mecanismo de banco de dados no Performance Insights. A métrica `tup_returned` mostra o número de linhas lidas. A métrica `tup_fetched` mostra o número de linhas retornadas ao cliente. Se `tup_returned` for significativamente maior que `tup_fetched`, talvez os dados não estejam devidamente indexados. Além disso, as estatísticas da tabela podem não estar atualizadas.
### Diminuir o número de buffers que devem ser alocados rapidamente
Para diminuir os eventos de espera `LWLock:buffer_mapping`, tente reduzir o número de buffers que devem ser alocados rapidamente. Uma estratégia é realizar operações em lote menores. Talvez seja possível obter lotes menores particionando tabelas.
# LWLock:BufferIO (IPC:BufferIO)
O evento `LWLock:BufferIO` ocorre quando o RDS para PostgreSQL aguarda outros processos terminarem suas operações de entrada/saída (E/S) ao tentarem acessar simultaneamente uma página. Sua finalidade é fazer com que a mesma página seja lida no buffer compartilhado.
**Topics**
+ [
## Versões de mecanismos relevantes
](#wait-event.lwlockbufferio.context.supported)
+ [
## Contexto
](#wait-event.lwlockbufferio.context)
+ [
## Causas
](#wait-event.lwlockbufferio.causes)
+ [
## Ações
](#wait-event.lwlockbufferio.actions)
## Versões de mecanismos relevantes
Essas informações de evento de espera são relevantes para todas as versões do RDS para PostgreSQL. Para o RDS para PostgreSQL 12 e versões anteriores, esse evento de espera é denominado lwlock:buffer\$1io, ao passo que, no RDS para PostgreSQL 13, ele é denominado lwlock:bufferio. A partir do RDS para PostgreSQL 14, o evento de espera BufferIO mudou do tipo de evento de espera `LWLock` para `IPC` (IPC:BufferIO).
## Contexto
Cada buffer compartilhado tem um bloqueio de E/S associado ao evento de espera `LWLock:BufferIO`, todas as vezes que um bloqueio (ou uma página) precisa ser recuperado fora do grupo de buffer compartilhado.
Esse bloqueio é utilizado para lidar com várias sessões que requerem acesso ao mesmo bloco. Esse bloco precisa ser lido de fora do grupo de buffer compartilhado, definido pelo parâmetro `shared_buffers`.
Assim que a página for lida dentro do grupo de buffer compartilhado, o bloqueio de `LWLock:BufferIO` será liberado.
**nota**
O evento de espera `LWLock:BufferIO` precede o evento de espera [IO:DataFileRead](wait-event.iodatafileread.md). O evento de espera `IO:DataFileRead` ocorre enquanto os dados estão sendo lidos do armazenamento.
Para obter mais informações sobre bloqueios leves, consulte [Visão geral de bloqueios](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Causas
Causas comuns do surgimento do evento `LWLock:BufferIO` nas principais esperas incluem:
+ Vários backends ou conexões tentando acessar a mesma página para a qual também há uma operação de E/S pendente
+ A proporção entre o tamanho do grupo de buffer compartilhado (definido pelo parâmetro `shared_buffers`) e o número de buffers necessários para a workload atual
+ O tamanho do grupo de buffer compartilhado não está bem equilibrado com o número de páginas que estão sendo despejadas por outras operações
+ Índices grandes ou inchados que exigem que o mecanismo leia mais páginas que o necessário no grupo de buffer compartilhado
+ Ausência índices, o que força o mecanismo de banco de dados a ler mais páginas das tabelas que o necessário
+ Pontos de verificação ocorrendo com muita frequência ou que precisam liberar muitas páginas modificadas
+ Picos repentinos de conexões de banco de dados tentando realizar operações na mesma página
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera:
+ Observe as métricas do Amazon CloudWatch para encontrar uma correlação entre reduções acentuadas nos eventos de espera `BufferCacheHitRatio` e `LWLock:BufferIO`. Esse efeito pode significar que existe uma pequena configuração de buffers compartilhados. Talvez seja necessário aumentá-lo ou aumentar a escala da classe de instância de banco de dados na vertical. Você pode dividir sua workload em mais nós de leitura.
+ Ajuste `max_wal_size` e `checkpoint_timeout` com base no horário de pico da workload, se você vir `LWLock:BufferIO` correspondendo a quedas da métrica `BufferCacheHitRatio`. Em seguida, identifique qual consulta pode estar causando isso.
+ Verifique se existem índices não utilizados e remova-os.
+ Use tabelas particionadas (que também tenham índices particionados). Fazer isso ajuda a manter a reordenação do índice baixo e reduz seu impacto.
+ Evite indexar colunas desnecessariamente.
+ Evite picos repentinos de conexão de banco de dados utilizando um grupo de conexões.
+ Restrinja o número máximo de conexões com o banco de dados como prática recomendada.
# LWLock:buffer\$1content (BufferContent)
O evento `LWLock:buffer_content` ocorre quando uma sessão aguarda para ler ou gravar uma página de dados na memória enquanto outra sessão fica com a página bloqueada para gravação. No RDS para PostgreSQL 13 e versões superiores, esse evento de espera é chamado de `BufferContent`.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.lwlockbuffercontent.context.supported)
+ [
## Contexto
](#wait-event.lwlockbuffercontent.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.lwlockbuffercontent.causes)
+ [
## Ações
](#wait-event.lwlockbuffercontent.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Contexto
Para ler ou manipular dados, o PostgreSQL os acessa por meio de buffers de memória compartilhada. Para ler a partir do buffer, um processo obtém um bloqueio leve (LWLock) no conteúdo do buffer no modo compartilhado. Para gravar no buffer, ele adquire esse bloqueio no modo exclusivo. Bloqueios compartilhados permitem que outros processos adquiram bloqueios compartilhados simultaneamente nesse conteúdo. Bloqueios exclusivos impedem que outros processos obtenham qualquer tipo de bloqueio nele.
O evento `LWLock:buffer_content` (`BufferContent`) indica que vários processos estão tentando obter um bloqueio no conteúdo de um buffer específico.
## Possíveis causas do maior número de esperas
Quando o evento `LWLock:buffer_content` (`BufferContent`) aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
**Maior número de atualizações simultâneas para os mesmos dados**
Pode haver um aumento no número de sessões simultâneas com consultas que atualizam o mesmo conteúdo do buffer. Essa contenção pode ser mais evidente em tabelas com vários índices.
**Os dados da workload não estão na memória**
Quando os dados que a workload ativa está processando não estão na memória, esses eventos de espera podem aumentar. Esse efeito ocorre porque os processos que mantêm bloqueios podem fazer isso por mais tempo enquanto executam operações de E/S de disco.
**Uso excessivo de restrições de chaves externas**
Restrições de chave externas podem aumentar o tempo durante o qual um processo mantém um bloqueio de conteúdo de buffer. Esse efeito ocorre porque operações de leitura exigem um bloqueio de conteúdo de buffer compartilhado na chave referenciada enquanto esta está sendo atualizada.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Você pode identificar eventos `LWLock:buffer_content` (`BufferContent`) utilizando o Amazon RDS Performance Insights ou consultando a visualização `pg_stat_activity`.
**Topics**
+ [
### Melhorar a eficiência na memória
](#wait-event.lwlockbuffercontent.actions.in-memory)
+ [
### Reduzir o uso de restrições de chaves externas
](#wait-event.lwlockbuffercontent.actions.foreignkey)
+ [
### Remover índices não utilizados
](#wait-event.lwlockbuffercontent.actions.indexes)
+ [
### Aumentar o tamanho do cache ao usar sequências
](#wait-event.lwlockbuffercontent.actions.sequences)
### Melhorar a eficiência na memória
Para aumentar as chances de que os dados da workload ativa estejam na memória, particione tabelas ou aumente a escala da sua classe de instância na vertical. Para obter informações sobre classes de instância de banco de dados, consulte [Classes de instâncias de banco de dados do ](Concepts.DBInstanceClass.md).
### Reduzir o uso de restrições de chaves externas
Investigue workloads com um número elevado de eventos de espera `LWLock:buffer_content` (`BufferContent`) quanto ao uso de restrições de chaves externas. Remova restrições desnecessárias de chaves externas.
### Remover índices não utilizados
Para workloads com um número elevado de eventos de espera `LWLock:buffer_content` (`BufferContent`), identifique índices não utilizados e remova-os.
### Aumentar o tamanho do cache ao usar sequências
Se suas tabelas usarem sequências, aumente o tamanho do cache para remover a contenção nas páginas de sequência e nas páginas de índice. Cada sequência é uma única página na memória compartilhada. O cache predefinido é de acordo com a conexão. Isso pode não ser suficiente para lidar com a workload quando muitas sessões simultâneas estão recebendo um valor de sequência.
# LWLock:lock\$1manager (LWLock:lockmanager)
Esse evento ocorre quando o mecanismo do RDS para PostgreSQL mantém a área de memória do bloqueio compartilhado para alocar, conferir e desalocar um bloqueio nos casos em que um bloqueio de caminho rápido não é possível.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.lw-lock-manager.context.supported)
+ [
## Contexto
](#wait-event.lw-lock-manager.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.lw-lock-manager.causes)
+ [
## Ações
](#wait-event.lw-lock-manager.actions)
## Versões compatíveis do mecanismo
As informações de eventos de espera são relevantes para o RDS para PostgreSQL versão 9.6 e posteriores. Para versões do RDS para PostgreSQL anteriores à versão 13, o nome desse evento de espera é `LWLock:lock_manager`. Para o RDS para PostgreSQL versão 13 e posteriores, o nome desse evento de espera é `LWLock:lockmanager`.
## Contexto
Quando você emite uma instrução SQL, o RDS para PostgreSQL registra bloqueios para proteger a estrutura, os dados e a integridade do banco de dados durante operações simultâneas. O mecanismo pode atingir esse objetivo utilizando um bloqueio de caminho rápido ou um bloqueio de caminho que não é rápido. Um bloqueio de caminho que não é rápido é mais caro e gera mais sobrecarga do que um bloqueio de caminho rápido.
### Bloqueio de caminho rápido
Para reduzir a sobrecarga de bloqueios que são retirados e liberados com frequência, mas que raramente entram em conflito, os processos de backend podem utilizar o bloqueio de caminho rápido. O banco de dados usa esse mecanismo para bloqueios que atendem aos seguintes critérios:
+ Usam o método de bloqueio DEFAULT.
+ Representam um bloqueio em uma relação de banco de dados em vez de uma relação compartilhada.
+ São bloqueios fracos que provavelmente não entrarão em conflito.
+ O mecanismo é capaz de verificar rapidamente se nenhum bloqueio conflitante pode existir.
O mecanismo não pode utilizar o bloqueio rápido de caminho quando uma das seguintes condições é verdadeira:
+ O bloqueio não atende aos critérios anteriores.
+ Não há mais slots disponíveis para o processo de backend.
Para ajustar as consultas para bloqueio rápido, é possível usar a consulta a seguir.
```
SELECT count(*), pid, mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 4,3,2
ORDER BY pid, mode;
count | pid | mode | fastpath
-------+------+-----------------+----------
16 | 9185 | AccessShareLock | t
336 | 9185 | AccessShareLock | f
1 | 9185 | ExclusiveLock | t
```
A consulta a seguir mostra somente o total em todo o banco de dados.
```
SELECT count(*), mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 3,2
ORDER BY mode,1;
count | mode | fastpath
-------+-----------------+----------
16 | AccessShareLock | t
337 | AccessShareLock | f
1 | ExclusiveLock | t
(3 rows)
```
Para obter mais informações sobre o bloqueio de caminho rápido, consulte o tópico sobre [caminho rápido](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76), no README do gerenciador de bloqueios do PostgreSQL e[pg-locks](https://www.postgresql.org/docs/9.3/view-pg-locks.html#AEN98195) na documentação do PostgreSQL.
### Exemplo de um problema de escalabilidade para o gerenciador de bloqueios
Neste exemplo, uma tabela chamada `purchases` armazena cinco anos de dados, particionados por dia. Cada partição possui dois índices. A seguinte sequência de eventos ocorre:
1. Você consulta muitos dias de dados, o que exige que o banco de dados leia várias partições.
1. O banco de dados cria uma entrada de bloqueio para cada partição. Se os índices de partição fizerem parte do caminho de acesso do otimizador, o banco de dados também criará uma entrada de bloqueio para eles.
1. Quando o número de entradas de bloqueios solicitadas para o mesmo processo de backend for maior que 16, que é o valor de `FP_LOCK_SLOTS_PER_BACKEND`, o gerenciador de bloqueio usará o método de bloqueio de caminho não rápido.
Aplicações modernas podem ter centenas de sessões. Se sessões simultâneas estiverem consultando o pai sem a devida limpeza da partição, o banco de dados poderá criar centenas ou até milhares de bloqueios de caminho não rápidos. Em geral, quando essa simultaneidade é maior que o número de vCPUs, o evento de espera `LWLock:lock_manager` é exibido.
**nota**
O evento de espera `LWLock:lock_manager` não está relacionado ao número de partições ou índices em um esquema de banco de dados e sim ao número de bloqueios de caminho não rápidos que o banco de dados deve controlar.
## Possíveis causas do maior número de esperas
Quando o evento de espera `LWLock:lock_manager` ocorre mais do que o normal, possivelmente indicando um problema de performance, as causas mais prováveis de picos súbitos são:
+ Sessões ativas simultâneas estão executando consultas que não utilizam bloqueios de caminho rápido. Essas sessões também excedem a vCPU máxima.
+ Um número elevado de sessões ativas simultâneas está acessando uma tabela fortemente particionada. Cada partição possui vários índices.
+ O banco de dados está passando por uma tempestade de conexões. Por padrão, algumas aplicações e softwares de grupo de conexões criam mais conexões quando o banco de dados está lento. Essa prática piora o problema. Ajuste o software do grupo de conexões para que tempestades de conexões não ocorram.
+ Um número elevado de sessões consulta uma tabela pai sem separar partições.
+ Um comando de linguagem de definição de dados (DDL), linguagem de manipulação de dados (DML) ou manutenção bloqueia exclusivamente uma relação ocupada ou tuplas que são frequentemente acessadas ou modificadas.
## Ações
Se o evento de espera `CPU` ocorrer, isso não indica necessariamente um problema de performance. Responda a esse evento somente quando a performance piorar e esse evento de espera estiver dominando a carga do banco de dados.
**Topics**
+ [
### Usar a limpeza de partição
](#wait-event.lw-lock-manager.actions.pruning)
+ [
### Remover índices desnecessários
](#wait-event.lw-lock-manager.actions.indexes)
+ [
### Ajustar suas consultas para bloqueio de caminho rápido
](#wait-event.lw-lock-manager.actions.tuning)
+ [
### Fazer ajustes com base em eventos de espera
](#wait-event.lw-lock-manager.actions.other-waits)
+ [
### Reduzir gargalos de hardware
](#wait-event.lw-lock-manager.actions.hw-bottlenecks)
+ [
### Usar um agrupador de conexões
](#wait-event.lw-lock-manager.actions.pooler)
+ [
### Fazer upgrade da versão do RDS para PostgreSQL
](#wait-event.lw-lock-manager.actions.pg-version)
### Usar a limpeza de partição
*Limpeza de partição* é uma estratégia de otimização de consultas para tabelas declarativamente particionadas que exclui partições desnecessárias das verificações de tabelas, melhorando assim a performance. Por padrão, a remoção de partição está ativada. Se ela estiver desativada, ative-a da seguinte maneira.
```
SET enable_partition_pruning = on;
```
As consultas podem tirar proveito da limpeza de partição quando suas cláusula `WHERE` contêm a coluna utilizada para o particionamento. Para obter mais informações, consulte o tópico sobre [Limpeza de partição](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING), na documentação do PostgreSQL.
### Remover índices desnecessários
Seu banco de dados pode conter índices não utilizados ou raramente utilizados. Se esse for o caso, considere excluí-los. Realize um dos procedimentos a seguir:
+ Saiba mais sobre como encontrar índices desnecessários lendo o tópico sobre [Índices não utilizados](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) na wiki do PostgreSQL.
+ Execute o PG Collector. Esse script SQL reúne informações do banco de dados e as apresenta em um relatório HTML consolidado. Confira a seção “Índices não utilizados”. Para obter mais informações, consulte [pg-collector](https://github.com/awslabs/pg-collector) no Repositório AWS Labs GitHub.
### Ajustar suas consultas para bloqueio de caminho rápido
Para descobrir se as suas consultas usam o bloqueio de caminho rápido, consulte a coluna `fastpath` na tabela `pg_locks`. Se as suas consultas não estiverem utilizando o bloqueio de caminho rápido, tente reduzir o número de relações por consulta para menos de 16.
### Fazer ajustes com base em eventos de espera
Se `LWLock:lock_manager` for o primeiro ou o segundo na lista de principais esperas, verifique se os seguintes eventos de espera também aparecem na lista:
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
Se os eventos anteriores aparecerem em posição elevada na lista, considere ajustar esses eventos de espera primeiro. Esses eventos podem ser um fator impulsionador para `LWLock:lock_manager`.
### Reduzir gargalos de hardware
É possível que haja um gargalo de hardware, como falta de CPU ou uso máximo da largura de banda do Amazon EBS. Nesses casos, considere reduzir gargalos de hardware. Considere as ações a seguir:
+ Aumente a escala da sua classe de instância na vertical.
+ Otimize consultas que consomem grandes quantidades de CPU e memória.
+ Altere a lógica da aplicação.
+ Arquive os dados.
Para obter mais informações sobre CPU, memória e largura de banda da rede do EBS, consulte [Tipos de instâncias do Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Usar um agrupador de conexões
Se o número total de conexões ativas exceder o máximo de vCPU, mais processos do SO exigirão CPU do que o tipo de instância pode suportar. Nesse caso, considere utilizar ou ajustar um grupo de conexões. Para obter mais informações sobre as vCPUs para o seu tipo de instância, consulte o tópico sobre [Tipos de instância do Amazon RDS](https://aws.amazon.com/rds/instance-types/).
Para obter mais informações sobre agrupamento de conexões, consulte os seguintes recursos:
+ [Amazon RDS Proxy](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Grupos conexões e fontes de dados](https://www.postgresql.org/docs/7.4/jdbc-datasource.html), na *Documentação do PostgreSQL*
### Fazer upgrade da versão do RDS para PostgreSQL
Se a versão atual do RDS para PostgreSQL for menor que 12, atualize para a versão 12 ou posterior. As versões 12 e posteriores do PostgreSQL têm um mecanismo de partição aprimorado. Para obter mais informações sobre a versão 12, consulte [Notas de release do PostgreSQL 12.0]( https://www.postgresql.org/docs/release/12.0/). Para obter mais informações sobre atualização do RDS para PostgreSQL, consulte [Atualizações do mecanismo de banco de dados do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md).
# LWLock:pg\$1stat\$1statements
O evento de espera LWLock:pg\$1stat\$1statements ocorre quando a extensão `pg_stat_statements` obtém um bloqueio exclusivo na tabela de hash que rastreia instruções SQL. Isso acontece nos seguintes cenários:
+ Quando o número de instruções rastreadas atinge o valor configurado do parâmetro `pg_stat_statements.max` e é necessário abrir espaço para mais entradas, a extensão executa uma classificação no número de chamadas, remove 5% das instruções menos executadas e preenche novamente o hash com as entradas restantes.
+ Quando `pg_stat_statements` executa uma operação `garbage collection` no arquivo `pgss_query_texts.stat` no disco e reescreve o arquivo.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#apg-rpg-lwlockpgstat.supported)
+ [
## Contexto
](#apg-rpg-lwlockpgstat.context)
+ [
## Possíveis causas do maior número de esperas
](#apg-rpg-lwlockpgstat.causes)
+ [
## Ações
](#apg-rpg-lwlockpgstat.actions)
## Versões compatíveis do mecanismo
As informações sobre esse evento de espera são aceitas em todas as versões do RDS para PostgreSQL.
## Contexto
**Conceitos básicos sobre a extensão pg\$1stat\$1statements**: essa extensão rastreia as estatísticas de execução de instruções SQL em uma tabela de hash. Ela rastreia as instruções SQL até o limite definido pelo parâmetro `pg_stat_statements.max`. Esse parâmetro determina o número máximo de instruções que podem ser rastreadas, o qual corresponde ao número máximo de linhas na visualização pg\$1stat\$1statements.
**Persistência das estatísticas de instrução**: a extensão mantém as estatísticas da instrução em todas as reinicializações da instância:
+ Gravando dados em um arquivo chamado pg\$1stat\$1statements.stat.
+ Usando o parâmetro pg\$1stat\$1statements.save para controlar o comportamento de persistência.
Quando pg\$1stat\$1statements.save é definido como:
+ ativado (padrão): as estatísticas são salvas no desligamento e recarregadas na inicialização do servidor.
+ desativado: as estatísticas não são salvas no desligamento nem recarregadas na inicialização do servidor.
**Armazenamento de texto de consulta**: a extensão armazena o texto das consultas rastreadas em um arquivo chamado `pgss_query_texts.stat`. Esse arquivo pode aumentar até o dobro do tamanho médio de todas as instruções SQL rastreadas antes que a coleta de resíduos ocorra. A extensão requer um bloqueio exclusivo na tabela de hash durante as operações de limpeza e regravação do arquivo `pgss_query_texts.stat`.
**Processo de desalocação de instruções**: quando o número de instruções rastreadas atinge o limite `pg_stat_statements.max` e novas instruções precisam ser rastreadas, a extensão:
+ Obtém um bloqueio exclusivo (LWLock:pg\$1stat\$1statements) na tabela de hash.
+ Carrega os dados existentes na memória local.
+ Executa uma classificação rápida com base no número de chamadas.
+ Remove as instruções menos chamadas (5% inferiores).
+ Preenche novamente a tabela de hash com as entradas restantes.
**Monitoramento da desalocação de instruções**: no PostgreSQL 14 e versões posteriores, você pode monitorar a desalocação de instruções usando a visualização pg\$1stat\$1statements\$1info. Essa visualização inclui uma coluna de desalocação que mostra quantas vezes as instruções foram desalocadas para abrir espaço para novas.
Se a desalocação de instruções ocorrer com frequência, haverá uma coleta de resíduos mais frequente do arquivo `pgss_query_texts.stat` no disco.
## Possíveis causas do maior número de esperas
As causas típicas do aumento de esperas `LWLock:pg_stat_statements` incluem:
+ Um aumento no número de consultas exclusivas usadas pela aplicação.
+ O valor do parâmetro `pg_stat_statements.max` é pequeno em comparação ao número de consultas exclusivas que estão sendo usadas.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Você pode identificar eventos `LWLock:pg_stat_statements` utilizando o Insights de Performance do Amazon RDS ou consultando a visualização `pg_stat_activity`.
Ajuste os parâmetros `pg_stat_statements` a seguir para controlar o comportamento de rastreamento e reduzir os eventos de espera das instruções LWLock:pg\$1stat\$1.
**Topics**
+ [
### Desabilitar o parâmetro pg\$1stat\$1statements.track
](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [
### Aumentar o parâmetro pg\$1stat\$1statements.max
](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [
### Desabilitar o parâmetro pg\$1stat\$1statements.track\$1utility
](#apg-rpg-lwlockpgstat.actions.disableutility)
### Desabilitar o parâmetro pg\$1stat\$1statements.track
Se o evento de espera LWLock:pg\$1stat\$1statements estiver afetando negativamente o desempenho do banco de dados e for necessária uma solução rápida antes de uma análise mais aprofundada da visualização `pg_stat_statements` para identificar a causa-raiz, o parâmetro `pg_stat_statements.track` poderá ser desabilitado configurando-o como `none`. Isso desabilitará a coleta de estatísticas de instrução.
### Aumentar o parâmetro pg\$1stat\$1statements.max
Para reduzir a desalocação e minimizar a coleta de resíduos do arquivo `pgss_query_texts.stat` no disco, aumente o valor do parâmetro `pg_stat_statements.max`. O valor padrão é `5,000`.
**nota**
O parâmetro `pg_stat_statements.max` é estático. É necessário reinicializar a instância de banco de dados para aplicar qualquer alteração nesse parâmetro.
### Desabilitar o parâmetro pg\$1stat\$1statements.track\$1utility
Você pode analisar a visualização pg\$1stat\$1statements para determinar quais comandos do utilitário estão consumindo mais recursos rastreados por `pg_stat_statements`.
O parâmetro `pg_stat_statements.track_utility` controla se o módulo rastreia os comandos do utilitário, que incluem todos os comandos, exceto SELECT, INSERT, UPDATE, DELETE e MERGE. Esse parâmetro é definido como por padrão `on`.
Por exemplo, quando sua aplicação usa muitas consultas de ponto de salvamento, que são inerentemente exclusivas, ela pode aumentar a desalocação de instruções. Para resolver isso, você pode desabilitar o parâmetro `pg_stat_statements.track_utility` para impedir que `pg_stat_statements` rastreie consultas de pontos de salvamento.
**nota**
O parâmetro `pg_stat_statements.track_utility` é dinâmico. Você pode alterar o respectivo valor sem reiniciar a instância de banco de dados.
**Example Exemplo de consultas exclusivas de ponto de salvamento em pg\$1stat\$1statements**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
O PostgreSQL 17 inclui vários aprimoramentos para o rastreamento de comandos de utilitário:
+ Os nomes de ponto de salvamento agora são exibidos como constantes.
+ Os IDs de transação global (GIDs) dos comandos de confirmação em duas fases agora são exibidos como constantes.
+ Os nomes das instruções DEALLOCATE são mostrados como constantes.
+ Os parâmetros CALL agora são exibidos como constantes.
# LWLock:SubtransSLRU (LWLock:SubtransControlLock)
Os eventos de espera `LWLock:SubtransSLRU` e `LWLock:SubtransBuffer` indicam que uma sessão está aguardando para acessar o cache simples utilizado com menor frequência (SLRU) para informações de subtransação. Isso ocorre ao determinar a visibilidade da transação e os relacionamentos pai-filho.
+ `LWLock:SubtransSLRU`: um processo está aguardando para acessar o cache simples menos utilizado recentemente (SLRU) para uma subtransação. No RDS para PostgreSQL antes da versão 13, esse evento de espera é chamado de `SubtransControlLock`.
+ `LWLock:SubtransBuffer`: um processo está aguardando a E/S em um buffer simples menos utilizado recentemente (SLRU) para uma subtransação. No RDS para PostgreSQL antes da versão 13, esse evento de espera é chamado de `subtrans`.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.lwlocksubtransslru.supported)
+ [
## Contexto
](#wait-event.lwlocksubtransslru.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.lwlocksubtransslru.causes)
+ [
## Ações
](#wait-event.lwlocksubtransslru.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Contexto
**Noções básicas sobre subtransações**: subtransação é uma transação dentro de uma transação no PostgreSQL. Também é conhecida como transação aninhada.
Normalmente, as subtransações são criadas quando você usa:
+ `SAVEPOINT`Comandos da
+ Blocos de exceção (`BEGIN/EXCEPTION/END`)
As subtransações permitem reverter partes de uma transação sem afetar toda ela. Isso oferece controle refinado sobre o gerenciamento de transações.
**Detalhes da implementação**: o PostgreSQL implementa subtransações como estruturas aninhadas nas transações principais. Cada subtransação recebe seu próprio ID.
Principais aspectos de implementação:
+ Os IDs de transação são monitorados em `pg_xact`.
+ Os relacionamentos pai-filho são armazenados no subdiretório `pg_subtrans` em `PGDATA`.
+ Cada sessão do banco de dados pode manter até `64` subtransações ativas.
+ Exceder esse limite causa estouro de subtransação, o que requer acesso ao cache simples utilizado com menor frequência (SLRU) para informações de subtransação.
## Possíveis causas do maior número de esperas
As causas comuns de contenção de SLRU por subtransação são as seguintes:
+ **Uso excessivo do tratamento de SAVEPOINT e EXCEPTION**: os procedimentos PL/pgSQL com manipuladores `EXCEPTION` criam automaticamente pontos de salvamento implícitos, independentemente da ocorrência de exceções. Cada `SAVEPOINT` inicia uma nova subtransação. Quando uma única transação acumula mais de 64 subtransações, ela aciona um estouro de SLRU de subtransação.
+ **Configurações de driver e ORM**: o uso de `SAVEPOINT` pode ser explícito no código da aplicação ou implícito nas configurações do driver. Muitas ferramentas de ORM e frameworks de aplicações geralmente usadas comportam transações aninhadas de forma nativa. Veja aqui alguns exemplos comuns:
+ O parâmetro do driver JDBC `autosave`, se definido como `always` ou `conservative`, gera pontos de salvamento antes de cada consulta.
+ Definições de transação do Spring Framework quando configuradas como `propagation_nested`.
+ Trilhos quando `requires_new: true` está definido.
+ SQLAlchemy quando `session.begin_nested` é usado.
+ Django quando blocos `atomic()` aninhados são usados.
+ GORM quando `Savepoint` é usado.
+ psqlODBC quando a configuração do nível de reversão é definida como reversão em nível de instrução (por exemplo, `PROTOCOL=7.4-2`).
+ **Altas workloads simultâneas com transações e subtransações de longa execução**: quando ocorre um estouro de SLRU de subtransação durante workloads altamente simultâneas e transações e subtransações de longa execução, o PostgreSQL sofre uma maior contenção. Isso se manifesta como eventos de espera elevados para bloqueios `LWLock:SubtransBuffer` e `LWLock:SubtransSLRU`.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Algumas ações fornecem alívio imediato, enquanto outras exigem investigação e correção no longo prazo.
**Topics**
+ [
### Monitorar o uso de subtransações
](#wait-event.lwlocksubtransslru.actions.monitor)
+ [
### Configurar parâmetros de memória
](#wait-event.lwlocksubtransslru.actions.memory)
+ [
### Ações de longo prazo
](#wait-event.lwlocksubtransslru.actions.longterm)
### Monitorar o uso de subtransações
Para as versões 16.1 e posteriores do PostgreSQL, use a consulta a seguir para monitorar as contagens de subtransações e o status de estouro por backend. Essa consulta une estatísticas de backend com informações de atividades para mostrar quais processos estão usando subtransações:
```
SELECT a.pid, usename, query, state, wait_event_type,
wait_event, subxact_count, subxact_overflowed
FROM (SELECT id, pg_stat_get_backend_pid(id) pid, subxact_count, subxact_overflowed
FROM pg_stat_get_backend_idset() id
JOIN LATERAL pg_stat_get_backend_subxact(id) AS s ON true
) a
JOIN pg_stat_activity b ON a.pid = b.pid;
```
Para as versões 13.3 e posteriores do PostgreSQL, monitore a visualização `pg_stat_slru` da pressão do cache de subtransação. A consulta SQL a seguir recupera estatísticas de cache SLRU para o componente Subtrans:
```
SELECT * FROM pg_stat_slru WHERE name = 'Subtrans';
```
Um valor `blks_read` consistentemente crescente indica acesso frequente ao disco para subtransações não armazenadas em cache, sinalizando uma possível pressão no cache de SLRU.
### Configurar parâmetros de memória
Para o PostgreSQL 17.1 e versões posteriores, é possível configurar o tamanho do cache de SLRU de subtransações usando o parâmetro `subtransaction_buffers`. O seguinte exemplo de configuração mostra como definir o parâmetro de buffer de subtransações:
```
subtransaction_buffers = 128
```
Esse parâmetro especifica a quantidade de memória compartilhada utilizada para armazenar conteúdo de subtransação (`pg_subtrans`). Quando especificado sem unidades, o valor representa blocos de `BLCKSZ` bytes, normalmente 8 KB cada. Por exemplo, definir o valor como 128 aloca 1 MB (128 x 8 kB) de memória para o cache de subtransações.
**nota**
É possível definir esse parâmetro em nível de cluster para que todas as instâncias permaneçam consistentes. Teste e ajuste o valor para melhor atender aos requisitos específicos da workload e à classe de instância. É necessário reinicializar a instância do gravador para que a alteração do parâmetro tenha efeito.
### Ações de longo prazo
+ **Examinar o código e as configurações da aplicação**: analise as configurações do código da aplicação e do driver do banco de dados quanto ao uso explícito e implícito de `SAVEPOINT` e ao uso de subtransações em geral. Identifique transações que podem geram mais de 64 subtransações.
+ **Reduzir o uso de pontos de salvamento**: minimize o uso de pontos de salvamento nas transações:
+ Analise os procedimentos PL/pgSQL e funções com blocos EXCEPTION. Os blocos EXCEPTION criam automaticamente pontos de salvamento implícitos, que podem contribuir para o estouro de subtransações. Cada cláusula EXCEPTION cria uma subtransação, independentemente de uma exceção realmente ocorrer durante a execução.
**Example**
Exemplo 1: uso problemático do bloco EXCEPTION
O exemplo de código a seguir mostra o uso problemático do bloco EXCEPTION que cria várias subtransações:
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
BEGIN
-- This creates a subtransaction for each iteration
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW());
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
EXCEPTION
WHEN unique_violation THEN
-- Handle duplicate audit entries
UPDATE user_audit
SET timestamp = NOW()
WHERE user_id = user_record.id AND action = 'processed';
END;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
O exemplo de código aprimorado a seguir reduz o uso de subtransações usando UPSERT em vez do tratamento de exceções:
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
-- Use UPSERT to avoid exception handling
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW())
ON CONFLICT (user_id, action)
DO UPDATE SET timestamp = NOW();
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
**Example**
Exemplo 2: manipulador de exceções STRICT
O exemplo de código a seguir mostra o tratamento problemático de EXCEPTION com NO\$1DATA\$1FOUND:
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
BEGIN
-- STRICT causes an exception if no rows or multiple rows found
SELECT email INTO STRICT user_email
FROM users
WHERE id = p_user_id;
RETURN user_email;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN 'Email not found';
END;
END;
$$ LANGUAGE plpgsql;
```
O exemplo de código aprimorado a seguir evita subtransações usando IF NOT FOUND em vez do tratamento de exceções:
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
SELECT email INTO user_email
FROM users
WHERE id = p_user_id;
IF NOT FOUND THEN
RETURN 'Email not found';
ELSE
RETURN user_email;
END IF;
END;
$$ LANGUAGE plpgsql;
```
+ Driver JDBC: o parâmetro `autosave`, se definido como `always` ou `conservative`, gera pontos de salvamento antes de cada consulta. Avalie se a configuração `never` seria aceitável para sua aplicação.
+ Driver ODBC do PostgreSQL (psqlODBC): a configuração em nível de reversão (para reversão em nível da instrução) cria pontos de salvamento implícitos para habilitar a funcionalidade de reversão da instrução. Avalie se a reversão em nível de transação ou nenhuma reversão seria aceitável para sua aplicação.
+ Examinar as configurações de transações do ORM
+ Pense nas estratégias alternativas de tratamento de erros que não exijam pontos de salvamento
+ **Otimizar o design da transação**: reestruture as transações para evitar o agrupamento excessivo e reduzir a probabilidade de condições de estouro de subtransações.
+ **Reduzir as transações de longa duração**: as transações de longa duração podem agravar os problemas com subtransações ao reter as informações delas por mais tempo. Monitore as métricas do Insights de Performance e configure o parâmetro `idle_in_transaction_session_timeout` para encerrar automaticamente as transações ociosas.
+ Monitorar as métricas do Insights de Performance: acompanhe métricas, incluindo `idle_in_transaction_count` (número de sessões inativas no estado da transação) e `idle_in_transaction_max_time` (duração da transação ociosa mais longa) para detectar transações de longa duração.
+ Configurar `idle_in_transaction_session_timeout`: defina esse parâmetro em seu grupo de parâmetros para encerrar automaticamente transações ociosas após um período especificado.
+ Monitoramento proativo: monitore altas ocorrências de eventos de espera `LWLock:SubtransBuffer` e `LWLock:SubtransSLRU` para detectar contenções relacionadas a subtransações antes que elas se tornem críticas.
# Tempo limite:PgSleep
O evento `Timeout:PgSleep` ocorre quando um processo do servidor chama a função `pg_sleep` e está aguardando o tempo limite de suspensão expirar.
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.timeoutpgsleep.context.supported)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.timeoutpgsleep.causes)
+ [
## Ações
](#wait-event.timeoutpgsleep.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Possíveis causas do maior número de esperas
Esse evento de espera ocorre quando uma aplicação, uma função armazenada ou um usuário emite uma instrução SQL que chama uma das seguintes funções:
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
As funções anteriores atrasarão a execução até que o número especificado de segundos tenha decorrido. Por exemplo, `SELECT pg_sleep(1)` pausa por 1 segundo. Para obter mais informações, consulte [Atrasar a execução](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) na documentação do PostgreSQL.
## Ações
Identifique a instrução que estava executando a função `pg_sleep`. Determine se o uso da função é apropriado.
# Timeout:VacuumDelay
O evento `Timeout:VacuumDelay` indica que o limite de custo para E/S de vácuo foi excedido e que o processo de vácuo foi suspenso. As operações de vácuo são interrompidas pelo período especificado no respectivo parâmetro de atraso de custo e, depois, ele retoma seu trabalho. Para o comando de vácuo manual, o atraso é especificado no parâmetro `vacuum_cost_delay`. Para o daemon de vácuo automático, o atraso é especificado no `autovacuum_vacuum_cost_delay parameter.`
**Topics**
+ [
## Versões compatíveis do mecanismo
](#wait-event.timeoutvacuumdelay.context.supported)
+ [
## Contexto
](#wait-event.timeoutvacuumdelay.context)
+ [
## Possíveis causas do maior número de esperas
](#wait-event.timeoutvacuumdelay.causes)
+ [
## Ações
](#wait-event.timeoutvacuumdelay.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL.
## Contexto
O PostgreSQL tem um daemon de vácuo automático e um comando de vácuo manual. O processo de vácuo automático está “ativado” por padrão para instâncias de banco de dados do RDS para PostgreSQL. O comando de vácuo manual é utilizado conforme a necessidade, por exemplo, para limpar tabelas de tuplas inoperantes ou gerar novas estatísticas.
Quando a aspiração está em andamento, o PostgreSQL usa um contador interno para acompanhar os custos estimados à medida que o sistema executa várias operações de E/S. Quando o contador atinge o valor especificado pelo parâmetro de limite de custo, o processo que executa a operação permanece inativo pelo breve período especificado no parâmetro de atraso de custo. Depois, ele redefine o contador e continua as operações.
O processo de vácuo tem parâmetros que podem ser usados para regular o consumo de recursos. O vácuo automático e o comando de vácuo manual têm seus próprios parâmetros para definir o valor limite de custo. Eles também têm seus próprios parâmetros para especificar um atraso de custo, uma quantidade de tempo para colocar o vácuo em repouso quando o limite é atingido. Dessa forma, o parâmetro de atraso de custo funciona como um controle de utilização do consumo de recursos. Nas listas a seguir, você pode encontrar a descrição desses parâmetros.
**Parâmetros que afetam o controle de utilização do daemon de vácuo automático**
+ `[autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)`: especifica o valor limite de custo a ser utilizado em operações automáticas de vácuo. Aumentar a configuração desse parâmetro permite que o processo de vácuo use mais recursos e diminua o evento de espera `Timeout:VacuumDelay`.
+ `[autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)`: especifica o valor de atraso de custo a ser utilizado em operações automáticas de vácuo. O valor padrão é 2 milissegundos. Definir o parâmetro de atraso como 0 desativa o controle de utilização e, portanto, o evento de espera `Timeout:VacuumDelay` não será exibido.
Para ter mais informações, consulte [Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY) (Aplicação automática do vacuum) na documentação do PostgreSQL.
**Parâmetros que afetam o controle de utilização do processo de vácuo manual**
+ `vacuum_cost_limit`: o limite no qual o processo de vácuo é suspenso. Por padrão, o limite é 200. Esse número representa as estimativas de custo acumuladas para E/S extras necessárias para vários recursos. Aumentar esse valor reduz o número do evento de espera `Timeout:VacuumDelay`.
+ `vacuum_cost_delay`: a quantidade de tempo que o processo de vácuo permanece inativo quando o limite de custo do vácuo é atingido. A configuração padrão é 0, o que significa que esse recurso está desativado. Você pode definir isso como um valor inteiro para especificar o número de milissegundos para ativar esse recurso, mas recomendamos que você o deixe na configuração padrão.
Para obter mais informações sobre o parâmetro `vacuum_cost_delay`, consulte [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST) (Consumo de recursos) na documentação do PostgreSQL.
Para saber mais sobre como configurar e usar o vácuo automático com o RDS for PostgreSQL, consulte [Trabalhar com o autovacuum do PostgreSQL no Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
## Possíveis causas do maior número de esperas
O `Timeout:VacuumDelay` é afetado pelo equilíbrio entre as configurações dos parâmetros de limite de custo (`vacuum_cost_limit`, `autovacuum_vacuum_cost_limit`) e os parâmetros de atraso de custo (`vacuum_cost_delay`, `autovacuum_vacuum_cost_delay`) que controlam a duração da suspensão do vácuo. Aumentar o valor de um parâmetro de limite de custo permite que mais recursos sejam utilizados pelo vácuo antes de serem colocados em repouso. Isso ocasiona menos eventos de espera `Timeout:VacuumDelay`. O aumento de qual quer um dos parâmetros de atraso faz com que o evento de espera `Timeout:VacuumDelay` ocorra com maior frequência e por longos períodos.
A configuração do parâmetro `autovacuum_max_workers` também pode aumentar o número de `Timeout:VacuumDelay`. Cada processo adicional de processamento do vácuo automático contribui para o mecanismo interno do contador e, portanto, o limite pode ser atingido mais rapidamente do que com um único processo de vácuo automático. À medida que o limite de custo é atingido mais rapidamente, o atraso de custo é aplicado com maior frequência, ocasionando mais eventos de espera `Timeout:VacuumDelay`. Para obter mais informações, consulte [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS) na documentação do PostgreSQL.
Objetos grandes, como 500 GB ou maiores, também aumentam esse evento de espera porque pode levar algum tempo para que o vácuo conclua o processamento de objetos grandes.
## Ações
Se as operações de vácuo forem concluídas conforme o esperado, nenhuma correção será necessária. Em outras palavras, esse evento de espera não indica necessariamente um problema. Isso indica que o vácuo está sendo colocado em repouso pelo período especificado no parâmetro de atraso para que os recursos possam ser aplicados a outros processos que precisam ser concluídos.
Se quiser que as operações de vácuo sejam concluídas mais rapidamente, você poderá reduzir os parâmetros de atraso. Isso reduz o tempo em que o vácuo permanece suspenso.
# Ajustar o RDS para PostgreSQL com insights proativos do Amazon DevOps Guru
Os insights proativos do DevOps Guru detectam condições em instâncias de banco de dados do RDS para PostgreSQL que podem causar problemas, permitindo que você as conheça antes que ocorram. Os insights proativos podem alertar quando ocorre um período longo de inatividade na conexão da transação. Para ter mais informações sobre como solucionar períodos longos de inatividade nas conexões das transações, consulte [O banco de dados está inativo há muito tempo na conexão da transação](#proactive-insights.idle-txn).
O DevOps Guru pode fazer o seguinte:
+ Evitar muitos problemas comuns de bancos de dados ao comparar a configuração do seu banco de dados com as configurações comuns recomendadas.
+ Alertar sobre problemas críticos em sua frota que, se não forem controlados, poderão causar problemas maiores no futuro.
+ Alertar sobre problemas recém-descobertos.
Cada insight proativo contém uma análise da causa do problema e recomendações de ações corretivas.
Para ter informações sobre o Amazon DevOps Guru para Amazon RDS, consulte [Analisar anomalias de performance com o DevOps Guru para Amazon RDS](devops-guru-for-rds.md).
## O banco de dados está inativo há muito tempo na conexão da transação
A conexão com o banco de dados está no estado `idle in transaction` há mais de 1.800 segundos.
**Topics**
+ [
### Versões compatíveis do mecanismo
](#proactive-insights.idle-txn.context.supported)
+ [
### Contexto
](#proactive-insights.idle-txn.context)
+ [
### Causas prováveis desse problema
](#proactive-insights.idle-txn.causes)
+ [
### Ações
](#proactive-insights.idle-txn.actions)
+ [
### Métricas relevantes
](#proactive-insights.idle-txn.metrics)
### Versões compatíveis do mecanismo
Essas informações de insights são aceitas em todas as versões do RDS para PostgreSQL.
### Contexto
Uma transação no estado `idle in transaction` pode conter bloqueios que impedem outras consultas. Também pode impedir que `VACUUM` (incluindo o autovacuum) limpe linhas mortas, causando inchaço no índice ou na tabela ou recorrência de IDs de transação.
### Causas prováveis desse problema
Uma transação iniciada em uma sessão interativa com BEGIN ou START TRANSACTION não terminou usando um comando COMMIT, ROLLBACK ou END. Isso faz com que a transação passe para o estado `idle in transaction`.
### Ações
Você pode encontrar transações inativas consultando `pg_stat_activity`.
Em seu cliente SQL, execute a seguinte consulta para listar todas as conexões em estado `idle in transaction` e ordená-las por duração:
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Recomendamos ações distintas dependendo dos motivos do insight.
**Topics**
+ [
#### Encerrar transação
](#proactive-insights.idle-txn.actions.end-txn)
+ [
#### Encerrar a conexão
](#proactive-insights.idle-txn.actions.end-connection)
+ [
#### Configurar o parâmetro idle\$1in\$1transaction\$1session\$1timeout
](#proactive-insights.idle-txn.actions.parameter)
+ [
#### Verificar o status de AUTOCOMMIT
](#proactive-insights.idle-txn.actions.autocommit)
+ [
#### Verificar a lógica da transação no código da aplicação
](#proactive-insights.idle-txn.actions.app-logic)
#### Encerrar transação
Quando você inicia uma transação em uma sessão interativa com BEGIN ou START TRANSACTION, ela passa para o estado `idle in transaction`. Ela permanecerá nesse estado até você encerrar a transação emitindo um comando COMMIT, ROLLBACK ou END, ou até desfazer completamente a conexão para reverter a transação.
#### Encerrar a conexão
Encerre a conexão com uma transação inativa usando a seguinte consulta:
```
SELECT pg_terminate_backend(pid);
```
pid é o ID de processo da conexão.
#### Configurar o parâmetro idle\$1in\$1transaction\$1session\$1timeout
Configure o parâmetro `idle_in_transaction_session_timeout` no grupo de parâmetros. A vantagem de configurar esse parâmetro é que ele não requer uma intervenção manual para encerrar transações que estão inativas há muito tempo. Para obter mais informações sobre esse parâmetro, consulte a [documentação do PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-client.html).
A mensagem a seguir será relatada no arquivo de log do PostgreSQL depois do encerramento da conexão quando uma conexão permanecer no estado idle\$1in\$1transaction por mais tempo do que o tempo especificado.
```
FATAL: terminating connection due to idle in transaction timeout
```
#### Verificar o status de AUTOCOMMIT
A opção AUTOCOMMIT está ativada por padrão. Se for acidentalmente desativada no cliente, ative-a novamente.
+ No cliente psql, execute o seguinte comando:
```
postgres=> \set AUTOCOMMIT on
```
+ Em pgadmin, ative-a escolhendo a opção AUTOCOMMIT na seta para baixo.
![\[Em pgadmin, escolha AUTOCOMMIT para ativá-la.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/apg-insight-pgadmin-autocommit.png)
#### Verificar a lógica da transação no código da aplicação
Investigue a lógica da aplicação em busca de possíveis problemas. Considere as ações a seguir:
+ Verifique se a confirmação automática do JDBC está definida como true na aplicação. Além disso, considere usar comandos `COMMIT` explícitos em seu código.
+ Verifique sua lógica de tratamento de erros para ver se ela fecha uma transação depois de um erro.
+ Verifique se a aplicação está demorando para processar as linhas retornadas por uma consulta enquanto a transação está aberta. Nesse caso, considere programa a aplicação para fechar a transação antes de processar as linhas.
+ Verifique se uma transação contém muitas operações de longa duração. Em caso afirmativo, divida uma única transação em várias transações.
### Métricas relevantes
As seguintes métricas de PI estão relacionadas a esse insight:
+ idle\$1in\$1transaction\$1count: número de sessões no estado `idle in transaction`.
+ idle\$1in\$1transaction\$1max\$1time: a duração da transação que passou mais tempo no estado `idle in transaction`.
# Usar extensões PostgreSQL com o Amazon RDS para PostgreSQL
É possível estender a funcionalidade do PostgreSQL instalando uma variedade de extensões e módulos. Por exemplo, para trabalhar com dados espaciais, você pode instalar e usar a extensão PostGIS. Para obter mais informações, consulte[Gerenciar dados espaciais com a extensão PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md) Como outro exemplo, se você quiser melhorar a entrada de dados para tabelas muito grandes, considere particionar seus dados usando `pg_partman`. Para saber mais, consulte [Gerenciar partições do PostgreSQL com a extensão pg\$1partman](PostgreSQL_Partitions.md).
**nota**
O RDS para PostgreSQL comporta extensões de linguagem confiáveis para PostgreSQL por meio da extensão `pg_tle`, que você pode adicionar à sua instância de banco de dados. Ao usar essa extensão, os desenvolvedores podem criar suas próprias extensões do PostgreSQL em um ambiente seguro que simplifique os requisitos de instalação e configuração. Para saber mais sobre as versões do RDS para PostgreSQL que aceitam a extensão `pg_tle` e ter mais informações, consulte [Trabalhar com Trusted Language Extensions para PostgreSQL](PostgreSQL_trusted_language_extension.md).
Em alguns casos, em vez de instalar uma extensão, você pode adicionar um módulo específico à lista de `shared_preload_libraries` no grupo de parâmetros de banco de dados personalizado da instância de banco de dados do RDS para PostgreSQL. Normalmente, o grupo de parâmetros padrão do cluster de banco de dados carrega somente as `pg_stat_statements`, mas vários outros módulos estão disponíveis para serem adicionados à lista. Por exemplo, você pode incluir a capacidade de agendamento adicionando o módulo `pg_cron`, conforme detalhado em [Agendar manutenção com a extensão pg\$1cron do PostgreSQL](PostgreSQL_pg_cron.md). Como outro exemplo, você pode registrar planos de execução de consultas carregando o módulo `auto_explain`. Para saber mais, consulte [Logging execution plans of queries](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) (Registrar em log planos de execução de consultas) no Centro de Conhecimentos da AWS.
Dependendo da versão do RDS para PostgreSQL, a instalação de uma extensão pode exigir permissões de `rds_superuser`, como a seguir:
+ Para o RDS para PostgreSQL versões 12 e versões anteriores, a instalação de extensões requer privilégios de `rds_superuser`.
+ Para o RDS para PostgreSQL versão 13 e versões superiores, os usuários (perfis) com permissões de criação em uma determinada instância de banco de dados podem instalar e usar quaisquer *extensões confiáveis*. Para obter uma lista de extensões confiáveis, consulte [Extensões confiáveis do PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted).
Também é possível especificar com precisão quais extensões podem ser instaladas na instância de banco de dados do RDS para PostgreSQL, listando-as no parâmetro `rds.allowed_extensions`. Para obter mais informações, consulte [Restringir a instalação de extensões do PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Para saber mais a respeito do perfil de `rds_superuser`, consulte [Noções básicas de perfis e permissões do PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
**Topics**
+ [
# Usar funções da extensão orafce
](Appendix.PostgreSQL.CommonDBATasks.orafce.md)
+ [
# Usar a compatibilidade com extensões delegadas do Amazon RDS para PostgreSQL
](RDS_delegated_ext.md)
+ [
# Gerenciar partições do PostgreSQL com a extensão pg\$1partman
](PostgreSQL_Partitions.md)
+ [
# Usar pgAudit para registrar a atividade do banco de dados
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [
# Agendar manutenção com a extensão pg\$1cron do PostgreSQL
](PostgreSQL_pg_cron.md)
+ [
# Usar pglogical para sincronizar dados entre instâncias
](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)
+ [
# Usar pgactive para comportar a replicação ativa-ativa
](Appendix.PostgreSQL.CommonDBATasks.pgactive.md)
+ [
# Reduzir o inchaço em tabelas e índices com a extensão pg\$1repack
](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md)
+ [
# Atualizar e usar a extensão PLV8
](PostgreSQL.Concepts.General.UpgradingPLv8.md)
+ [
# Usar PL/Rust para escrever funções do PostgreSQL na linguagem Rust
](PostgreSQL.Concepts.General.Using.PL_Rust.md)
+ [
# Gerenciar dados espaciais com a extensão PostGIS
](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
# Usar funções da extensão orafce
A extensão orafce fornece funções e operadores que emulam um subconjunto de funções e pacotes de um banco de dados Oracle. A extensão orafce permite fazer a portabilidade de uma aplicação Oracle para o PostgreSQL com mais facilidade. Essa extensão é compatível com o RDS para PostgreSQL versões 9.6.6 e posteriores. Para obter mais informações sobre a extensão, consulte o [orafce](https://github.com/orafce/orafce) no GitHub.
**nota**
O RDS para PostgreSQL não é compatível com o pacote `utl_file` que faz parte da extensão orafce. Isso ocorre porque as funções do esquema `utl_file` fornecem operações de leitura e gravação em arquivos de texto do sistema operacional, o que exige que o superusuário acesse o host subjacente. Como um serviço gerenciado, o RDS para PostgreSQL não fornece acesso ao host.
**Para usar a extensão orafce**
1. Conecte-se à instância de banco de dados com o nome do usuário principal que você usou para criar a instância de banco de dados.
Se você quiser ativar a extensão orafce para um banco de dados diferente na mesma instância de banco de dados, use o comando `/c dbname` do psql. Usando esse comando, você muda do banco de dados primário depois de iniciar a conexão.
1. Ativar a extensão orafce com a instrução `CREATE EXTENSION`.
```
CREATE EXTENSION orafce;
```
1. Transfira propriedade do esquema oracle para a função rds\$1superuser com a instrução `ALTER SCHEMA`.
```
ALTER SCHEMA oracle OWNER TO rds_superuser;
```
Caso queira ver uma lista de proprietários do esquema oracle, use o comando de psql `\dn`.
# Usar a compatibilidade com extensões delegadas do Amazon RDS para PostgreSQL
Usando a compatibilidade com extensões delegadas do PostgreSQL, é possível delegar o gerenciamento de extensões a um usuário que não precise ser um `rds_superuser`. Com esse suporte de extensão delegado, um novo perfil chamado `rds_extension` é criado, e você deve atribuí-lo a um usuário para gerenciar outras extensões. Esse perfil pode criar, atualizar e eliminar extensões.
É possível especificar quais extensões podem ser instaladas na instância de banco de dados do RDS listando-as no parâmetro `rds.allowed_extensions`. Para obter mais informações, consulte [Usar extensões PostgreSQL com o Amazon RDS para PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Extensions.html).
É possível restringir a lista de extensões disponíveis que podem ser gerenciadas pelo usuário com o perfil `rds_extension` usando o parâmetro `rds.allowed_delegated_extensions`.
O suporte de extensão delegado está disponível nas seguintes versões:
+ Todas as versões posteriores
+ 16.4 e versões 16 posteriores
+ 15.8 e versões 15 posteriores
+ 14.13 e versões 14 posteriores
+ 13.16 e versões 13 posteriores
+ 12.20 e versões 12 posteriores
**Topics**
+ [
## Ativar o suporte de extensão delegado a um usuário
](#RDSPostgreSQL.delegated_ext_mgmt)
+ [
## Configuração usada na compatibilidade com extensões delegadas do PostgreSQL
](#RDSPostgreSQL.delegated_ext_config)
+ [
## Desativar o suporte para a extensão delegada
](#RDSPostgreSQL.delegated_ext_disable)
+ [
## Benefícios de usar a compatibilidade com extensões delegadas do Amazon RDS
](#RDSPostgreSQL.delegated_ext_benefits)
+ [
## Limitação da compatibilidade com extensões delegadas do PostgreSQL
](#RDSPostgreSQL.delegated_ext_limit)
+ [
## Permissões necessárias para determinadas extensões
](#RDSPostgreSQL.delegated_ext_perm)
+ [
## Considerações sobre segurança
](#RDSPostgreSQL.delegated_ext_sec)
+ [
## Descartar cascata de extensão desabilitado
](#RDSPostgreSQL.delegated_ext_drop)
+ [
## Exemplos de extensões que podem ser adicionadas usando o suporte de extensão delegado
](#RDSPostgreSQL.delegated_ext_support)
## Ativar o suporte de extensão delegado a um usuário
É necessário executar o seguinte para habilitar o suporte de extensão delegado a um usuário:
1. **Conceder o perfil `rds_extension` a um usuário**: conecte-se ao banco de dados `rds_superuser` e execute o seguinte comando:
```
Postgres => grant rds_extension to user_name;
```
1. **Definir a lista de extensões disponíveis para usuários delegados gerenciarem**: o `rds.allowed_delegated_extensions` permite que você especifique um subconjunto das extensões disponíveis usando o parâmetro de cluster de banco de dados `rds.allowed_extensions`. É possível fazer isso em um dos seguintes níveis:
+ No cluster ou no grupo de parâmetros da instância, por meio do Console de gerenciamento da AWS ou da API. Para obter mais informações, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
+ Use o seguinte comando em nível de banco de dados:
```
alter database database_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
+ Use o seguinte comando em nível de usuário:
```
alter user user_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
**nota**
Não é necessário reiniciar o banco de dados depois de alterar o parâmetro dinâmico `rds.allowed_delegated_extensions`.
1. **Permitir que o usuário delegado acesse os objetos criados durante o processo de criação da extensão**: determinadas extensões criam objetos que exigem que permissões adicionais sejam concedidas para que o usuário com o perfil `rds_extension` possa acessá-los. O `rds_superuser` deve conceder ao usuário delegado acesso a esses objetos. Uma das opções é usar um gatilho de eventos para conceder permissão automaticamente ao usuário delegado.
**Exemplo de gatilho de eventos**
Se quiser permitir que um usuário delegado com `rds_extension` use extensões que exijam permissões de configuração nos objetos criados pela criação da extensão, você poderá personalizar o exemplo abaixo de um gatilho de eventos e adicionar somente as extensões para as quais você deseja que os usuários delegados tenham acesso à funcionalidade completa. Esse gatilho de eventos pode ser criado no modelo 1 (o modelo padrão), portanto, todo banco de dados criado a partir do modelo 1 terá esse gatilho de eventos. Quando um usuário delegado instalar a extensão, esse gatilho concederá automaticamente a propriedade dos objetos criados pela extensão.
```
CREATE OR REPLACE FUNCTION create_ext()
RETURNS event_trigger AS $$
DECLARE
schemaname TEXT;
databaseowner TEXT;
r RECORD;
BEGIN
IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
RAISE NOTICE 'SECURITY INVOKER';
RAISE NOTICE 'user: %', current_user;
FOR r IN SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands()
LOOP
CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
schemaname = (
SELECT n.nspname
FROM pg_catalog.pg_extension AS e
INNER JOIN pg_catalog.pg_namespace AS n
ON e.extnamespace = n.oid
WHERE e.oid = r.objid
);
databaseowner = (
SELECT pg_catalog.pg_get_userbyid(d.datdba)
FROM pg_catalog.pg_database d
WHERE d.datname = current_database()
);
RAISE NOTICE 'Record for event trigger %, objid: %,tag: %, current_user: %, schema: %, database_owenr: %', r.object_identity, r.objid, tg_tag, current_user, schemaname, databaseowner;
IF r.object_identity = 'address_standardizer_data_us' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_gaz TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_lex TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_rules TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'dict_int' THEN
EXECUTE pg_catalog.format('ALTER TEXT SEARCH DICTIONARY %I.intdict OWNER TO %I;', schemaname, databaseowner);
ELSIF r.object_identity = 'pg_partman' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config_sub TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.custom_time_partitions TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'postgis_topology' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE ON SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
END IF;
END LOOP;
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE EVENT TRIGGER log_create_ext ON ddl_command_end EXECUTE PROCEDURE create_ext();
```
## Configuração usada na compatibilidade com extensões delegadas do PostgreSQL
| Nome da configuração | Descrição | Valor padrão | Observações | Quem pode modificar ou conceder permissão |
| --- | --- | --- | --- | --- |
| `rds.allowed_delegated_extensions` | Esse parâmetro limita as extensões que um perfil rds\$1extension pode gerenciar em um banco de dados. Ele deve ser um subconjunto de rds.allowed\$1extensions. | string vazia | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/RDS_delegated_ext.html) Para saber mais sobre como configurar esse parâmetro, consulte [Ativar o suporte de extensão delegado a um usuário](#RDSPostgreSQL.delegated_ext_mgmt). | rds\$1superuser |
| `rds.allowed_extensions` | Esse parâmetro permite que o cliente limite as extensões que podem ser instaladas na instância de banco de dados do RDS. Para ter mais informações, consulte [Restringir a instalação de extensões do PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction). | "\$1" | Por padrão, esse parâmetro é definido como “\$1”, o que significa que todas as extensões aceitas no RDS para PostgreSQL e no Aurora PostgreSQL podem ser criadas por usuários com os privilégios necessários. Vazio significa que nenhuma extensão pode ser instalada na instância de banco de dados do RDS. | administrador |
| `rds-delegated_extension_allow_drop_cascade` | Esse parâmetro controla a capacidade do usuário com `rds_extension` de eliminar a extensão usando uma opção em cascata. | desligar | Por padrão, `rds-delegated_extension_allow_drop_cascade` é definido como `off`. Isso significa que os usuários com `rds_extension` não têm permissão para descartar uma extensão usando a opção em cascata. Para conceder essa capacidade, o parâmetro `rds.delegated_extension_allow_drop_cascade` deve ser definido como `on`. | rds\$1superuser |
## Desativar o suporte para a extensão delegada
**Desativar parcialmente**
Os usuários delegados não podem criar extensões, mas ainda podem atualizar as existentes.
+ Redefina `rds.allowed_delegated_extensions` como o valor padrão no grupo de parâmetros de cluster de banco de dados.
+ Use o seguinte comando em nível de banco de dados:
```
alter database database_name reset rds.allowed_delegated_extensions;
```
+ Use o seguinte comando em nível de usuário:
```
alter user user_name reset rds.allowed_delegated_extensions;
```
**Desativar totalmente**
Revogar o perfil `rds_extension` de um usuário vai restaurar as permissões padrão do usuário. O usuário não pode mais criar, atualizar nem descartar extensões.
```
postgres => revoke rds_extension from user_name;
```
## Benefícios de usar a compatibilidade com extensões delegadas do Amazon RDS
Usando a compatibilidade com extensões delegadas do PostgreSQL, é possível delegar, com segurança, o gerenciamento de extensões a usuários que não têm o perfil `rds_superuser`. Esse recurso oferece os seguintes benefícios:
+ É possível delegar facilmente o gerenciamento de extensões aos usuários de sua escolha.
+ Isso não exige o perfil `rds_superuser`.
+ Oferece a capacidade de oferecer compatibilidade com um conjunto diferente de extensões para bancos de dados diferentes no mesmo cluster de banco de dados.
## Limitação da compatibilidade com extensões delegadas do PostgreSQL
+ Objetos criados durante o processo de criação da extensão podem exigir privilégios adicionais para que a extensão funcione corretamente.
+ Algumas extensões não podem ser gerenciadas pelo usuário da extensão delegada por padrão, incluindo as seguintes: `log_fdw`, `pg_cron`, `pg_tle`, `pgactive`, `pglogical`, `postgis_raster`, `postgis_tiger_geocoder`, `postgis_topology`.
## Permissões necessárias para determinadas extensões
Para criar, usar ou atualizar as extensões a seguir, o usuário delegado deve ter os privilégios necessários nestas funções, tabelas e esquemas.
| Extensões que precisam de propriedade ou permissões | Função | Tabelas | Schema | Dicionário de pesquisa de texto | Comment |
| --- | --- | --- | --- | --- | --- |
| address\$1standardizer\$1data\$1us | nenhuma | us\$1gaz, us\$1lex, us\$1lex, I.us\$1rules | nenhuma | nenhuma | nenhuma |
| amcheck | bt\$1index\$1check, bt\$1index\$1parent\$1check | nenhuma | nenhuma | nenhuma | nenhuma |
| dict\$1int | nenhuma | nenhuma | nenhuma | intdict | nenhuma |
| pg\$1partman | nenhuma | custom\$1time\$1partitions, part\$1config, part\$1config\$1sub | nenhuma | nenhuma | nenhuma |
| pg\$1stat\$1statements | nenhuma | nenhuma | nenhuma | nenhuma | nenhuma |
| PostGIS | st\$1tileenvelope | spatial\$1ref\$1sys | nenhuma | nenhuma | nenhuma |
| postgis\$1raster | nenhuma | nenhuma | nenhuma | nenhuma | nenhuma |
| postgis\$1topology | nenhuma | topologia, camada | topologia | nenhuma | o usuário delegado deve ser o proprietário do banco de dados |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | nenhuma | nenhuma | nenhuma | nenhuma |
| rds\$1tools | role\$1password\$1encryption\$1type | nenhuma | nenhuma | nenhuma | nenhuma |
| postgis\$1tiger\$1geocoder | nenhuma | geocode\$1settings\$1default, geocode\$1settings | tiger | nenhuma | nenhuma |
| pg\$1freespacemap | pg\$1freespace | nenhuma | nenhuma | nenhuma | nenhuma |
| pg\$1visibility | pg\$1visibility | nenhuma | nenhuma | nenhuma | nenhuma |
## Considerações sobre segurança
Lembre-se de que um usuário com o perfil `rds_extension` poderá gerenciar extensões em todos os bancos de dados nos quais tiver o privilégio de conexão. Se a intenção for fazer com que um usuário delegado gerencie a extensão em um único banco de dados, uma prática recomendada é revogar todos os privilégios públicos em cada banco de dados e, depois, conceder explicitamente o privilégio de conexão desse banco de dados específico ao usuário delegado.
Existem várias extensões que podem permitir que um usuário acesse informações de vários bancos de dados. Garanta que os usuários que receberem `rds_extension` tenham recursos de vários bancos de dados antes de adicionar essas extensões a `rds.allowed_delegated_extensions`. Por exemplo, `postgres_fdw` e `dblink` oferecem a capacidade de consultar vários bancos de dados na mesma instância ou em instâncias remotas. `log_fdw` lê os arquivos de log do mecanismo postgres, relacionados a todos os bancos de dados na instância, possivelmente contendo consultas lentas ou mensagens de erro de vários bancos de dados. `pg_cron` permite a execução de trabalhos agendados em segundo plano na instância de banco de dados e pode configurar trabalhos para execução em um banco de dados diferente.
## Descartar cascata de extensão desabilitado
A capacidade de descartar a extensão com a opção em cascata por um usuário com o perfil `rds_extension` é controlada pelo parâmetro `rds.delegated_extension_allow_drop_cascade`. Por padrão, `rds-delegated_extension_allow_drop_cascade` é definido como `off`. Isso significa que os usuários com o perfil `rds_extension` não têm permissão para descartar uma extensão usando a opção em cascata, conforme mostrado na consulta a seguir.
```
DROP EXTENSION CASCADE;
```
Pois isso descartará automaticamente os objetos que dependem da extensão e, por sua vez, todos os objetos que dependem desses objetos. A tentativa de usar a opção em cascata gerará um erro.
Para conceder essa capacidade, o parâmetro `rds.delegated_extension_allow_drop_cascade` deve ser definido como `on`.
Alterar o parâmetro dinâmico `rds.delegated_extension_allow_drop_cascade` não requer a reinicialização do banco de dados. É possível fazer isso em um dos seguintes níveis:
+ No cluster ou no grupo de parâmetros da instância, por meio do Console de gerenciamento da AWS ou da API.
+ Usar o seguinte comando em nível de banco de dados:
```
alter database database_name set rds.delegated_extension_allow_drop_cascade = 'on';
```
+ Usar o seguinte comando em nível de usuário:
```
alter role tenant_user set rds.delegated_extension_allow_drop_cascade = 'on';
```
## Exemplos de extensões que podem ser adicionadas usando o suporte de extensão delegado
+ `rds_tools`
```
extension_test_db=> create extension rds_tools;
CREATE EXTENSION
extension_test_db=> SELECT * from rds_tools.role_password_encryption_type() where rolname = 'pg_read_server_files';
ERROR: permission denied for function role_password_encryption_type
```
+ `amcheck`
```
extension_test_db=> CREATE TABLE amcheck_test (id int);
CREATE TABLE
extension_test_db=> INSERT INTO amcheck_test VALUES (generate_series(1,100000));
INSERT 0 100000
extension_test_db=> CREATE INDEX amcheck_test_btree_idx ON amcheck_test USING btree (id);
CREATE INDEX
extension_test_db=> create extension amcheck;
CREATE EXTENSION
extension_test_db=> SELECT bt_index_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_check
extension_test_db=> SELECT bt_index_parent_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_parent_check
```
+ `pg_freespacemap`
```
extension_test_db=> create extension pg_freespacemap;
CREATE EXTENSION
extension_test_db=> SELECT * FROM pg_freespace('pg_authid');
ERROR: permission denied for function pg_freespace
extension_test_db=> SELECT * FROM pg_freespace('pg_authid',0);
ERROR: permission denied for function pg_freespace
```
+ `pg_visibility`
```
extension_test_db=> create extension pg_visibility;
CREATE EXTENSION
extension_test_db=> select * from pg_visibility('pg_database'::regclass);
ERROR: permission denied for function pg_visibility
```
+ `postgres_fdw`
```
extension_test_db=> create extension postgres_fdw;
CREATE EXTENSION
extension_test_db=> create server myserver foreign data wrapper postgres_fdw options (host 'foo', dbname 'foodb', port '5432');
ERROR: permission denied for foreign-data wrapper postgres_fdw
```
# Gerenciar partições do PostgreSQL com a extensão pg\$1partman
O particionamento de tabelas PostgreSQL fornece um framework para processamento de alta performance de entrada e relatórios de dados. Use o particionamento para bancos de dados que exigem entrada muito rápida de grandes quantidades de dados. O particionamento também fornece consultas mais rápidas de tabelas grandes. O particionamento ajuda a manter os dados sem afetar a instância do banco de dados, pois requer menos recursos de E/S.
Ao usar o particionamento, você pode dividir dados em blocos de tamanho personalizado para processamento. Por exemplo, você pode particionar dados de séries temporais para intervalos como por hora, diário, semanal, mensal, trimestral, anual, personalizado ou qualquer combinação destes. Para um exemplo de dados de séries temporais, se você particionar a tabela por hora, cada partição conterá uma hora de dados. Se você particionar a tabela de séries temporais por dia, as partições manterão dados de um dia e assim por diante. A chave de partição controla o tamanho de uma partição.
Quando você usa um comando SQL `INSERT` ou `UPDATE` em uma tabela particionada, o mecanismo de banco de dados roteia os dados para a partição apropriada. As partições de tabela PostgreSQL que armazenam os dados são tabelas filhas da tabela principal.
Durante as leituras de consulta de banco de dados, o otimizador PostgreSQL examina a cláusula `WHERE` da consulta e, se possível, direciona a verificação do banco de dados apenas para as partições relevantes.
A partir da versão 10, o PostgreSQL usa o particionamento declarativo para implementar o particionamento de tabela. Isso também é conhecido como particionamento nativo do PostgreSQL. Antes do PostgreSQL versão 10, você usou gatilhos para implementar partições.
O particionamento de tabelas PostgreSQL fornece os seguintes recursos:
+ Criação de novas partições a qualquer momento.
+ Intervalos variáveis de partição.
+ Partições destacáveis e reanexáveis usando instruções DDL (Data Definition Language, linguagem de definição de dados).
Por exemplo, partições destacáveis são úteis para remover dados históricos da partição principal, mas manter dados históricos para análise.
+ Novas partições herdam as propriedades da tabela do banco de dados pai, incluindo:
+ Índices
+ Chaves primárias, que devem incluir a coluna de chave de partição
+ Chaves externas
+ Restrições de verificação
+ Referências
+ Criação de índices para a tabela completa ou cada partição específica.
Você não pode alterar o esquema de uma partição individual. No entanto, você pode fazer uma alteração na tabela pai (adicionando uma nova coluna, por exemplo) que se propaga para as partições.
**Topics**
+ [
## Visão geral da extensão pg\$1partman do PostgreSQL
](#PostgreSQL_Partitions.pg_partman)
+ [
## Ativar a extensão pg\$1partman
](#PostgreSQL_Partitions.enable)
+ [
## Configurar partições usando a função create\$1parent
](#PostgreSQL_Partitions.create_parent)
+ [
## Configurar a manutenção da partição usando a função run\$1maintenance\$1proc
](#PostgreSQL_Partitions.run_maintenance_proc)
## Visão geral da extensão pg\$1partman do PostgreSQL
Você pode usar a extensão `pg_partman` do PostgreSQL para automatizar a criação e a manutenção de partições de tabelas. Para obter mais informações gerais, consulte [PG Partition Manager](https://github.com/pgpartman/pg_partman) na documentação `pg_partman`.
**nota**
A extensão `pg_partman` é compatível com o RDS para PostgreSQL versões 12.5 e posteriores.
Em vez de ter que criar manualmente cada partição, você ajusta o `pg_partman` com as seguintes configurações:
+ Tabela a ser particionada
+ Tipo de partição
+ Chave de partição
+ Granularidade de partição
+ Opções de pré-criação e gerenciamento de partições
Depois de criar uma tabela particionada do PostgreSQL, registre-a com `pg_partman` chamando a função `create_parent`. Fazer isso cria as partições necessárias com base nos parâmetros que você passa para a função.
A extensão `pg_partman` também fornece a função `run_maintenance_proc`, que você pode chamar de maneira programada para gerenciar as partições automaticamente. Para garantir que as partições adequadas sejam criadas conforme necessário, agende essa função para ser executada periodicamente (por hora, por exemplo). Você também pode garantir que as partições sejam descartadas automaticamente.
## Ativar a extensão pg\$1partman
Se você tiver vários bancos de dados dentro da mesma instância de banco de dados PostgreSQL para a qual deseja gerenciar partições, habilite a extensão `pg_partman` separadamente para cada banco de dados. Para habilitar a extensão `pg_partman` para um banco de dados específico, crie o esquema de manutenção de partição e crie a extensão `pg_partman` da maneira a seguir.
```
CREATE SCHEMA partman;
CREATE EXTENSION pg_partman WITH SCHEMA partman;
```
**nota**
Para criar a extensão `pg_partman`, certifique-se de que você tenha privilégios `rds_superuser`.
Se você receber um erro como o seguinte, conceda os privilégios de `rds_superuser` à conta ou use sua conta de superusuário.
```
ERROR: permission denied to create extension "pg_partman"
HINT: Must be superuser to create this extension.
```
Para conceder privilégios de `rds_superuser`, conecte-se à sua conta de superusuário e execute o seguinte comando.
```
GRANT rds_superuser TO user-or-role;
```
Para os exemplos que mostram usando a extensão pg\$1partman, usamos a seguinte tabela de banco de dados de amostra e partição. Esse banco de dados usa uma tabela particionada com base em um carimbo de data/hora. Um esquema `data_mart` contém uma tabela chamada `events` com uma coluna chamada `created_at`. As seguintes configurações estão incluídas na tabela `events`:
+ Chaves primárias `event_id` e `created_at`, que devem ter a coluna usada para orientar a partição.
+ Uma restrição de verificação `ck_valid_operation` para impor valores para uma coluna `operation` da tabela.
+ Duas chaves estrangeiras, onde uma (`fk_orga_membership)` aponta para a tabela externa `organization` e a outra (`fk_parent_event_id`) é uma chave estrangeira autorreferenciada.
+ Dois índices, onde um (`idx_org_id`) é para a chave estrangeira e o outro (`idx_event_type`) é para o tipo de evento.
As declarações DDL a seguir criam esses objetos, que serão incluídos automaticamente em cada partição.
```
CREATE SCHEMA data_mart;
CREATE TABLE data_mart.organization ( org_id BIGSERIAL,
org_name TEXT,
CONSTRAINT pk_organization PRIMARY KEY (org_id)
);
CREATE TABLE data_mart.events(
event_id BIGSERIAL,
operation CHAR(1),
value FLOAT(24),
parent_event_id BIGINT,
event_type VARCHAR(25),
org_id BIGSERIAL,
created_at timestamp,
CONSTRAINT pk_data_mart_event PRIMARY KEY (event_id, created_at),
CONSTRAINT ck_valid_operation CHECK (operation = 'C' OR operation = 'D'),
CONSTRAINT fk_orga_membership
FOREIGN KEY(org_id)
REFERENCES data_mart.organization (org_id),
CONSTRAINT fk_parent_event_id
FOREIGN KEY(parent_event_id, created_at)
REFERENCES data_mart.events (event_id,created_at)
) PARTITION BY RANGE (created_at);
CREATE INDEX idx_org_id ON data_mart.events(org_id);
CREATE INDEX idx_event_type ON data_mart.events(event_type);
```
## Configurar partições usando a função create\$1parent
Depois de habilitar a extensão `pg_partman`, use a função `create_parent` para configurar partições dentro do esquema de manutenção de partição. Aqui é usado o exemplo de tabela `events` criado em [Ativar a extensão pg\$1partmanConfigurar a manutenção da partição usando a função run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable). Chame a função `create_parent` da seguinte forma:
```
SELECT partman.create_parent(
p_parent_table => 'data_mart.events',
p_control => 'created_at',
p_type => 'range',
p_interval => '1 day',
p_premake => 30);
```
Os parâmetros são os seguintes:
+ `p_parent_table` – a tabela particionada pai. Essa tabela já deve existir e estar totalmente qualificada, incluindo o esquema.
+ `p_control` – a coluna na qual o particionamento deve ser baseado. O tipo de dados deve ser um inteiro ou baseado em tempo.
+ `p_type`: o tipo é `'range'` ou `'list'`.
+ `p_interval` – o intervalo ou a faixa de inteiros para cada partição. Os valores de exemplo incluem `1 day`, `1 hour` e assim por diante.
+ `p_premake` – o número de partições para criar antecipadamente a fim de dar suporte a novas inserções.
Para obter uma descrição completa da função `create_parent`, consulte [Funções de criação](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#user-content-creation-functions) na documentação do `pg_partman`..
## Configurar a manutenção da partição usando a função run\$1maintenance\$1proc
Você pode executar operações de manutenção de partição para criar automaticamente novas partições, desanexar partições ou remover partições antigas. A manutenção da partição depende da função `run_maintenance_proc` da extesão `pg_partman` e da extensão `pg_cron`, que inicia um programador interno. O agendador `pg_cron` executa automaticamente instruções SQL, funções e procedimentos definidos em seus bancos de dados.
A seguir, será usado o exemplo de tabela `events` criado em [Ativar a extensão pg\$1partmanConfigurar a manutenção da partição usando a função run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable) para definir que as operações de manutenção de partição serão executadas automaticamente. Como pré-requisito, adicione `pg_cron` ao parâmetro `shared_preload_libraries` no grupo de parâmetros da instância de banco de dados.
```
CREATE EXTENSION pg_cron;
UPDATE partman.part_config
SET infinite_time_partitions = true,
retention = '3 months',
retention_keep_table=true
WHERE parent_table = 'data_mart.events';
SELECT cron.schedule('@hourly', $$CALL partman.run_maintenance_proc()$$);
```
A seguir, você pode encontrar uma explicação detalhada do exemplo anterior:
1. Modifique o grupo de parâmetros associado à sua instância de banco de dados e adicione `pg_cron` ao valor do parâmetro `shared_preload_libraries`. Essa alteração exige a reinicialização da instância de banco de dados para que tenha efeito. Para obter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Execute o comando `CREATE EXTENSION pg_cron;` usando uma conta que tenha as permissões de `rds_superuser`. Isso habilita a extensão `pg_cron`. Para obter mais informações, consulte [Agendar manutenção com a extensão pg\$1cron do PostgreSQL](PostgreSQL_pg_cron.md).
1. Execute o comando `UPDATE partman.part_config` para ajustar as configurações `pg_partman` para a tabela `data_mart.events`.
1. Execute o comando `SET` . . . para configurar a tabela `data_mart.events`, com estas cláusulas:
1. `infinite_time_partitions = true,` – configura a tabela para poder criar novas partições automaticamente, sem qualquer limite.
1. `retention = '3 months',` – configura a tabela para ter uma retenção máxima de três meses.
1. `retention_keep_table=true `– Configura a tabela para que, quando o período de retenção for devido, a tabela não seja excluída automaticamente. Em vez disso, as partições que são mais antigas do que o período de retenção são apenas separadas da tabela pai.
1. Execute o comando `SELECT cron.schedule` . . . para fazer uma chamada da função `pg_cron`. Esta chamada define com que frequência o programador executa o procedimento de manutenção `pg_partman`, `partman.run_maintenance_proc`. Para este exemplo, o procedimento é executado a cada hora.
Para obter uma descrição completa da função `run_maintenance_proc`, consulte [Funções de manutenção](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#maintenance-functions) na documentação do `pg_partman`.
# Usar pgAudit para registrar a atividade do banco de dados
Instituições financeiras, agências governamentais e muitos setores precisam manter *registros de auditoria* para atender aos requisitos regulatórios. Ao usar a extensão do PostgreSQL Audit (pgAudit) com sua instância de banco de dados do RDS para PostgreSQL, você pode capturar os registros detalhados que normalmente são necessários aos auditores ou para atender aos requisitos regulatórios. Por exemplo, você pode configurar a extensão pgAudit para monitorar alterações feitas em tabelas e bancos de dados específicos, registrar o usuário que fez a alteração e muitos outros detalhes.
A extensão pgAudit se baseia na funcionalidade da infraestrutura de registro em log nativa do PostgreSQL, estendendo as mensagens de log com mais detalhes. Em outras palavras, é usada a mesma abordagem para visualizar o log de auditoria e quaisquer mensagens de log. Para obter mais informações sobre o registro em log do PostgreSQL, consulte [Arquivos de log do banco de dados RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
A extensão pgAudit retira dados confidenciais, como senhas de texto não criptografado, dos logs. Se sua instância de banco de dados do RDS para PostgreSQL estiver configurada para registrar declarações de linguagem de manipulação de dados (DML) conforme detalhado em [Ativar o registro em log de consultas para a instância de banco de dados do RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md), você poderá evitar o problema de senha de texto não criptografado usando a extensão do PostgreSQL Audit.
Você pode configurar a auditoria em suas instâncias de banco de dados com um alto grau de especificidade. É possível auditar todos os bancos de dados e todos os usuários. Ou você pode optar por auditar somente determinados bancos de dados, usuários e outros objetos. Também é possível excluir explicitamente da auditoria determinados usuários e bancos de dados. Para obter mais informações, consulte [Excluir usuários ou bancos de dados do registro em log de auditoria](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md).
Dada a quantidade de detalhes que podem ser capturados, recomendamos que, se você usar pgAudit, monitore seu consumo de armazenamento.
A extensão pgAudit é compatível com todas as Versões do RDS para PostgreSQL. Para obter uma lista de versões de pgAudit compatíveis com a versão do RDS para PostgreSQL, consulte [Extension versions for Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) (Versões de extensão para o Amazon Aurora PostgreSQL) em *Amazon RDS for PostgreSQL Release Notes* (Notas de versão do Amazon RDS para PostgreSQL).
**Topics**
+ [
# Configurar a extensão pgAudit
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)
+ [
# Auditar objetos de banco de dados
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.auditing.md)
+ [
# Excluir usuários ou bancos de dados do registro em log de auditoria
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)
+ [
# Referência para a extensão pgAudit
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md)
# Configurar a extensão pgAudit
Para configurar a extensão pgAudit em sua instância de banco de dados do RDS para PostgreSQL, , primeiro adicione pgAudit às bibliotecas compartilhadas no grupo de parâmetros de banco de dados personalizado para sua instância de banco de dados do RDS para PostgreSQL. Para obter informações sobre como criar um grupo de parâmetros de banco de dados, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md). Depois, instale a extensão pgAudit. Por fim, especifique os bancos de dados e os objetos que deseja auditar. Os procedimentos nesta seção mostram o procedimento. É possível usar o Console de gerenciamento da AWS ou a AWS CLI.
Você deve ter permissões como a função `rds_superuser` para realizar todas essas tarefas.
As etapas a seguir pressupõem que sua instância de banco de dados do RDS para PostgreSQL esteja associada a um grupo de parâmetros de banco de dados.
## Console
**Como configurar a extensão pgAudit**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, selecione sua instância de banco de dados do RDS para PostgreSQL.
1. Abra a guia **Configuration** (Configuração) para sua Instância de banco de dados do RDS para PostgreSQL. Entre os detalhes da instância, encontre o link **Parameter group** (Grupo de parâmetros).
1. Clique no link para abrir os parâmetros personalizados associados ao seu Instância de banco de dados do RDS para PostgreSQL.
1. No campo **Parameters** (Parâmetros), digite `shared_pre` para encontrar o parâmetro `shared_preload_libraries`.
1. Selecione **Edit parameters** (Editar parâmetros) para acessar os valores das propriedades.
1. Adicione `pgaudit` à lista no campo **Values** (Valores). Use uma vírgula para separar itens na lista de valores.
![\[Imagem do parâmetro shared_preload_libaries com pgAudit adicionada.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. Reinicie a instância de banco de dados do RDS para PostgreSQL para que a alteração no parâmetro `shared_preload_libraries` tenha efeito.
1. Quando a instância estiver disponível, verifique se a pgAudit foi inicializada. Use `psql` para se conectar à instância de banco de dados do RDS para PostgreSQL e depois execute o comando a seguir.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
1. Com a pgAudit inicializada, agora você pode criar a extensão. Você precisa criar a extensão depois de inicializar a biblioteca porque a extensão `pgaudit` instala acionadores de eventos para auditar declarações de linguagem de definição de dados (DDL).
```
CREATE EXTENSION pgaudit;
```
1. Feche a sessão `psql`.
```
labdb=> \q
```
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Encontre o parâmetro `pgaudit.log` na lista e defina como o valor apropriado para o caso de uso. Por exemplo, definir o parâmetro `pgaudit.log` como `write` conforme mostrado na imagem a seguir captura inserções, atualizações, exclusões e alguns outros tipos de alterações no log.
![\[Imagem do parâmetro pgaudit.log com a configuração.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/rpg_set_pgaudit-log-level.png)
Você também pode selecionar um dos valores a seguir para o parâmetro `pgaudit.log`.
+ none: esse é o valor padrão. Nenhuma alteração no banco de dados é registrada.
+ all: registra tudo (read, write, function, role, ddl, misc).
+ ddl: registra todas as instruções de linguagem de definição de dados (DDL) não incluídas na classe `ROLE`.
+ function: registra chamadas de função e blocos de `DO`.
+ misc: registra comandos diversos, como `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` e `SET`.
+ read: registra `SELECT` e `COPY` quando a fonte é uma relação (como uma tabela) ou uma consulta.
+ role: registra declarações relacionadas a funções e privilégios, como `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` e `DROP ROLE`.
+ write: registra `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` e `COPY` quando o destino é uma relação (tabela).
1. Escolha **Salvar alterações**.
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Selecione a instância de banco de dados do RDS para PostgreSQL na lista Bancos de dados.
## AWS CLI
**Como configurar a pgAudit**
Para configurar a pgAudit usando a AWS CLI, chame a operação [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para modificar os parâmetros do log de auditoria em seu grupo de parâmetros personalizado, conforme mostrado no procedimento a seguir.
1. Use o comando AWS CLI a seguir para adicionar `pgaudit` ao parâmetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use o comando AWS CLI a seguir para reinicializar a instância de banco de dados do RDS para PostgreSQL para que a biblioteca da pgaudit seja inicializada.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Quando a instância estiver disponível, verifique se a `pgaudit` foi inicializada. Use `psql` para se conectar à instância de banco de dados do RDS para PostgreSQL e, depois, execute o comando a seguir.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
Com a pgAudit inicializada, agora você pode criar a extensão.
```
CREATE EXTENSION pgaudit;
```
1. Feche a sessão `psql` para que você possa usar a AWS CLI.
```
labdb=> \q
```
1. Use o comando AWS CLI a seguir para especificar as classes de declaração que devem ser registradas pelo registro em log de auditoria da sessão. O exemplo define o parâmetro `pgaudit.log` como `write`, que captura inserções, atualizações e exclusões no log.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.log,ParameterValue=write,ApplyMethod=pending-reboot" \
--region aws-region
```
Você também pode selecionar um dos valores a seguir para o parâmetro `pgaudit.log`.
+ none: esse é o valor padrão. Nenhuma alteração no banco de dados é registrada.
+ all: registra tudo (read, write, function, role, ddl, misc).
+ ddl: registra todas as instruções de linguagem de definição de dados (DDL) não incluídas na classe `ROLE`.
+ function: registra chamadas de função e blocos de `DO`.
+ misc: registra comandos diversos, como `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` e `SET`.
+ read: registra `SELECT` e `COPY` quando a fonte é uma relação (como uma tabela) ou uma consulta.
+ role: registra declarações relacionadas a funções e privilégios, como `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` e `DROP ROLE`.
+ write: registra `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` e `COPY` quando o destino é uma relação (tabela).
Reinicie a instância de banco de dados do RDS para PostgreSQL usando o comando AWS CLI a seguir.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Auditar objetos de banco de dados
Com a pgAudit configurada em sua instância e banco de dados do RDS para PostgreSQL e configurada para seus requisitos, informações mais detalhadas são capturadas no log do PostgreSQL. Por exemplo, enquanto a configuração de registro em padrão do PostgreSQL identifica a data e a hora em que uma alteração foi feita em uma tabela do banco de dados, com a extensão pgAudit, a entrada do log pode incluir o esquema, o usuário que fez a alteração e outros detalhes, dependendo de como os parâmetros da extensão estão configurados. Você pode configurar a auditoria para monitorar as alterações das maneiras a seguir.
+ Para cada sessão, por usuário. Para o nível da sessão, você pode capturar o texto do comando totalmente qualificado.
+ Para cada objeto, por usuário e por banco de dados.
O recurso de auditoria de objetos é ativado quando você cria a função `rds_pgaudit` no sistema e depois a adiciona ao parâmetro `pgaudit.role` no grupo de parâmetros personalizado. Por padrão, o parâmetro `pgaudit.role` não está definido e o único valor permitido é `rds_pgaudit`. As etapas a seguir pressupõem que a `pgaudit` tenha sido inicializada e que você tenha criado a extensão `pgaudit` seguindo o procedimento em [Configurar a extensão pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md).
![\[Imagem do arquivo de log do PostgreSQL depois de configurar a pgAudit.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/pgaudit-log-example.png)
Conforme mostrado neste exemplo, a linha “LOG: AUDIT: SESSION” fornece informações sobre a tabela e o respectivo esquema, entre outros detalhes.
**Como configurar a auditoria de objetos**
1. Use `psql` para se conectar à instância de banco de dados do RDS para PostgreSQL.
```
psql --host=your-instance-name.aws-region.rds.amazonaws.com --port=5432 --username=postgrespostgres --password --dbname=labdb
```
1. Crie uma função de banco de dados chamada `rds_pgaudit` usando o comando a seguir.
```
labdb=> CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
```
1. Feche a sessão `psql`.
```
labdb=> \q
```
Nas próximas etapas, use a AWS CLI para modificar os parâmetros de log de auditoria no grupo de parâmetros personalizado.
1. Use o comando AWS CLI a seguir para definir o parâmetro `pgaudit.role` como `rds_pgaudit`. Por padrão, esse parâmetro está vazio, e `rds_pgaudit` é o único valor permitido.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use o comando AWS CLI a seguir para reinicializar a instância de banco de dados do RDS para PostgreSQL para que as alterações nos parâmetros tenham efeito.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Execute o comando a seguir para confirmar que `pgaudit.role` está definido como `rds_pgaudit`.
```
SHOW pgaudit.role;
pgaudit.role
------------------
rds_pgaudit
```
Para testar o registro em log da extensão pgAudit, execute vários comandos de exemplo semelhantes ao que você deseja auditar. Por exemplo, você pode executar os seguintes comandos.
```
CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id
----
(0 rows)
```
Os logs do banco de dados devem conter uma entrada semelhante à seguinte.
```
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
```
Para obter informações sobre como visualizar os logs, consulte [Monitorar arquivos de log do Amazon RDS](USER_LogAccess.md).
Para saber mais sobre a extensão pgAudit, consulte [pgAudit](https://github.com/pgaudit/pgaudit/blob/master/README.md) no GitHub.
# Excluir usuários ou bancos de dados do registro em log de auditoria
Conforme discutido em [Arquivos de log do banco de dados RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md), os logs do PostgreSQL consomem espaço de armazenamento. O uso da extensão pgAudit aumenta o volume de dados reunidos nos logs em vários graus, dependendo das alterações monitoradas. Talvez você não precise auditar todos os usuários nem bancos de dados no Instância de banco de dados do RDS para PostgreSQL.
Para minimizar os impactos no armazenamento e evitar a captura desnecessária de registros de auditoria, você pode excluir usuários e bancos de dados da auditoria. Você também pode alterar o registro em log em determinada sessão. Os exemplos a seguir mostram o procedimento.
**nota**
As configurações de parâmetros no nível da sessão têm precedência sobre as configurações no grupo de parâmetros de banco de dados personalizado para a instância de banco de dados do RDS para PostgreSQL. Se você não quiser que os usuários do banco de dados ignorem suas configurações de registro em log de auditoria, não se esqueça de alterar as permissões.
Suponha que sua instância de banco de dados do RDS para PostgreSQL esteja configurada ) para auditar o mesmo nível de atividade para todos os usuários e bancos de dados. Depois, decida que não quer auditar o usuário `myuser`. Você pode desativar a auditoria para `myuser` com o comando SQL a seguir.
```
ALTER USER myuser SET pgaudit.log TO 'NONE';
```
Depois, você pode usar a consulta a seguir para conferir a coluna `user_specific_settings` para `pgaudit.log` a fim de confirmar se o parâmetro está definido como `NONE`.
```
SELECT
usename AS user_name,
useconfig AS user_specific_settings
FROM
pg_user
WHERE
usename = 'myuser';
```
Você deve ver a saída da forma a seguir.
```
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
```
Você pode desativar o registro em log de determinado usuário no meio da sessão com o banco de dados com o comando a seguir.
```
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
```
Use a consulta a seguir para conferir a coluna de configurações de pgaudit.log para uma combinação específica de usuário e banco de dados.
```
SELECT
usename AS "user_name",
datname AS "database_name",
pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
pg_catalog.pg_db_role_setting s
LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
usename = 'myuser'
AND datname = 'mydatabase'
ORDER BY
1,
2;
```
Você verá uma saída semelhante à seguinte.
```
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
```
Depois de desativar a auditoria de `myuser`, você decide que não deseja monitorar as alterações em `mydatabase`. Você pode desativar a auditoria para esse banco de dados específico usando o comando a seguir.
```
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
```
Depois, use a consulta a seguir para conferir a coluna database\$1specific\$1settings a fim de confirmar se pgaudit.log está definido como NONE.
```
SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';
```
Você deve ver a saída da forma a seguir.
```
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
```
Para restaurar as configurações padrão para myuser, use o seguinte comando:
```
ALTER USER myuser RESET pgaudit.log;
```
Para restaurar as configurações padrão para um banco de dados, use o comando a seguir.
```
ALTER DATABASE mydatabase RESET pgaudit.log;
```
Para restaurar as configurações padrão de usuário e banco de dados, use o comando a seguir.
```
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
```
Você também pode capturar eventos específicos no log definindo `pgaudit.log` como um dos outros valores permitidos para o parâmetro `pgaudit.log`. Para ter mais informações, consulte [Lista de configurações permitidas para o parâmetro `pgaudit.log`](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings).
```
ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
```
# Referência para a extensão pgAudit
Você pode especificar o nível de detalhes que deseja para o log de auditoria alterando um ou mais dos parâmetros listados nesta seção.
## Controlar o comportamento da pgAudit
Você pode controlar o registro em log de auditoria alterando um ou mais dos parâmetros listados na tabela a seguir.
| Parameter | Descrição |
| --- | --- |
| `pgaudit.log` | Especifica as classes de declaração que serão registradas pelo registro em log de auditoria de sessão. Os valores permitidos incluem ddl, function, misc, read, role, write, none, all. Para obter mais informações, consulte [Lista de configurações permitidas para o parâmetro `pgaudit.log`](#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings). |
| `pgaudit.log_catalog` | Quando ativado (definido como 1), adiciona declarações à trilha de auditoria se todas as relações em uma declaração estiverem em pg\$1catalog. |
| `pgaudit.log_level` | Especifica o nível de log que será usado para entradas de log. Valores permitidos: debug5, debug4, debug3, debug2, debug1, info, notice, warning, log |
| `pgaudit.log_parameter` | Quando ativado (definido como 1), os parâmetros passados com a declaração são capturados no log de auditoria. |
| `pgaudit.log_relation` | Quando ativado (definido como 1), o log de auditoria da sessão cria uma entrada de log separada para cada relação (TABLE, VIEW etc.) referenciada em uma declaração SELECT ou DML. |
| `pgaudit.log_statement_once` | Especifica se o registro incluirá o texto e os parâmetros da instrução com a primeira entrada de log para uma combinação de instrução/subinstrução ou com cada entrada. |
| `pgaudit.role` | Especifica a função primária a ser usada para o registro em log de auditoria de objetos. A única entrada permitida é `rds_pgaudit`. |
## Lista de configurações permitidas para o parâmetro `pgaudit.log`
| Valor | Descrição |
| --- | --- |
| nenhuma | Esse é o padrão. Nenhuma alteração no banco de dados é registrada. |
| todas | Registra tudo (read, write, function, role, ddl, misc). |
| ddl | Registra todas as declarações de linguagem de definição de dados (DDL) não incluídas na classe `ROLE`. |
| função | Registra chamadas de função e blocos de `DO`. |
| misc | Registra comandos diversos, como `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` e `SET`. |
| leitura | Registra `SELECT` e `COPY` quando a fonte é uma relação (como uma tabela) ou uma consulta. |
| perfil | Registra declarações relacionadas a funções e privilégios, como `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` e `DROP ROLE`. |
| write | Registra `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` e `COPY` quando o destino é uma relação (tabela). |
Para registrar vários tipos de eventos com auditoria de sessões, use uma lista separada por vírgulas. Para registrar todos os tipos de eventos, defina `pgaudit.log` para `ALL`. Reinicie a instância de banco de dados para aplicar as alterações.
Com a auditoria de objetos, você pode refinar o registro em log de auditoria para trabalhar com relações específicas. Por exemplo, você pode especificar que deseja o registro em log de auditoria para operações `READ` em uma ou mais tabelas.
# Agendar manutenção com a extensão pg\$1cron do PostgreSQL
Você pode utilizar a extensão `pg_cron` do PostgreSQL para programar comandos de manutenção dentro de um banco de dados do PostgreSQL. Para obter mais informações sobre a extensão, consulte [O que é pg\$1cron?](https://github.com/citusdata/pg_cron) na documentação do pg\$1cron.
A extensão `pg_cron` é compatível com o mecanismo do RDS para PostgreSQL versões 12.5 e posteriores.
Para saber mais sobre como usar `pg_cron`, consulte [Programar trabalhos com pg\$1cron em bancos de dados do RDS para PostgreSQL ou compatíveis com o Aurora PostgreSQL](https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/).
**nota**
A versão da extensão `pg_cron` é exibida como uma versão de dois dígitos, por exemplo, 1.6, na visualização pg\$1available\$1extensions. Embora você possa ver versões de três dígitos, por exemplo, 1.6.4 ou 1.6.5, listadas em alguns contextos, você deve especificar a versão de dois dígitos ao realizar uma atualização de extensão.
**Topics**
+ [
## Configurar a extensão pg\$1cron
](#PostgreSQL_pg_cron.enable)
+ [
## Conceder permissões de banco de dados para usar pg\$1cron
](#PostgreSQL_pg_cron.permissions)
+ [
## Agendar trabalhos de pg\$1cron
](#PostgreSQL_pg_cron.examples)
+ [
## Referência para a extensão pg\$1cron
](#PostgreSQL_pg_cron.reference)
## Configurar a extensão pg\$1cron
Configure a extensão `pg_cron` da seguinte forma:
1. Modifique o grupo de parâmetros personalizado associado à sua instância de banco de dados do PostgreSQL adicionando `pg_cron` ao valor do parâmetro `shared_preload_libraries`.
+ Se a instância de banco de dados do RDS para PostgreSQL usa o parâmetro `rds.allowed_extensions` para listar explicitamente as extensões que podem ser instaladas, você precisa adicionar a extensão `pg_cron` à lista. Somente determinadas versões do RDS para PostgreSQL oferecem suporte ao parâmetro `rds.allowed_extensions`. Por padrão, todas as extensões disponíveis são permitidas. Para obter mais informações, consulte [Restringir a instalação de extensões do PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Reinicie a instância de banco de dados do PostgreSQL para que as alterações no grupo de parâmetros entrem em vigor. Para saber mais sobre como trabalhar com grupos de parâmetros, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Após a reinicialização da instância de banco de dados do PostgreSQL, execute o comando a seguir usando uma conta que tenha permissões `rds_superuser`. Por exemplo, se você usou as configurações padrão ao criar a instância de banco de dados do RDS para PostgreSQL, conecte-se como o usuário `postgres` e crie a extensão.
```
CREATE EXTENSION pg_cron;
```
O agendador do `pg_cron` é definido no banco de dados PostgreSQL padrão chamado `postgres`. Os objetos `pg_cron` são criados neste banco de dados `postgres` e todas as ações de agendamento são executadas neste banco de dados.
1. Você pode usar as configurações padrão ou programar trabalhos para serem executados em outros bancos de dados dentro de sua instância de banco de dados PostgreSQL. Para programar trabalhos a serem executados em outros bancos de dados em sua instância de banco de dados PostgreSQL, consulte o exemplo em [Agendar um trabalho cron para um banco de dados diferente do banco de dados padrão](#PostgreSQL_pg_cron.otherDB).
## Conceder permissões de banco de dados para usar pg\$1cron
A instalação da extensão `pg_cron` requer privilégios de `rds_superuser`. No entanto, as permissões para usar `pg_cron` podem ser concedidas (por um membro do grupo/perfil de `rds_superuser`) para outros usuários do banco de dados, para que eles possam programar seus próprios trabalhos. Recomendamos que você conceda permissões para o esquema `cron` somente conforme necessário se ele melhorar as operações do ambiente de produção.
Para conceder permissão a um usuário do banco de dados no esquema `cron`, execute o seguinte comando:
```
postgres=> GRANT USAGE ON SCHEMA cron TO db-user;
```
Isso concede a *db-user* permissão para acessar o esquema `cron` para programar trabalhos cron para os objetos que o usuário tem permissão para acessar. Se o usuário do banco de dados não tiver permissões, o trabalho falhará após a publicação da mensagem de erro no arquivo `postgresql.log`, conforme mostrado a seguir:
```
2020-12-08 16:41:00 UTC::@:[30647]:ERROR: permission denied for table table-name
2020-12-08 16:41:00 UTC::@:[27071]:LOG: background worker "pg_cron" (PID 30647) exited with exit code 1
```
Em outras palavras, certifique-se de que os usuários do banco de dados que tenham permissões no esquema `cron` também tenham permissões nos objetos (tabelas, esquemas e assim por diante) que planejam programar.
Os detalhes do trabalho cron e seu sucesso ou falha também são capturados na tabela `cron.job_run_details`. Para obter mais informações, consulte [Tabelas para agendar trabalhos e capturar status](#PostgreSQL_pg_cron.tables).
## Agendar trabalhos de pg\$1cron
As seções a seguir mostram como você pode agendar várias tarefas de gerenciamento usando trabalhos `pg_cron`.
**nota**
Ao criar trabalhos `pg_cron`, verifique se a configuração `max_worker_processes` a configuração é maior do que o número de `cron.max_running_jobs`. Um trabalho `pg_cron` falhará se ficar sem processos de operador em segundo plano. O número padrão de trabalhos `pg_cron` é `5`. Para obter mais informações, consulte [Parâmetros para gerenciar a extensão pg\$1cron](#PostgreSQL_pg_cron.parameters).
**Topics**
+ [
### Vacuum de tabelas
](#PostgreSQL_pg_cron.vacuum)
+ [
### Limpar a tabela de histórico de pg\$1cron
](#PostgreSQL_pg_cron.job_run_details)
+ [
### Registrar em log erros somente no arquivo postgresql.log
](#PostgreSQL_pg_cron.log_run)
+ [
### Agendar um trabalho cron para um banco de dados diferente do banco de dados padrão
](#PostgreSQL_pg_cron.otherDB)
### Vacuum de tabelas
O autovacuum lida com manutenção de vacuum para a maioria dos casos. No entanto, você pode agendar o vacuum de uma tabela específica quando quiser.
Consulte também, [Trabalhar com o autovacuum do PostgreSQL no Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
Veja a seguir um exemplo de uso da função `cron.schedule` para configurar um trabalho a ser usado `VACUUM FREEZE` em uma tabela específica todos os dias às 22:00 (GMT).
```
SELECT cron.schedule('manual vacuum', '0 22 * * *', 'VACUUM FREEZE pgbench_accounts');
schedule
----------
1
(1 row)
```
Após o exemplo anterior ser executado, você pode verificar o histórico na tabela `cron.job_run_details` da seguinte forma.
```
postgres=> SELECT * FROM cron.job_run_details;
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
-------+-------+---------+----------+----------+--------------------------------+-----------+----------------+-------------------------------+-------------------------------
1 | 1 | 3395 | postgres | adminuser| vacuum freeze pgbench_accounts | succeeded | VACUUM | 2020-12-04 21:10:00.050386+00 | 2020-12-04 21:10:00.072028+00
(1 row)
```
A seguir está uma consulta à tabela `cron.job_run_details` para ver os trabalhos que falharam.
```
postgres=> SELECT * FROM cron.job_run_details WHERE status = 'failed';
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
------+-------+---------+----------+----------+-------------------------------+--------+--------------------------------------------------+-------------------------------+------------------------------
5 | 4 | 30339 | postgres | adminuser| vacuum freeze pgbench_account | failed | ERROR: relation "pgbench_account" does not exist | 2020-12-04 21:48:00.015145+00 | 2020-12-04 21:48:00.029567+00
(1 row)
```
Para obter mais informações, consulte [Tabelas para agendar trabalhos e capturar status](#PostgreSQL_pg_cron.tables).
### Limpar a tabela de histórico de pg\$1cron
A tabela `cron.job_run_details` contém um histórico de trabalhos cron que podem se tornar muito grandes ao longo do tempo. Recomendamos que você agende um trabalho que limpe essa tabela. Por exemplo, manter uma semana de registros pode ser suficiente para fins de solução de problemas.
O exemplo a seguir usa a função [cron.schedule](#PostgreSQL_pg_cron.schedule) para agendar um trabalho que é executado todos os dias à meia-noite para limpar a tabela `cron.job_run_details`. O trabalho mantém apenas os últimos sete dias. Use sua `rds_superuser` para agendar o trabalho da seguinte forma.
```
SELECT cron.schedule('0 0 * * *', $$DELETE
FROM cron.job_run_details
WHERE end_time < now() - interval '7 days'$$);
```
Para obter mais informações, consulte [Tabelas para agendar trabalhos e capturar status](#PostgreSQL_pg_cron.tables).
### Registrar em log erros somente no arquivo postgresql.log
Para impedir a gravação na tabela `cron.job_run_details`, modifique o grupo de parâmetros associado à instância de banco de dados do PostgreSQL e defina o parâmetro `cron.log_run` como desativado. A extensão `pg_cron` não gravará mais na tabela e vai capturar erros somente no arquivo `postgresql.log`. Para obter mais informações, consulte [Modificar parâmetros em um grupo de parâmetros de banco de dados no Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
Use o comando a seguir para verificar o valor do parâmetro `cron.log_run`.
```
postgres=> SHOW cron.log_run;
```
Para obter mais informações, consulte [Parâmetros para gerenciar a extensão pg\$1cron](#PostgreSQL_pg_cron.parameters).
### Agendar um trabalho cron para um banco de dados diferente do banco de dados padrão
Os metadados para `pg_cron` são todos mantidos no banco de dados padrão PostgreSQL chamado `postgres`. Como os operadores em segundo plano são usados para executar os trabalhos cron de manutenção, você pode agendar um trabalho em qualquer um dos seus bancos de dados dentro da instância de banco de dados do PostgreSQL.
**nota**
Somente usuários com o perfil `rds_superuser` ou privilégios `rds_superuser` podem listar todos os trabalhos cron no banco de dados. Outros usuários podem visualizar somente seus próprios trabalhos na tabela `cron.job`.
1. No banco de dados cron, agende o trabalho como você normalmente faria usando a [cron.schedule](#PostgreSQL_pg_cron.schedule).
```
postgres=> SELECT cron.schedule('database1 manual vacuum', '29 03 * * *', 'vacuum freeze test_table');
```
1. Como um usuário com a função `rds_superuser`, atualize a coluna do banco de dados para o trabalho que você acabou de criar para que ele seja executado em outro banco de dados dentro de sua instância de banco de dados do PostgreSQL.
```
postgres=> UPDATE cron.job SET database = 'database1' WHERE jobid = 106;
```
1. Verifique consultando a tabela `cron.job`.
```
postgres=> SELECT * FROM cron.job;
jobid | schedule | command | nodename | nodeport | database | username | active | jobname
------+-------------+--------------------------------+-----------+----------+----------+-----------+--------+-------------------------
106 | 29 03 * * * | vacuum freeze test_table | localhost | 8192 | database1| adminuser | t | database1 manual vacuum
1 | 59 23 * * * | vacuum freeze pgbench_accounts | localhost | 8192 | postgres | adminuser | t | manual vacuum
(2 rows)
```
**nota**
Em algumas situações, você pode adicionar um cron job que você pretende executar em um banco de dados diferente. Nesses casos, o job pode tentar executar no banco de dados padrão (`postgres`) antes de atualizar a coluna correta do banco de dados. Se o nome de usuário tiver permissões, o trabalho será executado com êxito no banco de dados padrão.
## Referência para a extensão pg\$1cron
Você pode usar os seguintes parâmetros, funções e tabelas com a extensão `pg_cron`. Para obter mais informações, consulte [O que é pg\$1cron?](https://github.com/citusdata/pg_cron) na documentação do pg\$1cron.
**Topics**
+ [
### Parâmetros para gerenciar a extensão pg\$1cron
](#PostgreSQL_pg_cron.parameters)
+ [
### Referência da função: cron.schedule
](#PostgreSQL_pg_cron.schedule)
+ [
### Referência da função: cron.schedule
](#PostgreSQL_pg_cron.unschedule)
+ [
### Tabelas para agendar trabalhos e capturar status
](#PostgreSQL_pg_cron.tables)
### Parâmetros para gerenciar a extensão pg\$1cron
Veja a seguir uma lista de parâmetros que controlam o comportamento da extensão `pg_cron`.
| Parâmetro | Descrição |
| --- | --- |
| cron.database\$1name | O banco de dados em que os metadados de `pg_cron` são mantidos. |
| cron.host | O nome do host para se conectar ao PostgresSQL. Não é possível modificar esse valor. |
| cron.log\$1run | Registre todos os trabalhos executados na tabela `job_run_details`. Os valores são `on` ou `off`. Para obter mais informações, consulte [Tabelas para agendar trabalhos e capturar status](#PostgreSQL_pg_cron.tables). |
| cron.log\$1statement | Registre todas as instruções cron antes de executá-las. Os valores são `on` ou `off`. |
| cron.max\$1running\$1jobs | O número máximo de trabalhos que podem ser executados simultaneamente. |
| cron.use\$1background\$1workers | Use trabalhadores em segundo plano em vez de sessões de cliente. Não é possível modificar esse valor. |
Use o seguinte comando SQL para exibir esses parâmetros e seus valores.
```
postgres=> SELECT name, setting, short_desc FROM pg_settings WHERE name LIKE 'cron.%' ORDER BY name;
```
### Referência da função: cron.schedule
Essa função agenda um trabalho cron. Inicialmente, o trabalho é agendado no banco de dados `postgres` padrão. A função retorna um valor `bigint` que representa o identificador de trabalho. Para agendar trabalhos a serem executados em outros bancos de dados em sua instância de banco de dados PostgreSQL, consulte o exemplo em [Agendar um trabalho cron para um banco de dados diferente do banco de dados padrão](#PostgreSQL_pg_cron.otherDB).
A função tem dois formatos de sintaxe.
**Sintaxe**
```
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
**Parâmetros**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Exemplos**
```
postgres=> SELECT cron.schedule ('test','0 10 * * *', 'VACUUM pgbench_history');
schedule
----------
145
(1 row)
postgres=> SELECT cron.schedule ('0 15 * * *', 'VACUUM pgbench_accounts');
schedule
----------
146
(1 row)
```
### Referência da função: cron.schedule
Esta função exclui um trabalho cron. Você pode especificar `job_name` ou `job_id`. Uma política garante que você seja o proprietário para remover a programação do trabalho. A função retorna um booleano indicando êxito ou falha.
A função tem os seguintes formatos de sintaxe.
**Sintaxe**
```
cron.unschedule (job_id);
cron.unschedule (job_name);
```
**Parâmetros**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Exemplos**
```
postgres=> SELECT cron.unschedule(108);
unschedule
------------
t
(1 row)
postgres=> SELECT cron.unschedule('test');
unschedule
------------
t
(1 row)
```
### Tabelas para agendar trabalhos e capturar status
As tabelas a seguir são usadas para agendar os trabalhos cron e registrar como os trabalhos foram concluídos.
| Tabela | Descrição |
| --- | --- |
| cron.job | Contém os metadados sobre cada trabalho agendado. A maioria das interações com esta tabela deve ser feita por meio das funções `cron.schedule` e `cron.unschedule`. Não recomendamos conceder privilégios de atualização ou inserção diretamente a essa tabela. Isso permitiria que o usuário atualizasse a coluna `username` para ser executada como `rds-superuser`. |
| cron.job\$1run\$1details | Contém informações históricas sobre trabalhos agendados passados que foram executados. Isso é útil para investigar o status, as mensagens de retorno e as horas de início e término do trabalho executado. Para evitar que esta tabela cresça indefinidamente, purgue-a regularmente. Para ver um exemplo, consulte [Limpar a tabela de histórico de pg\$1cron](#PostgreSQL_pg_cron.job_run_details). |
# Usar pglogical para sincronizar dados entre instâncias
Todas as versões do RDS para PostgreSQL atualmente disponíveis são compatíveis com a extensão `pglogical`. A extensão pglogical é anterior ao recurso de replicação lógica funcionalmente similar que foi introduzido pelo PostgreSQL na versão 10. Para obter mais informações, consulte [Executar replicação lógica para o Amazon RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
A extensão `pglogical` é compatível com a replicação lógica entre dois ou mais Instâncias de banco de dados do RDS para PostgreSQL. Ela também é compatível com a replicação entre diferentes versões do PostgreSQL e entre bancos de dados executados em instâncias de banco de dados RDS para PostgreSQL e clusters de banco de dados Aurora PostgreSQL. A extensão `pglogical` usa um modelo de publicação e assinatura para replicar alterações em tabelas e outros objetos, como sequências, de um editor para um assinante. Ela depende de um slot de replicação para garantir que as alterações sejam sincronizadas de um nó do editor para um nó assinante, definido da seguinte forma.
+ O *nó do editor* é a instância de banco de dados RDS para PostgreSQL, que é a fonte de dados a serem replicados para outros nós. O nó do editor define as tabelas a serem replicadas em um conjunto de publicações.
+ O *nó do assinante* é a instância de banco de dados Aurora PostgreSQL que recebe atualizações WAL do editor. O assinante cria uma assinatura para se conectar ao editor e obter os dados WAL decodificados. Quando o assinante cria a assinatura, o slot de replicação é criado no nó do editor.
Depois, você pode encontrar informações sobre a configuração da extensão `pglogical`.
**Topics**
+ [
## Requisitos e limitações da extensão pglogical
](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations)
+ [
# Configurar a extensão pglogical
](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)
+ [
# Configurar a replicação lógica para a instância de banco de dados RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md)
+ [
# Restabelecer a replicação lógica após uma atualização principal
](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)
+ [
# Gerenciar slots de replicação lógica para o RDS for PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)
+ [
# Referência de parâmetros da extensão pglogical
](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md)
## Requisitos e limitações da extensão pglogical
Todas as versões atualmente disponíveis do RDS para PostgreSQL são compatíveis com a extensão `pglogical`.
Tanto o nó do editor quanto o do assinante devem estar configurados para replicação lógica.
As tabelas que você deseja replicar de um publicador para um assinante devem ter os mesmos nomes e o mesmo esquema. Essas tabelas também devem conter as mesmas colunas, e as colunas devem usar os mesmos tipos de dados. As tabelas de editores e assinantes devem ter as mesmas chaves primárias. Recomendamos que você use somente a CHAVE PRIMÁRIA como restrição exclusiva.
As tabelas no nó do assinante podem ter mais restrições permissivas do que as do nó do editor para restrições CHECK e NOT NULL.
A extensão `pglogical` fornece recursos como replicação bidirecional que não são compatíveis com o recurso de replicação lógica incorporado ao PostgreSQL (versão 10 e superior). Para obter mais informações, consulte [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Replicação bidirecional do PostgreSQL usando pglogical).
# Configurar a extensão pglogical
Para configurar a extensão `pglogical` em sua instância de banco de dados RDS para PostgreSQL , adicione `pglogical` às bibliotecas compartilhadas no grupo de parâmetros de banco de dados personalizado para sua instância de banco de dados RDS para PostgreSQL. Você também precisa definir o valor do parâmetro `rds.logical_replication` como `1`, para ativar a decodificação lógica. Finalmente, você cria a extensão no banco de dados. Você pode usar o Console de gerenciamento da AWS ou a AWS CLI para essas tarefas.
Você deve ter permissões como a função `rds_superuser` para realizar essas tarefas.
As etapas a seguir pressupõem que a instância de banco de dados do RDS para PostgreSQL está associada a um grupo de parâmetros de banco de dados. Para obter informações sobre como criar um grupo de parâmetros de banco de dados, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
## Console
**Como configurar a extensão pglogical**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, selecione sua instância de banco de dados do RDS para PostgreSQL.
1. Abra a guia **Configuration** (Configuração) para sua Instância de banco de dados do RDS para PostgreSQL. Entre os detalhes da instância, encontre o link **Parameter group** (Grupo de parâmetros).
1. Clique no link para abrir os parâmetros personalizados associados ao seu Instância de banco de dados do RDS para PostgreSQL.
1. No campo **Parâmetros**, digite `shared_pre` para encontrar o parâmetro `shared_preload_libraries`.
1. Selecione **Edit parameters** (Editar parâmetros) para acessar os valores das propriedades.
1. Adicione `pglogical` à lista no campo **Values** (Valores). Use uma vírgula para separar itens na lista de valores.
![\[Imagem do parâmetro shared_preload_libraries com pglogical adicionada.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pglogical.png)
1. Encontre o parâmetro `rds.logical_replication` e defina-o como `1` para ativar a replicação lógica.
1. Reinicialize a instância de banco de dados do RDS para PostgreSQL para que suas alterações tenham efeito.
1. Quando a instância estiver disponível, você poderá usar `psql` (ou pgAdmin) para se conectar à instância de banco de dados RDS para PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Para verificar se pglogical foi inicializada, execute o comando a seguir.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pglogical
(1 row)
```
1. Verifique a configuração que permite a decodificação lógica da forma a seguir.
```
SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
1. Crie a extensão da forma a seguir.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Escolha **Salvar alterações**.
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Selecione a instância de banco de dados do RDS para PostgreSQL na lista de bancos de dados para selecioná-la e depois selecione **Reboot** (Reinicializar) no menu Actions (Ações).
## AWS CLI
**Como configurar a extensão pglogical**
Para configurar a pglogical usando a AWS CLI, chame a operação [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para modificar determinados parâmetros em seu grupo de parâmetros personalizado, conforme mostrado no procedimento a seguir.
1. Use o comando AWS CLI a seguir para adicionar `pglogical` ao parâmetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use o comando AWS CLI a seguir para definir `rds.logical_replication` como `1` a fim de ativar o recurso de decodificação lógica para a Instância de banco de dados do RDS para PostgreSQL.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use o comando AWS CLI a seguir para reinicializar a instância de banco de dados do RDS para PostgreSQL para que a biblioteca da pglogical seja inicializada.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Quando a instância estiver disponível, use `psql` para se conectar à instância de banco de dados RDS para PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Crie a extensão da forma a seguir.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Reinicie a instância de banco de dados do RDS para PostgreSQL usando o comando AWS CLI a seguir.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Configurar a replicação lógica para a instância de banco de dados RDS para PostgreSQL
O procedimento a seguir mostra como iniciar a replicação lógica entre duas instâncias de banco de dados RDS PostgreSQL. As etapas pressupõem que tanto a fonte (editor) quanto o destino (assinante) tenham a extensão `pglogical` configurada conforme detalhado em [Configurar a extensão pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
**nota**
O `node_name` de um nó assinante não pode começar com `rds`.
**Como criar o nó do editor e definir as tabelas a serem replicadas**
Estas etapas pressupõem que a instância de banco de dados do RDS para PostgreSQL tenha um banco de dados com uma ou mais tabelas que você deseja replicar para outro nó. Você precisa recriar a estrutura da tabela do editor no assinante, então, primeiro, obtenha a estrutura da tabela, se necessário. Você pode fazer isso usando o metacomando `psql` `\d tablename` e criando a mesma tabela na instância do assinante. O procedimento a seguir cria uma tabela de exemplo no editor (fonte) para fins de demonstração.
1. Use `psql` para se conectar à instância que tem a tabela que você deseja usar como fonte para assinantes.
```
psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
Se você não tiver uma tabela, crie uma tabela de exemplo da forma a seguir.
1. Crie uma tabela de exemplo usando a declaração SQL a seguir.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Preencha a tabela com dados gerados usando a instrução SQL a seguir.
```
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
```
1. Verifique se os dados existem na tabela usando a declaração SQL a seguir.
```
SELECT count(*) FROM docs_lab_table;
```
1. Identifique essa instância de banco de dados do RDS para PostgreSQL como o nó do editor da forma a seguir.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_provider',
dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb');
create_node
-------------
3410995529
(1 row)
```
1. Adicione a tabela que você deseja replicar ao conjunto de replicação padrão. Para obter mais informações sobre conjuntos de replicação, consulte [Replication sets](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets) (Conjuntos de replicação) na documentação da pglogical.
```
SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL);
replication_set_add_table
---------------------------
t
(1 row)
```
A configuração do nó do editor está concluída. Agora você pode configurar o nó de assinante para receber as atualizações do editor.
**Como configurar o nó de assinante e criar uma assinatura para receber atualizações**
Estas etapas pressupõem que instância de banco de dados do RDS para PostgreSQL tenha sido configurada com a extensão `pglogical`. Para obter mais informações, consulte [Configurar a extensão pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
1. Use `psql` para se conectar à instância em que você deseja receber atualizações do editor.
```
psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Na instância de banco de dados RDS para PostgreSQL do assinante, crie a mesma tabela que existe no editor. Neste exemplo, a tabela é `docs_lab_table`. Você pode criar a tabela da seguinte maneira.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Verifique se essa tabela está vazia.
```
SELECT count(*) FROM docs_lab_table;
count
-------
0
(1 row)
```
1. Identifique essa instância de banco de dados RDS para PostgreSQL como o nó do assinante da forma a seguir.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_target',
dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********');
create_node
-------------
2182738256
(1 row)
```
1. Crie a assinatura.
```
SELECT pglogical.create_subscription(
subscription_name := 'docs_lab_subscription',
provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******',
replication_sets := ARRAY['default'],
synchronize_data := true,
forward_origins := '{}' );
create_subscription
---------------------
1038357190
(1 row)
```
Ao concluir essa etapa, os dados da tabela no editor são criados na tabela no assinante. Se você quiser verificar se isso ocorreu, verifique a consulta SQL a seguir.
```
SELECT count(*) FROM docs_lab_table;
count
-------
5000
(1 row)
```
Desse ponto em diante, as alterações feitas na tabela do editor são replicadas na tabela do assinante.
# Restabelecer a replicação lógica após uma atualização principal
Antes de realizar uma atualização de versão principal de uma instância de banco de dados do RDS para PostgreSQL que está sendo configurada como um nó de editor para replicação lógica, você deve eliminar todos os slots de replicação, mesmo aqueles que não estão ativos. Recomendamos que você desvie temporariamente as transações do banco de dados do nó do editor, elimine os slots de replicação, atualize a instância de banco de dados do RDS para PostgreSQL e, depois, restabeleça e reinicie a replicação.
Os slots de replicação são hospedados somente no nó do editor. O nó de assinante do RDS para PostgreSQL em um cenário de replicação lógica não tem slots a serem descartados, mas não pode ser atualizado para uma versão principal enquanto estiver designado como um nó de assinante com uma assinatura do editor. Antes de atualizar o nó de assinante do RDS para PostgreSQL, elimine a assinatura e o nó. Para obter mais informações, consulte [Gerenciar slots de replicação lógica para o RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
## Determinar se a replicação lógica foi interrompida
Você pode determinar se o processo de replicação foi interrompido consultando o nó do editor ou o nó do assinante da forma a seguir.
**Como conferir o nó do editor**
+ Use `psql` para se conectar ao nó do editor e, depois, consultar a função `pg_replication_slots`. Observe o valor na coluna ativa. Normalmente, isso retornará `t` (true) mostrando que a replicação está ativa. Se a consulta retornar `f` (false), é uma indicação de que a replicação para o assinante foi interrompida.
```
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f
(1 row)
```
**Como conferir o nó do assinante**
No nó do assinante, você pode conferir o status da replicação de três maneiras diferentes.
+ Examine os logs do PostgreSQL no nó do assinante para encontrar mensagens de falha. O log identifica falhas com mensagens que incluem o código de saída 1, conforme mostrado a seguir.
```
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1
2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
```
+ Consulte a função `pg_replication_origin`. Conecte-se ao banco de dados no nó do assinante usando `psql` e consulte a função `pg_replication_origin` da forma a seguir.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
```
O conjunto de resultados vazio significa que a replicação foi interrompida. Normalmente, você deve ver a saída da forma a seguir.
```
roident | roname
---------+----------------------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
+ Consulte a função `pglogical.show_subscription_status` conforme exibido no exemplo a seguir.
```
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
---====----------------+--------+-------------------------------------
docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
Essa saída mostra que a replicação foi interrompida. Seu status é `down`. Normalmente, a saída mostra o status como `replicating`.
Se seu processo de replicação lógica tiver sido interrompido, você poderá restabelecer a replicação seguindo estas etapas.
**Como restabelecer a replicação lógica entre os nós do editor e do assinante**
Para restabelecer a replicação, primeiro você desconecta o assinante do nó do editor e depois restabelece a assinatura, conforme descrito nestas etapas.
1. Conecte-se ao nó do assinante usando `psql` da forma a seguir.
```
psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Desative a assinatura usando a função `pglogical.alter_subscription_disable`.
```
SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable
----------------------------
t
(1 row)
```
1. Obtenha o identificador do nó do editor consultando a `pg_replication_origin` da forma a seguir.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+-------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
1. Use a resposta da etapa anterior com o comando `pg_replication_origin_create` para atribuir o identificador que pode ser usado pela assinatura quando restabelecida.
```
SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create
------------------------------
1
(1 row)
```
1. Ative a assinatura passando seu nome com um status de `true`, conforme exibido no exemplo a seguir.
```
SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable
---------------------------
t
(1 row)
```
Consulte o status do nó. Seu status deve ser `replicating` conforme mostrado neste exemplo.
```
SELECT subscription_name,status,slot_name
FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
-------------------------------+-------------+-------------------------------------
docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)
```
Confira o status do slot de replicação do assinante no nó do editor. A coluna `active` do slot deve retornar `t` (true), indicando que a replicação foi restabelecida.
```
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t
(1 row)
```
# Gerenciar slots de replicação lógica para o RDS for PostgreSQL
Antes de realizar uma atualização de versão principal de uma uma instância de banco de dados do RDS para PostgreSQL que está atuando como um nó de editor em um cenário de replicação lógica, você deve eliminar os slots de replicação na instância. O processo de pré-conferência da atualização da versão principal notifica você de que a atualização não pode continuar até que os slots sejam eliminados.
Para eliminar slots da sua instância de banco de dados do RDS para PostgreSQL, primeiro cancele a assinatura e depois o slot.
Para identificar os slots de replicação que foram criados usando a extensão `pglogical`, faça login em cada banco de dados e obtenha o nome dos nós. Ao consultar o nó do assinante, você obtém os nós do editor e do assinante na saída, conforme mostrado neste exemplo.
```
SELECT * FROM pglogical.node;
node_id | node_name
------------+-------------------
2182738256 | docs_lab_target
3410995529 | docs_lab_provider
(2 rows)
```
Você pode obter os detalhes sobre a assinatura com a consulta a seguir.
```
SELECT sub_name,sub_slot_name,sub_target
FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target
----------+--------------------------------+------------
docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)
```
Agora você pode cancelar a assinatura da forma a seguir.
```
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription
-------------------
1
(1 row)
```
Depois de cancelar a assinatura, você pode excluir o nó.
```
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node
-----------
t
(1 row)
```
Você pode verificar se o nó não existe mais da forma a seguir.
```
SELECT * FROM pglogical.node;
node_id | node_name
---------+-----------
(0 rows)
```
# Referência de parâmetros da extensão pglogical
Na tabela, você pode encontrar parâmetros associados à extensão `pglogical`. Parâmetros como `pglogical.conflict_log_level` e `pglogical.conflict_resolution` são usados para lidar com conflitos de atualização. Podem surgir conflitos quando alterações são feitas localmente nas mesmas tabelas que estão inscritas para receber alterações do editor. Os conflitos também podem ocorrer durante vários cenários, como replicação bidirecional ou quando vários assinantes estão se replicando do mesmo editor. Para obter mais informações, consulte [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Replicação bidirecional do PostgreSQL usando pglogical).
| Parameter | Descrição |
| --- | --- |
| pglogical.batch\$1inserts | Inserções em lote, se possível. Não definido por padrão. Mude para “1” para ativar, “0” para desativar. |
| pglogical.conflict\$1log\$1level | Define o nível de log a ser usado para registrar em log conflitos resolvidos. Os valores de string compatíveis são debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. |
| pglogical.conflict\$1resolution | Define o método a ser usado para resolver conflitos quando eles podem ser resolvidos. Os valores de string compatíveis são error, apply\$1remote, keep\$1local, last\$1update\$1wins, first\$1update\$1wins. |
| pglogical.extra\$1connection\$1options | Opções de conexão para adicionar a todas as conexões de nó de pares. |
| pglogical.synchronous\$1commit | Valor de confirmação síncrona específica do pglogical |
| pglogical.use\$1spi | Use a SPI (interface de programação de servidores) em vez da API de baixo nível para aplicar alterações. Defina como “1” para ativar, “0” para desativar. Para obter mais informações sobre a SPI, consulte [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html) (Interface de programação de servidores) na documentação do PostgreSQL. |
# Usar pgactive para comportar a replicação ativa-ativa
A extensão `pgactive` usa replicação ativa-ativa para comportar e coordenar operações de gravação em vários bancos de dados do RDS para PostgreSQL. O Amazon RDS para PostgreSQL é compatível com a extensão `pgactive` nas seguintes versões:
+ RDS para PostgreSQL 17.0 e todas as versões posteriores
+ RDS para PostgreSQL 16.1 e versões 16 posteriores
+ RDS para PostgreSQL 15.4-R2 e versões 15 posteriores
+ RDS para PostgreSQL 14.10 e versões 14 posteriores
+ RDS para PostgreSQL 13.13 e versões 13 posteriores
+ RDS para PostgreSQL 12.17 e versões 12 posteriores
+ RDS para PostgreSQL 11.22
**nota**
Quando há operações de gravação em mais de um banco de dados em uma configuração de replicação, existe a possibilidade de conflitos. Para obter mais informações, consulte . [Lidar com conflitos na replicação ativa-ativa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
**Topics**
+ [
## Limitações da extensão pgactive
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.requirements-limitations)
+ [
# Inicializar o recurso de extensão pgactive
](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)
+ [
# Configurar a replicação ativa-ativa para as instâncias de banco de dados do RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pgactive.setup-replication.md)
+ [
# Medir o atraso de replicação entre membros pgactive
](Appendix.PostgreSQL.CommonDBATasks.pgactive.replicationlag.md)
+ [
# Configurar as definições de parâmetro para a extensão pgactive
](Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.md)
+ [
# Noções básicas sobre conflitos ativos-ativos
](Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.replication.md)
+ [
# Noções básicas sobre o esquema da pgactive
](Appendix.PostgreSQL.CommonDBATasks.pgactive.schema.md)
+ [
# Referência de funções da pgactive
](pgactive-functions-reference.md)
+ [
# Lidar com conflitos na replicação ativa-ativa
](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
+ [
# Lidar com sequências na replicação ativa-ativa
](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)
## Limitações da extensão pgactive
+ Todas as tabelas exigem uma chave primária; do contrário, atualizações e exclusões não são permitidas. Os valores na coluna Chave primária não devem ser atualizados.
+ As sequências podem ter lacunas e, às vezes, podem não seguir uma ordem. As sequências não são replicadas. Para obter mais informações, consulte [Lidar com sequências na replicação ativa-ativa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md).
+ O DDL e os objetos grandes não são replicados.
+ Índices secundários exclusivos podem causar divergência de dados.
+ O agrupamento precisa ser idêntico em todos os nós do grupo.
+ O balanceamento de carga entre os nós é um antipadrão.
+ Transações grandes podem causar atraso na replicação.
# Inicializar o recurso de extensão pgactive
Para inicializar o recurso de extensão `pgactive` na instância de banco de dados do RDS para PostgreSQL, defina o valor do parâmetro `rds.enable_pgactive` como `1` e, em seguida, crie a extensão no banco de dados. Isso ativa automaticamente os parâmetros `rds.logical_replication` e `track_commit_timestamp` e define o valor de `wal_level` como `logical`.
Você deve ter permissões como a função `rds_superuser` para realizar essas tarefas.
Você pode usar o Console de gerenciamento da AWS ou a AWS CLI para criar as instâncias necessárias do banco de dados RDS para PostgreSQL. As etapas a seguir pressupõem que a instância de banco de dados do RDS para PostgreSQL esteja associada a um grupo de parâmetros de banco de dados personalizado. Para obter mais informações sobre como criar um grupo de parâmetros de banco de dados personalizado, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
## Console
**Como inicializar o recurso de extensão pgactive**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha a instância de banco de dados do RDS para PostgreSQL.
1. Abra a guia **Configuração** para a instância de banco de dados do RDS para PostgreSQL. Nos detalhes da instância, encontre o link do **Grupo de parâmetros da instância de banco de dados**.
1. Clique no link para abrir os parâmetros personalizados associados à instância de banco de dados do RDS para PostgreSQL.
1. Encontre o parâmetro `rds.enable_pgactive` e configure-o como `1` para inicializar o recurso `pgactive`.
1. Escolha **Salvar alterações**.
1. No painel de navegação do console do Amazon RDS, escolha **Bancos de dados**.
1. Selecione a instância de banco de dados do RDS para PostgreSQL e escolha **Reinicializar** no menu **Ações**.
1. Confirme a reinicialização da instância de banco de dados para que as alterações tenham efeito.
1. Quando a instância de banco de dados estiver disponível, use `psql` ou qualquer outro cliente PostgreAQL para se conectar à instância de banco de dados do RDS para PostgreSQL.
O exemplo a seguir pressupõe que a instância de banco de dados do RDS para PostgreSQL tenha um banco de dados padrão chamado *postgres*.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Para verificar se pgactive foi inicializada, execute o comando a seguir.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Se `pgactive` estiver em `shared_preload_libraries`, o comando anterior retornará o seguinte:
```
?column?
----------
t
```
## AWS CLI
**Como inicializar o recurso de extensão pgactive**
Para inicializar `pgactive` usando a AWS CLI, execute a operação [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para modificar determinados parâmetros no grupo parâmetros personalizado, conforme mostrado no procedimento a seguir.
1. Use o comando AWS CLI a seguir para definir `rds.enable_pgactive` como `1` para inicializar o recurso `pgactive` da instância de banco de dados do RDS para PostgreSQL.
```
postgres=>aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.enable_pgactive,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use o comando AWS CLI a seguir para reinicializar a instância de banco de dados do RDS para PostgreSQL e inicializar a biblioteca da `pgactive`.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Quando a instância estiver disponível, use `psql` para se conectar à instância de banco de dados RDS para PostgreSQL.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master user --password=PASSWORD --dbname=postgres
```
1. Para verificar se pgactive foi inicializada, execute o comando a seguir.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Se `pgactive` estiver em `shared_preload_libraries`, o comando anterior retornará o seguinte:
```
?column?
----------
t
```
# Configurar a replicação ativa-ativa para as instâncias de banco de dados do RDS para PostgreSQL
O procedimento a seguir mostra como iniciar a replicação ativa-ativa entre dois clusters de banco de dados do duas instâncias de banco de dados do RDS para PostgreSQL em que `pgactive` está disponível. Para executar o exemplo de alta disponibilidade multirregional, você precisa implantar instâncias do Amazon RDS para PostgreSQL em duas regiões diferentes e configurar o emparelhamento de VPC. Para obter mais informações, consulte [Emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
**nota**
O envio de tráfego entre várias regiões pode gerar custos adicionais.
Estas etapas pressupõem que a instância de banco de dados do RDS para PostgreSQL foi habilitada com a extensão `pgactive`. Para obter mais informações, consulte [Inicializar o recurso de extensão pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
**Como configurar a primeira instância de banco de dados do RDS para PostgreSQL com a extensão `pgactive`**
O exemplo a seguir ilustra como o grupo `pgactive` é criado e mostra outras etapas necessárias para criar a extensão `pgactive` na instância de banco de dados do RDS para PostgreSQL.
1. Use `psql` ou outra ferramenta cliente para se conectar à primeira instância de banco de dados do RDS para PostgreSQL.
```
psql --host=firstinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Crie um banco de dados na instância do RDS para PostgreSQL usando o seguinte comando:
```
postgres=> CREATE DATABASE app;
```
1. Alterne a conexão para o novo banco de dados usando o seguinte comando:
```
\c app
```
1. Crie e preencha uma tabela de exemplo usando a seguinte instrução SQL:
1. Crie uma tabela de exemplo usando a declaração SQL a seguir.
```
app=> CREATE SCHEMA inventory;
CREATE TABLE inventory.products (
id int PRIMARY KEY, product_name text NOT NULL,
created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP);
```
1. Preencha a tabela com alguns dados de amostra usando a instrução SQL a seguir.
```
app=> INSERT INTO inventory.products (id, product_name)
VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
```
1. Verifique se os dados existem na tabela usando a declaração SQL a seguir.
```
app=>SELECT count(*) FROM inventory.products;
count
-------
3
```
1. Crie uma extensão `pgactive` no banco de dados existente.
```
app=> CREATE EXTENSION pgactive;
```
1. Para criar e inicializar com segurança o grupo da pgactive, use os seguintes comandos:
```
app=>
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
Agora você pode inicializar o grupo de replicações e adicionar esta primeira instância:
```
SELECT pgactive.pgactive_create_group(
node_name := 'endpoint1-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Use os seguintes comandos como um método alternativo, mas menos seguro, para criar e inicializar o grupo da pgactive:
```
app=> SELECT pgactive.pgactive_create_group(
node_name := 'node1-app',
node_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node1-app é o nome atribuído para identificar de maneira exclusiva um nó no grupo `pgactive`.
**nota**
Para realizar essa etapa com êxito em uma instância de banco de dados acessível ao público geral, você deve ativar o parâmetro `rds.custom_dns_resolution` definindo-o como `1`.
1. Para verificar se a instância de banco de dados está pronta, use o seguinte comando:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Se o comando for bem-sucedido, você verá o seguinte resultado:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
**Como configurar a segunda instância do RDS para PostgreSQL e juntá-la ao grupo `pgactive`**
O exemplo a seguir mostra como juntar uma instância de banco de dados do RDS para PostgreSQL ao grupo `pgactive`, bem como outras etapas necessárias para criar a extensão `pgactive` na instância de banco de dados.
Estas etapas pressupõem que as instâncias de banco de dados do RDS para PostgreSQL tenham sido configuradas com a extensão `pgactive`. Para obter mais informações, consulte [Inicializar o recurso de extensão pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
1. Use `psql` para se conectar à instância em que você deseja receber atualizações do editor.
```
psql --host=secondinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Crie um banco de dados na segunda instância de banco de dados do RDS para PostgreSQL usando o seguinte comando:
```
postgres=> CREATE DATABASE app;
```
1. Alterne a conexão para o novo banco de dados usando o seguinte comando:
```
\c app
```
1. Crie a extensão `pgactive` no banco de dados existente.
```
app=> CREATE EXTENSION pgactive;
```
1. Junte a segunda instância de banco de dados do RDS para PostgreSQL ao grupo do `pgactive` de uma forma mais segura usando os seguintes comandos:
```
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
```
SELECT pgactive.pgactive_join_group(
node_name := 'endpoint2-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint2',
join_using_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Use os comandos a seguir como um método alternativo, mas menos seguro, para juntar a segunda instância de banco de dados do RDS for PostgreSQL ao grupo da `pgactive`:
```
app=> SELECT pgactive.pgactive_join_group(
node_name := 'node2-app',
node_dsn := 'dbname=app host=secondinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD',
join_using_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node2-app é o nome atribuído para identificar de maneira exclusiva um nó no grupo `pgactive`.
1. Para verificar se a instância de banco de dados está pronta, use o seguinte comando:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Se o comando for bem-sucedido, você verá o seguinte resultado:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Se o primeiro banco de dados RDS para PostgreSQL for relativamente grande, você poderá ver `pgactive.pgactive_wait_for_node_ready()` emitindo o relatório de progresso da operação de restauração. A saída será semelhante à seguinte:
```
NOTICE: restoring database 'app', 6% of 7483 MB complete
NOTICE: restoring database 'app', 42% of 7483 MB complete
NOTICE: restoring database 'app', 77% of 7483 MB complete
NOTICE: restoring database 'app', 98% of 7483 MB complete
NOTICE: successfully restored database 'app' from node node1-app in 00:04:12.274956
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Deste ponto em diante, `pgactive` sincroniza os dados entre as duas instâncias de banco de dados.
1. Você pode usar o comando a seguir para verificar se o banco de dados da segunda instância de banco de dados tem os dados:
```
app=> SELECT count(*) FROM inventory.products;
```
Se os dados forem sincronizados com sucesso, você verá a seguinte saída:
```
count
-------
3
```
1. Execute o seguinte comando para inserir novos valores:
```
app=> INSERT INTO inventory.products (id, product_name) VALUES (4, 'lotion');
```
1. Conecte-se ao banco de dados da primeira instância de banco de dados e execute a seguinte consulta:
```
app=> SELECT count(*) FROM inventory.products;
```
Se a replicação ativa-ativa for inicializada, a saída será semelhante à seguinte:
```
count
-------
4
```
**Como desanexar e remover uma instância de banco de dados do grupo `pgactive`**
É possível desanexar e remover uma instância de banco de dados do grupo `pgactive` usando estas etapas:
1. Você pode separar a segunda instância de banco de dados da primeira instância de banco de dados usando o seguinte comando:
```
app=> SELECT * FROM pgactive.pgactive_detach_nodes(ARRAY[‘node2-app']);
```
1. Remova a extensão `pgactive` da segunda instância de banco de dados usando o seguinte comando:
```
app=> SELECT * FROM pgactive.pgactive_remove();
```
Para remover a extensão forçosamente:
```
app=> SELECT * FROM pgactive.pgactive_remove(true);
```
1. Descarte a extensão usando o seguinte comando:
```
app=> DROP EXTENSION pgactive;
```
# Medir o atraso de replicação entre membros pgactive
Você pode usar a consulta a seguir para visualizar o atraso de replicação entre os membros de `pgactive`. Execute essa consulta em cada nó de `pgactive` para ter a imagem completa.
```
app=> SELECT * FROM pgactive.pgactive_get_replication_lag_info();
│-[ RECORD 1 ]--------+---------------------------------------------
│node_name | node2-app
│node_sysid | 7481018224801653637
│application_name | pgactive:7481018224801653637:send
│slot_name | pgactive_16385_7481018224801653637_0_16385__
│active | t
│active_pid | 783486
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/2108150
│confirmed_flush_lsn | 0/2154690
│sent_lsn | 0/2154690
│write_lsn | 0/2154690
│flush_lsn | 0/2154690
│replay_lsn | 0/2154690
│-[ RECORD 2 ]--------+---------------------------------------------
│node_name | node1-app
│node_sysid | 7481018033434600853
│application_name | pgactive:7481018033434600853:send
│slot_name | pgactive_16385_7481018033434600853_0_16385__
│active | t
│active_pid | 783488
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/20F5AD0
│confirmed_flush_lsn | 0/214EF68
│sent_lsn | 0/214EF68
│write_lsn | 0/214EF68
│flush_lsn | 0/214EF68
│replay_lsn | 0/214EF68
```
Monitore, no mínimo, os seguintes diagnósticos:
active
Configure alertas quando active for false, o que indica que o slot não está em uso no momento (a instância do assinante foi desconectada do publicador).
pending\$1wal\$1decoding
Na replicação lógica do PostgreSQL, os arquivos WAL são armazenados em formato binário. O publicador deve decodificar essas alterações do WAL e convertê-las em alterações lógicas (como operações de inserção, atualização ou exclusão).
A métrica pending\$1wal\$1decoding mostra o número de arquivos WAL aguardando decodificação do lado do publicador.
Esse número pode aumentar devido a estes fatores:
+ Quando o assinante não estiver conectado, o status active será false e pending\$1wal\$1decoding aumentará.
+ O slot está ativo, mas o publicador não consegue acompanhar o volume de alterações do WAL.
pending\$1wal\$1to\$1apply
A métrica pending\$1wal\$1apply indica o número de arquivos WAL que ainda precisam ser aplicados do lado do assinante.
Vários fatores podem impedir que o assinante aplique alterações e possivelmente provocar um cenário de disco cheio:
+ Diferenças de esquema: por exemplo, quando você tem alterações no fluxo do WAL para uma tabela chamada sample e essa tabela não existe do lado do assinante.
+ Valores nas colunas da chave primária foram atualizados.
+ Índices secundários exclusivos podem causar divergência de dados.
# Configurar as definições de parâmetro para a extensão pgactive
É possível usar a consulta a seguir para visualizar todos os parâmetros associados à extensão `pgactive`.
```
app=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';
```
Você pode configurar a extensão `pgactive` usando vários parâmetros. Esses parâmetros podem ser definidos por meio do Console de gerenciamento da AWS ou da interface da CLI AWS.
## Principais parâmetros da extensão pgactive
A seguinte tabela apresenta uma referência para os principais parâmetros da extensão `pgactive`:
| Parâmetro | Unidade | Padrão | Descrição |
| --- | --- | --- | --- |
| pgactive.conflict\$1logging\$1include\$1tuples | `boolean` | – | Registra em log informações completas da tupla para a extensão `pgactive`. É necessário reinicializar o servidor para que as alterações entrem em vigor. |
| pgactive.log\$1conflicts\$1to\$1table | `boolean` | – | Determina se a extensão `pgactive` registra em log os conflitos detectados na tabela `pgactive.pgactive_conflict_history`. Para ter mais informações e detalhes, consulte “Registro em log de conflitos”. É necessário reinicializar o servidor para que as alterações entrem em vigor. |
| pgactive.log\$1conflicts\$1to\$1logfile | `boolean` | – | Determina se a extensão `pgactive` registra em log os conflitos detectados no arquivo de log do PostgreSQL. Para ter mais informações e detalhes, consulte “Registro em log de conflitos”. É necessário reinicializar o servidor para que as alterações entrem em vigor. |
| pgactive.synchronous\$1commit | `boolean` | desligar | Determina o comportamento de confirmação dos operadores apply da pgactive. Quando desabilitados (off), os operadores apply executam confirmações assíncronas, o que melhora o throughput do PostgreSQL durante as operações apply, mas atrasa as confirmações de reprodução para o precedente. Configurá-los como `off` é sempre seguro e não causará perda ou omissão de transações. Essa configuração afeta apenas o tempo de liberação do disco no nó subsequente e quando as confirmações são enviadas ao precedente. O sistema atrasa o envio das confirmações de liberação de reprodução até que as confirmações sejam liberadas para o disco por meio de operações não relacionadas, como pontos de verificação ou trabalho periódico. No entanto, se o precedente tiver o subsequente listado em `synchronous_standby_names`, configurá-lo como `off` fará com que as confirmações síncronas no precedente demorem mais para relatar êxito ao cliente. Nesse caso, configure o parâmetro como `on`. Mesmo quando esse parâmetro é definido como `on` com os nós listados em `synchronous_standby_names`, conflitos de replicação ainda podem ocorrer em configurações ativas-ativas. Isso ocorre porque o sistema não tem bloqueio entre nós e gerenciamento global de snapshots, permitindo que transações simultâneas em nós diferentes modifiquem a mesma tupla. Além disso, as transações só iniciam a replicação depois de serem confirmadas no nó precedente. Habilitar a confirmação síncrona não transforma a extensão pgactive em um sistema sempre consistente. |
| pgactive.temp\$1dump\$1directory | `string` | – | Define o caminho de armazenamento temporário necessário para as operações de clonagem do banco de dados durante a configuração inicial. Esse diretório deve ser gravável pelo usuário do Postgres e ter espaço de armazenamento suficiente para conter um despejo completo do banco de dados. O sistema usa esse local somente durante a configuração inicial do banco de dados com operações de cópia lógica. Esse parâmetro não é usado pelo `pgactive_init_copy command`. |
| pgactive.max\$1ddl\$1lock\$1delay | `milliseconds` | `-1` | Especifica o tempo máximo de espera para o bloqueio de DDL antes de interromper à força as transações de gravação simultâneas. O valor padrão é `-1`, que adota o valor definido em `max_standby_streaming_delay`. Esse parâmetro aceita unidades de tempo. Por exemplo, você pode configurá-lo como 10s (10 segundos). Durante esse período de espera, o sistema tenta adquirir bloqueios de DDL enquanto aguarda a confirmação ou reversão das transações de gravação em andamento. Para ter mais informações, consulte “DDL Locking”. |
| pgactive.ddl\$1lock\$1timeout | `milliseconds` | `-1` | Especifica por quanto tempo uma tentativa de bloqueio de DDL espera para obter o bloqueio. O valor padrão é `-1`, que usa o valor especificado em lock\$1timeout. Você pode definir esse parâmetro usando unidades de tempo, como 10s (10 segundos). Esse temporizador controla apenas o período de espera para obter um bloqueio de DDL. Quando o sistema obtém o bloqueio e inicia a operação de DDL, o temporizador para. Esse parâmetro não limita a duração total em que um bloqueio de DDL pode ser mantido ou o tempo geral de operação de DDL. Para controlar a duração total da operação, use `statement_timeout` em vez disso. Para ter mais informações, consulte “DDL Locking”. |
| pgactive.debug\$1trace\$1ddl\$1locks\$1level | `boolean` | – | Substitui o nível de log de depuração padrão para operações de bloqueio de DDL na extensão `pgactive`. Quando configurada, essa definição faz com que mensagens relacionadas ao bloqueio de DDL sejam emitidas no nível de depuração de LOG em vez de no nível padrão. Use esse parâmetro para monitorar a atividade de bloqueio de DDL sem habilitar os níveis detalhados de log `DEBUG1` ou `DEBUG2` em todo o servidor. Níveis de log, em ordem crescente de detalhamento: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Para ter mais informações sobre as opções de monitoramento, consulte “Monitoring global DDL locks”. As alterações nessa configuração entram em vigor quando você a recarrega. Não é necessário reiniciar o servidor. |
## Parâmetros adicionais da extensão pgactive
A tabela a seguir apresenta as opções de configuração internas e menos frequentemente usadas disponíveis para a extensão `pgactive`.
| Parâmetro | Unidade | Padrão | Descrição |
| --- | --- | --- | --- |
| pgactive.debug\$1apply\$1delay | `integer` | – | Define um atraso de apply (em milissegundos) para conexões configuradas que não têm um atraso de apply explícito na respectiva entrada `pgactive.pgactive_connections`. Esse atraso é definido durante a criação do nó ou o tempo de junção, e a pgactive não reproduzirá uma transação em nós pares enquanto pelo menos o número especificado de milissegundos não tiver decorrido desde que ela foi confirmada. Usado principalmente para simular redes de alta latência em ambientes de teste para facilitar a criação de conflitos. Por exemplo, com um atraso de 500 ms nos nós A e B, você terá pelo menos 500 ms para realizar uma inserção conflitante no nó B depois de inserir um valor no nó A. Requer o recarregamento do servidor ou a reinicialização dos operadores apply para entrar em vigor. |
| pgactive.connectability\$1check\$1duration | `integer` | – | Especifica a duração (em segundos) em que um operador de banco de dados tenta estabelecer conexões durante tentativas malsucedidas. O operador faz 1 tentativa de conexão por segundo até ter êxito ou atingir esse valor de tempo limite. Essa configuração é útil quando o mecanismo de banco de dados é iniciado antes de o operador estar pronto para estabelecer conexões. |
| pgactive.skip\$1ddl\$1replication | `boolean` | `on` | Controla como as alterações de DDL são replicadas ou tratadas no Amazon RDS com `pgactive` habilitada. Quando definido como `on`, o nó processa as alterações de DDL como um nó não pgactive. Os seguintes requisitos se aplicam ao trabalhar com esse parâmetro: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Você pode modificar esse parâmetro de duas maneiras com privilégios de superusuário: globalmente e localmente (nível de sessão). A alteração incorreta desse parâmetro pode desfazer suas configurações de replicação. |
| pgactive.do\$1not\$1replicate | `boolean` | – | Esse parâmetro é somente para uso interno. Ao definir esse parâmetro em uma transação, as alterações não são replicadas para outros nós no cluster de banco de dados. A alteração incorreta desse parâmetro pode desfazer suas configurações de replicação. |
| pgactive.discard\$1mismatched\$1row\$1attributes | `boolean` | – | Esse parâmetro destina-se somente a especialistas. Recomendamos usá-lo somente ao solucionar problemas específicos de replicação. Use esse parâmetro quando: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Essa configuração substitui a seguinte mensagem de erro e permite que surjam divergências de dados para que a replicação continue: .: `cannot right-pad mismatched attributes; attno %u is missing in local table and remote row has non-null, non-dropped value for this attribute` A alteração incorreta desse parâmetro pode desfazer suas configurações de replicação. |
| pgactive.debug\$1trace\$1replay | `boolean` | – | Quando definido como `on`, ele emite uma mensagem de log para cada ação remota que os operadores apply subsequentes processam. Os logs incluem: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Os logs também capturam comandos de DDL enfileirados e exclusões de tabela.para> Por padrão, os logs não incluem o conteúdo de campos de linha. Para incluir valores de linha nos logs, você deve recompilar com os seguintes sinalizadores habilitados: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) A habilitação dessa configuração de registro em log pode afetar o desempenho. Recomendamos habilitá-la somente quando necessário para solucionar problemas. As alterações nessa configuração entram em vigor quando você a recarrega. Não é necessário reiniciar o servidor. |
| pgactive.extra\$1apply\$1connection\$1options | | – | Você pode configurar os parâmetros de conexão para todas as conexões de nós pares com nós da pgactive. Esses parâmetros controlam configurações, como keepalives e modos SSL. Por padrão, a pgactive usa os seguintes parâmetros de conexão: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Para substituir os parâmetros padrão, use o comando semelhante abaixo: pgactive.extra\$1apply\$1connection\$1options = 'keepalives=0' As strings de conexão de nós individuais têm precedência sobre essas configurações e sobre as opções de conexão integradas da pgactive. Para ter mais informações sobre formatos de string de conexão, consulte as [strings de conexão libpq](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING). Recomendamos manter as configurações padrão de keepalive habilitadas. Só desabilite os keepalives se você tiver problemas para concluir grandes transações em redes não confiáveis. Recomendamos manter as configurações padrão de keepalive habilitadas. Só desabilite os keepalives se você tiver problemas para concluir grandes transações em redes não confiáveis. As alterações nessa configuração entram em vigor quando você a recarrega. Não é necessário reiniciar o servidor. |
| pgactive.init\$1node\$1parallel\$1jobs (int) | | – | Especifica o número de trabalhos paralelos que `pg_dump` e `pg_restore` podem usar durante junções de nós lógicos com a função `pgactive.pgactive_join_group`. As alterações nessa configuração entram em vigor quando você a recarrega. Não é necessário reiniciar o servidor. |
| pgactive.max\$1nodes | `int` | 4 | Especifica o número máximo de nós permitidos em um grupo da extensão pgactive. O valor padrão é quatro nós. Você deve considerar o seguinte ao definir o valor desse parâmetro: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Você pode definir esse parâmetro de duas maneiras: no arquivo de configuração e usando o comando `ALTER SYSTEM SET`. O valor padrão para esse parâmetro é `4`; ou seja, pode haver no máximo quatro nós permitidos no grupo da extensão `pgactive` em qualquer momento específico. A alteração entra em vigor após a reinicialização do servidor. |
| pgactive.permit\$1node\$1identifier\$1getter\$1function\$1creation | `boolean` | – | Esse parâmetro destina-se somente para uso interno. Quando habilitada, a extensão `pgactive` permite a criação da função getter do identificador de nó da pgactive. |
# Noções básicas sobre conflitos ativos-ativos
Quando você usa pgactive no modo ativo-ativo, gravar nas mesmas tabelas por meio de vários nós pode criar conflitos de dados. Embora alguns sistemas de clustering usem bloqueios distribuídos para impedir o acesso simultâneo, a pgactive adota uma abordagem otimista que é mais adequada para aplicações distribuídas geograficamente.
Alguns sistemas de clustering de banco de dados impedem o acesso simultâneo aos dados por meio de bloqueios distribuídos. Embora essa abordagem funcione quando os servidores estão próximos, não é possível usá-la para aplicações distribuídas geograficamente porque, para oferecer um bom desempenho, é necessária uma latência extremamente baixa. Em vez de usar bloqueios distribuídos (uma abordagem pessimista), a extensão pgactive usa uma abordagem otimista. Isso significa que ela:
+ Ajuda a evitar conflitos quando possível.
+ Possibilita que determinados tipos de conflito ocorram.
+ Oferece resolução quando ocorrem conflitos.
Essa abordagem oferece maior flexibilidade ao criar aplicações distribuídas.
## Como os conflitos acontecem
Os conflitos entre nós surgem de sequências de eventos que não poderiam acontecer se todas as transações envolvidas ocorressem simultaneamente no mesmo nó. Como os nós só trocam alterações após a confirmação das transações, cada transação é válida individualmente no nó em que foi confirmada, mas não seria válida se executada em outro nó que tivesse feito outro trabalho nesse meio tempo. Como o apply da pgactive basicamente reproduz a transação nos outros nós, a operação de repetição pode falhar se houver um conflito entre uma transação que está sendo aplicada e uma transação que foi confirmada no nó receptor.
O motivo pelo qual a maioria dos conflitos não pode acontecer quando todas as transações são executadas em um único nó é que o PostgreSQL tem mecanismos de comunicação entre transações para evitá-los, como:
+ Índices UNIQUE
+ SEQUENCEs
+ Bloqueio de linha e relação
+ Rastreamento de dependências SERIALIZÁVEL
Todos esses mecanismos são formas de comunicação entre transações para evitar problemas indesejáveis de simultaneidade.
A pgactive alcança baixa latência e lida bem com partições de rede porque não usa um gerenciador de transações distribuídas ou gerenciador de bloqueios. Mas isso significa que as transações em nós diferentes são executadas de maneira totalmente isolada umas das outras. Embora o isolamento normalmente melhore a consistência do banco de dados, nesse caso, você precisa reduzir o isolamento para evitar conflitos.
## Tipos de conflito
Os conflitos que podem ocorrer incluem:
**Topics**
+ [
### Conflitos de PRIMARY KEY ou UNIQUE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict1)
+ [
### Conflitos INSERT/INSERT
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict2)
+ [
### INSERTs que violam várias restrições UNIQUE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict3)
+ [
### Conflitos UPDATE/UPDATE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict4)
+ [
### Conflitos UPDATE na CHAVE PRIMÁRIA
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)
+ [
### UPDATEs que violam várias restrições UNIQUE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict6)
+ [
### Conflitos UPDATE/DELETE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)
+ [
### Conflitos INSERT/UPDATE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict8)
+ [
### Conflitos DELETE/DELETE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict9)
+ [
### Conflitos de restrição de chave estrangeira
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict10)
+ [
### Conflitos de restrição de exclusão
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict11)
+ [
### Conflitos de dados globais
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict12)
+ [
### Conflitos de bloqueio e interrupções decorrentes de deadlock
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict13)
+ [
### Conflitos divergentes
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)
### Conflitos de PRIMARY KEY ou UNIQUE
Os conflitos de linha ocorrem quando várias operações tentam modificar a mesma chave de linha de uma maneira não possíveis em um único nó. Esses conflitos representam o tipo mais comum de conflito de dados.
A pgactive resolve conflitos detectados por meio da abordagem de última atualização prevalece ou de seu manipulador de conflitos personalizado.
Os conflitos de linha incluem:
+ INSERT versus INSERT
+ INSERT versus UPDATE
+ UPDATE versus DELETE
+ INSERT versus DELETE
+ DELETE versus DELETE
+ INSERT versus DELETE
### Conflitos INSERT/INSERT
Esse conflito mais comum ocorre quando INSERTs em dois nós diferentes criam uma tupla com os mesmos valores de PRIMARY KEY (ou valores de restrição UNIQUE idênticos quando não existe PRIMARY KEY).
O pgactivelink resolve conflitos de INSERT usando o carimbo de data/hora do host de origem para manter a tupla mais recente. Você pode substituir esse comportamento padrão com seu manipulador de conflitos personalizado. Embora esse processo não exija nenhuma ação especial do administrador, esteja ciente de que o pgactivelink descarta uma das operações INSERT em todos os nós. Nenhuma mesclagem automática de dados ocorre, a menos que seu manipulador personalizado a implemente.
O pgactivelink só pode resolver conflitos envolvendo uma única violação de restrição. Se um INSERT violar várias restrições UNIQUE, você deverá implementar estratégias adicionais de resolução de conflitos.
### INSERTs que violam várias restrições UNIQUE
Um conflito INSERT/INSERT pode violar várias restrições UNIQUE, incluindo a PRIMARY KEY. O pgactivelink só pode lidar com conflitos que envolvam uma única restrição UNIQUE. Quando os conflitos violarem várias restrições UNIQUE, o operador apply falhará e retornará o seguinte erro:
`multiple unique constraints violated by remotely INSERTed tuple.`
Em versões mais antigas, essa situação gerava um erro de “conflito de exclusividade divergente”.
Para resolver esses conflitos, você deve executar uma ação manual. Use DELETE para excluir as tuplas locais conflitantes ou UPDATE para atualizá-las e remover os conflitos com a nova tupla remota. Esteja ciente de que talvez você precise resolver várias tuplas conflitantes. No momento, o pgactivelink não oferece nenhuma funcionalidade integrada para ignorar, descartar ou mesclar tuplas que violem várias restrições únicas.
**nota**
Para ter mais informações, consulte UPDATEs que violam várias restrições UNIQUE.
### Conflitos UPDATE/UPDATE
Esse conflito ocorre quando dois nós modificam simultaneamente a mesma tupla sem alterar a PRIMARY KEY. O pgactivelink resolve esses conflitos usando a lógica de última atualização prevalece ou seu manipulador de conflitos personalizado, se definido. Uma CHAVE PRIMÁRIA é essencial para correspondência de tuplas e resolução de conflitos. Para tabelas sem CHAVE PRIMÁRIA, o pgactivelink rejeita as operações UPDATE com o seguinte erro:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
### Conflitos UPDATE na CHAVE PRIMÁRIA
A pgactive tem limitações para lidar com atualizações de CHAVE PRIMÁRIA. Embora você possa realizar a operação UPDATE em uma CHAVE PRIMÁRIA, a pgactive não consegue resolver conflitos automaticamente usando a lógica de última atualização prevalece para essas operações. Você deve garantir que as atualizações da CHAVE PRIMÁRIA não entrem em conflito com os valores existentes. Se ocorrerem conflitos durante as atualizações da CHAVE PRIMÁRIA, eles se tornarão conflitos divergentes e exigirão intervenção manual. Para ter mais informações sobre como lidar com essas situações, consulte [Conflitos divergentes](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATEs que violam várias restrições UNIQUE
O pgactivelink não consegue aplicar a resolução de conflitos de última atualização prevalece quando um UPDATE recebido viola várias restrições UNIQUE ou valores de CHAVE PRIMÁRIA. Esse comportamento é semelhante às operações INSERT com várias violações de restrição. Essas situações criam conflitos divergentes que exigem intervenção manual. Para obter mais informações, consulte [Conflitos divergentes](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### Conflitos UPDATE/DELETE
Esses conflitos ocorrem quando um nó executa UPDATE em uma linha e outro nó executa simultaneamente DELETE nessa linha. Nesse caso, ocorre um conflito UPDATE/DELETE na reprodução. A solução é descartar qualquer UPDATE que chegue após um DELETE, a menos que seu manipulador de conflitos personalizado especifique o contrário.
O pgactivelink requer uma CHAVE PRIMÁRIA para combinar tuplas e resolver conflitos. Para tabelas sem CHAVE PRIMÁRIA, ele rejeita operações DELETE com o seguinte erro:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
**nota**
O pgactivelink não consegue distinguir entre os conflitos UPDATE/DELETE e INSERT/UPDATE. Em ambos os casos, um UPDATE afeta uma linha inexistente. Devido à replicação assíncrona e à falta de ordem de reprodução entre os nós, o pgactivelink não consegue determinar se o UPDATE é para uma nova linha (INSERT ainda não recebido) ou uma linha excluída. Em ambos os cenários, o pgactivelink descarta o UPDATE.
### Conflitos INSERT/UPDATE
Esse conflito pode ocorrer em ambientes com vários nós. Isso acontece quando um nó insere uma linha, um segundo nó a atualiza e um terceiro nó recebe o UPDATE antes do INSERT original. Por padrão, o pgactivelink resolve esses conflitos descartando o UPDATE, a menos que seu acionador de conflito personalizado especifique o contrário. Esteja ciente de que esse método de resolução pode provocar inconsistências de dados entre os nós. Para ter mais informações sobre cenários semelhantes e o respectivo tratamento, consulte [Conflitos UPDATE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7).
### Conflitos DELETE/DELETE
Esse conflito ocorre quando dois nós diferentes excluem simultaneamente a mesma tupla. O pgactivelink considera esses conflitos não prejudiciais porque as duas operações DELETE têm o mesmo resultado final. Nesse cenário, o pgactivelink ignora com segurança uma das operações DELETE sem afetar a consistência de dados.
### Conflitos de restrição de chave estrangeira
As restrições de CHAVE ESTRANGEIRA podem causar conflitos ao aplicar transações remotas aos dados locais existentes. Esses conflitos geralmente ocorrem quando as transações são aplicadas em uma sequência diferente da ordem lógica nos nós de origem.
Por padrão, a pgactive aplica alterações com session\$1replication\$1role como `replica`, o que ignora as verificações de chave estrangeira durante a replicação. Em configurações ativas-ativas, isso pode provocar violações de chave estrangeira. A maioria das violações é temporária e resolvida quando a replicação é concluída. Mas pode haver chaves estrangeiras pendentes porque a pgactive não permite o bloqueio de linhas entre nós.
Esse comportamento é inerente aos sistemas ativos-ativos assíncronos com tolerância à partição. Por exemplo, o nó A pode inserir uma nova linha secundária enquanto o nó B exclui simultaneamente a linha principal. O sistema não consegue impedir esse tipo de modificação simultânea entre os nós.
Para minimizar conflitos de chave estrangeira, recomendamos o seguinte:
+ Limite as relações de chave estrangeira a entidades estreitamente relacionadas.
+ Modifique as entidades relacionadas por meio de um único nó quando possível.
+ Escolha entidades que raramente exijam modificação.
+ Implemente o controle de simultaneidade em nível de aplicação para modificações.
### Conflitos de restrição de exclusão
O pgactivelink não permite restrições de exclusão e limita a criação de restrições.
**nota**
Se você converter um banco de dados independente existente em um banco de dados pgactivelink, remova manualmente todas as restrições de exclusão.
Em um sistema assíncrono distribuído, não é possível garantir que nenhum conjunto de linhas viole a restrição. Isso ocorre porque todas as transações em nós diferentes são totalmente isoladas. As restrições de exclusão podem gerar deadlocks de reprodução, impedindo que a reprodução progrida de um nó para outro devido a violações da restrição de exclusão.
Se você forçar o pgactivelink a criar uma restrição de exclusão ou se não remover as existentes ao converter um banco de dados independente em pgactivelink, é provável que a replicação seja interrompida. Para restaurar o progresso da replicação, remova ou altere as tuplas locais que estão em conflito com uma tupla remota de entrada para que a transação remota possa ser aplicada.
### Conflitos de dados globais
Ao usar o pgactivelink, conflitos podem ocorrer quando os nós têm diferentes dados globais do sistema geral do PostgreSQL, como funções. Esses conflitos podem fazer com que as operações, principalmente de DDL, sejam bem-sucedidas e confirmadas em um nó, mas falhem ao serem aplicadas a outros nós.
Se um usuário existir em um nó e não em outro, podem ocorrer problemas de replicação:
+ O Node1 tem um usuário chamado `fred`, mas esse usuário não existe no Node2.
+ Quando `fred` cria uma tabela no Node1, a tabela é replicada com `fred` como proprietário.
+ Quando esse comando de DDL é aplicado ao Node2, ele falha porque o usuário `fred` não existe.
+ Essa falha gera um ERRO nos logs do PostgreSQL no Node2 e incrementa o contador `pgactive.pgactive_stats.nr_rollbacks`.
**Resolução:** crie o usuário `fred` no Node2. O usuário não precisa de permissões idênticas, mas deve existir em ambos os nós.
Se uma tabela existir em um nó e não em outro, as operações de modificação de dados vão falhar:
+ O Node1 tem uma tabela chamada `foo` que não existe no Node2.
+ Qualquer operação de DML na tabela `foo` no Node1 falhará quando replicada para o Node2.
**Resolução:** crie a tabela `foo` no Node2 com a mesma estrutura.
**nota**
No momento, o pgactivelink não replica comandos CREATE USER ou operações de DDL. A replicação de DDL está programada para uma versão futura.
### Conflitos de bloqueio e interrupções decorrentes de deadlock
Como os processos apply da pgactive operam como sessões normais de usuário, eles seguem as regras padrão de bloqueio de linhas e tabelas. Isso pode fazer com que os processos apply do pgactivelink aguardem bloqueios mantidos por transações de usuário ou por outros processos apply.
Os seguintes tipos de bloqueio podem afetar os processos apply:
+ Bloqueio explícito em nível de tabela (LOCK TABLE…) por sessão de usuário
+ Bloqueio explícito em nível de linha (SELECT… FOR UPDATE/FOR SHARE) por sessão de usuário
+ Bloqueio de chaves estrangeiras
+ Bloqueio implícito devido operações de UPDATE, INSERT ou DELETE de linhas, seja da atividade local ou do operador apply de outros servidores
Deadlocks podem ocorrer entre:
+ Um processo apply do pgactivelink e uma transação do usuário
+ Dois processos apply
Quando ocorrem deadlocks, o detector de deadlock do PostgreSQL encerra uma das transações problemáticas. Se o processo do operador apply do pgactivelink for encerrado, ele fará uma nova tentativa automaticamente e em geral terá êxito.
**nota**
Esses problemas são temporários e normalmente não exigem intervenção do administrador. Se um processo apply for bloqueado por um longo período devido ao bloqueio de uma sessão de usuário ociosa, você poderá encerrar a sessão do usuário para retomar a replicação. Essa situação é semelhante a quando um usuário mantém um bloqueio longo que afeta a sessão de outro usuário.
Para identificar atrasos na reprodução relacionados ao bloqueio, habilite o recurso `log_lock_waits` no PostgreSQL.
### Conflitos divergentes
Conflitos divergentes ocorrem quando dados que deveriam ser idênticos entre os nós diferem inesperadamente. Embora esses conflitos não devam acontecer, nem todos podem ser evitados de forma confiável na implementação atual.
**nota**
A modificação da CHAVE PRIMÁRIA de uma linha poderá causar conflitos divergentes se outro nó alterar a chave da mesma linha antes de todos os nós processarem a alteração. Evite alterar as chaves primárias ou restrinja as alterações a um nó designado. Para obter mais informações, consulte [Conflitos UPDATE na CHAVE PRIMÁRIA](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5).
Conflitos divergentes envolvendo dados de linha geralmente exigem intervenção do administrador. Para resolver esses conflitos, você deve ajustar manualmente os dados em um nó para corresponder a outro e, ao mesmo tempo, desabilitar temporariamente a replicação usando `pgactive.pgactive_do_not_replicate`. Esses conflitos não devem ocorrer quando você usa a pgactive conforme documentado e evita configurações ou funções marcadas como inseguras.
Como administrador, você deve resolver esses conflitos manualmente. Dependendo do tipo de conflito, você precisará usar opções avançadas, como `pgactive.pgactive_do_not_replicate`. Use essas opções com cuidado, pois o uso indevido pode piorar a situação. Devido à variedade de possíveis conflitos, não podemos fornecer instruções gerais de resolução.
Conflitos divergentes ocorrem quando dados que deveriam ser idênticos entre diferentes nós diferem inesperadamente. Embora esses conflitos não devam acontecer, nem todos podem ser evitados de forma confiável na implementação atual.
## Evitar ou permitir conflitos
Na maioria dos casos, você pode usar o design de aplicação adequado para evitar conflitos ou tornar a aplicação tolerante a conflitos.
Os conflitos só ocorrem quando acontecem operações simultâneas em vários nós. Como evitar conflitos:
+ Grave em apenas um nó.
+ Grave em subconjuntos de banco de dados independentes em cada nó (por exemplo, atribua um esquema separado a cada nó).
Quanto a conflitos INSERT versus INSERT, use sequências globais para evitar conflitos por completo.
Se os conflitos não forem aceitáveis para seu caso de uso, considere implementar o bloqueio distribuído no nível da aplicação. Muitas vezes, a melhor abordagem é projetar a aplicação para funcionar com os mecanismos de resolução de conflitos da pgactive, em vez de tentar evitar todos os conflitos. Para obter mais informações, consulte [Tipos de conflito](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflicttypes).
## Registro em log de conflitos
O pgactivelink registra incidentes de conflito na tabela `pgactive.pgactive_conflict_history` para ajudar você a diagnosticar e lidar com conflitos ativos-ativos. O registro em log de conflitos nessa tabela ocorre somente quando você define `pgactive.log_conflicts_to_table` como verdadeiro. A extensão pgactive também registra em log conflitos no arquivo de log do PostgreSQL quando log\$1min\$1messages é definido como `LOG` ou `lower`, independentemente da configuração `pgactive.log_conflicts_to_table`.
Use a tabela do histórico de conflitos para:
+ Medir a frequência com que a aplicação cria conflitos.
+ Identificar onde os conflitos ocorrem.
+ Melhorar a aplicação para reduzir as taxas de conflito.
+ Detectar casos em que as resoluções de conflito não produzem os resultados desejados.
+ Determinar onde você precisa de acionadores de conflito definidos pelo usuário ou alterações no design da aplicação.
Quanto a conflitos de linha, você pode, opcionalmente, registrar em log valores de linha. Isso é controlado pela configuração `pgactive.log_conflicts_to_table`. Observe que:
+ Essa opção é global para todo o banco de dados.
+ Não há controle por tabela sobre o registro em log de valores de linha.
+ Nenhum limite é aplicado a números de campo, elementos de matriz ou comprimentos de campo.
+ A habilitação desse recurso pode não ser aconselhável se você trabalha com linhas de vários megabytes que podem desencadear conflitos.
Como a tabela do histórico de conflitos contém dados de todas as tabelas do banco de dados (cada uma com esquemas possivelmente diferentes), os valores das linhas registradas em log são armazenados como campos JSON. O JSON é criado usando `row_to_json`, de forma semelhante a chamá-lo diretamente do SQL. O PostgreSQL não oferece uma função `json_to_row`, então você precisará de um código específico de tabela (em PL/pgSQL, PL/Python, PL/Perl etc.) para reconstruir uma tupla de tipo composto por meio do JSON registrado em log.
**nota**
O suporte a conflitos definidos pelo usuário está programado como um futuro recurso de extensão.
# Noções básicas sobre o esquema da pgactive
O esquema da pgactive gerencia a replicação ativa-ativa no RDS para PostgreSQL. Esse esquema contém tabelas que armazenam informações de configuração e status da replicação.
**nota**
O esquema da pgactive está evoluindo e está sujeito a alterações. Não modifique os dados nessas tabelas diretamente.
As tabelas principais no esquema da pgactive incluem:
+ `pgactive_nodes`: armazena informações sobre os nós no grupo de replicação ativa-ativa.
+ `pgactive_connections`: armazena detalhes da conexão para cada nó.
## pgactive\$1nodes
A pgactive\$1nodes armazena informações sobre os nós que participam do grupo de replicação ativa-ativa.
| Coluna | Tipo | Collation (Agrupamento) | Anulável | Padrão |
| --- | --- | --- | --- | --- |
| node\$1sysid | texto | – | não nulo | – |
| node\$1timeline | oid | – | não nulo | – |
| node\$1dboid | oid | – | não nulo | – |
| node\$1status | char | – | não nulo | – |
| node\$1name | texto | – | não nulo | – |
| node\$1dsn | texto | – | não nulo | – |
| node\$1init\$1from\$1dsn | texto | – | não nulo | – |
| node\$1read\$1only | booleano | – | – | false |
| node\$1seq\$1id | smallint | – | não nulo | – |
**node\$1sysid**
ID exclusivo para um nó, gerado durante `pgactive_create_group` ou `pgactive_join_group`.
**node\$1status**
Prontidão do nó:
+ **b**: iniciando a configuração
+ **i**: inicializando
+ **c**: recuperando
+ **o**: criando slots de saída
+ **r**: pronto
+ **k**: encerrado
Essa coluna não indica se um nó está conectado ou desconectado.
**node\$1name**
Nome de nó exclusivo fornecido pelo usuário.
**node\$1dsn**
String de conexão ou nome de mapeamento do usuário
**node\$1init\$1from\$1dsn**
DSN com base no qual esse nó foi criado.
## pgactive\$1connection
A pgactive\$1connections armazena detalhes da conexão para cada nó.
| Coluna | Tipo | Collation (Agrupamento) | Anulável | Padrão |
| --- | --- | --- | --- | --- |
| conn\$1sysid | texto | nenhuma | não nulo | nenhuma |
| conn\$1timeline | oid | nenhuma | não nulo | nenhuma |
| conn\$1dboid | oid | nenhuma | não nulo | nenhuma |
| conn\$1dsn | texto | nenhuma | não nulo | nenhuma |
| conn\$1apply\$1delay | integer | nenhuma | nenhuma | nenhuma |
| conn\$1replication\$1sets | texto | nenhuma | nenhuma | nenhuma |
conn\$1sysid
Identificador do nó ao qual essa entrada se refere.
conn\$1dsn
O mesmo que `node_dsn` de pgactive.pgactive\$1nodes.
conn\$1apply\$1delay
Se definido, milissegundos de espera antes de aplicar cada transação por meio do nó remoto. Principalmente para depuração. Se nulo, o padrão global se aplica.
## Trabalhar com conjuntos de replicações
Os conjuntos de replicações determinam quais tabelas incluir ou excluir das operações de replicação. Por padrão, todas as tabelas são replicadas, a menos que você especifique o contrário usando as seguintes funções:
+ `pgactive_exclude_table_replication_set()`: exclui tabelas especificadas da replicação.
+ `pgactive_include_table_replication_set()`: inclui tabelas especificadas na replicação.
**nota**
Antes de configurar os conjuntos de replicações, considere o seguinte:
Você pode configurar a inclusão ou exclusão da tabela somente depois de executar `pgactive_create_group()`, mas antes de `pgactive_join_group()`.
Depois de usar `pgactive_exclude_table_replication_set()`, você não pode usar `pgactive_include_table_replication_set()`.
Depois de usar `pgactive_include_table_replication_set()`, você não pode usar `pgactive_exclude_table_replication_set()`.
O sistema trata as tabelas recém-criadas de forma diferente com base na sua configuração inicial:
+ Se você excluiu tabelas: todas as outras tabelas criadas depois de `pgactive_join_group()` serão automaticamente incluídas na replicação.
+ Se você incluiu tabelas: todas as outras tabelas criadas depois de `pgactive_join_group()` serão automaticamente excluídas da replicação.
Para visualizar a configuração do conjunto de replicações de uma tabela específica, use a função `pgactive.pgactive_get_table_replication_sets()`.
# Referência de funções da pgactive
Abaixo, você pode encontrar uma lista de funções da pgactive com os respectivos parâmetros, valores de retorno e observações práticas de uso para ajudar você a usá-las de forma eficaz:
## get\$1last\$1applied\$1xact\$1info
Recupera as informações da última transação aplicada para um nó especificado.
**Arguments (Argumentos)**
+ sysid (text): OID de carimbo de data/hora
+ dboid (OID)
**Tipo de retorno**
Ela registra o seguinte:
+ last\$1applied\$1xact\$1id (OID)
+ last\$1applied\$1xact\$1committs (carimbo de data/hora com fuso horário)
+ last\$1applied\$1xact\$1at (carimbo de data/hora com fuso horário)
**Observações de uso**
Use esta função para recuperar as informações da última transação aplicada para um nó especificado.
## pgactive\$1apply\$1pause
Pausa o processo apply da replicação.
**Arguments (Argumentos)**
Nenhum
**Tipo de retorno**
boolean
**Observações de uso**
Chame esta função para pausar o processo apply da replicação.
## pgactive\$1apply\$1resume
Retoma o processo apply da replicação.
**Arguments (Argumentos)**
Nenhum
**Tipo de retorno**
nulo
**Observações de uso**
Chame essa função para retomar o processo apply da replicação.
## pgactive\$1is\$1apply\$1paused
Verifica se o processo apply da replicação está em pausa no momento.
**Arguments (Argumentos)**
Nenhum
**Tipo de retorno**
boolean
**Observações de uso**
Use essa função para verificar se o processo apply da replicação está em pausa no momento.
## pgactive\$1create\$1group
Cria um grupo da pgactive convertendo um banco de dados independente no nó inicial.
**Arguments (Argumentos)**
+ node\$1name (text)
+ node\$1dsn (text)
+ apply\$1delay integer DEFAULT NULL::integer - replication\$1sets text[] DEFAULT ARRAY[‘default’::text]
**Tipo de retorno**
nulo
**Observações de uso**
Cria um grupo da pgactive convertendo um banco de dados independente no nó inicial. A função realiza verificações de integridade antes de transformar o nó em um nó pgactive. Antes de usar essa função, o cluster do PostgreSQL deve ter `max_worker_processes` suficientes para comportar operadores em segundo plano da pgactive.
## pgactive\$1detach\$1nodes
Remove os nós especificados do grupo da pgactive.
**Arguments (Argumentos)**
+ p\$1nodes (text[])
**Tipo de retorno**
nulo
**Observações de uso**
Use essa função para remover os nós especificados do grupo da pgactive.
## pgactive\$1exclude\$1table\$1replication\$1set
Exclui uma tabela específica da replicação.
**Arguments (Argumentos)**
+ p\$1relation (regclass)
**Tipo de retorno**
nulo
**Observações de uso**
Use essa função para excluir uma tabela específica da replicação.
## pgactive\$1get\$1replication\$1lag\$1info
Recupera informações detalhadas do atraso da replicação, incluindo detalhes do nó, status do WAL e valores de LSN.
**Arguments (Argumentos)**
Nenhum
**Tipo de retorno**
Registro SETOF: node\$1name text, node\$1sysid text, application\$1name text, slot\$1name text, active boolean, active\$1pid integer, pending\$1wal\$1decoding bigint (tamanho aproximado do WAL em bytes a ser decodificado no nó emissor), pending\$1wal\$1to\$1apply bigint (tamanho aproximado do WAL em bytes a ser decodificado no nó receptor), restart\$1lsn pg\$1lsn, confirmed\$1flush\$1lsn pg\$1lsn, sent\$1lsn pg\$1lsn, write\$1lsn pg\$1lsn, flush\$1lsn pg\$1lsn, replay\$1lsn pg\$1lsn
**Observações de uso**
Chame esta função para recuperar informações sobre o atraso da replicação, incluindo detalhes do nó, status do WAL e valores de LSN.
## pgactive\$1get\$1stats
Recupera estatísticas de replicação da pgactive.
**Arguments (Argumentos)**
Nenhum
**Tipo de retorno**
Registro SETOF: rep\$1node\$1id oid, rilocalid oid, riremoteid text, nr\$1commit bigint, nr\$1rollback bigint, nr\$1insert bigint, nr\$1insert\$1conflict bigint, nr\$1update bigint, nr\$1update\$1conflict bigint, nr\$1delete bigint, nr\$1delete\$1conflict bigint, nr\$1disconnect bigint
**Observações de uso**
Use esta função para recuperar estatísticas de replicação da pgactive.
## pgactive\$1get\$1table\$1replication\$1sets
Obtém a configuração do conjunto de replicações para uma relação específica.
**Arguments (Argumentos)**
+ relation (regclass)
**Tipo de retorno**
Registro SETOF
**Observações de uso**
Chame esta função para obter a configuração do conjunto de replicações para uma relação específica.
## pgactive\$1include\$1table\$1replication\$1set
Inclui uma tabela específica na replicação.
**Arguments (Argumentos)**
+ p\$1relation (regclass)
**Tipo de retorno**
nulo
**Observações de uso**
Use esta função para incluir uma tabela específica na replicação.
## pgactive\$1join\$1group
Adiciona um nó a um grupo existente da pgactive.
**Arguments (Argumentos)**
+ node\$1name (text)
+ node\$1dsn (text)
+ join\$1using\$1dsn (text)
+ apply\$1delay (integer, optional)
+ replication\$1sets (text[], default: ['default'])
+ bypass\$1collation\$1check (boolean, default: false)
+ bypass\$1node\$1identifier\$1creation (boolean, default: false)
+ bypass\$1user\$1tables\$1check (boolean, default: false)
**Tipo de retorno**
nulo
**Observações de uso**
Chame essa função para adicionar um nó a um grupo existente da pgactive. O cluster do PostgreSQL deve ter max\$1worker\$1processes suficientes para os operadores em segundo plano da pgactive.
## pgactive\$1remove
Remove todos os componentes da pgactive do nó local.
**Arguments (Argumentos)**
+ force (boolean, default: false)
**Tipo de retorno**
nulo
**Observações de uso**
Chame esta função para remover todos os componentes da pgactive do nó local.
## pgactive\$1snowflake\$1id\$1nextval
Gera valores de sequência exclusivos específicos do nó.
**Arguments (Argumentos)**
+ regclass
**Tipo de retorno**
bigint
**Observações de uso**
Use esta função para gerar valores de sequência exclusivos específicos do nó.
## pgactive\$1update\$1node\$1conninfo
Atualiza as informações de conexão de um nó da pgactive.
**Arguments (Argumentos)**
+ node\$1name\$1to\$1update (text)
+ node\$1dsn\$1to\$1update (text)
**Tipo de retorno**
nulo
**Observações de uso**
Usa esta função para atualizar as informações de conexão de um nó da pgactive.
## pgactive\$1wait\$1for\$1node\$1ready
Monitora o progresso das operações de criação de grupo ou junção.
**Arguments (Argumentos)**
+ timeout (integer, default: 0)
+ progress\$1interval (integer, default: 60)
**Tipo de retorno**
nulo
**Observações de uso**
Chame esta função para monitorar o progresso das operações de criação de grupo ou junção.
# Lidar com conflitos na replicação ativa-ativa
A extensão `pgactive` funciona por banco de dados e não por cluster. Cada instância de banco de dados que usa `pgactive` é uma instância independente e pode aceitar alterações de dados de qualquer fonte. Quando uma alteração é enviada a uma instância de banco de dados, o PostgreSQL a confirma localmente e depois usa `pgactive` para replicar a alteração de forma assíncrona para outras instâncias de banco de dados. Quando duas instâncias de banco de dados do PostgreSQL atualizam o mesmo registro quase ao mesmo tempo, pode ocorrer um conflito.
A extensão `pgactive` fornece mecanismos para detecção de conflitos e resolução automática. Ela rastreia o carimbo de data/hora em que a transação foi confirmada em ambas as instâncias de banco de dados e aplica automaticamente a alteração com o carimbo de data/hora mais recente. A extensão `pgactive` também registra em log quando ocorre um conflito na tabela `pgactive.pgactive_conflict_history`.
O `pgactive.pgactive_conflict_history` continuará crescendo. Talvez você queira definir uma política de limpeza. Isso pode ser feito excluindo alguns registros regularmente ou definindo um esquema de particionamento para essa relação (e depois separando, descartando e truncando as partições de interesse). Para implementar a política de limpeza regularmente, uma opção é usar a extensão `pg_cron`. Veja as informações a seguir de um exemplo para a tabela de histórico `pg_cron`, [Agendar manutenção com a extensão pg\$1cron do PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html).
# Lidar com sequências na replicação ativa-ativa
Uma instância de banco de dados do RDS para PostgreSQL com a extensão `pgactive` usa dois mecanismos de sequência diferentes para gerar valores exclusivos.
**Sequências globais**
Para usar uma sequência global, crie uma sequência local com a instrução `CREATE SEQUENCE`. Use `pgactive.pgactive_snowflake_id_nextval(seqname)` em vez de `usingnextval(seqname)` para obter o próximo valor exclusivo da sequência.
O exemplo a seguir cria uma rede global.
```
app=> CREATE TABLE gstest (
id bigint primary key,
parrot text
);
```
```
app=>CREATE SEQUENCE gstest_id_seq OWNED BY gstest.id;
```
```
app=> ALTER TABLE gstest \
ALTER COLUMN id SET DEFAULT \
pgactive.pgactive_snowflake_id_nextval('gstest_id_seq');
```
**Sequências particionadas**
Em sequências divididas ou particionadas, uma sequência normal do PostgreSQL é usada em cada nó. Cada sequência é incrementada na mesma quantidade e começa com diferentes deslocamentos. Por exemplo, com a etapa 100, o nó 1 gera a sequência como 101, 201, 301 e assim por diante, e o nó 2 gera a sequência como 102, 202, 302 e assim por diante. Esse esquema funciona bem mesmo que os nós não possam se comunicar por longos períodos, mas exige que o designer especifique um número máximo de nós ao estabelecer o esquema e requer configuração por nó. Erros podem facilmente levar à sobreposição de sequências.
É relativamente simples configurar essa abordagem com `pgactive` criando a sequência desejada em um nó da seguinte maneira:
```
CREATE TABLE some_table (generated_value bigint primary key);
```
```
app=> CREATE SEQUENCE some_seq INCREMENT 100 OWNED BY some_table.generated_value;
```
```
app=> ALTER TABLE some_table ALTER COLUMN generated_value SET DEFAULT nextval('some_seq');
```
Em seguida, chame `setval` em cada nó para fornecer um valor inicial de deslocamento diferente da forma a seguir.
```
app=>
-- On node 1
SELECT setval('some_seq', 1);
-- On node 2
SELECT setval('some_seq', 2);
```
# Reduzir o inchaço em tabelas e índices com a extensão pg\$1repack
É possível usar a extensão `pg_repack` para remover a sobrecarga de tabelas e índices como uma alternativa a `VACUUM FULL`. Esta extensão é compatível com o RDS para PostgreSQL versões 9.6.3 e posteriores. Para ter mais informações sobre a extensão `pg_repack` e a recriação da tabela inteira, consulte a [documentação de projetos do GitHub](https://reorg.github.io/pg_repack/).
Ao contrário de `VACUUM FULL`, a extensão `pg_repack` requer um bloqueio exclusivo (AccessExclusiveLock) somente por um curto período durante a operação de recriação da tabela nos seguintes casos:
+ Criação inicial da tabela de logs: uma tabela de logs é criada para registrar as alterações que ocorrem durante a cópia inicial dos dados, conforme mostrado no seguinte exemplo:
```
postgres=>\dt+ repack.log_*
List of relations
-[ RECORD 1 ]-+----------
Schema | repack
Name | log_16490
Type | table
Owner | postgres
Persistence | permanent
Access method | heap
Size | 65 MB
Description |
```
+ Fase final de troca e descarte.
Para o restante da operação de recriação, ela só precisa de um bloqueio `ACCESS SHARE` na tabela original para copiar as linhas dela para a nova tabela. Isso ajuda as operações INSERT, UPDATE e DELETE a prosseguir normalmente.
## Recomendações
As recomendações a seguir se aplicam ao remover a sobrecarga das tabelas e dos índices usando a extensão `pg_repack`:
+ Realize a recriação fora do horário comercial ou durante uma janela de manutenção para minimizar o impacto na performance de outras atividades do banco de dados.
+ Monitore atentamente as sessões de bloqueio durante a atividade de recriação e garanta que não haja nenhuma atividade na tabela original que possa bloquear `pg_repack`, especificamente durante a fase final de troca e descarte, quando ela precisa de um bloqueio exclusivo na tabela original. Para ter mais informações, consulte [Como identificar o que está bloqueando uma consulta](https://repost.aws/knowledge-center/rds-aurora-postgresql-query-blocked).
Ao ver uma sessão de bloqueio, é possível encerrá-la usando o comando a seguir após uma análise cuidadosa. Isso ajuda na continuação da `pg_repack` para concluir a recriação:
```
SELECT pg_terminate_backend(pid);
```
+ Ao aplicar as alterações acumuladas da tabela de logs de `pg_repack's` em sistemas com uma taxa de transação muito alta, o processo de aplicação pode não ser capaz de acompanhar a taxa de alterações. Nesses casos, `pg_repack` não conseguiria concluir o processo de aplicação. Para obter mais informações, consulte [Monitorar a nova tabela durante a recriação](#Appendix.PostgreSQL.CommonDBATasks.pg_repack.Monitoring). Se os índices estiverem muito sobrecarregados, uma solução alternativa será realizar uma recriação somente de índices. Isso também ajuda os ciclos de limpeza do índice do VACUUM a terminar mais rapidamente.
É possível ignorar a fase de limpeza do índice usando o VACUUM manual do PostgreSQL versão 12, e ela é ignorada automaticamente durante o autovacuum de emergência do PostgreSQL versão 14. Isso ajuda o VACUUM a ser concluído mais rapidamente sem remover a sobrecarga do índice e serve apenas para situações de emergência, como evitar o VACUUM de encapsulamento. Para ter mais informações, consulte [Evitar a sobrecarga nos índices](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html#AuroraPostgreSQL.diag-table-ind-bloat.AvoidinginIndexes) no Guia do usuário do Amazon Aurora.
## Pré-requisitos
+ A tabela deve ter PRIMARY KEY ou a restrição UNIQUE não nula.
+ A versão da extensão deve ser a mesma para o cliente e para o servidor.
+ Garanta que a instância do RDS tenha mais `FreeStorageSpace` do que o tamanho total da tabela sem a sobrecarga. Por exemplo, pense no tamanho total da tabela, incluindo TOAST e índices, como 2 TB, e a sobrecarga total na tabela, como 1 TB. O `FreeStorageSpace` necessário deve ser maior do que o valor exibido pelo seguinte cálculo:
`2TB (Table size)` - `1TB (Table bloat)` = `1TB`
É possível usar a consulta a seguir para conferir o tamanho total da tabela e usar `pgstattuple` para gerar a sobrecarga. Para ter mais informações, consulte [Diagnosticar a sobrecarga na tabela e no índice](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html) no Guia do usuário do Amazon Aurora.
```
SELECT pg_size_pretty(pg_total_relation_size('table_name')) AS total_table_size;
```
Esse espaço é recuperado após a conclusão da atividade.
+ Garanta que a instância do RDS tenha capacidade computacional e de E/S suficientes para lidar com a operação de recriação. Pense na possibilidade de aumentar a escala da classe de instância verticalmente para conseguir o equilíbrio ideal de performance.
**Como usar a extensão `pg_repack`**
1. Instale a extensão `pg_repack` na instância de banco de dados RDS for PostgreSQL executando o comando a seguir.
```
CREATE EXTENSION pg_repack;
```
1. Execute os comandos a seguir para conceder acesso de gravação para recriar as tabelas de logs temporárias criadas pelo `pg_repack`.
```
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC;
```
1. Conecte-se ao banco de dados usando o utilitário de cliente `pg_repack`. Use uma conta que tenha privilégios `rds_superuser`. Como exemplo, suponha que a função `rds_test` tenha os privilégios `rds_superuser`. A sintaxe a seguir realiza a `pg_repack` para tabelas completas, incluindo todos os índices da tabela no banco de dados `postgres`.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test -k postgres
```
**nota**
É necessário se conectar usando a opção -k. Não há suporte para a opção -a.
A resposta do cliente `pg_repack` fornece informações sobre as tabelas recriadas na instância de banco de dados.
```
INFO: repacking table "pgbench_tellers"
INFO: repacking table "pgbench_accounts"
INFO: repacking table "pgbench_branches"
```
1. A sintaxe a seguir recria uma única tabela `orders` incluindo índices no banco de dados `postgres`.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders -k postgres
```
A sintaxe a seguir recria somente os índices da tabela `orders` no banco de dados `postgres`.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders --only-indexes -k postgres
```
## Monitorar a nova tabela durante a recriação
+ O tamanho do banco de dados é aumentado pelo tamanho total da tabela menos a sobrecarga, até a fase de troca e descarte da recriação. É possível monitorar a taxa de crescimento do tamanho do banco de dados, calcular a velocidade da recriação e estimar aproximadamente o tempo necessário para concluir a transferência inicial dos dados.
Por exemplo, pense no tamanho total da tabela como 2 TB, o tamanho do banco de dados como 4 TB e a sobrecarga total na tabela como 1 TB. O valor do tamanho total do banco de dados exibido pelo cálculo no final da operação de recriação é o seguinte:
`2TB (Table size)` \$1 `4 TB (Database size)` - `1TB (Table bloat)` = `5TB`
É possível calcular aproximadamente a velocidade da operação de recriação criando uma amostra da taxa de crescimento em bytes entre dois pontos no tempo. Se a taxa de crescimento for de 1 GB por minuto, poderá levar mil minutos ou 16,6 horas aproximadamente para concluir a operação inicial de criação da tabela. Além da criação inicial da tabela, a `pg_repack` também precisa aplicar as alterações acumuladas. O tempo necessário depende da taxa de aplicação das alterações em andamento, além das alterações acumuladas.
**nota**
É possível usar a extensão `pgstattuple` para calcular a sobrecarga na tabela. Para ter mais informações, consulte [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html).
+ O número de linhas na tabela de logs `pg_repack's`, no esquema de recriação, representa o volume de alterações pendentes para serem aplicadas à nova tabela após o carregamento inicial.
É possível conferir a tabela de logs `pg_repack's` em `pg_stat_all_tables` para monitorar as alterações aplicadas à nova tabela. `pg_stat_all_tables.n_live_tup` indica o número de registros pendentes a serem aplicados à nova tabela. Para ter mais informações, consulte [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW).
```
postgres=>SELECT relname,n_live_tup FROM pg_stat_all_tables WHERE schemaname = 'repack' AND relname ILIKE '%log%';
-[ RECORD 1 ]---------
relname | log_16490
n_live_tup | 2000000
```
+ É possível usar a extensão `pg_stat_statements` para descobrir o tempo gasto em cada etapa da operação de recriação. Isso é útil na preparação para aplicar a mesma operação de recriação em um ambiente de produção. É possível ajustar a cláusula `LIMIT` para estender ainda mais a saída.
```
postgres=>SELECT
SUBSTR(query, 1, 100) query,
round((round(total_exec_time::numeric, 6) / 1000 / 60),4) total_exec_time_in_minutes
FROM
pg_stat_statements
WHERE
query ILIKE '%repack%'
ORDER BY
total_exec_time DESC LIMIT 5;
query | total_exec_time_in_minutes
-----------------------------------------------------------------------+----------------------------
CREATE UNIQUE INDEX index_16493 ON repack.table_16490 USING btree (a) | 6.8627
INSERT INTO repack.table_16490 SELECT a FROM ONLY public.t1 | 6.4150
SELECT repack.repack_apply($1, $2, $3, $4, $5, $6) | 0.5395
SELECT repack.repack_drop($1, $2) | 0.0004
SELECT repack.repack_swap($1) | 0.0004
(5 rows)
```
A recriação é uma operação extraordinária, portanto, a tabela original não é afetada e não prevemos nenhum desafio inesperado que exija a recuperação da tabela original. Se a recriação falhar inesperadamente, você deverá inspecionar a causa do erro e resolvê-lo.
Depois que o problema for resolvido, descarte e recrie a extensão `pg_repack` no banco de dados em que a tabela existe e repita a etapa `pg_repack`. Além disso, a disponibilidade de recursos computacionais e a acessibilidade simultânea da tabela desempenham um papel crucial na conclusão oportuna da operação de recriação.
# Atualizar e usar a extensão PLV8
O PLV8 é uma extensão de linguagem Javascript confiável para o PostgreSQL. Você pode usá-lo para procedimentos armazenados, gatilhos e outros códigos processuais que podem ser chamados do SQL. Essa extensão de idioma é compatível com todas as versões atuais do PostgreSQL.
Se você usar o [PLV8](https://plv8.github.io/) e atualizar o PostgreSQL para uma nova versão do PLV8, você poderá aproveitar imediatamente a nova extensão. Tome as medidas a seguir para sincronizar os metadados do catálogo com a nova versão do PLV8. Estas etapas são opcionais, mas recomendamos fortemente que você as conclua para evitar avisos de incompatibilidade dos metadados.
O processo de atualização elimina todas as suas funções PLV8 existentes. Portanto, recomendamos que você crie um snapshot da sua instância de banco de dados do RDS para PostgreSQL antes de atualizar. Para obter mais informações, consulte [Criar um snapshot de banco de dados para uma instância de banco de dados single-AZ para o Amazon RDS](USER_CreateSnapshot.md).
**Importante**
A partir da versão 18 do PostgreSQL, o Amazon RDS para PostgreSQL descontinuará as extensões `plcoffee` e `plls` do PostgreSQL. Recomendamos que você pare de usar o CoffeeScript e o LiveScript em suas aplicações para garantir um caminho de atualização para futuras atualizações de versão do mecanismo.
**Para sincronizar os metadados do catálogo com uma nova versão do PLV8**
1. Verifique se você precisa atualizar. Para fazer isso, execute o comando a seguir enquanto conectado à instância.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
Se os resultados contiverem valores para uma versão instalada que seja um número menor que a versão padrão, continue com este procedimento para atualizar suas extensões. Por exemplo, o seguinte conjunto de resultados indica que você deve atualizar.
```
name | default_version | installed_version | comment
--------+-----------------+-------------------+--------------------------------------------------
plls | 2.1.0 | 1.5.3 | PL/LiveScript (v8) trusted procedural language
plcoffee| 2.1.0 | 1.5.3 | PL/CoffeeScript (v8) trusted procedural language
plv8 | 2.1.0 | 1.5.3 | PL/JavaScript (v8) trusted procedural language
(3 rows)
```
1. Crie um snapshot da sua instância de banco de dados do RDS para PostgreSQL se você ainda não tiver feito isso. Você pode continuar com as seguintes etapas enquanto o snapshot estiver sendo criado.
1. Obtenha uma contagem do número de funções do PLV8 em sua instância de banco de dados para que você possa confirmar se todas estão implementadas depois da atualização. Por exemplo, a consulta SQL a seguir retorna o número de funções gravadas em plv8, plcoffee e plls.
```
SELECT proname, nspname, lanname
FROM pg_proc p, pg_language l, pg_namespace n
WHERE p.prolang = l.oid
AND n.oid = p.pronamespace
AND lanname IN ('plv8','plcoffee','plls');
```
1. Use o pg\$1dump para criar um arquivo de despejo de somente esquema. Por exemplo, crie um arquivo na máquina do cliente no diretório `/tmp`.
```
./pg_dump -Fc --schema-only -U master postgres >/tmp/test.dmp
```
Esse exemplo usa as seguintes opções:
+ `-Fc`: formato personalizado
+ --schema-only: fará o despejo apenas dos comandos necessários para criar o esquema (funções em nosso caso)
+ `-U`: o nome do usuário mestre do RDS
+ `database`: o nome do banco de dados de nossa instância de banco de dados
Para obter mais informações sobre pg\$1dump, consulte [pg\$1dump](https://www.postgresql.org/docs/current/static/app-pgdump.html ) na documentação do PostgreSQL.
1. Extraia a declaração DDL "CREATE FUNCTION" que está presente no arquivo de despejo. O exemplo a seguir usa o comando `grep` para extrair a instrução DDL que cria as funções e as salva em um arquivo. Use isso em etapas subsequentes para recriar as funções.
```
./pg_restore -l /tmp/test.dmp | grep FUNCTION > /tmp/function_list
```
Para obter mais informações sobre pg\$1restore, consulte [pg\$1restore](https://www.postgresql.org/docs/current/static/app-pgrestore.html) na documentação do PostgreSQL.
1. Descarte as funções e as extensões. O exemplo a seguir descarta todos os objetos baseados em PLV8. A opção de cascata garante que qualquer dependente seja descartado.
```
DROP EXTENSION plv8 CASCADE;
```
Se sua instância do PostgreSQL contiver objetos baseados em plcoffee ou plls, repita essa etapa para essas extensões.
1. Crie as extensões. O exemplo a seguir cria as extensões plv8, plcoffee e plls.
```
CREATE EXTENSION plv8;
CREATE EXTENSION plcoffee;
CREATE EXTENSION plls;
```
1. Crie as funções usando o arquivo de despejo e o arquivo do “driver”.
O exemplo a seguir recria as funções que você extraiu anteriormente.
```
./pg_restore -U master -d postgres -Fc -L /tmp/function_list /tmp/test.dmp
```
1. Verifique se todas as suas funções foram recriadas usando a seguinte consulta.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
A versão 2 do PLV8 adiciona a seguinte linha extra ao conjunto de resultados:
```
proname | nspname | lanname
---------------+------------+----------
plv8_version | pg_catalog | plv8
```
# Usar PL/Rust para escrever funções do PostgreSQL na linguagem Rust
O PL/Rust é uma extensão de linguagem Rust confiável para o PostgreSQL. Você pode usá-lo para procedimentos armazenados, funções e outros códigos processuais que podem ser chamados do SQL. A extensão de linguagem PL/Rust está disponível nas seguintes versões:
+ RDS para PostgreSQL 17.1 e versões 17 posteriores
+ RDS para PostgreSQL 16.1 e versões 16 posteriores
+ RDS para PostgreSQL 15.2-R2 e versões 15 posteriores
+ RDS para PostgreSQL 14.9 e versões 14 posteriores
+ RDS para PostgreSQL 13.12 e versões 13 posteriores
Para obter mais informações, consulte [PL/Rust](https://github.com/tcdi/plrust#readme) no GitHub.
**Topics**
+ [
## Configurar o PL/Rust
](#PL_Rust-setting-up)
+ [
## Criar funções com o PL/Rust
](#PL_Rust-create-function)
+ [
## Usar caixas com PL/Rust
](#PL_Rust-crates)
+ [
## Limitações do PL/Rust
](#PL_Rust-limitations)
## Configurar o PL/Rust
Para instalar a extensão plrust da instância de banco de dados, adicione o plrust ao parâmetro `shared_preload_libraries` no grupo de parâmetros de banco de dados associado à instância de banco de dados. Com a extensão plrust instalada, é possível criar funções.
Para modificar o parâmetro `shared_preload_libraries`, a instância de banco de dados deve estar associada a um grupo de parâmetros personalizado. Para obter mais informações sobre como criar um grupo de parâmetros de banco de dados personalizado, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
É possível instalar a extensão plrust usando o Console de gerenciamento da AWS ou a AWS CLI.
As etapas a seguir pressupõem que a instância de banco de dados esteja associada a um grupo de parâmetros de banco de dados personalizado.
### Console
**Instalar a extensão plrust no parâmetro `shared_preload_libraries`**
Conclua as etapas a seguir usando uma conta que seja membro do grupo (perfil) `rds_superuser`.
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Bancos de dados**.
1. Escolha o nome da instância de banco de dados para mostrar os detalhes.
1. Abra a guia **Configuração** da instância de banco de dados e encontre o link do grupo de parâmetros da instância de banco de dados.
1. Clique no link para abrir os parâmetros personalizados associados à instância de banco.
1. No campo **Parâmetros**, digite `shared_pre` para encontrar o parâmetro **`shared_preload_libraries`**.
1. Selecione **Edit parameters** (Editar parâmetros) para acessar os valores das propriedades.
1. Adicione plrust à lista no campo **Valores**. Use uma vírgula para separar itens na lista de valores.
1. Reinicialize a instância de banco de dados para que a alteração no parâmetro `shared_preload_libraries` tenha efeito. A reinicialização inicial pode exigir mais tempo para ser concluída.
1. Quando a instância estiver disponível, verifique se plrust foi inicializado. Use `psql` para se conectar à instância de banco de dados e execute o comando a seguir.
```
SHOW shared_preload_libraries;
```
O resultado deve ser semelhante ao seguinte:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
### AWS CLI
**Instalar a extensão plrust no parâmetro shared\$1preload\$1libraries**
Conclua as etapas a seguir usando uma conta que seja membro do grupo (perfil) `rds_superuser`.
1. Utilize o comando [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) da AWS CLI para adicionar plrust ao parâmetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=plrust,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use o comando [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) da AWS CLI para reinicializar a instância de banco de dados e inicializar a biblioteca plrust. A reinicialização inicial pode exigir mais tempo para ser concluída.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Quando a instância estiver disponível, é possível verificar se plrust foi inicializado. Use `psql` para se conectar à instância de banco de dados e execute o comando a seguir.
```
SHOW shared_preload_libraries;
```
O resultado deve ser semelhante ao seguinte:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
## Criar funções com o PL/Rust
O PL/Rust compilará a função como uma biblioteca dinâmica, a carregará e a executará.
A função do Rust a seguir filtra múltiplos de uma matriz.
```
postgres=> CREATE LANGUAGE plrust;
CREATE EXTENSION
```
```
CREATE OR REPLACE FUNCTION filter_multiples(a BIGINT[], multiple BIGINT) RETURNS BIGINT[]
IMMUTABLE STRICT
LANGUAGE PLRUST AS
$$
Ok(Some(a.into_iter().filter(|x| x.unwrap() % multiple != 0).collect()))
$$;
WITH gen_values AS (
SELECT ARRAY(SELECT * FROM generate_series(1,100)) as arr)
SELECT filter_multiples(arr, 3)
from gen_values;
```
## Usar caixas com PL/Rust
No RDS para PostgreSQL versões 16.3-R2 e posterior, 15.7-R2 e versões 15 posteriores, 14.12-R2 e versões 14 posteriores e 13.15-R2 e versões 13 posteriores, o PL/Rust é compatível com caixas adicionais:
+ `url`
+ `regex`
+ `serde`
+ `serde_json`
No RDS para PostgreSQL versões 15.5-R2 e posterior, 14.10-R2 e versões 14 posteriores e 13.13-R2 e versões 13 posteriores, o PL/Rust é compatível com duas caixas adicionais:
+ `croaring-rs`
+ `num-bigint`
A partir das versões 15.4, 14.9 e 13.12 do Amazon RDS para PostgreSQL, o PL/Rust comporta as seguintes caixas:
+ `aes`
+ `ctr`
+ `rand`
Somente os recursos padrão são comportados para essas caixas. As novas versões do RDS para PostgreSQL poderão conter versões de caixa atualizadas, ao passo que as mais antigas podem deixar de ter suporte.
Siga as práticas recomendadas para realizar uma atualização de versão principal e testar se suas funções do PL/Rust são compatíveis com a nova versão principal. Para obter mais informações, consulte a publicação de blog [Práticas recomendadas para atualizar o Amazon RDS para versões principais e secundárias do PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-upgrading-amazon-rds-to-major-and-minor-versions-of-postgresql/) e [Atualizar o mecanismo de banco de dados PostgreSQL para Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html) no “Guia do usuário do Amazon RDS”.
Exemplos de uso de dependências ao criar uma função PL/Rust estão disponíveis em [Usar dependências](https://tcdi.github.io/plrust/use-plrust.html#use-dependencies).
## Limitações do PL/Rust
Por padrão, os usuários do banco de dados não podem usar PL/Rust. Para fornecer acesso ao PL/Rust, conecte-se como usuário com o privilégio rds\$1superuser e execute o seguinte comando:
```
postgres=> GRANT USAGE ON LANGUAGE PLRUST TO user;
```
# Gerenciar dados espaciais com a extensão PostGIS
PostGIS é uma extensão do PostgreSQL para armazenar e gerenciar informações espaciais. Para saber mais sobre a extensão PostGIS, consulte [Postgis.net](https://postgis.net/).
Desde a versão 10.5, o PostgreSQL é compatível com a biblioteca libprotobuf 1.3.0 usada pelo PostGIS para trabalhar com dados de blocos vetoriais do Mapbox.
A configuração da extensão PostGIS exige privilégios `rds_superuser`. Recomendamos criar um usuário (perfil) para gerenciar a extensão PostGIS e os dados espaciais. A extensão PostGIS e seus componentes relacionados adicionam milhares de funções ao PostgreSQL. Considere criar a extensão PostGIS em seu próprio esquema se isso fizer sentido para o seu caso de uso. O exemplo a seguir mostra como instalar a extensão em seu próprio banco de dados, mas isso não é necessário.
**Topics**
+ [
## Etapa 1: Criar um usuário (função) para gerenciar a extensão PostGIS
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Connect)
+ [
## Etapa 2: Carregar as extensões PostGIS
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.LoadExtensions)
+ [
## Etapa 3: Transferir a propriedade dos esquemas de extensão
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferOwnership)
+ [
## Etapa 4: Transferir a propriedade dos objetos PostGIS
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferObjects)
+ [
## Etapa 5: Testar as extensões
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Test)
+ [
## Etapa 6: Atualize a extensão PostGIS
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)
+ [Versões de extensão PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS)
+ [Upgrade do PostGIS 2 para o PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)
## Etapa 1: Criar um usuário (função) para gerenciar a extensão PostGIS
Primeiro, conecte-se a uma instância de banco de dados do RDS para PostgreSQL como um usuário que tem privilégios `rds_superuser`. Se você manteve o nome padrão ao configurar a instância, se conectará como `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Crie um perfil separado (usuário) para administrar a extensão PostGIS.
```
postgres=> CREATE ROLE gis_admin LOGIN PASSWORD 'change_me';
CREATE ROLE
```
Conceda a esse perfil privilégios `rds_superuser` para permitir que ele instale a extensão.
```
postgres=> GRANT rds_superuser TO gis_admin;
GRANT
```
Crie um banco de dados a ser usado para seus artefatos PostGIS. Esta etapa é opcional. Como alternativa, você pode criar um esquema em seu banco de dados de usuário para as extensões PostGIS, mas isso também não é necessário.
```
postgres=> CREATE DATABASE lab_gis;
CREATE DATABASE
```
Conceda a `gis_admin` todos os privilégios no banco de dados `lab_gis`.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_gis TO gis_admin;
GRANT
```
Saia da sessão e reconecte-se a uma instância de banco de dados do RDS para PostgreSQL como `gis_admin`.
```
postgres=> psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=gis_admin --password --dbname=lab_gis
Password for user gis_admin:...
lab_gis=>
```
Continue a configurar a extensão conforme detalhado nas próximas etapas.
## Etapa 2: Carregar as extensões PostGIS
A extensão PostGIS inclui várias extensões relacionadas que funcionam juntas para fornecer funcionalidade geoespacial. Dependendo do seu caso de uso, talvez você não precise de todas as extensões criadas nesta etapa.
Use instruções `CREATE EXTENSION` para carregar as extensões PostGIS.
```
CREATE EXTENSION postgis;
CREATE EXTENSION
CREATE EXTENSION postgis_raster;
CREATE EXTENSION
CREATE EXTENSION fuzzystrmatch;
CREATE EXTENSION
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION
CREATE EXTENSION postgis_topology;
CREATE EXTENSION
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION
```
É possível verificar os resultados executando a consulta SQL mostrada no exemplo a seguir, que lista as extensões e seus proprietários.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+-----------
public | postgres
tiger | rdsadmin
tiger_data | rdsadmin
topology | rdsadmin
(4 rows)
```
## Etapa 3: Transferir a propriedade dos esquemas de extensão
Use as instruções ALTER SCHEMA para transferir a propriedade dos esquemas à função `gis_admin`.
```
ALTER SCHEMA tiger OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA tiger_data OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA topology OWNER TO gis_admin;
ALTER SCHEMA
```
Se você quiser confirmar a alteração de propriedade, realize a consulta SQL a seguir. Ou é possível usar o metacomando `\dn` na linha de comando do psql.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+---------------
public | postgres
tiger | gis_admin
tiger_data | gis_admin
topology | gis_admin
(4 rows)
```
## Etapa 4: Transferir a propriedade dos objetos PostGIS
**nota**
Não altere a propriedade das funções do PostGIS. A operação adequada e as futuras atualizações do PostGIS exigem que essas funções retenham a propriedade original. Para ter mais informações sobre permissões do PostGIS, consulte [Segurança do PostgreSQL](https://postgis.net/workshops/postgis-intro/security.html).
Use a seguinte função para transferir a propriedade das tabelas do PostGIS ao perfil `gis_admin`. Execute a seguinte instrução no prompt psql para criar a função.
```
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
CREATE FUNCTION
```
Depois, execute a consulta a seguir para executar a função `exec` que, por sua vez, executa as instruções e altera as permissões.
```
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO gis_admin;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
```
## Etapa 5: Testar as extensões
Para evitar a necessidade de especificar o nome do esquema, adicione o esquema `tiger` ao seu caminho de pesquisa usando o seguinte comando.
```
SET search_path=public,tiger;
SET
```
Teste o esquema `tiger` usando a seguinte instrução SELECT.
```
SELECT address, streetname, streettypeabbrev, zip
FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
address | streetname | streettypeabbrev | zip
---------+------------+------------------+-------
1 | Devonshire | Pl | 02109
(1 row)
```
Para saber mais sobre essa extensão, consulte [Geocodificador Tiger](https://postgis.net/docs/Extras.html#Tiger_Geocoder) na documentação do PostGIS.
Teste o acesso ao esquema `topology` usando a seguinte instrução `SELECT`. Isso chama a função `createtopology` para registrar um novo objeto de topologia (my\$1new\$1topo) com o identificador de referência espacial especificado (26986) e a tolerância padrão (0,5). Para saber mais, consulte [CreateTopology](https://postgis.net/docs/CreateTopology.html) na documentação do PostGIS.
```
SELECT topology.createtopology('my_new_topo',26986,0.5);
createtopology
----------------
1
(1 row)
```
## Etapa 6: Atualize a extensão PostGIS
Cada nova versão do PostgreSQL oferece suporte a uma ou mais versões da extensão PostGIS compatíveis com essa versão. A atualização do mecanismo PostgreSQL para uma nova versão não atualiza automaticamente a extensão PostGIS. Antes de atualizar o mecanismo PostgreSQL, faça upgrade do PostGIS para a versão mais recente disponível para a versão atual do PostgreSQL. Para obter detalhes, consulte [Versões de extensão PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS).
Após a atualização do mecanismo PostgreSQL, faça upgrade da extensão PostGIS novamente, desta vez para a versão compatível com a versão recém-atualizada do mecanismo PostgreSQL. Para obter mais informações sobre como fazer upgrade do mecanismo PostgreSQL, consulte [Como atualizar a versão principal do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Você pode verificar as atualizações de versão da extensão PostGIS disponíveis na sua instância de banco de dados do RDS para PostgreSQL a qualquer momento. Para fazer isso, execute o comando a seguir. Esta função está disponível com PostGIS 2.5.0 e versões posteriores.
```
SELECT postGIS_extensions_upgrade();
```
Se a sua aplicação não oferecer suporte à versão mais recente do PostGIS, você poderá instalar uma versão mais antiga do PostGIS que esteja disponível na sua versão principal conforme o exposto a seguir.
```
CREATE EXTENSION postgis VERSION "2.5.5";
```
Se quiser fazer upgrade para uma versão específica do PostGIS usando uma versão mais antiga, também poderá usar o comando a seguir.
```
ALTER EXTENSION postgis UPDATE TO "2.5.5";
```
Dependendo de sua versão atual antes do upgrade, talvez você precise usar essa função novamente. O resultado da primeira execução da função determina a necessidade de uma função de atualização adicional. Por exemplo, isso acontece em caso de upgrade do PostGIS 2 para o PostGIS 3. Para obter mais informações, consulte [Upgrade do PostGIS 2 para o PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3).
Se você atualizou essa extensão para se preparar para uma atualização da versão principal do mecanismo PostgreSQL, poderá continuar com outras tarefas preliminares. Para obter mais informações, consulte [Como atualizar a versão principal do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
## Versões de extensão PostGIS
Recomendamos que você instale as versões de todas as extensões, como PostGIS, conforme listado em [“Extension versions for Amazon RDS para PostgreSQL”](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) (Versões de extensões para o Amazon RDS para PostgreSQL) nas *Notas de lançamento do Amazon RDS para PostgreSQL.* Você pode conferir quais versões estão disponíveis na sua versão usando o comando a seguir.
```
SELECT * FROM pg_available_extension_versions WHERE name='postgis';
```
Informações sobre versões estão disponíveis nas seções a seguir das *Notas de lançamento do Amazon RDS para PostgreSQL*:
+ [ Extensões do PostgreSQL versão 16 compatíveis com o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-16x)
+ [ Extensões do PostgreSQL versão 15 compatíveis com o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-15x)
+ [ Extensões do PostgreSQL versão 14 compatíveis com o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-14x)
+ [ Extensões do PostgreSQL versão 13 compatíveis com o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-13x)
+ [ Extensões do PostgreSQL versão 12 compatíveis com o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-12x)
+ [ Extensões do PostgreSQL versão 11 compatíveis com o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-11x)
+ [ Extensões do PostgreSQL versão 10 compatíveis com o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-101x)
+ [ Extensões do PostgreSQL versão 9.6.x compatíveis com o Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-96x)
## Upgrade do PostGIS 2 para o PostGIS 3
A partir da versão 3.0, a funcionalidade de rasterização do PostGIS é uma extensão separada, `postgis_raster`. Essa extensão tem seu próprio caminho de instalação e upgrade. Isso remove dezenas de funções, tipos de dados e outros artefatos necessários para o processamento de imagens rasterizadas da extensão `postgis` principal. Isso significa que, se o seu caso de uso não exigir processamento de rasterização, você não precisará instalar a extensão `postgis_raster`.
No exemplo de upgrade a seguir, o primeiro comando de upgrade extrai a funcionalidade de rasterização na extensão `postgis_raster`. Um segundo comando de upgrade é necessário para atualizar `postgis_raster` para a nova versão.
**Como fazer upgrade do PostGIS 2 para o PostGIS 3**
1. Identifique a versão padrão do PostGIS que está disponível para a versão do PostgreSQL em seu Instância de banco de dados do RDS para PostgreSQL. Para fazer isso, execute a consulta a seguir.
```
SELECT * FROM pg_available_extensions
WHERE default_version > installed_version;
name | default_version | installed_version | comment
---------+-----------------+-------------------+------------------------------------------------------------
postgis | 3.1.4 | 2.3.7 | PostGIS geometry and geography spatial types and functions
(1 row)
```
1. Identifique as versões do PostGIS instaladas em cada banco de dados na sua instância de banco de dados do RDS para PostgreSQL. Em outras palavras, consulte cada banco de dados do usuário da seguinte forma.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
---------+---------+--------+---------------------------------------------------------------------
postgis | 2.3.7 | public | PostGIS geometry, geography, and raster spatial types and functions
(1 row)
```
Essa divergência entre a versão padrão (PostGIS 3.1.4) e a versão instalada (PostGIS 2.3.7) significa que você precisa atualizar a extensão PostGIS.
```
ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION
WARNING: unpackaging raster
WARNING: PostGIS Raster functionality has been unpackaged
```
1. Execute a consulta a seguir para verificar se a funcionalidade de rasterização já está em seu próprio pacote.
```
SELECT
probin,
count(*)
FROM
pg_proc
WHERE
probin LIKE '%postgis%'
GROUP BY
probin;
probin | count
--------------------------+-------
$libdir/rtpostgis-2.3 | 107
$libdir/postgis-3 | 487
(2 rows)
```
O resultado mostra que ainda há uma diferença entre as versões. As funções do PostGIS são da versão 3 (postgis-3), enquanto as funções de rasterização (rtpostgis) são da versão 2 (rtpostgis-2.3). Para concluir a atualização, execute o comando de upgrade novamente, da seguinte forma.
```
postgres=> SELECT postgis_extensions_upgrade();
```
Você pode ignorar as mensagens de aviso. Execute a consulta a seguir novamente para verificar se a atualização foi concluída. A atualização é concluída quando o PostGIS e todas as extensões relacionadas deixam de estar sinalizadas como necessitando de atualização.
```
SELECT postgis_full_version();
```
1. Use a consulta a seguir para ver o processo de atualização concluído e as extensões empacotadas separadamente, e verifique se as versões correspondem.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
----------------+---------+--------+---------------------------------------------------------------------
postgis | 3.1.5 | public | PostGIS geometry, geography, and raster spatial types and functions
postgis_raster | 3.1.5 | public | PostGIS raster types and functions
(2 rows)
```
A saída mostra que a extensão PostGIS 2 foi atualizada para PostGIS 3, e tanto `postgis` quanto a extensão `postgis_raster` agora separada estão na versão 3.1.5.
Depois que essa atualização for concluída, se você não planejar usar a funcionalidade de rasterização, poderá descartar a extensão da seguinte forma.
```
DROP EXTENSION postgis_raster;
```
# Trabalhar com os invólucros de dados externos compatíveis do Amazon RDS for PostgreSQL
Um Foreign Data Wraper (FDW – Empacotador de dados externos) é um tipo específico de extensão que fornece acesso a dados externos. Por exemplo, a extensão `oracle_fdw` permite que o cluster de banco de dados do RDS for PostgreSQL funcione com bancos de dados Oracle. Citando outro exemplo, se você usar a extensão `postgres_fdw` nativa do PostgreSQL, poderá acessar dados armazenados em instâncias de banco de dados do PostgreSQL externas à instância de banco de dados do RDS for PostgreSQL.
A seguir, você encontrará informações sobre vários invólucros de dados externos do PostgreSQL compatíveis.
**Topics**
+ [
# Usar a extensão log\$1fdw para acessar o log de banco de dados usando SQL
](CHAP_PostgreSQL.Extensions.log_fdw.md)
+ [
# Usar a extensão postgres\$1fdw para acessar dados externos
](postgresql-commondbatasks-fdw.md)
+ [
# Trabalhar com bancos de dados MySQL usando a extensão mysql\$1fdw
](postgresql-mysql-fdw.md)
+ [
# Trabalhar com um banco de dados Oracle usando a extensão oracle\$1fdw
](postgresql-oracle-fdw.md)
+ [
# Trabalhar com bancos de dados do SQL Server usando a extensão tds\$1fdw
](postgresql-tds-fdw.md)
# Usar a extensão log\$1fdw para acessar o log de banco de dados usando SQL
A instância de banco de dados do RDS para PostgreSQL é compatível com a extensão `log_fdw`, que permite acessar o log do mecanismo de banco de dados usando uma interface SQL. A extensão `log_fdw` apresenta duas novas funções que facilitam a criação de tabelas externas para logs de banco de dados:
+ `list_postgres_log_files` – lista os arquivos no diretório do log do banco de dados e o tamanho do arquivo em bytes.
+ `create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text)` – cria uma tabela externa para o arquivo especificado no banco de dados atual.
Todas as funções criadas por `log_fdw` são de propriedade do `rds_superuser`. Os membros da função `rds_superuser` podem conceder acesso a essas funções para outros usuários do banco de dados.
Por padrão, os arquivos de log são gerados pelo Amazon RDS no formato (erro padrão) `stderr`, conforme especificado no parâmetro `log_destination`. Existem apenas duas opções para esse parâmetro, `stderr` e `csvlog` (valores separados por vírgula, CSV). Se você adicionar a opção `csvlog` ao parâmetro, o Amazon RDS gerará os logs `stderr` e `csvlog`. Isso pode afetar a capacidade de armazenamento em seu cluster de banco de dados. Portanto, você precisa estar ciente dos outros parâmetros que afetam o processamento de logs. Para obter mais informações, consulte [Definir o destino dos logs (`stderr`, `csvlog`)](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md#USER_LogAccess.Concepts.PostgreSQL.Log_Format).
Um benefício de gerar logs do `csvlog` é que a extensão `log_fdw` permite criar tabelas externas com dados divididos ordenadamente em várias colunas. Para fazer isso, sua instância precisa estar associada a um grupo de parâmetros de banco de dados personalizado para que você possa alterar a configuração para `log_destination`. Para obter mais informações sobre como fazer isso, consulte [Trabalhar com parâmetros na instância de banco de dados do RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
O exemplo a seguir pressupõe que o parâmetro `log_destination` inclua `cvslog`.
**Para usar a extensão log\$1fdw**
1. Instale a extensão `log_fdw`.
```
postgres=> CREATE EXTENSION log_fdw;
CREATE EXTENSION
```
1. Crie o servidor de log como um wrapper externo de dados.
```
postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;
CREATE SERVER
```
1. Selecione todos os arquivos de log na lista.
```
postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;
```
A seguir você encontra um exemplo de resposta.
```
file_name | file_size_bytes
------------------------------+-----------------
postgresql.log.2023-08-09-22.csv | 1111
postgresql.log.2023-08-09-23.csv | 1172
postgresql.log.2023-08-10-00.csv | 1744
postgresql.log.2023-08-10-01.csv | 1102
(4 rows)
```
1. Crie uma tabela com uma única coluna "log\$1entry" para o arquivo selecionado.
```
postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log',
'log_server', 'postgresql.log.2023-08-09-22.csv');
```
A resposta não fornece nenhum detalhe além de que a tabela agora existe.
```
-----------------------------------
(1 row)
```
1. Selecione um exemplo de arquivo de log. O código a seguir recupera o horário do log e a descrição da mensagem de erro.
```
postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;
```
A seguir você encontra um exemplo de resposta.
```
log_time | message
----------------------------------+---------------------------------------------------------------------------
Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr
Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC
Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0
Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE
Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578
Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0
Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1
(7 rows)
```
# Usar a extensão postgres\$1fdw para acessar dados externos
Você pode acessar dados em uma tabela em um servidor de banco de dados remoto com a extensão [postgres\$1fdw](https://www.postgresql.org/docs/current/static/postgres-fdw.html). Se você configurar uma conexão remota usando a instância de banco de dados do PostgreSQL, o acesso também estará disponível para a réplica de leitura.
**Para usar postgres\$1fdw para acessar um servidor de banco de dados remoto**
1. Instale a extensão postgres\$1fdw.
```
CREATE EXTENSION postgres_fdw;
```
1. Crie um servidor de dados externo usando CREATE SERVER.
```
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'xxx.xx.xxx.xx', port '5432', dbname 'foreign_db');
```
1. Crie um mapeamento de usuário para identificar a função a ser usada no servidor remoto.
**Importante**
Para ocultar a senha a fim de que ela não apareça nos logs, defina `log_statement=none` no nível da sessão. A configuração no nível do parâmetro não oculta a senha.
```
CREATE USER MAPPING FOR local_user
SERVER foreign_server
OPTIONS (user 'foreign_user', password 'password');
```
1. Crie uma tabela que mapeia para a tabela no servidor remoto.
```
CREATE FOREIGN TABLE foreign_table (
id integer NOT NULL,
data text)
SERVER foreign_server
OPTIONS (schema_name 'some_schema', table_name 'some_table');
```
# Trabalhar com bancos de dados MySQL usando a extensão mysql\$1fdw
Para acessar um banco de dados compatível com MySQL pela instância de banco de dados RDS para PostgreSQL, você pode instalar e usar a extensão `mysql_fdw`. Esse invólucro de dados externos permite que você trabalhe com o RDS for MySQL, o Aurora MySQL, o MariaDB e outros bancos de dados compatíveis com MySQL. A conexão da instância de bancos de dados do RDS para PostgreSQL ao banco de dados MySQL é criptografada com base no melhor esforço, dependendo das configurações do cliente e do servidor. No entanto, você pode impor a criptografia, se quiser. Para obter mais informações, consulte [Usar criptografia em trânsito com a extensão](#postgresql-mysql-fdw.encryption-in-transit).
A extensão `mysql_fdw` é compatível com o Amazon RDS para PostgreSQL versão 14.2, 13.6 e posteriores. Ela é compatível com seleções, inserções, atualizações e exclusões de um banco de dados do RDS for PostgreSQL para tabelas em uma instância de banco de dados compatível com MySQL.
**Topics**
+ [
## Configurar um banco de dados RDS para PostgreSQL para usar a extensão mysql\$1fdw
](#postgresql-mysql-fdw.setting-up)
+ [
## Exemplo: trabalhar com um banco de dados do RDS para MySQL pelo RDS para PostgreSQL
](#postgresql-mysql-fdw.using-mysql_fdw)
+ [
## Usar criptografia em trânsito com a extensão
](#postgresql-mysql-fdw.encryption-in-transit)
## Configurar um banco de dados RDS para PostgreSQL para usar a extensão mysql\$1fdw
Para configurar a extensão `mysql_fdw` na instância de banco de dados do RDS para PostgreSQL, é necessário carregar a extensão na instância de banco de dados e, em seguida, criar o ponto de conexão com a instância de banco de dados do MySQL. Para essa tarefa, você precisa ter os seguintes detalhes sobre a instância de banco de dados do MySQL:
+ Nome de host ou endpoint. Para uma instância de banco de dados do RDS para MySQL, é possível encontrar o endpoint usando o console. Escolha a guia “Connectivity & security” (Conectividade e segurança) e procure na seção “Endpoint and port” (Endpoint e porta).
+ Número da porta. O número da porta padrão do MySQL é 3306.
+ O nome do banco de dados. O identificador do banco de dados.
Você também precisa fornecer acesso no grupo de segurança ou na lista de controle de acesso (ACL) para a porta 3306 do MySQL. Tanto o cluster de MySQL precisam acessar a porta 3306. Se o acesso não estiver configurado corretamente, ao tentar se conectar à tabela compatível com o MySQL, será exibida uma mensagem de erro semelhante à seguinte:
```
ERROR: failed to connect to MySQL: Can't connect to MySQL server on 'hostname.aws-region.rds.amazonaws.com:3306' (110)
```
No procedimento a seguir, você (como a conta `rds_superuser`) cria o servidor externo. Depois, você concede acesso ao servidor externo a usuários específicos. Em seguida, esses usuários criam seus próprios mapeamentos para as contas de usuário apropriadas do MySQL para trabalhar com a instância de banco de dados do MySQL.
**Para usar mysql\$1fdw a fim de acessar um servidor de banco de dados MySQL**
1. Conecte-se à instância de banco de dados do PostgreSQL usando uma conta que tenha a função `rds_superuser`. Se tiver aceitado os padrões ao criar a instância de banco de dados do RDS para PostgreSQL, o nome de usuário será `postgres` e você poderá se conectar usando a ferramenta da linha de comando `psql` da seguinte forma:
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres –-password
```
1. Instale a extensão `mysql_fdw` da seguinte forma:
```
postgres=> CREATE EXTENSION mysql_fdw;
CREATE EXTENSION
```
Depois que a extensão é instalada na instância de banco de dados do RDS para PostgreSQL, é possível configurar o servidor externo que fornece a conexão com um banco de dados MySQL.
**Para criar o servidor externo**
Execute essas tarefas na instância de banco de dados do RDS para PostgreSQL. As etapas presumem que você esteja conectado como usuário com privilégios `rds_superuser`, como `postgres`.
1. Crie um servidor externo na instância de banco de dados do RDS para PostgreSQL:
```
postgres=> CREATE SERVER mysql-db FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'db-name.111122223333.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Conceda aos usuários apropriados acesso ao servidor externo. Eles devem ser usuários não administradores, ou seja, usuários sem a função `rds_superuser`.
```
postgres=> GRANT USAGE ON FOREIGN SERVER mysql-db to user1;
GRANT
```
Os usuários do PostgreSQL criam e gerenciam suas próprias conexões com o banco de dados do MySQL por meio do servidor externo.
## Exemplo: trabalhar com um banco de dados do RDS para MySQL pelo RDS para PostgreSQL
Suponha que você tenha uma tabela simples em uma instância de banco de dados do RDS para PostgreSQL. Os usuários do RDS para PostgreSQL querem consultar os itens `SELECT`, `INSERT`, `UPDATE` e `DELETE` nessa tabela. Suponha que a extensão `mysql_fdw` foi criada na instância de banco de dados do RDS for PostgreSQL, conforme detalhado no procedimento anterior. Depois de se conectar à instância de banco de dados do RDS for PostgreSQL como um usuário com privilégios `rds_superuser`, é possível prosseguir com as etapas abaixo.
1. Crie um servidor externo na instância de banco de dados do RDS para PostgreSQL:
```
test=> CREATE SERVER mysqldb FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'your-DB.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Conceda uso a um usuário que não tenha permissões `rds_superuser`; por exemplo, `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER mysqldb TO user1;
GRANT
```
1. Conecte-se como *user1* e, em seguida, crie um mapeamento para o usuário do MySQL:
```
test=> CREATE USER MAPPING FOR user1 SERVER mysqldb OPTIONS (username 'myuser', password 'mypassword');
CREATE USER MAPPING
```
1. Crie uma tabela externa vinculada a uma tabela do MySQL:
```
test=> CREATE FOREIGN TABLE mytab (a int, b text) SERVER mysqldb OPTIONS (dbname 'test', table_name '');
CREATE FOREIGN TABLE
```
1. Execute uma consulta simples na tabela externa:
```
test=> SELECT * FROM mytab;
a | b
---+-------
1 | apple
(1 row)
```
1. Você pode adicionar, alterar e remover dados da tabela do MySQL. Por exemplo:
```
test=> INSERT INTO mytab values (2, 'mango');
INSERT 0 1
```
Execute a consulta `SELECT` novamente para ver os resultados:
```
test=> SELECT * FROM mytab ORDER BY 1;
a | b
---+-------
1 | apple
2 | mango
(2 rows)
```
## Usar criptografia em trânsito com a extensão
A conexão com o MySQL pelo RDS para PostgreSQL usa criptografia em trânsito (TLS/SSL) por padrão. No entanto, a conexão volta para não criptografada quando a configuração do cliente e do servidor é diferente. Você pode impor a criptografia para todas as conexões de saída especificando a opção `REQUIRE SSL` nas contas de usuário do RDS for MySQL. Essa mesma abordagem também funciona para contas de usuário do MariaDB e do Aurora MySQL.
Para contas de usuário do MySQL configuradas como `REQUIRE SSL`, a tentativa de conexão falhará se não for possível estabelecer uma conexão segura.
Para aplicar criptografia a contas de usuário do banco de dados do MySQL existentes, você pode usar o comando `ALTER USER`. A sintaxe varia, dependendo da versão do MySQL, conforme mostrado na tabela a seguir. Para obter mais informações, consulte [ALTER USER](https://dev.mysql.com/doc/refman/8.0/en/alter-user.html) no *Manual de referência do MySQL*.
| MySQL 5.7, MySQL 8.0 | MySQL 5.6 |
| --- | --- |
| `ALTER USER 'user'@'%' REQUIRE SSL;` | `GRANT USAGE ON *.* to 'user'@'%' REQUIRE SSL;` |
Para obter mais informações sobre a extensão `mysql_fdw`, consulte a documentação do [mysql\$1fdw](https://github.com/EnterpriseDB/mysql_fdw).
# Trabalhar com um banco de dados Oracle usando a extensão oracle\$1fdw
Para acessar um banco de dados Oracle pela instância de banco de dados do RDS for PostgreSQL, você pode instalar e usar a extensão `oracle_fdw`. Essa extensão é um invólucro de dados externos para bancos de dados Oracle. Para saber mais sobre a extensão, consulte a documentação do [oracle\$1fdw](https://github.com/laurenz/oracle_fdw).
A extensão `oracle_fdw` é compatível com o RDS for PostgreSQL 12.7, 13.3 e versões posteriores.
**Topics**
+ [
## Ativação da extensão oracle\$1fdw
](#postgresql-oracle-fdw.enabling)
+ [
## Exemplo: usar um servidor externo vinculado a um banco de dados Amazon RDS for Oracle
](#postgresql-oracle-fdw.example)
+ [
## Como trabalhar com criptografia em trânsito
](#postgresql-oracle-fdw.encryption)
+ [
## Noções básicas da visualização e das permissões de pg\$1user\$1mappings
](#postgresql-oracle-fdw.permissions)
## Ativação da extensão oracle\$1fdw
Para usar a extensão oracle\$1fdw, realize o procedimento a seguir.
**Para ativar a extensão oracle\$1fdw**
+ Execute o comando a seguir usando uma conta que tenha as permissões de `rds_superuser`.
```
CREATE EXTENSION oracle_fdw;
```
## Exemplo: usar um servidor externo vinculado a um banco de dados Amazon RDS for Oracle
O exemplo a seguir mostra o uso de um servidor externo vinculado a um banco de dados Amazon RDS for Oracle.
**Para criar um servidor externo vinculado a um banco de dados do RDS for Oracle**
1. Na instância de banco de dados do RDS for Oracle, observe:
+ Endpoint
+ Port
+ Database name
1. Crie um servidor externo.
```
test=> CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//endpoint:port/DB_name');
CREATE SERVER
```
1. Conceda uso a um usuário que não tenha privilégios `rds_superuser`, por exemplo `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
```
1. Conecte-se como `user1` e crie um mapeamento para um usuário Oracle.
```
test=> CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user 'oracleuser', password 'mypassword');
CREATE USER MAPPING
```
1. Crie uma tabela estrangeira vinculada a uma tabela Oracle.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER oradb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Consulte a tabela externa.
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
Se a consulta relatar o seguinte erro, verifique seu grupo de segurança e a lista de controle de acesso (ACL) para verificar se as duas instâncias podem se comunicar.
```
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
```
## Como trabalhar com criptografia em trânsito
A criptografia PostgreSQL-to-Oracle em trânsito é baseada em uma combinação de parâmetros de configuração de cliente e servidor. Para obter um exemplo usando o Oracle 21c, consulte [About the Values for Negotiating Encryption and Integrity](https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-network-data-encryption-and-integrity.html#GUID-3A2AF4AA-AE3E-446B-8F64-31C48F27A2B5) (Sobre os valores para negociar criptografia e integridade) na documentação do Oracle. Como o cliente usado para oracle\$1fdw no Amazon RDS está configurado com `ACCEPTED`, a criptografia depende da configuração do servidor de banco de dados do Oracle e utiliza a Oracle Security Library (libnnz) para isso.
Se o banco de dados estiver no RDS for Oracle, consulte [Criptografia de rede nativa do Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.NetworkEncryption.html) para configurar a criptografia.
## Noções básicas da visualização e das permissões de pg\$1user\$1mappings
O catálogo PostgreSQL `pg_user_mapping` armazena o mapeamento de um usuário do RDS for PostgreSQL para o usuário em um servidor de dados externo (remoto). O acesso ao catálogo é restrito, mas você usa a visualização `pg_user_mappings` para ver os mapeamentos. Veja a seguir um exemplo que mostra como as permissões se aplicam a um banco de dados Oracle de exemplo, mas essas informações se aplicam de forma mais geral a qualquer wrapper de dados externo.
Na saída a seguir, você pode encontrar funções e permissões mapeadas para três usuários de exemplo diferentes. Usuários eo `rdssu1` e `rdssu2` são membros da função `rds_superuser`, e `user1` não é. O exemplo usa o metacomando `\du` do `psql` para listar as funções existentes.
```
test=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+-------------------------------------------------------------
rdssu1 | | {rds_superuser}
rdssu2 | | {rds_superuser}
user1 | | {}
```
Todos os usuários, incluindo aqueles com privilégios `rds_superuser`, têm permissão para visualizar seus próprios mapeamentos de usuário (`umoptions`) na tabela `pg_user_mappings`. Como mostrado no exemplo a seguir, quando `rdssu1` tenta obter todos os mapeamentos do usuário, é gerado um erro, mesmo com privilégios `rdssu1``rds_superuser`:
```
test=> SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
```
Veja a seguir alguns exemplos:
```
test=> SET SESSION AUTHORIZATION rdssu1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd}
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
test=> SET SESSION AUTHORIZATION rdssu2;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd}
(3 rows)
test=> SET SESSION AUTHORIZATION user1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+--------------------------------
16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd}
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
```
Devido às diferenças na implementação de `information_schema._pg_user_mappings` e `pg_catalog.pg_user_mappings`, um `rds_superuser` criado manualmente requer outras permissões para visualizar senhas no `pg_catalog.pg_user_mappings`.
Nenhuma permissão adicional é necessária para um `rds_superuser` visualizar senhas no `information_schema._pg_user_mappings`.
Usuários que não tenham a função `rds_superuser` poderão visualizar senhas em `pg_user_mappings` somente nas seguintes condições:
+ O usuário atual é o usuário que está sendo mapeado e é proprietário do servidor ou mantém o privilégio `USAGE` sobre ele.
+ O usuário atual é o proprietário do servidor, e o mapeamento é para `PUBLIC`.
# Trabalhar com bancos de dados do SQL Server usando a extensão tds\$1fdw
Você pode usar a extensão `tds_fdw` do PostgreSQL para acessar bancos de dados compatíveis com o protocolo de fluxo de dados tabular (TDS), como bancos de dados do Sybase e do Microsoft SQL Server. Esse invólucro de dados externos permite que você se conecte pela instância de banco de dados do RDS for PostgreSQL a bancos de dados que usam o protocolo TDS, incluindo o Amazon RDS for Microsoft SQL Server. Para obter mais informações, consulte a documentação do [tds-fdw/tds\$1fdw](https://github.com/tds-fdw/tds_fdw) no GitHub.
A extensão `tds_fdw` é compatível com o Amazon RDS for PostgreSQL versões 14.2, 13.6 e posteriores.
## Configurar o banco de dados do RDS for PostgreSQL para usar a extensão tds\$1fdw
Nos procedimentos a seguir, você pode encontrar um exemplo de configuração e uso de `tds_fdw` com uma instância de banco de dados do RDS for PostgreSQL. Antes de se conectar a um banco de dados do SQL Server usando `tds_fdw`, é necessário obter os seguintes detalhes da instância:
+ Nome de host ou endpoint. Para uma instância de banco de dados do RDS for SQL Server, você pode encontrar o endpoint usando o console. Escolha a guia “Connectivity & security” (Conectividade e segurança) e procure na seção “Endpoint and port” (Endpoint e porta).
+ Número da porta. O número da porta padrão para o Microsoft SQL Server é 1433.
+ O nome do banco de dados. O identificador do banco de dados.
Você também precisa fornecer acesso no grupo de segurança ou na lista de controle de acesso (ACL) para a porta 1433 do SQL Server. Tanto a instância de banco de dados do RDS for PostgreSQL como a instância de banco de dados do RDS for SQL Server precisam de acesso à porta 1433. Se o acesso não estiver configurado corretamente, ao tentar consultar o Microsoft SQL Server, será exibida a seguinte mensagem de erro:
```
ERROR: DB-Library error: DB #: 20009, DB Msg: Unable to connect:
Adaptive Server is unavailable or does not exist (mssql2019.aws-region.rds.amazonaws.com), OS #: 0, OS Msg: Success, Level: 9
```
**Para usar tds\$1fdw a fim de se conectar a um banco de dados do SQL Server**
1. Conecte-se à instância de banco de dados do PostgreSQL usando uma conta que tenha a função `rds_superuser`:
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=test –-password
```
1. Instale a extensão `tds_fdw`:
```
test=> CREATE EXTENSION tds_fdw;
CREATE EXTENSION
```
Depois que a extensão for instalada na instância de banco de dados do RDS for PostgreSQL, configure o servidor externo.
**Para criar o servidor externo**
Execute essas tarefas na instância de banco de dados do RDS for PostgreSQL usando uma conta com privilégios `rds_superuser`.
1. Crie um servidor externo na instância de banco de dados do RDS para PostgreSQL:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing');
CREATE SERVER
```
Para acessar dados não ASCII do lado do SQLServer, crie um link de servidor com a opção character\$1set na instância de banco de dados do RDS para PostgreSQL:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing', character_set 'UTF-8');
CREATE SERVER
```
1. Conceda uso a um usuário que não tenha permissões da função `rds_superuser`; por exemplo, `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER sqlserverdb TO user1;
```
1. Conecte-se como user1 e, em seguida, crie um mapeamento para um usuário do SQL Server:
```
test=> CREATE USER MAPPING FOR user1 SERVER sqlserverdb OPTIONS (username 'sqlserveruser', password 'password');
CREATE USER MAPPING
```
1. Crie uma tabela externa vinculada a uma tabela do SQL Server:
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER sqlserverdb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Consulte a tabela externa:
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
### Usar criptografia em trânsito para a conexão
A conexão do RDS for PostgreSQL com o SQL Server usa criptografia em trânsito (TLS/SSL), dependendo da configuração do banco de dados do SQL Server. Se o SQL Server não estiver configurado para criptografia, o cliente do RDS for PostgreSQL que faz a solicitação ao banco de dados do SQL Server retornará ao estado de não criptografado.
Você pode aplicar a criptografia para a conexão com instâncias de banco de dados do RDS for SQL Server definindo o parâmetro `rds.force_ssl`. Para saber como, consulte [Forçar conexões com a instância de banco de dados para usar SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html#SQLServer.Concepts.General.SSL.Forcing). Para obter mais informações sobre a configuração de SSL/TLS para o RDS for SQL Server, consulte [Usar SSL com uma instância de banco de dados do Microsoft SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html).
# Trabalhar com Trusted Language Extensions para PostgreSQL
O Trusted Language Extensions para PostgreSQL é um kit de desenvolvimento de código aberto para criar extensões do PostgreSQL. Ele permite que você crie extensões do PostgreSQL de alta performance e as execute com segurança em sua instância de banco de dados do RDS para PostgreSQL. Ao usar o Trusted Language Extensions (TLE) para PostgreSQL, você pode criar extensões do PostgreSQL que sigam a abordagem documentada para estender a funcionalidade do PostgreSQL. Para obter mais informações, consulte [Packaging Related Objects into an Extension](https://www.postgresql.org/docs/current/extend-extensions.html) (Compactar objetos relacionados em uma extensão) na documentação do PostgreSQL.
Um dos principais benefícios do TLE é que você pode usá-lo em ambientes que não fornecem acesso ao sistema de arquivos subjacente à instância do PostgreSQL. Anteriormente, a instalação de uma nova extensão exigia acesso ao sistema de arquivos. O TLE remove essa restrição. Ele fornece um ambiente de desenvolvimento para criar extensões para qualquer banco de dados do PostgreSQL, como as executadas em suas instâncias de banco de dados do RDS para PostgreSQL.
O TLE foi projetado para impedir o acesso a recursos inseguros para as extensões criadas com o uso do TLE. Seu ambiente de execução limita o impacto de qualquer defeito de extensão em uma única conexão de banco de dados. O TLE também oferece aos administradores de banco de dados um controle refinado sobre quem pode instalar extensões e fornece um modelo de permissões para executá-las.
O TLE é compatível com as seguintes versões do RDS para PostgreSQL:
+ Versão 18.1 e versões 18 posteriores
+ Versão 17.1 e versões 17 posteriores
+ Versão 16.1 e versões 16 posteriores
+ Versão 15.2 e versões 15 posteriores
+ Versão 14.5 e versões 14 posteriores
+ Versão 13.12 e versões 13 posteriores
O ambiente de desenvolvimento e de execução do Trusted Language Extensions são empacotados como a extensão `pg_tle` do PostgreSQL, versão 1.0.1. É compatível com a criação de extensões em JavaScript, Perl, Tcl, PL/pgSQL e SQL. Você instala a extensão `pg_tle` em sua instância de banco de dados do RDS para PostgreSQL da mesma forma que instala outras extensões do PostgreSQL. Depois de configurar `pg_tle`, os desenvolvedores podem usá-lo para criar extensões do PostgreSQL, conhecidas como *extensões TLE*.
Nos tópicos a seguir, você encontrará informações sobre como configurar Trusted Language Extensions e como começar a criar suas próprias extensões TLE.
**Topics**
+ [
# Terminologia
](PostgreSQL_trusted_language_extension-terminology.md)
+ [
# Requisitos para usar Trusted Language Extensions para PostgreSQL
](PostgreSQL_trusted_language_extension-requirements.md)
+ [
# Configurar o Trusted Language Extensions em sua instância de banco de dados do RDS para PostgreSQL
](PostgreSQL_trusted_language_extension-setting-up.md)
+ [
# Visão geral do Trusted Language Extensions para PostgreSQL
](PostgreSQL_trusted_language_extension.overview.md)
+ [
# Criar extensões TLE para RDS para PostgreSQL
](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md)
+ [
# Descartar suas extensões TLE de um banco de dados
](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md)
+ [
# Desinstalar o Trusted Language Extensions para PostgreSQL
](PostgreSQL_trusted_language_extension-uninstalling-pg_tle-devkit.md)
+ [
# Usar ganchos do PostgreSQL com suas extensões TLE
](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md)
+ [
# Usar tipos de dados personalizados no TLE
](PostgreSQL_trusted_language_extension-custom-data-type.md)
+ [
# Referência de funções para Trusted Language Extensions para PostgreSQL
](PostgreSQL_trusted_language_extension-functions-reference.md)
+ [
# Referência de ganchos para Trusted Language Extensions para PostgreSQL
](PostgreSQL_trusted_language_extension-hooks-reference.md)
# Terminologia
Para ajudar você a entender melhor o Trusted Language Extensions, consulte o glossário a seguir para conhecer os termos usados neste tópico.
**Trusted Language Extensions para PostgreSQL**
*Trusted Language Extensions para PostgreSQL* é o nome oficial do kit de desenvolvimento de código aberto que vem com a extensão `pg_tle`. Ele está disponível para uso em qualquer sistema PostgreSQL. Para obter mais informações, consulte [aws/pg\$1tle](https://github.com/aws/pg_tle) no GitHub.
**Trusted Language Extensions**
*Trusted Language Extensions* é o nome abreviado de Trusted Language Extensions para PostgreSQL. Esse nome curto e sua abreviatura (TLE) também são utilizados nesta documentação.
**linguagem confiável**
Uma *linguagem confiável* é uma linguagem de programação ou script que tem atributos de segurança específicos. Por exemplo, as linguagens confiáveis geralmente restringem o acesso ao sistema de arquivos e limitam o uso de propriedades de rede especificadas. O kit de desenvolvimento TLE foi projetado para oferecer suporte a linguagens confiáveis. O PostgreSQL é compatível com várias linguagens diferentes que são usadas para criar extensões confiáveis ou não confiáveis. Por exemplo, consulte [Trusted and Untrusted PL/Perl](https://www.postgresql.org/docs/current/plperl-trusted.html) (PL/Perl confiável e não confiável) na documentação do PostgreSQL. Quando você cria uma extensão com o uso de Trusted Language Extensions, a extensão usa inerentemente mecanismos de linguagem confiáveis.
**Extensão TLE**
Uma *extensão TLE* é uma extensão do PostgreSQL criada com o uso do kit de desenvolvimento Trusted Language Extensions (TLE).
# Requisitos para usar Trusted Language Extensions para PostgreSQL
A seguir são apresentados os requisitos para configurar e usar o kit de desenvolvimento TLE.
+ ** Versões do RDS para PostgreSQL**: o Trusted Language Extensions só é compatível com o RDS para PostgreSQL versões 13.12 e versões 13 posteriores, 14.5 e versões 14 posteriores e 15.2 e versões posteriores.
+ Se você precisar atualizar sua instância do RDS para PostgreSQL, consulte [Atualizações do mecanismo de banco de dados do RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md).
+ Se você ainda não tem uma instância de banco de dados do Amazon RDS que execute o PostgreSQL, você pode criar uma. Para ter mais informações, consulte Instância de banco de dados do RDS para PostgreSQL, consulte [Criar uma instância de banco de dados PostgreSQL e conectar-se a ela](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md).
+ **Requer privilégios `rds_superuser`**: para instalar e configurar a extensão `pg_tle`, sua função de usuário do banco de dados deve ter as permissões da função `rds_superuser`. Por padrão, essa função é concedida ao usuário `postgres` que cria o Instância de banco de dados do RDS para PostgreSQL.
+ **Requer um grupo de parâmetros de banco de dados personalizado**: sua instância de banco de dados do RDS para PostgreSQL deve ser configurada com um grupo de parâmetros de banco de dados personalizado.
+ Se sua instância do RDS para PostgreSQL não estiver configurada com um grupo de parâmetros de banco de dados personalizado, você deverá criar um e associá-lo à sua instância de banco de dados do RDS para PostgreSQL. Para obter um breve resumo das etapas, consulte [Criar e aplicar um grupo de parâmetros de banco de dados personalizado](#PostgreSQL_trusted_language_extension-requirements-create-custom-params).
+ Se sua instância de banco de dados do RDS para PostgreSQL já estiver configurada usando um grupo de parâmetros de banco de dados, você poderá configurar o Trusted Language Extensions. Para obter detalhes, consulte [Configurar o Trusted Language Extensions em sua instância de banco de dados do RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
## Criar e aplicar um grupo de parâmetros de banco de dados personalizado
Use as etapas a seguir para criar um grupo de parâmetros de banco de dados personalizado e configurar sua instância de banco de dados do RDS para PostgreSQL para usá-lo.
### Console
**Como criar um grupo de parâmetros de banco de dados personalizado e usá-lo com a instância de banco de dados do RDS para PostgreSQL**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Selecione Parameter groups (Grupos de parâmetros) no menu do Amazon RDS
1. Escolha **Criar grupo de parâmetros**.
1. Na página **Parameter group details** (Detalhes do grupo de parâmetros), insira as informações a seguir.
+ Em **Parameter group family** (Família de grupos de parâmetros), selecione postgres14.
+ Em **Type** (Tipo), selecione DB Parameter Group (Grupo de parâmetros de banco de dados).
+ Em **Group name** (Nome do grupo), forneça ao seu grupo de parâmetros um nome significativo no contexto de suas operações.
+ Em **Description** (Descrição), insira uma descrição útil para que outras pessoas de sua equipe possam encontrá-lo facilmente.
1. Escolha **Criar**. Seu grupo de parâmetros de banco de dados personalizado é criado em sua Região da AWS. Agora você pode modificar sua instância do RDS para PostgreSQL para usá-la seguindo as próximas etapas.
1. Selecione **Databases** (Bancos de dados) no menu do Amazon RDS.
1. Selecione a instância de banco de dados do RDS para PostgreSQL que você deseja usar com o TLE dentre as opções listadas e, depois, selecione **Modify** (Modificar).
1. Na Na página Modify DB instance settings (Modificar configurações da instância de banco de dados), encontre **Database options** (Opções de banco de dados) na seção Additional configuration (Configuração adicional) e selecione seu grupo de parâmetros de banco de dados personalizado no seletor.
1. Selecione **Continue** (Continuar) para salvar a alteração.
1. Selecione **Apply immediately** (Aplicar imediatamente) para que você possa continuar configurando da instância de banco de dados do RDS para PostgreSQL para usar o TLE.
Para continuar configurando seu sistema para Trusted Language Extensions, consulte [Configurar o Trusted Language Extensions em sua instância de banco de dados do RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
Para obter mais informações sobre como trabalhar com Grupos de parâmetros do banco de dados, consulte [Grupos de parâmetros de banco de dados para instâncias de banco de dados do Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
### AWS CLI
Você pode evitar especificar o argumento `--region` ao usar comandos da CLI configurando sua AWS CLI com sua Região da AWS padrão. Para obter mais informações, consulte [Conceitos básicos de configuração da ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) no *Guia do usuário do AWS Command Line Interface*.
**Como criar um grupo de parâmetros de banco de dados personalizado e usá-lo com a instância de banco de dados do RDS para PostgreSQL**
1. Use o comando [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) da AWS CLI para criar um grupo de parâmetros de banco de dados personalizado com base em postgres14 para sua Região da AWS.
Para Linux, macOS ou Unix:
```
aws rds create-db-parameter-group \
--region aws-region \
--db-parameter-group-name custom-params-for-pg-tle \
--db-parameter-group-family postgres14 \
--description "My custom DB parameter group for Trusted Language Extensions"
```
Para Windows:
```
aws rds create-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name custom-params-for-pg-tle ^
--db-parameter-group-family postgres14 ^
--description "My custom DB parameter group for Trusted Language Extensions"
```
Seu grupo de parâmetros de banco de dados personalizado está disponível em sua Região da AWS, para que você possa modificar a instância de banco de dados do RDS para PostgreSQL para usá-lo.
1. Use o comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) da AWS CLI para aplicar seu grupo de parâmetros de banco de dados personalizado à instância de banco de dados do RDS para PostgreSQL. Esse comando reinicia imediatamente a instância ativa.
Para Linux, macOS ou Unix:
```
aws rds modify-db-instance \
--region aws-region \
--db-instance-identifier your-instance-name \
--db-parameter-group-name custom-params-for-pg-tle \
--apply-immediately
```
Para Windows:
```
aws rds modify-db-instance ^
--region aws-region ^
--db-instance-identifier your-instance-name ^
--db-parameter-group-name custom-params-for-pg-tle ^
--apply-immediately
```
Para continuar configurando seu sistema para Trusted Language Extensions, consulte [Configurar o Trusted Language Extensions em sua instância de banco de dados do RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
Para ter mais informações, consulte [Grupos de parâmetros para Amazon RDS](USER_WorkingWithParamGroups.md).
# Configurar o Trusted Language Extensions em sua instância de banco de dados do RDS para PostgreSQL
As etapas a seguir pressupõem que sua instância de banco de dados do RDS para PostgreSQL esteja associada a um grupo de parâmetros de banco de dados. Você pode usar o Console de gerenciamento da AWS ou a AWS CLI para essas etapas.
Ao configurar o Trusted Language Extensions em sua instância de banco de dados do RDS para PostgreSQL, você o instala em um banco de dados específico para uso pelos usuários do banco de dados que têm permissões nesse banco de dados.
## Console
**Como configurar o Trusted Language Extensions**
Execute as etapas a seguir usando uma conta que seja membro do grupo `rds_superuser` (função).
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, selecione sua instância de banco de dados do RDS para PostgreSQL.
1. Abra a guia **Configuration** (Configuração) para sua Instância de banco de dados do RDS para PostgreSQL. Entre os detalhes da instância, encontre o link **Parameter group** (Grupo de parâmetros).
1. Clique no link para abrir os parâmetros personalizados associados ao seu Instância de banco de dados do RDS para PostgreSQL.
1. No campo **Parameters** (Parâmetros), digite `shared_pre` para encontrar o parâmetro `shared_preload_libraries`.
1. Selecione **Edit parameters** (Editar parâmetros) para acessar os valores das propriedades.
1. Adicione `pg_tle` à lista no campo **Values** (Valores). Use uma vírgula para separar itens na lista de valores.
![\[Imagem do parâmetro shared_preload_libraries com pg_tle adicionado.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pg_tle.png)
1. Reinicie a instância de banco de dados do RDS para PostgreSQL para que a alteração no parâmetro `shared_preload_libraries` tenha efeito.
1. Quando a instância estiver disponível, verifique se `pg_tle` foi inicializado. Use `psql` para se conectar à instância de banco de dados do RDS para PostgreSQL e depois execute o comando a seguir.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
1. Com a extensão `pg_tle` inicializada, agora você pode criar a extensão.
```
CREATE EXTENSION pg_tle;
```
Para verificar se a extensão está instalada, você pode usar o metacomando `psql` a seguir.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
```
1. Conceda a função `pgtle_admin` ao nome de usuário principal que você criou para sua instância de banco de dados do RDS para PostgreSQL ao configurá-la. Se você aceitou o padrão, é `postgres`.
```
labdb=> GRANT pgtle_admin TO postgres;
GRANT ROLE
```
É possível verificar se a concessão ocorreu usando o metacomando `psql` conforme mostrado no exemplo a seguir. Somente as funções `pgtle_admin` e `postgres` são mostradas na saída. Para ter mais informações, consulte [Noções básicas sobre o perfil rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
```
labdb=> \du
List of roles
Role name | Attributes | Member of
-----------------+---------------------------------+-----------------------------------
pgtle_admin | Cannot login | {}
postgres | Create role, Create DB +| {rds_superuser,pgtle_admin}
| Password valid until infinity |...
```
1. Feche a sessão `psql` usando o metacomando `\q`.
```
\q
```
Para começar a criar extensões TLE, consulte [Exemplo: Criar uma extensão de linguagem confiável usando SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
## AWS CLI
Você pode evitar especificar o argumento `--region` ao usar comandos da CLI configurando sua AWS CLI com sua Região da AWS padrão. Para obter mais informações, consulte [Conceitos básicos de configuração da ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) no *Guia do usuário do AWS Command Line Interface*.
**Como configurar o Trusted Language Extensions**
1. Utilize o comando [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI para adicionar `pg_tle` ao parâmetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pg_tle,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilize o comando [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) da AWS CLI para reinicializar a instância de banco de dados do RDS para PostgreSQL e inicialize a biblioteca `pg_tle`.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Quando a instância estiver disponível, verifique se a `pg_tle` foi inicializada. Use `psql` para se conectar à instância de banco de dados do RDS para PostgreSQL e, depois, execute o comando a seguir.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
Com `pg_tle` inicializado, agora você pode criar a extensão.
```
CREATE EXTENSION pg_tle;
```
1. Conceda a função `pgtle_admin` ao nome de usuário principal que você criou para sua instância de banco de dados do RDS para PostgreSQL ao configurá-la. Se você aceitou o padrão, é `postgres`.
```
GRANT pgtle_admin TO postgres;
GRANT ROLE
```
1. Feche a sessão `psql` da forma a seguir.
```
labdb=> \q
```
Para começar a criar extensões TLE, consulte [Exemplo: Criar uma extensão de linguagem confiável usando SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
# Visão geral do Trusted Language Extensions para PostgreSQL
O Trusted Language Extensions para PostgreSQL é uma extensão do PostgreSQL que você instala em sua instância de banco de dados do RDS para PostgreSQL da mesma forma que configura outras extensões do PostgreSQL. Na imagem a seguir de um exemplo de banco de dados na ferramenta cliente pgAdmin, você pode ver alguns dos componentes que compõem a extensão `pg_tle`.
![\[Imagem mostrando alguns dos componentes que compõem o kit de desenvolvimento TLE.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/apg-pg_tle-installed-view-in-pgAdmin.png)
É possível ver os detalhes a seguir.
1. O kit de desenvolvimento Trusted Language Extensions para PostgreSQL é embalado como a extensão `pg_tle`. Assim, o `pg_tle` é adicionado às extensões disponíveis para o banco de dados no qual está instalado.
1. O TLE tem seu próprio esquema, `pgtle`. Esse esquema contém funções auxiliares (3) para instalar e gerenciar as extensões criadas.
1. O TLE fornece mais de uma dúzia de funções auxiliares para instalar, registrar e gerenciar suas extensões. Para saber mais sobre essas funções, consulte [Referência de funções para Trusted Language Extensions para PostgreSQL](PostgreSQL_trusted_language_extension-functions-reference.md).
São outros componentes da extensão `pg_tle`:
+ **A função `pgtle_admin`**: a função `pgtle_admin` é criada quando a extensão `pg_tle` é instalada. Essa função é privilegiada e deve ser tratada como tal. É altamente recomendável seguir o princípio de *privilégio mínimo* ao conceder a função `pgtle_admin` a usuários de banco de dados. Em outras palavras, conceda a função `pgtle_admin` somente aos usuários do banco de dados que tenham permissão para criar, instalar e gerenciar novas extensões TLE, como `postgres`.
+ **A tabela `pgtle.feature_info`**: `pgtle.feature_info` é uma tabela protegida que contém informações sobre seus TLEs, ganchos e as funções e os procedimentos armazenados personalizados utilizados. Se você tiver privilégios `pgtle_admin`, use as funções de Trusted Language Extensions a seguir para adicionar e atualizar essas informações na tabela.
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
# Criar extensões TLE para RDS para PostgreSQL
Você pode instalar qualquer extensão criada com o TLE em qualquer instância de banco de dados do RDS para PostgreSQL que tenha a extensão `pg_tle` instalada. A extensão `pg_tle` tem como escopo o banco de dados PostgreSQL no qual ela está instalada. As extensões que você cria usando o TLE têm como escopo o mesmo banco de dados.
Use as várias funções `pgtle` para instalar o código que compõe sua extensão TLE. As funções do Trusted Language Extensions a seguir exigem a função `pgtle_admin`.
+ [pgtle.install\$1extension](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path)
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension (nome)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension (nome, versão)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
## Exemplo: Criar uma extensão de linguagem confiável usando SQL
O exemplo a seguir mostra como criar uma extensão TLE chamada `pg_distance` que contém algumas funções SQL para calcular distâncias usando fórmulas diferentes. Na lista, você pode encontrar a função para calcular a distância de Manhattan e a função para calcular a distância euclidiana. Para obter mais informações sobre a diferença entre essas fórmulas, consulte [Geometria taxicab](https://en.wikipedia.org/wiki/Taxicab_geometry) [Geometria euclidiana](https://en.wikipedia.org/wiki/Euclidean_geometry) na Wikipedia.
Você poderá usar esse exemplo em sua própria instância de banco de dados do RDS para PostgreSQL se tiver a extensão `pg_tle` configurada conforme detalhado em [Configurar o Trusted Language Extensions em sua instância de banco de dados do RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
**nota**
Você precisa ter os privilégios da função `pgtle_admin` para seguir esse procedimento.
**Como criar o exemplo de extensão TLE**
As etapas a seguir usam um exemplo de banco de dados chamado `labdb`. Esse banco de dados é de propriedade do usuário primário `postgres`. A função `postgres` também tem as permissões da função `pgtle_admin`.
1. Use o `psql` para se conectar à Instância de banco de dados do RDS para PostgreSQL.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Crie uma extensão TLE denominada `pg_distance` copiando o código a seguir e colando-o no console da sessão `psql`.
```
SELECT pgtle.install_extension
(
'pg_distance',
'0.1',
'Distance functions for two points',
$_pg_tle_$
CREATE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL;
CREATE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL;
CREATE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL;
$_pg_tle_$
);
```
Você verá a saída da forma a seguir.
```
install_extension
---------------
t
(1 row)
```
Os artefatos que compõem a extensão `pg_distance` agora estão instalados em seu banco de dados. Esses artefatos incluem o arquivo de controle e o código da extensão, que são itens que precisam estar presentes para que a extensão possa ser criada usando o comando `CREATE EXTENSION`. Em outras palavras, você ainda precisa criar a extensão para disponibilizar suas funções aos usuários do banco de dados.
1. Para criar a extensão, use o comando `CREATE EXTENSION` como você faz com qualquer outra extensão. Assim como acontece com outras extensões, o usuário do banco de dados precisa ter as permissões `CREATE` no banco de dados.
```
CREATE EXTENSION pg_distance;
```
1. Para testar a extensão TLE `pg_distance`, você pode usá-la para calcular a [distância de Manhattan](https://en.wikipedia.org/wiki/Taxicab_geometry) entre quatro pontos.
```
labdb=> SELECT manhattan_dist(1, 1, 5, 5);
8
```
Para calcular a [distância euclidiana](https://en.wikipedia.org/wiki/Euclidean_geometry) entre o mesmo conjunto de pontos, você pode usar o seguinte.
```
labdb=> SELECT euclidean_dist(1, 1, 5, 5);
5.656854249492381
```
A extensão `pg_distance` carrega as funções no banco de dados e as disponibiliza para qualquer usuário com permissões no banco de dados.
## Modificar a extensão TLE
Para melhorar a performance da consulta para as funções empacotadas nessa extensão TLE, adicione os dois atributos do PostgreSQL a seguir às suas especificações.
+ `IMMUTABLE`: o atributo `IMMUTABLE` garante que o otimizador de consultas possa usar otimizações para melhorar os tempos de resposta da consulta. Para obter mais informações, consulte [Function Volatility Categories](https://www.postgresql.org/docs/current/xfunc-volatility.html) (Categorias de volatilidade de funções) na documentação do PostgreSQL.
+ `PARALLEL SAFE`: o atributo `PARALLEL SAFE` é outro atributo que permite que o PostgreSQL execute a função no modo paralelo. Para obter mais informações, consulte [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) na documentação do PostgreSQL.
No exemplo a seguir, você pode ver como a função `pgtle.install_update_path` é usada para adicionar esses atributos a cada função para criar uma versão `0.2` da extensão TLE `pg_distance`. Para ter mais informações sobre essa função, consulte [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path). Você precisa ter a função `pgtle_admin` para realizar essa tarefa.
**Como atualizar uma extensão TLE existente e especificar a versão padrão**
1. Conecte-se à instância de banco de dados do RDS para PostgreSQL usando `psql` ou outra ferramenta de cliente, como o pgAdmin
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Modifique a extensão TLE existente copiando o código a seguir e colando-o no console da sessão `psql`.
```
SELECT pgtle.install_update_path
(
'pg_distance',
'0.1',
'0.2',
$_pg_tle_$
CREATE OR REPLACE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
$_pg_tle_$
);
```
Você verá uma resposta semelhante ao seguinte.
```
install_update_path
---------------------
t
(1 row)
```
Você pode tornar essa versão da extensão a versão padrão, para que os usuários do banco de dados não precisem especificar uma versão ao criar ou atualizar a extensão em seu banco de dados.
1. Para especificar que a versão modificada (versão 0.2) de sua extensão TLE é a versão padrão, use a função `pgtle.set_default_version` conforme mostrado no exemplo a seguir.
```
SELECT pgtle.set_default_version('pg_distance', '0.2');
```
Para ter mais informações sobre essa função, consulte [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version).
1. Com o código implementado, você pode atualizar a extensão TLE instalada da maneira usual, utilizando o comando `ALTER EXTENSION ... UPDATE`, conforme mostrado aqui:
```
ALTER EXTENSION pg_distance UPDATE;
```
# Descartar suas extensões TLE de um banco de dados
Você pode descartar suas extensões TLE usando o comando `DROP EXTENSION` da mesma forma que faz com outras extensões do PostgreSQL. Descartar a extensão não remove os arquivos de instalação que a compõem, o que permite aos usuários recriar a extensão. Para remover a extensão e seus arquivos de instalação, execute o processo de duas etapas a seguir.
**Como descartar a extensão TLE e remover seus arquivos de instalação**
1. Use `psql` ou outra ferramenta de cliente para se conectar à instância de banco de dados do RDS para PostgreSQL.
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Descarte a extensão como você faria com qualquer extensão do PostgreSQL.
```
DROP EXTENSION your-TLE-extension
```
Por exemplo, se você criar a extensão `pg_distance` conforme detalhado em [Exemplo: Criar uma extensão de linguagem confiável usando SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example), poderá descartar a extensão da forma a seguir.
```
DROP EXTENSION pg_distance;
```
Você vê uma saída confirmando que a extensão foi descartada da forma a seguir.
```
DROP EXTENSION
```
Neste ponto, a extensão não estará mais ativa no banco de dados. No entanto, seus arquivos de instalação e arquivo de controle ainda estão disponíveis no banco de dados, portanto, os usuários do banco de dados poderão criar a extensão novamente, se desejarem.
+ Se quiser deixar os arquivos de extensão intactos para que os usuários do banco de dados possam criar sua extensão TLE, você pode parar neste ponto.
+ Se quiser remover todos os arquivos que compõem a extensão, siga para a próxima etapa.
1. Para remover todos os arquivos de instalação da sua extensão, use a função `pgtle.uninstall_extension`. Essa função remove todos os arquivos de código e controle de sua extensão.
```
SELECT pgtle.uninstall_extension('your-tle-extension-name');
```
Por exemplo, para remover todos os arquivos de instalação `pg_distance`, use o comando a seguir.
```
SELECT pgtle.uninstall_extension('pg_distance');
uninstall_extension
---------------------
t
(1 row)
```
# Desinstalar o Trusted Language Extensions para PostgreSQL
Se você não quiser mais criar suas próprias extensões TLE usando o TLE, poderá descartar a extensão `pg_tle` e remover todos os artefatos. Essa ação inclui descartar todas as extensões TLE no banco de dados e o esquema `pgtle`.
**Como descartar a extensão `pg_tle` e seu esquema de um banco de dados**
1. Use `psql` ou outra ferramenta de cliente para se conectar à instância de banco de dados do RDS para PostgreSQL.
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Descarte a extensão `pg_tle` do banco de dados. Se o banco de dados tiver suas próprias extensões TLE ainda em execução no banco de dados, você também precisará descartar essas extensões. Para isso, você pode usar a palavra-chave `CASCADE`, conforme mostrado a seguir.
```
DROP EXTENSION pg_tle CASCADE;
```
Se a extensão `pg_tle` ainda não estiver ativa no banco de dados, você não precisará usar a palavra-chave `CASCADE`.
1. Descarte o esquema `pgtle`. Essa ação remove todas as funções de gerenciamento do banco de dados.
```
DROP SCHEMA pgtle CASCADE;
```
O comando retornará o seguinte quando o processo for concluído.
```
DROP SCHEMA
```
A extensão `pg_tle`, seu esquema e funções e todos os artefatos são removidos. Para criar extensões usando o TLE, execute o processo de configuração novamente. Para ter mais informações, consulte [Configurar o Trusted Language Extensions em sua instância de banco de dados do RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
# Usar ganchos do PostgreSQL com suas extensões TLE
Um *gancho* é um mecanismo de retorno de chamada disponível no PostgreSQL que possibilita aos desenvolvedores chamar funções personalizadas ou outras rotinas durante operações regulares de banco de dados. O kit de desenvolvimento TLE é compatível com ganchos do PostgreSQL para que você possa integrar funções personalizadas com o comportamento do PostgreSQL no ambiente de execução. Por exemplo, você pode usar um gancho para associar o processo de autenticação ao seu próprio código personalizado ou modificar o processo de planejamento e execução de consultas de acordo com suas necessidades específicas.
Suas extensões TLE podem usar ganchos. Se um gancho tiver escopo global, ele se aplicará a todos os bancos de dados. Portanto, se sua extensão TLE usar um gancho global, você precisará criar sua extensão TLE em todos os bancos de dados que seus usuários puderem acessar.
Ao usar a extensão `pg_tle` para criar seu próprio Trusted Language Extensions, você pode usar os ganchos disponíveis de uma API SQL para criar as funções de sua extensão. Você deve registrar todos os ganchos com `pg_tle`. Para alguns ganchos, talvez você também precise definir vários parâmetros de configuração. Por exemplo, o gancho de verificação `passcode` pode ser configurado como ativado, desativado ou obrigatório. Para obter mais informações sobre os requisitos específicos dos ganchos `pg_tle` disponíveis, consulte [Referência de ganchos para Trusted Language Extensions para PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md).
## Exemplo: Criar uma extensão que use um gancho do PostgreSQL
O exemplo abordado nesta seção usa um gancho do PostgreSQL para conferir a senha fornecida durante operações específicas de SQL e impede que os usuários do banco de dados definam suas senhas como qualquer uma das contidas na tabela `password_check.bad_passwords`. A tabela contém as dez opções de senhas mais usadas, mas facilmente identificáveis.
Para configurar esse exemplo em sua instância de banco de dados do RDS para PostgreSQL, você já deve ter instalado o Trusted Language Extensions. Para obter detalhes, consulte [Configurar o Trusted Language Extensions em sua instância de banco de dados do RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
**Como configurar o exemplo de gancho de verificação de senha**
1. Use o `psql` para se conectar à Instância de banco de dados do RDS para PostgreSQL.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Copie o código do [Lista de códigos do gancho de verificação de senha](#PostgreSQL_trusted_language_extension-example-hook_code_listing) e cole-o no banco de dados.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
Quando a extensão for carregada em seu banco de dados, você verá uma saída como a seguinte.
```
install_extension
-------------------
t
(1 row)
```
1. Enquanto ainda estiver conectado ao banco de dados, agora você poderá criar a extensão.
```
CREATE EXTENSION my_password_check_rules;
```
1. Você pode confirmar que a extensão foi criada no banco de dados usando o metacomando `psql` a seguir.
```
\dx
List of installed extensions
Name | Version | Schema | Description
-------------------------+---------+------------+-------------------------------------------------------------
my_password_check_rules | 1.0 | public | Prevent use of any of the top-ten most common bad passwords
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
1. Abra outra sessão do terminal para trabalhar com o AWS CLI. Você precisa modificar seu grupo de parâmetros de banco de dados personalizado para ativar o gancho de verificação de senha. Para isso, use o comando [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) da CLI, conforme mostrado no exemplo a seguir.
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Quando o parâmetro é ativado com êxito, você vê uma saída como a seguinte.
```
(
"DBParameterGroupName": "docs-lab-parameters-for-tle"
}
```
Poderá levar alguns minutos para que a alteração na configuração do grupo de parâmetros tenha efeito. No entanto, esse parâmetro é dinâmico, portanto, você não precisa reiniciar a instância de banco de dados do RDS para PostgreSQL para que a configuração tenha efeito.
1. Abra a sessão `psql` e consulte o banco de dados para verificar se o gancho password\$1check foi ativado.
```
labdb=> SHOW pgtle.enable_password_check;
pgtle.enable_password_check
-----------------------------
on
(1 row)
```
O gancho de verificação de senha agora está ativo. É possível testá-lo criando uma função e usando uma das senhas incorretas, conforme mostrado no exemplo a seguir.
```
CREATE ROLE test_role PASSWORD 'password';
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 21 at RAISE
SQL statement "SELECT password_check.passcheck_hook(
$1::pg_catalog.text,
$2::pg_catalog.text,
$3::pgtle.password_types,
$4::pg_catalog.timestamptz,
$5::pg_catalog.bool)"
```
A saída foi formatada para facilitar a leitura.
O exemplo a seguir mostra que o comportamento do metacomando interativo `pgsql` `\password` também é afetado pelo gancho password\$1check.
```
postgres=> SET password_encryption TO 'md5';
SET
postgres=> \password
Enter new password for user "postgres":*****
Enter it again:*****
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 12 at RAISE
SQL statement "SELECT password_check.passcheck_hook($1::pg_catalog.text, $2::pg_catalog.text, $3::pgtle.password_types, $4::pg_catalog.timestamptz, $5::pg_catalog.bool)"
```
Você poderá descartar essa extensão TLE e desinstalar seus arquivos de origem, se desejar. Para obter mais informações, consulte [Descartar suas extensões TLE de um banco de dadosDescartar suas extensões TLE de um banco de dados](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md).
### Lista de códigos do gancho de verificação de senha
O código de exemplo mostrado aqui define a especificação da extensão TLE `my_password_check_rules`. Quando você copia esse código e o cola em seu banco de dados, o código da extensão `my_password_check_rules` é carregado no banco de dados e o gancho `password_check` é registrado para uso pela extensão.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
# Usar tipos de dados personalizados no TLE
O PostgreSQL comporta comandos para registrar novos tipos básicos (também conhecidos como tipos escalares) para lidar de forma eficiente com estruturas de dados complexas no banco de dados. Um tipo básico permite que você personalize como os dados são armazenados internamente e como convertê-los de e em uma representação textual externa. Esses tipos de dados personalizados são úteis ao estender o PostgreSQL para comportar domínios funcionais em que um tipo integrado, como número ou texto, não pode fornecer semântica de pesquisa suficiente.
O RDS para PostgreSQL permite que você crie tipos de dados personalizados em sua extensão de linguagem confiável e defina funções que comportem operações de SQL e indexação para esses novos tipos de dados. Os tipos de dados estão disponíveis para as seguintes versões:
+ RDS para PostgreSQL 15.7 e as versões 15 posteriores
+ RDS para PostgreSQL 14.9 e versões 14 posteriores
+ RDS para PostgreSQL 13.2 e versões 13 posteriores
Para obter mais informações, consulte [Tipos de Trusted Language Base](https://github.com/aws/pg_tle/blob/main/docs/09_datatypes.md).
# Referência de funções para Trusted Language Extensions para PostgreSQL
Veja a documentação de referência a seguir sobre as funções disponíveis em Trusted Language Extensions para PostgreSQL. Use essas funções para instalar, registrar, atualizar e gerenciar suas *extensões TLE*, ou seja, as extensões do PostgreSQL que você desenvolve usando o kit de desenvolvimento Trusted Language Extensions.
**Topics**
+ [
## pgtle.available\$1extensions
](#pgtle.available_extensions)
+ [
## pgtle.available\$1extension\$1versions
](#pgtle.available_extension_versions)
+ [
## pgtle.extension\$1update\$1paths
](#pgtle.extension_update_paths)
+ [
## pgtle.install\$1extension
](#pgtle.install_extension)
+ [
## pgtle.install\$1update\$1path
](#pgtle.install_update_path)
+ [
## pgtle.register\$1feature
](#pgtle.register_feature)
+ [
## pgtle.register\$1feature\$1if\$1not\$1exists
](#pgtle.register_feature_if_not_exists)
+ [
## pgtle.set\$1default\$1version
](#pgtle.set_default_version)
+ [
## pgtle.uninstall\$1extension (nome)
](#pgtle.uninstall_extension-name)
+ [
## pgtle.uninstall\$1extension (nome, versão)
](#pgtle.uninstall_extension-name-version)
+ [
## pgtle.uninstall\$1extension\$1if\$1exists
](#pgtle.uninstall_extension_if_exists)
+ [
## pgtle.uninstall\$1update\$1path
](#pgtle.uninstall_update_path)
+ [
## pgtle.uninstall\$1update\$1path\$1if\$1exists
](#pgtle.uninstall_update_path_if_exists)
+ [
## pgtle.unregister\$1feature
](#pgtle.unregister_feature)
+ [
## pgtle.unregister\$1feature\$1if\$1exists
](#pgtle.unregister_feature_if_exists)
## pgtle.available\$1extensions
A função `pgtle.available_extensions` é uma função de retorno de conjunto. Ela retorna todas as extensões TLE disponíveis no banco de dados. Cada linha retornada contém informações sobre uma única extensão TLE.
### Protótipo de função
```
pgtle.available_extensions()
```
### Função
Nenhum.
### Argumentos
Nenhum.
### Saída
+ `name`: o nome da extensão TLE.
+ `default_version`: a versão da extensão TLE a ser usada quando `CREATE EXTENSION` é chamada sem uma versão especificada.
+ `description`: uma descrição mais detalhada sobre a extensão TLE.
### Exemplo de uso
```
SELECT * FROM pgtle.available_extensions();
```
## pgtle.available\$1extension\$1versions
A função `available_extension_versions` é de retorno de conjunto. Ela retorna uma lista de todas as extensões TLE disponíveis e suas versões. Cada linha contém informações sobre uma versão específica de determinada extensão TLE, incluindo se ela requer uma função específica.
### Protótipo de função
```
pgtle.available_extension_versions()
```
### Função
Nenhum.
### Argumentos
Nenhum.
### Saída
+ `name`: o nome da extensão TLE.
+ `version`: a versão da extensão TLE.
+ `superuser`: esse valor é sempre `false` para suas extensões TLE. As permissões necessárias para criar a extensão TLE ou atualizá-la são as mesmas para criar outros objetos em determinado banco de dados.
+ `trusted`: esse valor é sempre `false` para uma extensão TLE.
+ `relocatable`: esse valor é sempre `false` para uma extensão TLE.
+ `schema`: especifica o nome do esquema no qual a extensão TLE está instalada.
+ `requires`: uma matriz contendo os nomes de outras extensões necessárias para essa extensão TLE.
+ `description`: uma descrição detalhada da extensão TLE.
Para obter mais informações sobre valores de saída, consulte [Packaging Related Objects into an Extension > Extension Files](https://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) (Compactação de objetos relacionados em uma extensão > arquivos de extensão) na documentação do PostgreSQL.
### Exemplo de uso
```
SELECT * FROM pgtle.available_extension_versions();
```
## pgtle.extension\$1update\$1paths
A função `extension_update_paths` é de retorno de conjunto. Ela retorna uma lista de todos os caminhos de atualização possíveis para uma extensão TLE. Cada linha inclui as atualizações ou downgrades disponíveis para essa extensão TLE.
### Protótipo de função
```
pgtle.extension_update_paths(name)
```
### Função
Nenhum.
### Argumentos
`name`: o nome da extensão TLE da qual obter caminhos de atualização.
### Saída
+ `source`: a versão de origem de uma atualização.
+ `target`: a versão de destino de uma atualização.
+ `path`: o caminho de atualização usado para atualizar uma extensão TLE da versão `source` para a `target`, por exemplo, `0.1--0.2`.
### Exemplo de uso
```
SELECT * FROM pgtle.extension_update_paths('your-TLE');
```
## pgtle.install\$1extension
A função `install_extension` permite que você instale os artefatos que compõem sua extensão TLE no banco de dados, após o qual ela pode ser criada usando o comando `CREATE EXTENSION`.
### Protótipo de função
```
pgtle.install_extension(name text, version text, description text, ext text, requires text[] DEFAULT NULL::text[])
```
### Função
Nenhum.
### Argumentos
+ `name`: o nome da extensão TLE. Esse valor é usado ao chamar`CREATE EXTENSION`.
+ `version`: a versão da extensão TLE.
+ `description`: uma descrição detalhada da extensão TLE. Essa descrição é exibida no campo `comment` em `pgtle.available_extensions()`.
+ `ext`: o conteúdo da extensão TLE. Esse valor contém objetos, como funções.
+ `requires`: um parâmetro opcional que especifica dependências para essa extensão TLE. A extensão `pg_tle` é adicionada automaticamente como uma dependência.
Muitos desses argumentos são iguais aos incluídos em um arquivo de controle de extensão para instalar uma extensão do PostgreSQL no sistema de arquivos de uma instância do PostgreSQL. Para obter mais informações, consulte [Extension Files](http://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) (Arquivos de extensão) em [Packaging Related Objects into an Extension](https://www.postgresql.org/docs/current/extend-extensions.html) (Compactação de objetos relacionados em uma extensão) na documentação do PostgreSQL.
### Saída
Essa função retorna `OK` em caso de sucesso e `NULL` em caso de erro.
+ `OK`: a extensão TLE foi instalada com êxito no banco de dados.
+ `NULL`: a extensão TLE não foi instalada com êxito no banco de dados.
### Exemplo de uso
```
SELECT pgtle.install_extension(
'pg_tle_test',
'0.1',
'My first pg_tle extension',
$_pgtle_$
CREATE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 42;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.install\$1update\$1path
A função `install_update_path` fornece um caminho de atualização entre duas versões diferentes de uma extensão TLE. Essa função permite que os usuários de sua extensão TLE atualizem sua versão usando a sintaxe `ALTER EXTENSION ... UPDATE`.
### Protótipo de função
```
pgtle.install_update_path(name text, fromvers text, tovers text, ext text)
```
### Função
`pgtle_admin`
### Argumentos
+ `name`: o nome da extensão TLE. Esse valor é usado ao chamar`CREATE EXTENSION`.
+ `fromvers`: a versão de origem da extensão TLE para a atualização.
+ `tovers`: a versão de destino da extensão TLE para a atualização.
+ `ext`: o conteúdo da atualização. Esse valor contém objetos, como funções.
### Saída
Nenhum.
### Exemplo de uso
```
SELECT pgtle.install_update_path('pg_tle_test', '0.1', '0.2',
$_pgtle_$
CREATE OR REPLACE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 21;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.register\$1feature
A função `register_feature` adiciona o recurso interno especificado do PostgreSQL à tabela `pgtle.feature_info`. Os ganchos do PostgreSQL são um exemplo de um recurso interno do PostgreSQL. O kit de desenvolvimento Trusted Language Extensions é compatível com o uso de ganchos do PostgreSQL. Atualmente, essa função é compatível com o recurso a seguir.
+ `passcheck`: registra o gancho de verificação de senha com seu procedimento ou função que personaliza o comportamento de verificação de senha do PostgreSQL.
### Protótipo de função
```
pgtle.register_feature(proc regproc, feature pg_tle_feature)
```
### Função
`pgtle_admin`
### Argumentos
+ `proc`: o nome de uma função ou um procedimento armazenado a ser usado para o recurso.
+ `feature`: o nome do recurso `pg_tle` (como`passcheck`) a ser registrado na função.
### Saída
Nenhum.
### Exemplo de uso
```
SELECT pgtle.register_feature('pw_hook', 'passcheck');
```
## pgtle.register\$1feature\$1if\$1not\$1exists
A função `pgtle.register_feature_if_not_exists` adiciona o recurso do PostgreSQL especificado à tabela `pgtle.feature_info` e identifica a extensão TLE ou outro procedimento ou função que usa o recurso. Para obter mais informações sobre ganchos e Trusted Language Extensions, consulte[Usar ganchos do PostgreSQL com suas extensões TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md).
### Protótipo de função
```
pgtle.register_feature_if_not_exists(proc regproc, feature pg_tle_feature)
```
### Função
`pgtle_admin`
### Argumentos
+ `proc`: o nome de uma função ou um procedimento armazenado que contém a lógica (código) a ser usada como um recurso para sua extensão TLE. Por exemplo, o código `pw_hook`.
+ `feature`: o nome do recurso do PostgreSQL a ser registrado na função TLE. Atualmente, o único recurso disponível é o gancho `passcheck`. Para ter mais informações, consulte [Gancho de verificação de senha (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Saída
Retorna `true` após registrar o recurso para a extensão especificada. Retorna `false` se o recurso já estiver registrado.
### Exemplo de uso
```
SELECT pgtle.register_feature_if_not_exists('pw_hook', 'passcheck');
```
## pgtle.set\$1default\$1version
A função `set_default_version` permite que você especifique uma `default_version` para sua extensão TLE. Você pode usar essa função para definir um caminho de atualização e designar a versão como padrão para sua extensão TLE. Quando os usuários do banco de dados especificam sua extensão TLE nos comandos `CREATE EXTENSION` e `ALTER EXTENSION ... UPDATE`, essa versão da extensão TLE é criada no banco de dados para esse usuário.
Essa função retorna `true` em caso de êxito. Se a extensão TLE especificada no argumento `name` não existir, a função retornará um erro. Da mesma forma, se a `version` da extensão TLE não existir, ela retornará um erro.
### Protótipo de função
```
pgtle.set_default_version(name text, version text)
```
### Função
`pgtle_admin`
### Argumentos
+ `name`: o nome da extensão TLE. Esse valor é usado ao chamar`CREATE EXTENSION`.
+ `version`: a versão da extensão TLE para definir o padrão.
### Saída
+ `true`: quando a configuração da versão padrão é bem-sucedida, a função retorna `true`.
+ `ERROR`: retornará uma mensagem de erro se uma extensão TLE com o nome ou versão especificados não existir.
### Exemplo de uso
```
SELECT * FROM pgtle.set_default_version('my-extension', '1.1');
```
## pgtle.uninstall\$1extension (nome)
A função `uninstall_extension` remove todas as versões de uma extensão TLE de um banco de dados. Essa função impede que futuras chamadas de `CREATE EXTENSION` instalem a extensão TLE. Se a extensão TLE não existir no banco de dados, um erro será gerado.
A função `uninstall_extension` não descartará uma extensão TLE se ela estiver atualmente ativa no banco de dados. Para remover uma extensão TLE que está ativa no momento, você precisa chamar explicitamente `DROP EXTENSION` para removê-la.
### Protótipo de função
```
pgtle.uninstall_extension(extname text)
```
### Função
`pgtle_admin`
### Argumentos
+ `extname`: o nome da extensão TLE a ser desinstalada. Esse nome é o mesmo usado com `CREATE EXTENSION` para carregar a extensão TLE para uso em determinado banco de dados.
### Saída
Nenhum.
### Exemplo de uso
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test');
```
## pgtle.uninstall\$1extension (nome, versão)
A função `uninstall_extension(name, version)` remove a versão especificada da extensão TLE do banco de dados. Essa função impede que `CREATE EXTENSION` e `ALTER EXTENSION` instalem ou atualizem uma extensão TLE para a versão especificada. Essa função também remove todos os caminhos de atualização para a versão especificada da extensão TLE. Essa função não desinstalará a extensão TLE se ela estiver atualmente ativa no banco de dados. Você deve chamar explicitamente `DROP EXTENSION` para remover a extensão TLE. Para desinstalar todas as versões de uma extensão TLE, consulte[pgtle.uninstall\$1extension (nome)](#pgtle.uninstall_extension-name).
### Protótipo de função
```
pgtle.uninstall_extension(extname text, version text)
```
### Função
`pgtle_admin`
### Argumentos
+ `extname`: o nome da extensão TLE. Esse valor é usado ao chamar`CREATE EXTENSION`.
+ `version`: a versão da extensão TLE a ser desinstalada do banco de dados.
### Saída
Nenhum.
### Exemplo de uso
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test', '0.2');
```
## pgtle.uninstall\$1extension\$1if\$1exists
A função `uninstall_extension_if_exists` remove todas as versões de uma extensão TLE de determinado banco de dados. Se a extensão TLE não existir, a função retornará silenciosamente (nenhuma mensagem de erro será gerada). Se a extensão especificada estiver atualmente ativa em um banco de dados, essa função não a descartará. Você deve chamar explicitamente `DROP EXTENSION` para remover a extensão TLE antes de usar essa função para desinstalar seus artefatos.
### Protótipo de função
```
pgtle.uninstall_extension_if_exists(extname text)
```
### Função
`pgtle_admin`
### Argumentos
+ `extname`: o nome da extensão TLE. Esse valor é usado ao chamar `CREATE EXTENSION`.
### Saída
A função `uninstall_extension_if_exists` retorna `true` após a desinstalação da extensão especificada. Se a extensão especificada não existir, a função retornará `false`.
+ `true`: retorna `true` após a desinstalação da extensão TLE.
+ `false`: retorna `false` quando a extensão TLE não existe no banco de dados.
### Exemplo de uso
```
SELECT * FROM pgtle.uninstall_extension_if_exists('pg_tle_test');
```
## pgtle.uninstall\$1update\$1path
A função `uninstall_update_path` remove o caminho de atualização especificado de uma extensão TLE. Isso impede `ALTER EXTENSION ... UPDATE TO` de usar isso como um caminho de atualização.
Se a extensão TLE estiver sendo usada atualmente por uma das versões desse caminho de atualização, ela permanecerá no banco de dados.
Se o caminho de atualização especificado não existir, essa função gerará um erro.
### Protótipo de função
```
pgtle.uninstall_update_path(extname text, fromvers text, tovers text)
```
### Função
`pgtle_admin`
### Argumentos
+ `extname`: o nome da extensão TLE. Esse valor é usado ao chamar`CREATE EXTENSION`.
+ `fromvers`: a versão de origem da extensão TLE usada no caminho de atualização.
+ `tovers`: a versão de destino da extensão TLE usada no caminho de atualização.
### Saída
Nenhum.
### Exemplo de uso
```
SELECT * FROM pgtle.uninstall_update_path('pg_tle_test', '0.1', '0.2');
```
## pgtle.uninstall\$1update\$1path\$1if\$1exists
A função `uninstall_update_path_if_exists` é semelhante a `uninstall_update_path` no sentido de remover o caminho de atualização especificado de uma extensão TLE. No entanto, se o caminho de atualização não existir, essa função não gerará uma mensagem de erro. Em vez disso, a função retornará `false`.
### Protótipo de função
```
pgtle.uninstall_update_path_if_exists(extname text, fromvers text, tovers text)
```
### Função
`pgtle_admin`
### Argumentos
+ `extname`: o nome da extensão TLE. Esse valor é usado ao chamar`CREATE EXTENSION`.
+ `fromvers`: a versão de origem da extensão TLE usada no caminho de atualização.
+ `tovers`: a versão de destino da extensão TLE usada no caminho de atualização.
### Saída
+ `true`: a função atualizou com êxito o caminho da extensão TLE.
+ `false`: a função não conseguiu atualizar o caminho da extensão TLE.
### Exemplo de uso
```
SELECT * FROM pgtle.uninstall_update_path_if_exists('pg_tle_test', '0.1', '0.2');
```
## pgtle.unregister\$1feature
A função `unregister_feature` fornece uma maneira de remover funções que foram registradas para usar recursos `pg_tle`, como ganchos. Para obter informações sobre como registrar uma recurso, consulte [pgtle.register\$1feature](#pgtle.register_feature).
### Protótipo de função
```
pgtle.unregister_feature(proc regproc, feature pg_tle_features)
```
### Função
`pgtle_admin`
### Argumentos
+ `proc`: o nome de uma função armazenada a ser registrada em um recurso `pg_tle`.
+ `feature`: o nome do recurso `pg_tle` a ser registrado na função. Por exemplo, `passcheck` é um recurso que pode ser registrado para uso pelas extensões de linguagem confiáveis desenvolvidas por você. Para ter mais informações, consulte [Gancho de verificação de senha (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Saída
Nenhum.
### Exemplo de uso
```
SELECT * FROM pgtle.unregister_feature('pw_hook', 'passcheck');
```
## pgtle.unregister\$1feature\$1if\$1exists
A função `unregister_feature` fornece uma maneira de remover funções que foram registradas para usar recursos `pg_tle`, como ganchos. Para ter mais informações, consulte [Usar ganchos do PostgreSQL com suas extensões TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md). Retorna `true` após cancelar o registro do recurso com êxito. Retorna `false` se o recurso não foi registrado.
Para obter informações sobre como registrar recursos `pg_tle` para suas extensões TLE, consulte [pgtle.register\$1feature](#pgtle.register_feature).
### Protótipo de função
```
pgtle.unregister_feature_if_exists('proc regproc', 'feature pg_tle_features')
```
### Função
`pgtle_admin`
### Argumentos
+ `proc`: o nome da função armazenada que foi registrada para incluir um recurso `pg_tle`.
+ `feature`: o nome do recurso `pg_tle` que foi registrado com a extensão de linguagem confiável.
### Saída
Retorna `true` ou `false` da maneira a seguir.
+ `true`: a função cancelou com êxito o registro do recurso da extensão.
+ `false`: a função não conseguiu cancelar o registro do recurso da extensão TLE.
### Exemplo de uso
```
SELECT * FROM pgtle.unregister_feature_if_exists('pw_hook', 'passcheck');
```
# Referência de ganchos para Trusted Language Extensions para PostgreSQL
O Trusted Language Extensions para PostgreSQL é compatível com ganchos do PostgreSQL. Um *gancho* é um mecanismo interno de retorno de chamada disponível para que os desenvolvedores estendam a funcionalidade principal do PostgreSQL. Usando ganchos, os desenvolvedores podem implementar suas próprias funções ou procedimentos para uso durante várias operações de banco de dados, modificando assim o comportamento do PostgreSQL de alguma forma. Por exemplo, você pode usar um gancho `passcheck` para personalizar a forma como o PostgreSQL manipula as senhas fornecidas ao criar ou alterar senhas para usuários (funções).
Veja a documentação a seguir para saber mais sobre o hook passcheck disponível para as extensões TLE. Para saber mais sobre os hooks disponíveis, incluindo o hook de autenticação do cliente, consulte [Trusted Language Extensions hooks](https://github.com/aws/pg_tle/blob/main/docs/04_hooks.md).
## Gancho de verificação de senha (passcheck)
O gancho `passcheck` é usado para personalizar o comportamento do PostgreSQL durante o processo de verificação de senha para os comandos SQL e o metacomando `psql` a seguir.
+ `CREATE ROLE username ...PASSWORD`: para obter mais informações, consulte [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) na documentação do PostgreSQL.
+ `ALTER ROLE username...PASSWORD`: para obter mais informações, consulte [ALTER ROLE](https://www.postgresql.org/docs/current/sql-alterrole.html) na documentação do PostgreSQL.
+ `\password username`: esse metacomando interativo `psql` altera com segurança a senha do usuário especificado usando o hash da senha antes de usar a sintaxe `ALTER ROLE ... PASSWORD` de forma transparente. O metacomando é um invólucro seguro para o comando `ALTER ROLE ... PASSWORD`, portanto, o gancho se aplica ao comportamento do metacomando `psql`.
Para ver um exemplo, consulte [Lista de códigos do gancho de verificação de senha](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md#PostgreSQL_trusted_language_extension-example-hook_code_listing).
**Contents**
+ [
### Protótipo de função
](#passcheck_hook-prototype)
+ [
### Argumentos
](#passcheck_hook-arguments)
+ [
### Configuração
](#passcheck_hook-configuration)
+ [
### Observações de uso
](#passcheck_hook-usage)
### Protótipo de função
```
passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
```
### Argumentos
A função de gancho `passcheck` usa os seguintes argumentos:
+ `username`: o nome (como texto) da função (nome de usuário) que está definindo uma senha.
+ `password`: o texto simples ou a senha com hash. A senha digitada deve corresponder ao tipo especificado em `password_type`.
+ `password_type`: especifique o formato `pgtle.password_type` da senha. Esse formato pode ser uma das opções a seguir.
+ `PASSWORD_TYPE_PLAINTEXT`: uma senha de texto simples.
+ `PASSWORD_TYPE_MD5`: uma senha que foi criptografada usando o algoritmo MD5 (resumo de mensagens 5).
+ `PASSWORD_TYPE_SCRAM_SHA_256`: uma senha que foi criptografada usando o algoritmo SCRAM-SHA-256.
+ `valid_until`: especifique a hora em que a senha se torna inválida. Esse argumento é opcional. Se você usar esse argumento, especifique a hora como um valor `timestamptz`.
+ `valid_null`: se esse valor booliano estiver definido como `true`, a opção `valid_until` será definida como `NULL`.
### Configuração
A função `pgtle.enable_password_check` controla se o gancho passcheck está ativo. O gancho passcheck tem três configurações possíveis.
+ `off`: desativa o gancho de verificação de senha `passcheck`. Este é o valor padrão.
+ `on`: ativa o gancho de verificação de senha `passcode` para que as senhas sejam conferidas na tabela.
+ `require`: requer que um gancho de verificação de senha seja definido.
### Observações de uso
Para ativar ou desativar o gancho `passcheck`, você precisa modificar o grupo de parâmetros de banco de dados personalizado para a instância de banco de dados do RDS para PostgreSQL.
Para Linux, macOS ou Unix:
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Para Windows:
```
aws rds modify-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name your-custom-parameter-group ^
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```