Introdução a Replicação e alta disponibilidade no PostgreSQL

Replicação e alta disponibilidade no PostgreSQL

Carlos Eduardo Smanioto

Neste artigo introdutório iremos falar sobre algo que é de grande utilidade para os desenvolvedores e DBAs: múltiplas instâncias do nosso banco de dados para alta disponibilidade, backup ou migração de versão no-downtime (sem queda do oferecimento da informação). Estas são algumas vantagens da replicação com alta disponibilidade.

Neste primeiro artigo vamos explorar o Slony, um software de replicação que em conjunto com outras ferramentas do Linux se torna um forte aliado na alta disponibilidade de servidores PostgreSQL.

Como nas outras vezes, este artigo exige um pouco de conhecimento de instalação do PostgreSQL a partir do código fonte. Foi explicado algo sobre isso nos artigos de tuning do PostgreSQL no Linux (edições 12, 14 e 19 da SQL Magazine).

Entendendo o que é replicação

É a cópia (transmissão) de informações de uma ou mais bases de dados para outra estrutura semelhante. No caso dos SGBDs, é a duplicação de uma determinada “ação” em base de dados separadas logicamente e/ou geograficamente. Em outras palavras, replicação é a sincronização de ações de um SGBD em duas ou mais bases de dados com a mesma estrutura, podendo ser na mesma máquina replicando com ela mesma (separadas logicamente) ou em máquinas distintas (separadas por pontos geográficos).

Toda sincronização é realizada no instante em que a informação se torna consistente no SGBD. Quando isso acontece, podemos ter dois tipos de sincronização: síncrona e assíncrona.

Replicação síncrona (sincronizada)

Neste tipo de sincronização, a replicação da ação é feita instantaneamente. Se alguma cópia do banco é alterada, essa alteração será imediatamente aplicada a todos os outros bancos dentro da transação. A replicação síncrona é apropriada em aplicações comerciais onde é exigido um nível de atualização muito preciso em todos os servidores envolvidos.

Desvantagem

Existem algumas desvantagens neste tipo de replicação. Mas, dentre as principais, podemos citar:

·         Perda sensível da performance;

Uma das grandes explicações para isso é que ao executar uma ação na base “central”, ela irá instantaneamente replicar para as demais dentro da mesma transação do usuário, ou seja, a ação não retorna o “ok final” para o usuário que executou a ação sem que as demais bases estejam atualizadas. Veja o exemplo na Listagem 1.

# Cliente executando um insert:

Insert into teste(1,2,3);

#SGBD replicando o comando no modelo síncrono:

Begin

          Insert into teste(1,2,3);

          Replicar();

end;

Listagem 1. Representação de replicação síncrona.

Replicar() é um comando de replicação interno hipotético. O importante é imaginar aqui que o cliente fica esperando o “end.” da transação para obter novamente o controle da aplicação. Isso porque a maioria das ferramentas de replicação síncrona utiliza triggers para chamar o agente replicador.

·         Exige um meio de transmissão de dados de alta velocidade com padrão de qualidade superior ao modelo de replicação assíncrona;

Como dá para imaginar, o sucesso deste modelo exige métodos de transmissão de dados de grande eficácia e eficiência. Dificilmente será possível, por exemplo, utilizar uma assinatura ADSL “padrão” oferecido pelas empresas de telefonia brasileiras. Serão necessários serviços específicos e, dependendo muito do “volume diário de dados replicado”, uma grande quantidade de banda.

Replicação assíncrona (não sincronizada)

Neste modelo a replicação não é instantânea. O replicador monta um histórico das ações a serem replicadas e em um determinado momento é feita a replicação entre as bases de dados relacionadas. A alteração será propagada e aplicada para outra base em um segundo passo, dentro de uma transação separada. Esta poderá ocorrer em segundos, minutos, horas ou até dias depois, dependendo da configuração pré-estabelecida.

Desvantagem

·         Consumo de recursos das máquinas envolvidas acima do normal no momento da replicação;

Isso é um fator negativo, pois o SGBD perde o poder de resposta nos momentos que está replicando. Logicamente, esta é uma verdade apenas para grandes volumes de dados.

·         As informações nas máquinas envolvidas não estarão o tempo todo atualizadas.

Este é um dos grandes problemas da replicação, as máquinas envolvidas na replicação ficarão desatualizadas até que o processo de replicação seja iniciado.

Soluções de replicação no PostgreSQL

