Trabalhar com recursos do PostgreSQL compatíveis com o Amazon RDS para PostgreSQL - Amazon Relational Database Service

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 for PostgreSQL. Para saber mais sobre outras tarefas comuns do DBA, consulte Tarefas comuns de DBA do Amazon RDS para PostgreSQL.

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

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.

A seguir, você pode encontrar informações sobre mais alguns recursos compatíveis com o RDS para PostgreSQL.

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 (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 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 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 (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 ter mais informações, consulte Usar pglogical para sincronizar dados entre instâncias.

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.

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.

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

  3. Reinicialize a instância de banco de dados para que o parâmetro estático rds.logical_replication tenha efeito.

  4. 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_decoding 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.

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” (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_recvlogical, 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)

Disco de RAM para o stats_temp_directory

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.

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.

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.

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 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” (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). Para obter informações sobre o ICU-60, consulte Baixar o ICU 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 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: 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: 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 e na Unicode to LATIN9 collations 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?

Para obter mais informações sobre como gerenciar agrupamentos no PostgreSQL, consulte “Collation Support” (Compatibilidade com agrupamentos) na documentação do PostgreSQL.