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