Configurando o Wal2json

As implantações IBM Cloud® Databases for PostgreSQL são compatíveis com o plug-in wal2json, habilitando a decodificação lógica em sua implantação.

Nota:

Preterido: Esse plug-in está obsoleto nas versões PostgreSQL 9.6 e 10.
Suportado: Disponível somente nas versões 11 e superiores do site PostgreSQL.

Primeiro, é necessário definir as configurações wal_level, max_replication_slots e max_wal_senders. Mude o wal_level para logical. O max_replication_slots e o max_wal_senders precisam ser configurados para um valor maior que 20. O Databases for PostgreSQL reserva 20 slots de replicação e emissores WAL para fins operacionais atuais e futuros.
```
curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/configuration
  -H 'Authorization: Bearer <>'
  -H 'Content-Type: application/json'
  -d '{"configuration": {
        "wal_level": "logical",
        "max_replication_slots": 21,
        "max_wal_senders": 21
        }
      }'
```
Configure uma senha para o usuário repl. É possível mudar a senha de qualquer usuário usando o comando cdb deployment-user-password do plug-in da CLI do Cloud Databases ou o terminal /deployments/{id}/users/{username} da API do Cloud Databases. O usuário repl tem privilégios de replicação e o plug-in wal2json o utiliza após a configuração de uma senha para ele.
Crie um slot de replicação no banco de dados por meio da API do Cloud Databases. Envie uma solicitação de POST para o terminal /deployments/{id}/postgresql/logical_replication_slots.
```
curl -X POST https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/postgresql/logical_replication_slots   -H 'Authorization: Bearer <>'
  -H 'Content-Type: application/json'
  -d '{"logical_replication_slot": {
       "name": "<slot_name>",
       "database_name": "<database_name>",
       "plugin_type": "wal2json"
       }
     }'
```
O tipo de plug-in deve ser wal2json. O banco de dados deve ser um existente. O nome do slot pode conter apenas letras minúsculas, números e o caractere de sublinhado. Você pode verificar a existência do slot de replicação conectando-se a qualquer banco de dados e executando o seguinte comando:
```
SELECT * FROM pg_replication_slots WHERE slot_name = '<slot_name>';
```
Para testar o plug-in, execute pg_recvlogical na linha de comando. O comando está disponível em uma instalação do PostgreSQL. Use o host e a porta da sua implantação e o nome do banco de dados e do slot que você criou por meio da API.
```
PGSSLMODE=require pg_recvlogical -d <DATABASE NAME> -U repl -h <HOST> -p <PORT>    --slot <SLOT NAME> --start -o pretty-print=1 -f -
```
Crie uma tabela em ibmclouddb e insira alguns dados. Certifique-se de que as inserções sejam feitas na linha de comando que está sendo executada pg_recvlogical.

As criações de tabelas não são exibidas.

Considerações e dicas sobre Wal2json

Configurar wal_level como logical aumenta o tamanho dos arquivos WAL porque o PostgreSQL precisa de mais dados para realizar a decodificação lógica. Se você não estiver usando wal2json, deixe wal_level como padrão. Arquivos WAL maiores significam potencialmente que é necessário mais espaço em disco. A taxa de transferência de gravação pode diminuir, juntamente com o atraso de replicação que afeta a alta disponibilidade e as réplicas somente leitura, além de tempos de restauração mais longos a partir de um backup.
A decodificação lógica tem um conjunto de restrições sobre o que é replicado. Algumas delas incluem esquema/DDL, sequências, TRUNCAMENTO e objetos grandes.
Quando uma comutação de HA controlada acontece, é possível que eventos de replicação sejam entregues mais de uma vez. Os aplicativos de recebimento de dados devem ser capazes de manipular os eventos que estão sendo entregues mais de uma vez.
Se você criar um slot de replicação lógica e um consumidor não estiver conectado e consumindo as mudanças, você correrá o risco de executar sua implementação sem espaço em disco. O slot de replicação informa ao PostgreSQL para manter todos os logs de transações que têm as mudanças que o consumidor precisa. Se nada estiver consumindo essas mudanças, o PostgreSQL continuará a coletá-las até que esteja sem espaço em disco. É possível monitorar o espaço em disco com a integração do IBM Cloud® Monitoring. Se você ficar sem espaço, será possível aumentar a capacidade do disco, o que permitirá que o banco de dados seja iniciado. Em seguida, será possível começar a consumir as mudanças ou descartar o slot.

É possível verificar quanto espaço em disco está usado por um slot de replicação específico e se esse slot de replicação tem um consumidor ativo. Use o usuário admin para executar um dos comandos a seguir:

PostgreSQL 10.x e mais recente

SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) AS lag, active from pg_replication_slots WHERE slot_type='logical';

PostgreSQL 9.x

SELECT slot_name, pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(),restart_lsn)) AS lag, active FROM pg_replication_slots WHERE slot_type='logical';

Se você observar um uso de disco maior do que o esperado em sua implantação, solucione o problema verificando se o slot de replicação tem um consumidor e se a implantação não está ficando sem espaço em disco.