Decodificaçã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á prestes a ser desativado. Recomendamos vivamente que atualize para a Base de Dados Azure para PostgreSQL – Servidor Flexível. Para obter mais informações sobre a migração para a Base de Dados Azure para PostgreSQL – Servidor Flexível, veja O que está a acontecer à Base de Dados Azure para PostgreSQL Single Server?.

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

A decodificação lógica usa um plug-in de saída para converter o WAL (log de gravação antecipada) do Postgres em um formato acessível. Banco de Dados do Azure para PostgreSQL fornece os plug-ins de saída wal2json, test_decoding e pgoutput. pgoutput é disponibilizado pelo PostgreSQL do PostgreSQL versão 10 e acima.

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

Observação

Não há suporte para a replicação lógica usando a publicação/assinatura do PostgreSQL com Banco de Dados do Azure para PostgreSQL - Servidor Único.

Configurar seus servidores

A decodificação lógica e as réplicas de leitura dependem do WAL (Log Write-Ahead) do Postgres para obter informações. Esses dois recursos precisam de diferentes níveis de registro em log 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 certo de registro em 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:

  • Desativada - Coloca o mínimo de informações 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 Desativada. Esse é 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ógica - Mais detalhada do que Réplica. 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.

Usando 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 do qual você executará a replicação lógica. O nome da regra de firewall deve incluir _replrule. Por exemplo, test_replrule. Crie uma regra de firewall no nível de servidor do PostgreSQL do Azure com o comando az postgres server firewall-rule create.

Usando o Portal do Azure

  1. Definir o suporte à replicação do Azure como lógico. Selecione Salvar.

    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 do qual você executará a replicação lógica. O nome da regra de firewall deve incluir _replrule. Por exemplo, test_replrule. Selecione Salvar.

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

Iniciar decodificação lógica

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

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

Protocolo de streaming

O consumo de 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 do wal2json para obter um exemplo usando o protocolo de streaming com pg_recvlogical.

Interface do SQL

No exemplo a seguir, usamos a interface do SQL com o plug-in 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 terá a seguinte aparência:

    {
      "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. Descarte o slot quando terminar de usá-lo.

    SELECT pg_drop_replication_slot('test_slot');

Slots de monitoramento

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 tenham sido lidas por um consumidor. Se o consumidor falhar ou não tiver sido configurado corretamente, os logs não consumidos irão compilar e preencher o armazenamento. Além disso, os logs não consumidos aumentam o risco da ID de transação wraparound. Ambas as situações podem fazer com que o servidor fique indisponível. Portanto, é essencial que os slots de replicação lógica sejam consumidos continuamente. Se um slot de replicação lógica não for mais usado, descarte-o imediatamente.

A coluna 'ativa' na exibição pg_replication_slots indicará se há um consumidor conectado a um slot.

SELECT * FROM pg_replication_slots;

Definir alertas no Armazenamento usado e métricas Retardo máximo entre as réplicas para notificá-lo quando os valores aumentarem além dos limites normais.

Importante

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

Como soltar um slot

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

Para soltar 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 para replica ou off. Os detalhes WAL retidos por logical são mais detalhados e devem ser desabilitados quando a decodificação lógica não estiver em uso.

Próximas etapas