Palestra DBABrasil 2023

Marcelo — Tue, 27 Jun 2023 19:34:27 +0000

Palestra DBABrasil 2023

E nesse último final de semana tivemos a edição de retorno triunfal do grande DBABrasil (https://dbabrasil.net.br/). Além de rever amigos, pude palestrar sobre um assunto que gosto muito: Alta Disponibilidade e Recuperação de Desastres.

A casa estava cheia e é isso que a gente adora!

Você pode baixar o material aqui nesse link: https://github.com/marceloadade/Lives/tree/main/DBABR2023

Abraços e ótimos estudos!

The post Palestra DBABrasil 2023 appeared first on DBBITS.

Usando Kafka pra replicar dados do Posgres pro SQL SERVER

Marcelo — Thu, 31 Mar 2022 22:12:44 +0000

O Desafio

Os dados estão no centro de qualquer sistema de decisão empresarial de qualquer organização. Você provavelmente ouviu a expressão: “Dados é o novo Petróleo”.

No entanto, nem sempre (na verdade, é raramente) que todos os dados necessários estão localizados em apenas um lugar, como um RDBMS de remos e baunilha. Normalmente está espalhado por diferentes RDBMS e outros silos de dados.

Portanto, não é incomum encontrar situações em que os dados estão em todos os tipos de fontes diferentes e o DBA ou O Engenheiro de Dados precisa implementar um solution que puxa todos os dados relevantes para um local centralizado para análises posteriores.

Imagem 1: As muitas fontes de dados possíveis

Recentemente nos deparamos com um caso em que um cliente tinha dados de vendas em uma instância rds AWS Postgres e precisava que os dados (um conjunto de tables para ser mais preciso) fossem replicados (quase em tempo real) em algumas tabelas em seu Azure VM com MS SQL SERVER. Infelizmente, a replicação heterogênea é marcada como depreciada e só funciona entre SQL SERVER e ORACLE. Não é permitido postgres no lote. Além disso, não há replicação heterogênea nativa no lado dos Postgres. Isso pode ser alcançado on-only com o uso de ferramentas de terceiros ou manualmente no modo de esforço ALTO – criando um MECHANISM CDC (Change Data Capture) usando gatilhos e, em seguida, puxando dados de tabelas de controle. Isso parece certo para implementar, mas o tempo é essencial. Desenvolver tal solução levaria algum tempo.

Portanto, outra solução tinha que ser usada para alcançar o movimento de dados necessário .

Uma possível solução (por que Kafka)

A imagem 1 mostra um cenário possível, mas não mostra a solução como em qual ferramenta poderia ser usada como pipeline. O cenário do Big Data tem muitas ferramentas que talvez pudessem conseguir isso, mas nenhuma delas tinha as vantagens que Kafka oferecia.
Originalmente, o Apache Kafka foi projetado para ser uma fila de mensagens como o aplicativo (lembra-se da IBM MQ Series ou mesmo do SQL SERVER Service Broker?). A melhor definição do que é pode ser citada da Confluent: “Apache Kafka é uma tecnologia de streaming de eventos distribuídos pela comunidade capaz de lidar com trilhões de eventos por dia”. Da mente de um DBA: Bem, o streaming deve ser como uma replicação, mas enorme! Isso é preciso, mas um Sistema de Streaming precisa ter a capacidade de ingerir dados de muitas fontes de dados diferentes e deve ser capaz de entregar suas mensagens em uma variedade de pontos finais de dados também. Poderíamos escolher entre muitas ferramentas para conseguir isso, Azure Event Hubs ou AWS Kinesis ou até mesmo o Kafka gerenciado em Nuvem Confluente. However, para aprender como as coisas funcionam sob o capô e já que todas elas vêm de origens semelhantes (que é o código de código aberto Apache Kafka) ou têm o mesmo objetivo decidimos mostrar ao cliente como configurar o ambiente a partir do zero do solo sem quaisquer Serviços Gerenciados para o processamento do Stream. Então, a imagem anterior seria mais ou menos assim:

Imagem 2: Usando Kafka para lidar com muitas fontes e entregar a mensagem para um (ou muitos) destinos

Como uma breve introdução, os componentes básicos do Apache Kafka são:

Mensagem:A menor unidade de dados em Kafka, do ponto de vista da DBA, uma mensagem é uma linha em uma tabela db. No que diz respeito a Kafka, uma mensagem é uma série de bytes.
Esquema: Uma estrutura que acompanha mensagens, para que elas possam ser desarmadas pelos aplicativos que consomem ;
Tópicos: As mensagens são categorizadas em Tópicos. No Mundo DBA, isso seria o equivalente a uma “mesa”. As mensagens são lidas de acordo em troca de conteúdo;
Produtores e Consumidores: Lembra-se de Editores e Assinantes de Replicação do SQL SERVER? A ideia é muito semelhante aqui, no entanto, Kafka tem a capacidade de lidar com vários produtores e consumidores ao mesmo tempo.
Corretores e Clusters: Um único servidor Kafka é um “corretor”. Recebe mensagens dos produtores, escreve um deslocamento para eles e persiste em disco. Também servirá aos consumidores como eles pedem mensagens. De um modo geral, em um ambiente de produção, os Corretores fazem parte de um Cluster
Conectores: Apache Kafka tem muitos conectores para lidar com consumidores e produtores (que poderiam ser do tipo pia). Uma grande variedade de conectores está disponível gratuitamente ou para compra. Você encontrará a maioria deles na página web confluente (https://www.confluent.io/product/confluent-connectors).

Em conclusão, kafka é a ferramenta de escolha para essa tarefa e vamos criar todo o ambiente para a movimentação de dados do zero. Para mais informações, acesse aqui: https://kafka.apache.org/documentation.

A arquitetura

Para alcançar a funcionalidade de Streaming e ver o fluxo de dados em ação, usaremos um conjunto de tabelas do Postgresql DB como fonte, um conjunto de tabelas do SQL SERVER como destino e Apache Kafka agirá como o “mecanismo de replicação”. Para se conectar aos Postgres e detectar suas alterações de dados (CDC), também é necessário um plugin conector. Neste caso, vamos usar o Debezium, pois ele também é de código aberto e construído do zero para trabalhar com Kafka o mais facilmente possível.

Imagem 3: Movendo dados de Postgres para MS SQL em poucas palavras

Mergulhando um pouco mais em detalhes, no final desta série de postagem do Blog devemos ter:

um VM Linux que tem uma instância pós-ano e os binários Kafka idealmente com conectividade à Internet (usaremos o Cli Confluente para tornar a implantação um pouco menos complicada). O Debezium para Pós-Grau também será instalado neste VM;
Um Windows VM (ou um local) com uma instância de SERVIDOR SQL MS.

Então nossa arquitetura deve parecer um pouco mais com a Imagem 4.

Imagem 4: Detalhando a arquitetura

Também tenha em mente que, para alcançar o objetivo necessário (replicar dados do Postgres para o SQL SERVER usando Kafka), poderíamos simplesmente usar um produto Kafka-as-a-service em qualquer um dos principais Provedores de Nuvem. No entanto, para entender completamente como a arquitetura funciona e simplesmente como uma vitrine decidimos não usar nenhum produto relacionado ao SaaS, nem Docker nesta série. Você pode encontrar uma nova série no blog this em um futuro próximo que contempla os Serviços de Nuvem. Com as expectativas estabelecidas, estamos prontos para prosseguir…

Sujando as mãos

Vamos começar instalando nosso primeiro VM. Estou usando um PC Windows para fazer todos os meus testes, então estou criando o VM em Hyper-V. Feel livre para usar qualquer hipervisor que você preferir. Minha escolha para OS é Red Hat Developer edição 8.5. Você precisará assinar o Portal do Chapéu Vermelho: https://developers.redhat.com/prod ucts/rhel/visão geral.

Passo 1: Criando a Máquina Virtual

No meu caso, criarei um VM chamado Júpiter para agir como nosso servidor Postgres e Kafka.
Será uma Geração 2 no que diz respeito ao Hyper-V. Certifique-se de alocar memória suficiente para que você possa testar properly. Estou definindo o meu para cerca de 6 GB – dinâmico, o que significa que Hyper-V não vai dedicar essa memória inteiramente ao VM.
Para rede, estou adicionando um adaptador ethernet virtual que está conectado à nic física do host, o que significa que o roteador wi-fi atribuirá um endereço IP diretamente ao VM.
Para uma pequena amostra de dados, 60 GB de espaço em disco é mais do que suficiente.
Conecte o iso red hat para que você possa instalar o SO em breve.
Certifique-se de definir uma quantidade razoável de cpus virtuais e desativar o Secure Boot por enquanto.
Habilite todos os serviços de hóspedes.
Vamos instalar o SISTEMA OPERACIONAL, Iniciar o VM, selecionar a janela do console e acertar qualquer tecla para que o processo Instalar seja iniciado.
Escolha seu idioma de instalação preferido.
Aqui está o que queremos ajustar nesta tela: Definir partição para Auto, desativar Kdump, ativar rede, definir Senha Raiz, criar um usuário (no meu caso: bigdatadude). Depois de definir todas as configurações desejadas, podemos clicar em Iniciar a Instalação.
Pode levar um tempo para concluir a instalação do SO. Depois disso, não podemos reiniciar.
Na fase de configuração você precisa aceitar os termos de licença (que você provavelmente não lerá).
Depois de terminar, aperte a configuração de acabamento.
Você definitivamente deve registrar o novo VM com sua conta Red Hat, caso contrário você não será capaz de baixar os pacotes necessários para o ambiente funcionar corretamente. Basta clicar em Registrar e adicionar seu número de usuário (NÃO EMAIL) e senha para sua conta red hat.
Neste ponto podemos ignorar as próximas telas e não precisamos assinar em nenhuma outra conta on-line.
Agora não precisamos mais usar a GUI. Podemos começar a usar qualquer aplicativo semelhante a terminal no Windows para fazer o interact com o nosso VM. Minha escolha é MobaXTerm (https://mobaxterm.mobatek.net/download.html).
Você precisará obter o endereço IP para o VM que você acabou de instalar. Você pode fazer isso abrindo uma janela do terminal e digitando: “ifconfig”.
MobaXTerm é muito útil e tem uma interface do usuário muito intuitiva, assim que você se conectar você verá uma janela lateral semelhante ao Windows Explorer (você pode transferir arquivos aqui se quiser) e o terminal principal do bash onde você pode inputar os comandos necessários.

No próximo post vamos instalar e configurar o banco de dados Postgres, criar um pequeno conjunto de dados e instalar o software necessário confluente para o software Apache Kafka funcionar. Então fique ligado para atualizações!

The post Usando Kafka pra replicar dados do Posgres pro SQL SERVER appeared first on DBBITS.

Live 01: Migrando Bancos de Dados no SQL SERVER utilizando Always On Availability Groups

Marcelo — Mon, 29 Mar 2021 22:47:34 +0000

Salve pessoal!

Na última quarta-feira tivemos uma Live onde conversamos sobre as Estratégias de migração de bancos de dados utilizando Always On Availability Groups e outras soluções de HADR no MS SQL SERVER.

Tivemos aquele tradicional desenho também! Você pode conferir aqui embaixo:

Você pode conferir a Live aqui:

É isso galera! Espero que tenham gostado e deixem aqui uma sugestão:
Sobre o que você quer que eu fale na próxima aula?!

Abraços e ótimos estudos!

ps: Sabia que tem um treinamento de Alta Disponibilidade esperando por você?
Você pode baixar o material pra conferir e assistir um módulo grátis!
Confira aqui: Keeping Your SQL Server Always On – DBBITS

The post Live 01: Migrando Bancos de Dados no SQL SERVER utilizando Always On Availability Groups appeared first on DBBITS.