Partilhar via

Descodificação lógica

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Único

Importante

O Banco de Dados do Azure para PostgreSQL - Servidor Único está no caminho da desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único PostgreSQL?.

A decodificação lógica no PostgreSQL permite transmitir alterações de dados para consumidores externos. A decodificação lógica é popularmente usada para streaming de eventos e alterar cenários de captura de dados.

A descodificação lógica utiliza um plug-in de saída para converter o registo de escrita prévia (WAL) do Postgres num formato legível. O Banco de Dados do Azure para PostgreSQL fornece os plug-ins de saída wal2json, test_decoding e pgoutput. O pgoutput é disponibilizado pelo PostgreSQL a partir da versão 10 e superior.

Para uma visão geral de como funciona a decodificação lógica do Postgres, visite nosso blog.

Nota

A replicação lógica usando publicação/assinatura do PostgreSQL não é suportada com o Banco de Dados do Azure para PostgreSQL - Servidor Único.

Configurar o servidor

A decodificação lógica e as réplicas de leitura dependem do log de gravação antecipada (WAL) do Postgres para obter informações. Esses dois recursos precisam de níveis diferentes de registro do Postgres. A decodificação lógica precisa de um nível mais alto de registro em log do que as réplicas de leitura.

Para configurar o nível correto de log, use o parâmetro de suporte de replicação do Azure. O suporte à replicação do Azure tem três opções de configuração:

  • Off - Coloca o mínimo de informação no WAL. Essa configuração não está disponível na maioria dos servidores do Banco de Dados do Azure para PostgreSQL.
  • Réplica - Mais detalhada do que Off. Este é o nível mínimo de registro em log necessário para que as réplicas de leitura funcionem. Essa configuração é o padrão na maioria dos servidores.
  • Lógico - Mais detalhado que Replica. Este é o nível mínimo de registro em log para que a decodificação lógica funcione. As réplicas de leitura também funcionam nessa configuração.

Utilizar a CLI do Azure

  1. Defina azure.replication_support como logical.

    az postgres server configuration set --resource-group mygroup --server-name myserver --name azure.replication_support --value logical

  2. Reinicie o servidor para aplicar a alteração.

    az postgres server restart --resource-group mygroup --name myserver

  3. Se você estiver executando o Postgres 9.5 ou 9.6 e usar o acesso à rede pública, adicione a regra de firewall para incluir o endereço IP público do cliente de onde você executará a replicação lógica. O nome da regra de firewall deve incluir _replrule. Por exemplo, test_replrule. Para criar uma nova regra de firewall no servidor, execute o comando az postgres server firewall-rule create .

Através do portal do Azure

  1. Defina o suporte à replicação do Azure como lógico. Selecione Guardar.

    Banco de Dados do Azure para PostgreSQL - Replicação - Suporte à replicação do Azure

  2. Reinicie o servidor para aplicar a alteração selecionando Sim.

    Banco de Dados do Azure para PostgreSQL - Replicação - Confirmar reinicialização

  3. Se você estiver executando o Postgres 9.5 ou 9.6 e usar o acesso à rede pública, adicione a regra de firewall para incluir o endereço IP público do cliente de onde você executará a replicação lógica. O nome da regra de firewall deve incluir _replrule. Por exemplo, test_replrule. Em seguida, selecione Guardar.

    Banco de Dados do Azure para PostgreSQL - Replicação - Adicionar regra de firewall

Iniciar a decodificação lógica

A decodificação lógica pode ser consumida via protocolo de streaming ou interface SQL. Ambos os métodos usam slots de replicação. Um slot representa um fluxo de alterações de um único banco de dados.

O uso de um slot de replicação requer os privilégios de replicação do Postgres. No momento, o privilégio de replicação só está disponível para o usuário administrador do servidor.

Protocolo de streaming

Consumir alterações usando o protocolo de streaming geralmente é preferível. Você pode criar seu próprio consumidor / conector, ou usar uma ferramenta como Debezium.

Visite a documentação wal2json para obter um exemplo usando o protocolo de streaming com pg_recvlogical.

Interface SQL

No exemplo abaixo, usamos a interface SQL com o plugin wal2json.

  1. Crie um slot.

    SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');

  2. Emita comandos SQL. Por exemplo:

    CREATE TABLE a_table (
   id varchar(40) NOT NULL,
   item varchar(40),
   PRIMARY KEY (id)
);

INSERT INTO a_table (id, item) VALUES ('id1', 'item1');
DELETE FROM a_table WHERE id='id1';

  3. Consuma as alterações.

    SELECT data FROM pg_logical_slot_get_changes('test_slot', NULL, NULL, 'pretty-print', '1');

    A saída será semelhante a:

    {
      "change": [
      ]
}
{
      "change": [
               {
                        "kind": "insert",
                        "schema": "public",
                        "table": "a_table",
                        "columnnames": ["id", "item"],
                        "columntypes": ["character varying(40)", "character varying(40)"],
                        "columnvalues": ["id1", "item1"]
               }
      ]
}
{
      "change": [
               {
                        "kind": "delete",
                        "schema": "public",
                        "table": "a_table",
                        "oldkeys": {
                              "keynames": ["id"],
                              "keytypes": ["character varying(40)"],
                              "keyvalues": ["id1"]
                        }
               }
      ]
}

  4. Solte o slot assim que terminar de usá-lo.

    SELECT pg_drop_replication_slot('test_slot');

Monitorização de faixas horárias

Você deve monitorar a decodificação lógica. Qualquer slot de replicação não utilizado deve ser descartado. Os slots mantêm os logs WAL do Postgres e os catálogos de sistema relevantes até que as alterações sejam lidas por um consumidor. Se o consumidor falhar ou não tiver sido configurado corretamente, os logs não consumidos se acumularão e preencherão seu armazenamento. Além disso, os logs não consumidos aumentam o risco de encapsulamento de ID de transação. Ambas as situações podem fazer com que o servidor fique indisponível. Portanto, é fundamental que os slots de replicação lógica sejam consumidos continuamente. Se um slot de replicação lógica não for mais usado, solte-o imediatamente.

A coluna «ativo» na vista pg_replication_slots indicará se existe um consumidor ligado a uma ranhura.

SELECT * FROM pg_replication_slots;

Defina alertas sobre o armazenamento usado e o atraso máximo nas métricas de réplicas para notificá-lo quando os valores aumentarem além dos limites normais.

Importante

Você deve descartar os slots de replicação não utilizados. Não fazer isso pode levar à indisponibilidade do servidor.

Como largar uma ranhura

Se você não estiver consumindo ativamente um slot de replicação, deverá descartá-lo.

Para descartar um slot de replicação chamado test_slot usando SQL:

SELECT pg_drop_replication_slot('test_slot');

Importante

Se você parar de usar a decodificação lógica, altere azure.replication_support de volta para replica ou off. Os detalhes WAL retidos por logical são mais detalhados e devem ser desativados quando a decodificação lógica não estiver em uso.

Próximos passos