Visão conceitual de replicação de banco de dados

A replicação é um conjunto de tecnologias utilizadas para copiar e distribuir objetos e dados de um banco de dados para um outro banco de dados, sincronizando estes dados com a finalidade de se manter a consistência.
Destes bancos de dados, a replicação pode ser feita entre servidores ou entre servidores e clientes.

Replicação de dados entre servidores:

  • Suporte na melhoria na escalabilidade e disponibilidade;
  • Armazenamento de dados e geração de relatórios;
  • Integração de dados de diversos sites.

Replicação de dados entre servidores e clientes:

  • Suporte a troca de dados com usuários móveis;
  • Utilizado a aplicativos de ponto de vendas para o consumidor;
  • Integração de dados em diversos sites.

Componentes de topologia de replicação:

  • Publicador;
  • Distribuidor;
  • Assinantes;
  • Publicações;
  • Artigos;
  • Assinaturas.

Para entender melhor o conceito da replicação e sua topologia, normalmente usamos uma metáfora para exemplificar.
No caso a metáfora é de uma editora de revista (ou jornal, se preferir), onde a própria editora é o “publicador”, o assinante é aquele que recebe seu exemplar da revista, o distribuidor é aquele que faz a entrega e assim por diante.
O único detalhe em que esta metáfora não se enquadra quando relacionamos o caso da editora de revistas com a replicação em si é que na replicação de dados, o assinante pode efetuar atualizações (bilateral) e o publicador(editora) pode enviar alterações incrementais nos artigos. Em outras palavras, o que muda é que no caso de uma editora, você apenas recebe a informação, não atualiza e sempre a editora manda uma edição da revista na versão “final”.

Tipos de Replicação (Publicações):

  • Replicação de Instantâneo (snapshot Publication)
  • Replicação de Transacional (Transactional Publication)
  • Replicação de Mesclagem (Merge Publication)

Este é um básico, um conceito que julgo ser bastante didático e necessário, podendo ajudar quem está começando a entender o que é a “Replicação”, sua finalidade e importância. Pra quem já conhece mas não utiliza, penso que vale relembrar.

No caso de uma integração de um banco OLTP (online transacional) para um banco de ODS (Operational Data Source, que é a base do ETL para um Datawarehouse) a replicação pode suprir a necessidade como uma solução viável.

OLTP, ODS, Datawarehouse, OLAP,… são assuntos que pretendo tratar em outro post, afinal é um assunto distinto, com outro conceito e outra finalidade.

Sobre o conceito de replicação, é isto.