Vamos estudar um pouco de cada solução de replicação. Conhecer cada ferramenta é importante no mundo open source devido ao amadurecimento rápido (ou às vezes demorado) do código. O que há em comum nas ferramentas que serão aqui apresentadas é que são recém nascidas, mas muito poderosas.

PgCluster

O primeiro a analisarmos rapidamente é o PgCluster. O grande diferencial deste sistema é a replicação baseada na query, ou seja, o cliente executa uma instrução SQL e esta instrução pode ser executada nos demais clusters. Abaixo alguns pontos sobre o produto:

·         Replicação síncrona incluindo balanceamento de carga;

·         Pode ser encontrado em http://pgcluster.projects.postgresql.org;

·         Não se tem conhecimento da estabilidade e desempenho.

PgPool

PgPool é um connection pool server para PostgreSQL, ou seja,  é uma camada entre o cliente (front end) e o servidor (back end). Assemelha-se com o PgCluster porém, como Pool, faz caches das conexões com o PostgreSQL reduzindo o overhead e aliviando assim o banco. É possível também usá-lo para prover alta disponibilidade já que o pgpool foi projetado não somente para fazer cache, mas também replicação. Veja abaixo algumas de suas possíveis implementações:

·         Implementa Pool de conexão sem alterar a aplicação cliente;

·         Balanceamento de carga;

·         Cache de conexões;

·         Replicação síncrona;

·         Transfere as conexões para um segundo servidor caso o primeiro caia;

·         Pode ser encontrado em http://pgpool.projects.postgresql.org/.

pgReplicator

pgReplicator é uma ferramenta de replicação assíncrona. O pgReplicator é baseado na linguagem procedural interpretada TCL com o PostgreSQL como contêiner. Como características do produto, posso citar:

·         “Armazena e encaminha” – replicação assíncrona (via script.sql);

·         Projeto parado;

·         Pode ser encontrado em http://pgreplicator.sourceforge.net.

Daffodil Replicator

Daffodil Replicator é um software de replicação com suporte bidirecional (Figura 1): sincronização de todas as mudanças feitas pelos subscritores (Slave) e pelo publisher (master) periodicamente ou on-demand (quando necessitar das informações). Para resolver conflitos, são predefinidos algoritmos entre o publisher e os subscritores. A replicação bi-direcional é usada, por exemplo, em uma rede de lojas no qual existe a necessidade de compartilhamento de informações. O grande diferencial do Daffodil Replicator é a replicação de SGBDs heterogêneos/homogêneos. Ele permite a replicação entre Oracle, SQL Server, DB2, Daffodil DB, PostgreSQL e Derbv (Figura 2).

O Daffodil Replicator é baseado no conceito de “Publish and Subcribe” (na arquitetura cliente servidor). O publish é a coleção de uma ou mais tabelas necessárias para a replicação. Já o subscription é a cópia das tabelas envolvidas no publish em uma camada cliente. Basicamente podemos dizer que o publish é o MASTER e o subscribe é o SLAVE.

Na Figura 2, vemos o servidor Publisher (MASTER), que pode ser um Oracle, SQL Server, PostgreSQL, Daffodil DB, Derby, enviando dados para todos os servidores subscriber (Slave). Observe que cada servidor possui uma API Daffodil. No caso dos Subscriber, a API CLIENT e no Publisher, a API MASTER. Outro ponto que vale destacar é que cada Subscriber está usando um SGBDs diferente.

Figura 1. Diagrama da replicação do Daffodil Replicator.

Figura 2. Diagrama de funcionamento da API Java do Daffodil Replicator.

Dentre as características do Daffodil Replicator, posso citar:

·         Replicação entre os principais SGBDs do mercado;

·         Replicação bidirecional (Figura 1);

·         Desenvolvido em JAVA (Figura 2);

·         Pode ser encontrado em http://www.daffodildb.com/replicator/dbreplicator.html.

Slony - I

Slony-I é um software de replicação que segue o modelo “master para múltiplos slaves” com “cascateamento” de slaves e failover. Isto significa que no caso da queda de um MASTER, um dos SLAVEs assume como novo MASTER e caso um dos SLAVEs responsável pela transmissão dos dados para outros SLAVEs também “caia”, o SLONY-I pode usar uma rota alternativa (Figuras 3 e 4). Vejamos a baixo algumas características do SLONY - I:

·         Replicação Master para múltiplos Slaves (Figura 3);

·         Replicação assíncrona;

·         É possível criar vários níveis de Slave (Figura 3);

·         Mecanismo para promover um Slave para um Master se este cair (Figura 4);

·         Backup e point-in-time; ...