Hoje um e-mail na lista do PostgreSQL me levou inspirou a escrever este texto. A questão é que muitas pessoas confundem replicação com clustering. A confusão não é a tôa… a palavra Cluster possui vários significados diferentes dependendo do contexto. Temos a idéia de tabelas clusterizadas, que possuem significado diferente no Oracle e PostgreSQL por exemplo e por sua vez não tem nada a ver com o conceito de cluster de SGDB. O PostgreSQL chama de Cluster o conjunto de banco de dados gerenciados por uma única instância (conjunto de datafiles, arquivos de controle e processos no servidor que formam um SGDB). O PGCluster apesar do nome, é uma solução de replicação e não de clustering! Algumas soluções proprietárias também gostam de adotar o status de Cluster, quando na verdade se tratam de soluções de replicação. O princípio da replicação é a de ter cópias de dados em mais de um banco de dados que possam ser sincronizadas entre si. O princípio do cluster é ter vários SGDBs se comportando como se fossem uma só instância de forma transparente para a aplicação. Veja por exemplo que o conceito de Grid, que a Oracle adotou como buzz word, não existe de fato em banco de dados!

Quando falamos em Cluster de banco de dados, pensamos em 3 tipos de clusters:

Quando falamos em Replicação de banco de dados, pensamos em 4 tipos de replicação orientados por 2 paradigmas distintos:

Vejamos algumas diferenças entre replicação e cluster:

A replicação pode ser parcial ou total (em relação aos objetos do banco de dados), enquanto o cluster é sempre total em relação a uma instância do banco de dados (no caso do PostgreSQL seria em relação a um cluster criado pelo initdb).

Em princípio, parece que uma uma replicação MultiMaster síncrona é equivalente a um Cluster Shared Nothing. No entanto, note que um Cluster Shared Nothing cada nó possui apenas uma fatia do banco de dados em seu storage enquanto na replicação MultiMaster síncrona, cada nó possui uma cópia completa dos dados. Cada técnica de cluster e replicação tem diversos tipos de implementações servindo para diferentes propósitos e com diferentes limitações. Saber distinguir cada um deles é fundamental para saber por onde começar a procurar por uma solução adequada para cada tipo de problema, seja ele de alta disponibilidade, balanceamento de carga ou de bancos de dados distribuídos.

O PostgreSQL conta hoje com várias soluções de Replicação Assíncrona Master/Slave que vai do Stand By (implementado no PostgreSQL padrão), Slony I e outros. O PgPool I e II é não são exatamente soluções de replicação e sim de pool de conexões com suporte a um tipo de replicação síncrona. A única solução de replicação MultiMaster Síncrona existente hoje é o PGCluster. O projeto do Slony II pretendia ser uma nova implementação deste tipo mas foi abandonado devida a alta complexidade do projeto. O PGCluster II pretende ser uma implementação de Cluster Shared All (no mesmo estilo do Oracle RAC), mas o projeto ainda é muito recente para se saber se ele será bem sucedido.

Para saber mais veja:

12 respostas

  1. Olá,

    Só acho que as soluções de replicação do Postgre pecam por não estarem integradas ao banco nativamente. Não conheço o Oracle, mas o DB2 tem soluções assim de forma, digamos, simplificada e integrada.
    Veja o Slony, por exemplo: um emaranhado de criação de triggers em tabelas e que não contemplam as alterações DDL feitas nessas.

    Mas o time de desenvolvimento do Post, principalmente seu ‘timoneiro’ Tom Lane, parecem não estar muito entusiasmados com isso.

    Parabéns pelo blog!

  2. Particularmente eu acho desnecessário colocar tudo dentro do SGDB. Veja, existem várias soluções diferentes. Como escolher qual solução integrar dentro do PostgreSQL?

    Uma vez que replicação não é realmente uma opção standard, acho que não há problemas em deixa-la de fora. A instalação inclusive fica mais enxuta. Mas quem sabe se um dia tivermos uma solução killer isto não possa vir a acontecer?

  3. presico de alquem para fazer esse servico favor entra em contato comigo pelo email

  4. Caro Telles,

    Muito obrigado por este artigo! Estou a fazer um trabalho para a faculdade em que tenho que fazer um pequeno estudo de mercado de SGBDs… Quanto mais documentação dos SGBDs lia, mais a confusão se instalava na minha cabeça. Agora será mais fácil fazer o levantamento das funcionalidades de forma correcta.

    Muito obrigado e um abraço do outro lado do Oceano Atlântico!
    João

  5. Olá boa noite, parabéns pelo tópico estou com o mesmo problema e espero a mesmo solução mas ate o momento não sei nem por onde começar, se por um acaso o senhor puder me enviar algun material te agradeço de coração trabalho com vb.net e bd mysql

    jsguaruja@hotmail.com

    Guarujá SP

  6. Um erro grosseiro – de palmatória, diria a minha velha professora de Português! – tira o mérito a este trabalho que pretende ser didáctico e cultural: na 4ª linha em vez de ser “haver” deve ser escrito “a ver”.

    1. Se eu apanhasse cada vez que cometo um erro de ortografia, já estaria morto, por linchamento… hahahaha. Por outro lado, se eu fosse muito rigoroso com a escrita o processo todo se tornaria muito chato e penoso e eu escreveria menos. A sorte é que na Web é mais simples corrigir e os leitores são os primeiros a me ajudar…

      O erro foi corrigido. Obrigado pelo toque.

Deixe uma resposta