7 thoughts on “Visão conceitual de replicação de banco de dados

  1. Pingback: SQL Server: Melhor forma de remover uma replicação » Rodrigo Pelosini

  2. Rafael Azevedo (@rafabts)

    Preciso implementar uma solução para o seguinte cenário:

    Uma base de dados local, que funcione em uma central de processamento de dados ( e que pode eventualmente estar off-line ) precisa estar “sincronizada” com uma outra base de dados em servidor web de alta disponibilidade.

    Ao começar estudar, tenho me deparado com várias opções como “replicação”, “espelhamento” de banco de dados e ainda opções “out-of-the-box” como frameworks de sincronização como Microsoft Sync Framework.

    Estou com dificuldade para identificar a melhor opção para este cenário. Imagino que replicação de dados seja o mais adequado, mas ainda estou confuso.

    A partir de sua experiência, tens alguma coisa a me dizer que poderia esclarecer-me um pouco?

    Obrigado!

    Ah, post muito bom… Difícil achar algo que explique conceitos antes de nos “encher” de tecnologias… hehe

    Reply
    1. Rodrigo Pelosini Post author

      Olá Rafael, tudo bem? Quando você diz sobre um banco de dados que eventualmente pode estar offline, entendo que está se referindo à conectividade, certo? Bem, me parece óbvio que sim. Falo isto porque é possível ter apenas o banco como offline e já vi isto acontecer. Alguns deixam como single user para operaçāo de backup – o que pra microsoft sql server nāo é necessário. Como citou microsoft sync, suponho que esteja usando o microsoft sql server.
      Justamente seria esta minha próxima pergunta, se era microsoft sql server. Vamos ao ponto agora.
      Na minha opiniāo, se voce quer um ambiente de contingência (porque citou ter um servidor remoto de alta disponibilidade), ao meu ver o melhor seria ter uma replicaçāo por merge.
      Isto eu implementei no meu trabalho e posso garantir que funciona bem. Nāo sei se consegui esclarecer, mas fique a vontade caso nāo seja bem isso que queria. (Nem citei sobre cluster pra nāo dar mais confusāo, que é outra coisa, como os dois servidores trabalhando em conjunto compartilhando recursos. Nāo tem nada a ver com replicaçāo…)

      Reply
      1. Rafael Azevedo

        Sim, estava me referindo a conectividade.

        O objetivo é sim, gerar um ambiente de contigência, onde uma central de processamento de dados, ainda que desconectada da internet, e portanto desconectada do banco de dados disponível em um servidor de alta disponibilidade consiga continuar trabalhando, alterando e inserindo dados, sendo estas alterações enviadas para este banco de alta disponibilidade assim que a conexão for reestabelecida. (Vale considerar que este banco de alta disponibilidade é povoado por centenas de clientes capazes de sincronizar dados em suas bases de dados locais, via SyncFramework). Estou criando um monstro… hehe

        Durante as minhas pesquisas, cheguei a mesma conclusão que você, replicação por merge parece ser a solução mais interessante.

        Estávamos planejando utilizar SQL Server 2008 Express, tanto no servidor de alta disponibilidade quanto na central de processamento de dados, por uma questão financeira. Porém, para este tipo de replicação, o “Publisher” tem que ser de uma versão superior do SQL Server, a Standard que eleva bastante os nossos custos ( estamos utilizando os servidores da Amazon, que cobra por quantidade de conexões, etc… ).

        Estamos considerando manter a instância SQL Express na amazon como (subscriber) de uma instância do SQL Server Standard (publisher) na nossa central de processamento de dados. Acho que sai mais em conta uma licença própria do Standard do que utilizá-lo sobre demanda via Amazon.

        Gostaria sim que me mandasse o cenário que você mencionou no cometário, seria de bastante ajuda.

        Ah, desculpe-me pelo incômodo das perguntas, mas é que tenho tomado tantas decisões arquiteturais importantes baseadas em “achismos” que não resisti a oportunidade de perguntar e expor a minha situação a alguém com mais experiência que eu.

        Valeu mesmo pela disponibilidade!

        Reply
        1. Rodrigo Pelosini Post author

          Olá Rafael. Sāo tantos detalhes que nāo sei por onde começar.

          Começo entāo falando que está correta sua idéia, um sql express ( ao menos a versāo que citou) nāo pode ser um publicador ou distribuidor (publisher ou distributor), por ter principalmente como caracteristica da versāo a ausencia do agente (sql server agent), que é normalmente usado para execuçāo de tarefas de distribuiçāo. Na versāo express, como assinante, beleza.

          Vou partir pro cenário. Dois servidores sql server, um no datacenter do escritorio, outro na fabrica. Na fabrica, temos o ambiente de contigencia, quer dizer, somente se torna o principal caso haja algum problema no escritório. Temos um sistema no escritorio, outro na fabrica, mas somente no escritorio funcionando. Os dados sāo sempre enviados do escritorio pra fabrica, um sentido só, mesmo a replicaçāo sendo merge. Se há um problema no escritorio e a aplicaçāo/banco estiver indisponivel, ativamos o software da fabrica, com a string de conexāo apontada ao sql server da fabrica. Quando se estabelecer o sistema no datacenter do escritorio, tiramos do ar a aplicaçāo da fabrica e colocamos no ar o do escritorio. Neste momento, os dados da fabrica seguem pro escritorio.

          Nāo sei se ficou claro o exemplo, vou te mandar um email em particular. Vale a pena termos contato, aumentando nosso “network”.

          E parabéns, nitidamente se observa que você está com a liçāo de casa feita – e bem feita.

          Grande abraço

          Reply

Deixe uma resposta