O Real-Time Intelligence no Microsoft Fabric fornece vários conectores de captura de dados de alteração de banco de dados, incluindo banco de dados SQL, MySQL, PostgreSQL e Cosmos DB, o que permite que qualquer pessoa reaja facilmente e execute ações em alterações de banco de dados em tempo real. Cada um dos bancos de dados funciona de maneira diferente quando se trata de habilitar o CDC, dando permissão aos usuários e como eles replicam as alterações do banco de dados para o Eventstream. Este blog descreve alguns pontos importantes a serem lembrados ao usar o banco de dados PostgreSQL CDC no Eventstream.
O conector CDC do PostgreSQL é baseado no conector Debezium para PostgreSQL.
A configuração dessa origem CDC no Eventstream é abordada na documentação “Adicionar fonte CDC do banco de dados PostgreSQL a um Eventstream“.
Há considerações importantes sobre o banco de dados PostgreSQL e as propriedades do Debezium que os usuários devem ter em mente ao usar essa fonte de conector
Habilitar decodificação lógica
- O banco de dados PostgreSQL precisa ter a decodificação lógica habilitada e WAL_LEVEL definida como lógica. O conector Eventstream usa o plug-in de saída “pgoutput” para logs de gravação antecipada. Você pode verificar o nível atual do WAL executando o código a seguir no banco de dados PostgreSQL.
Permissões do usuário
- O usuário que precisa ser configurado para CDC no Eventstream precisa ter um mínimo de permissões de replicação no banco de dados. Execute o seguinte comando no banco de dados PostgreSQL:
- Para trabalhar com publicação, o usuário precisa ter permissão de administrador/superusuário. Se o usuário não puder receber permissões de administrador/superusuário, precisamos considerar a configuração da propriedade publication.autocreate.mode do conector Debezium como desabilitado. A opção padrão dessa propriedade é filtrada no conector Eventstream, que requer permissão de administrador.
Publicação
- O PostgreSQL trabalha com o conceito de publicações nas quais os registros do CDC são publicados. Por padrão, o conector sempre tenta criar uma publicação no banco de dados com o nome ‘dbz_publication’. Um superusuário/administrador no banco de dados terá, por padrão, permissões para criar/alterar uma publicação. Isso também significa que, se vários conectores estiverem sendo usados, a publicação será substituída por conectores criados posteriormente e os conectores criados anteriormente não receberão eventos CDC. Como eles usam o mesmo nome de publicação, os conectores criados posteriormente atualizarão sua lista de tabelas filtradas na publicação.
- Para evitar dar permissão mais alta aos usuários ou conector que tentam criar sua própria publicação, podemos definir a propriedade publication.autocreate.mode como desabilitada.
- Definir essa propriedade como desabilitada significa que o conector não tentará criar “dbz_publication” e procurará uma publicação existente. Portanto, certifique-se de que as publicações sejam pré-criadas no banco de dados.
- A pré-criação de publicações no banco de dados fornecerá controle total aos DBAs para adicionar tabelas que serão anexadas a cada publicação da qual o CDC é extraído.
- Um administrador de banco de dados pode criar uma publicação e anexar tabelas a ela executando o seguinte comando:
Slot de replicação
- A interface do usuário do Eventstream fornece um espaço reservado opcional para fornecer o nome do slot. É aconselhável fornecer obrigatoriamente um nome de slot de replicação para controlar quais slots estão sendo consumidos pelo conector Eventstream e outros canais de replicação no banco de dados.
- Você pode criar um slot de replicação no banco de dados PostgreSQL executando o comando a seguir.
Instantâneo histórico
- Após a configuração inicial, o conector inicialmente traz um instantâneo histórico de todas as tabelas incluídas na interface do usuário do Eventstream.
A configuração do conector do Eventstream fornece espaço reservado para fornecer a lista de tabelas ou escolher Todas as tabelas
- Consideração importante para grandes bancos de dados transacionais – em vez de Todas as tabelas, os usuários podem dividir logicamente a tabela usando vários conectores no Eventstream. Eles podem inserir uma lista separada por vírgulas de tabelas em vez de Todas as tabelas ou agrupá-las em um nível de tabela ou esquema usando a expressão regex. O campo de lista de tabelas deve ser usado com cautela porque tem limitação de caracteres de 128 com regex ou lista separada por vírgulas de 100 tabelas.
- É importante selecionar apenas as tabelas em que toda a carga histórica é necessária. Caso contrário, acabaremos obtendo uma grande quantidade de dados no Eventstream. Isso significa que levará tempo para carregar no destino, o CDC não será iniciado até que o instantâneo seja concluído e a lista de pendências poderá continuar aumentando, o que resultará em tráfego de dados no Eventstream.
- Em caso de problemas durante o snapshot em tabelas grandes, devido ao tempo limite no banco de dados de origem, execute o seguinte comando no banco de dados PostgreSQL:
ALTER ROLE <user> SET idle_in_transaction_session_timeout=’0′;
- Outra consideração importante é que a taxa de transferência do conector CDC e do Eventstream são diferentes. A configuração na interface do usuário do Eventstream altera apenas a taxa de transferência do Eventstream. Os números de taxa de transferência são descritos na documentação de taxa de transferência do Conector.
- Lembre-se de que o instantâneo e o CDC funcionam de maneira diferente. Snapshot é uma instrução select simples em cada tabela e não depende diretamente do WAL. Isso significa que não há número de sequência de log/marca d’água mantido durante um instantâneo. Quaisquer problemas durante o instantâneo reiniciarão o conector e reiniciarão o instantâneo, resultando em duplicatas no banco de dados.
- Problemas no instantâneo podem ocorrer devido a problemas de permissões de tabela, tabelas grandes, tempos limite, conversões de tipo de dados ou limitação do Eventstream. É importante planejá-los antes de iniciar o instantâneo.
CDC
- Após o instantâneo, imediatamente o conector entrará no modo CDC, onde a publicação e os pontos mencionados acima sobre as permissões do usuário precisam ser considerados.
- Para evitar conflitos de publicações e slots, cada um dos conectores Debezium de origem também pode ser iniciado mencionando explicitamente as propriedades – publication.name e slot.name.
- Fornecer as propriedades acima junto com publication.autocreate.mode = disabled significa que os registros CDC fluem sem problemas sem permissão do usuário negado se o administrador ou superusuário não estiver sendo usado.
- Os registros CDC têm um esquema específico da carga – eles contêm pares de valores de chave antes e depois de colunas e linhas da tabela de banco de dados. Há uma opção que podemos habilitar para garantir que antes e depois sejam sempre preenchidos via CDC, o que facilita atualizações, inserções e exclusões em aplicativos downstream. Isso também ajudará as tabelas sem chave primária.
- Execute o seguinte comando no banco de dados PostgreSQL:
Tipo de dados handling
- Por padrão, o conector Debezium usa o tipo de dados numérico decimal para conversão binária. Isso não pode ser usado para a maioria dos clientes e pode precisar de etapas extras para converter esses números de volta em formato utilizável.
- Isso pode ser feito definindo a propriedade decimal.handling.mode como double.
- Sem definir a propriedade, uma coluna que é decimal, digamos que ‘UnitPrice’ aparecerá no Eventstream como binário Ex: UnitPrice: “RnLs=”.
- Se a propriedade for definida como double no conector, o valor será exibido corretamente Ex: UnitPrice: 63.90.
O conector CDC do Eventstream remove a sobrecarga de manter e executar uma infraestrutura enorme para mover dados de banco de dados para o Microsoft Fabric. Como esse é um conector gerenciado, não há nenhum código complexo a ser escrito ou várias ferramentas a serem configuradas. O conector mudará da carga histórica para o CDC de streaming por conta própria, o que o torna uma boa opção para clientes que planejam obter insights acionáveis sobre alterações no banco de dados.
Se os usuários puderem garantir que as configurações acima do conector sejam usadas com os valores corretos, o instantâneo e o CDC funcionarão perfeitamente, mesmo ao trabalhar em tabelas de banco de dados grandes. Embora atualmente algumas dessas configurações não sejam expostas na interface do usuário, verifique com a equipe da Microsoft se as alterações podem ser feitas no back-end do conector. A maioria das opções acima acabará sendo exposta na interface do usuário, o que dá controle total ao usuário para alterar a configuração.
Source: Blog Microsoft Fabric.
Acelere sua estratégia de dados com o conector CDC para PostgreSQL no Microsoft Fabric
A integração do conector CDC para PostgreSQL ao Eventstream do Microsoft Fabric representa uma transformação poderosa para quem deseja capturar alterações em tempo real e transformar dados em decisões instantâneas. Com suporte nativo a configurações avançadas como publication.autocreate.mode, replicação controlada por slot e snapshot histórico, essa solução elimina a complexidade da infraestrutura e entrega uma performance ágil e escalável — mesmo em bases de dados robustas.
Para que sua empresa possa aproveitar ao máximo essa tecnologia, é essencial contar com especialistas que conheçam não apenas o funcionamento técnico do CDC, mas que também saibam como alinhar essa ferramenta à estratégia de dados do seu negócio. A equipe da DataEX está pronta para te ajudar nessa jornada.
Preencha o formulário abaixo e nosso time de especialistas entrará em contato.
E não se esqueça de nos seguir em nossas social networks e leia o blog Data Universe diariamente.
