carlos augusto paiva

UNIVERSIDADE FEDERAL DE SERGIPECAMPUS PROF. ALBERTO CARVALHO

DEPARTAMENTO DE SISTEMAS DE INFORMAÇÃO

MATHEUS DOS SANTOS LIMA

APLICAÇÃO DE ESTRATÉGIAS DE REPLICAÇÃO DE BASES DE DADOS EM SISTEMAS GERENCIADORES DE

BANCO DE DADOSITABAIANA

2011

UNIVERSIDADE FEDERAL DE SERGIPECAMPUS PROF. ALBERTO CARVALHO

DEPARTAMENTO DE SISTEMAS DE INFORMAÇÃOMATHEUS DOS SANTOS LIMA


BANCO DE DADOSTrabalho de Conclusão de

Curso submetido ao Departamento

de Sistemas de Informação da

Universidade Federal de Sergipe

como requisito parcial para a

obtenção do título de Bacharel em

Sistemas de Informação.

Orientador: Msc. André Vinicius Rodrigues Passos Nascimento

ITABAIANA

2011

Lima, Matheus do Santos.

Aplicação de Estratégias de Replicação de Bases de Dados

em Sistemas Gerenciadores de Banco de Dados / Matheus dos

Santos Lima – Itabaiana: UFS, 2011.

49 f. 27 cm

Trabalho de Conclusão de Curso (graduação) –

Universidade Federal de Sergipe, Curso de Sistemas de

Informação, 2011.

MATHEUS DOS SANTOS LIMA


BANCO DE DADOS

Trabalho de Conclusão de Curso submetido ao corpo docente do Departamento de

Sistemas de Informação da Universidade Federal de Sergipe (DSIITA/UFS) como parte dos

requisitos para obtenção do grau de Bacharel em Sistemas de Informação

Itabaiana, ([dia] , [mês] e [ano] da aprovação).

BANCA EXAMINADORA:

____________________________________________________

Prof André Vinicius Rodrigues Passos Nascimento, Msc.

Orientador

DSIITA/UFS

_______________________________________________

Prof Methanias Colaço Júnior, Dr.

DSIITA/UFS

_______________________________________________

Prof Andrés Ignácio Martínez Menéndez, Msc.

DSIITA/UFS

Dedico a

Jordana Naftali Bomfim Lima

AGRADECIMENTOS

Agradeço, primeiro, a Deus, porque esteve sempre presente mesmo quando eu estava

ausente..

Ao meu orientador, Prof. Msc. André Vinicius R. P. Nascimento, por ter dedicado

parte do seu tempo a me orientar nessa busca por conhecimento, tirando minhas dúvidas e

sendo exemplo de dedicação.

Aos meus professores, pelo comprometimento com minha formação acadêmica e dos

meus colegas; sendo verdadeiros mestres! E por terem me entusiasmado mais a cada dia,

durante minha formação.

Aos meus colegas de curso, que uniram forças, caminharam juntos e compartilharam

conhecimentos ao longo do curso.

À minha namorada Jordana Naftali, pela atenção, apoio, amor e carinho dedicados a

mim. Por ter compreendido e aberto mão do nosso tempo para que pudesse me dedicar a este

trabalho.

À minha família pelo apoio e cobrança, que foram fundamentais para conclusão do

trabalho.

“Levei vinte anos para fazer sucesso da noite para o dia.”

(Eddie Cantor)

LIMA, Matheus dos Santos. Aplicação de Estratégias de Replicação de Bases

de Dados em Sistemas Gerenciadores de Banco de Dados. 2011. Trabalho de

Conclusão de Curso – Curso de Sistemas de Informação, Departamento de Sistemas de

Informação, Universidade Federal de Sergipe, Itabaiana, 2011.

RESUMO

Replicação de Bases de Dados pode ser entendida como um conjunto de técnicas

utilizadas para manter cópias consistentes de um mesmo item de dado em diferentes bancos

de dados. Os principais objetivos da replicação são: alcançar melhor desempenho e aumento

de disponibilidade. A melhoria do desempenho é alcançada através da utilização de cópias

locais, eliminando, dessa forma, a necessidade de conexões remotas. O aumento da

disponibilidade é alcançado através da existência de cópias de um mesmo item de dado. Uma

vez que uma base dados, por algum motivo, fica indisponível, um sistema de informação pode

passar a consultar os dados na réplica até que o problema seja resolvido. Esse trabalho tem

por objetivo estudar as principais arquiteturas e estratégias de propagação de atualizações

utilizadas no processo de replicação de bases de dados, e verificar a implementação dessas

arquiteturas e estratégias, ou suas variações, nos principais Sistemas Gerenciadores de

Banco de Dados Relacionais.

Palavras-chave: Banco de Dados. Replicação. Disponibilidade.

ABSTRACT

Database replication can be understood as a set of techniques used to maintain

consistent copies of the same item of data in different databases. The main objectives that

replication intend to achieve are better performance and availability. The performance

improvement is achieved through the use of local copies, thereby eliminating the need

for remote connections. Increased availability is achieved through the existence of copies of

the same data item. Once a database, for some reason, is unavailable, an information

system can move on to query the data in the replica until the problem is resolved. This

work aims to study the main architectures and update propagation strategies used in

database replication, and verify the implementation of these architectures and strategies,

or variations, among some of the most widely used Relational Database

Management Systems.

Key-words: Database. Replication. Availability.

LISTA DE FIGURAS

Figura 1 – Arquitetura Primary Copy...........................................................................20

Figura 2 – Arquitetura Update Everywhere..................................................................21

Figura 3 - Eager Primary Copy.....................................................................................23

Figura 4 - Eager Update Everywhere............................................................................24

Figura 5 - Lazy Primary Copy......................................................................................25

Figura 6 - Lazy Update Everywhere.............................................................................26

Figura 7 – Modelo Publicador/Assinante......................................................................28

Figura 8 - Snapshot Replication....................................................................................32

Figura 9 - Transactional Replication.............................................................................34

Figura 10 - Merge Replication......................................................................................35

Figura 11 – Modelo de dados de exemplo....................................................................37

Figura 12 – Configure Distribution...............................................................................38

Figura 13 – Selecionar Distribuidor..............................................................................39

Figura 14 – Selecionar pasta de Snapdshot...................................................................40

Figura 15 – Selecionar Base de Distribuição................................................................41

Figura 16 – Selecionar Publicador................................................................................42

Figura 17 – Finalizando configuração do Distribuidor................................................43

Figura 18 – Status da configuração do Distribuidor.....................................................44

Figura 19 – Nova Publicação........................................................................................45

Figura 20 – Selecionando Publicador para nova Publicação........................................46

Figura 21 – Selecionando tipo de Publicação...............................................................47

Figura 22 – Escolhendo Artigos....................................................................................48

Figura 23 – Filtrando Artigos........................................................................................49

Figura 24 – Agendamento de Snapshot........................................................................50

Figura 25 – Parâmetros para agendamento de Sanpshot...............................................51

Figura 26 – Configurações de segurança do Agente.....................................................52

Figura 27 – Parâmetros de login do Snapshot Agent....................................................53

Figura 28 – Finalizando a configuração da nova Publicação........................................54

Figura 29 – Status da configuração da nova Publicação...............................................55

Figura 30 – Nova Assinatura.........................................................................................56

Figura 31 – Selecionando Publicador para a Assinatura...............................................57

Figura 32 – Local de execução do Agente....................................................................58

Figura 33 - Assinantes...................................................................................................59

Figura 34 – Logando no servidor Assinante.................................................................59

Figura 35 – Base de Dados que receberá a Assinatura.................................................60

Figura 36 – Configuração de segurança do Distribuidor..............................................61

Figura 37 – Parâmetros de login do Distribuidor..........................................................62

Figura 38 – Intervalo de sincronização.........................................................................63

Figura 39 – Preparando a inicialização da Assinatura..................................................64

Figura 40 – Status da configuração da Assinatura........................................................65

Figura 41 – Tabelas replicadas no Assinante................................................................66

Figura 42 - Arquitetura do Pgpool................................................................................69

LISTA DE TABELAS

Tabela 1 – Matriz Estratégias de Replicação X Arquitetura.........................................22

SUMÁRIO

1 Introdução...............................................................................................................15

1.1 Objetivos.........................................................................................................16

1.1.1 Objetivo Geral...........................................................................................16

1.1.2 Objetivos específicos.................................................................................16

1.2 Relevância do Trabalho...................................................................................16

1.3 Metodologia....................................................................................................17

1.4 Estrutura do Trabalho......................................................................................17

2 Replicação de Bases de Dados...............................................................................19

2.1 Esquemas de Replicação.................................................................................20

2.1.1 Arquitetura.................................................................................................20

2.1.2 Estratégias de propagação.........................................................................22

2.1.3 Estratégias de Propagação x Arquitetura...................................................22

3 Replicação no SGBD Microsoft SQL Server.........................................................27

3.1 Modelo de Replicação.....................................................................................27

3.2 Tipos de Replicação........................................................................................30

3.2.1 Snapshot Replication.................................................................................31

3.2.2 Transactional Replication..........................................................................32

3.2.3 Merge Replication.....................................................................................34

3.3 Estudo de Caso................................................................................................36

3.3.1 Configurando a Replicação.......................................................................37

3.4 Considerações..................................................................................................67

4 PostgreSQL.............................................................................................................68

4.1 Pgpool-II..........................................................................................................68

4.1.1 Configurando o Pgpool-II..........................................................................70

4.2 Slony-I.............................................................................................................73

4.2.1 Configurando o Slony-I.............................................................................74

13

4.3 PGCluster........................................................................................................77

4.3.1 Configurando o PGCluster........................................................................78

4.4 Postgres-R.......................................................................................................84

4.5 Considerações..................................................................................................85

5 Conclusões e Trabalhos Futuros.............................................................................86

6 Referências.............................................................................................................87

14

1 Introdução

Replicação de Bases de Dados pode ser entendida como um conjunto de técnicas

utilizadas para manter cópias consistentes de um mesmo item de dado em diferentes bancos

de dados. A utilização dessas técnicas possui como principais objetivos a melhoria do

desempenho na execução de operações e o aumento da disponibilidade (BERNSTEIN ,1997).

A melhoria do desempenho é alcançada através da utilização de cópias locais,

eliminando, dessa forma, a necessidade de conexões remotas. Nesses casos, as operações de

leitura apresentam um comportamento semelhante às operações em bases sem replicação. As

operações de escrita, no entanto, precisam de algum tipo de coordenação entre as diferentes

réplicas para que as informações permaneçam consistentes em todas as bases envolvidas no

processo de replicação. (WIESMANN,2000a).

O aumento da disponibilidade também é alcançado através da existência de cópias de

um mesmo item de dado. Uma vez que uma base dados, por algum motivo, fica indisponível,

um sistema de informação pode passar a consultar os dados na réplica até que o problema seja

resolvido. Tudo isso deve ocorrer de forma transparente para o cliente, seja ele um usuário ou

aplicação. (WIESMANN, 2000b).

Existem diferentes classificações ou parâmetros que categorizam os tipos de

replicação existentes (GRAY, 1996) (WIESMANN, 2000b) (BERNSTEIN ,1997). No

entanto, é possível identificar dois critérios comuns para classificar os tipos de replicação: a)

Arquitetura e b) Estratégia de Propagação de Atualizações.

Esse trabalho, portanto, tem por objetivo estudar as principais arquiteturas e

estratégias de propagação de atualizações utilizadas no processo de replicação de bases de

dados, e verificar a implementação dessas arquiteturas e estratégias, ou suas variações, nos

principais Sistemas Gerenciadores de Banco de Dados Relacionais.

15

1.1 Objetivos

1.1.1 Objetivo Geral

Estudar a disciplina Replicação de Bases de Dados, suas principais arquiteturas e

estratégias de propagação de atualizações, e apresentar a implementação dessas arquiteturas e

estratégias em alguns dos principais Sistemas Gerenciadores de Banco de Dados Relacionais.

1.1.2 Objetivos específicos

Realizar uma revisão bibliográfica e reunir conhecimento sobre abordagens de

replicação de bases de dados;

Analisar a implementação de replicação ou variações das estratégias existentes na

literatura nos Sistemas Gerenciadores de Banco de Dados Relacionais Microsoft

SQL Server e PostgreSQL;

Realizar um estudo de caso e observar as diferentes implementações ou variações

em relação à arquitetura, características e conformidade com as estratégias

apontadas na revisão da literatura.

1.2 Relevância do Trabalho

Os sistemas de informação estão cada vez mais presentes no cotidiano das pessoas,

sejam em sistemas corporativos, softwares de entretenimento, comércios eletrônicos e muitos

outros ambientes. Os sistemas computacionais vêm sendo introduzidos em tarefas básicas e

essenciais, tornando pessoas e corporações dependentes dessas tecnologias.

A falta de operação de um serviço computacional pode trazer muitos transtornos e

prejuízos. Para solucionar esse problema, surgem os sistemas de alta disponibilidade, nos

quais a idéia é manter o serviço funcionando, mesmo em caso de falha em um dos

componentes. Uma forma comum de se alcançar sistemas de alta disponibilidade é usar

técnicas de replicação de banco de dados, visto que uma das falhas de maior impacto ocorre

quando o acesso aos dados se torna indisponível.

As literaturas direcionadas para determinadas tecnologias relacionais apresentam

apenas as soluções implementadas e carecem de uma explicação das várias soluções de

replicação existentes. Essa falta pode induzir à utilização de arquiteturas e estratégias não

16

adequadas em função do casamento com determinado produto (CIPRIANI, 2009) (PARTIO,

2007) (PAUL, 2009) (DESHPANDE, 2010).

Por outro lado, as literaturas que apresentam a disciplina de replicação de bases de

dados independente de tecnologia carecem de estudos de caso práticos que apresentem as

particularidades de determinado produto e os passos necessários para implementar

efetivamente uma estratégia de replicação (WIESMANN, 2000) (GRAY, HELLAND e

O'NEIL, 1996) (BERNSTEIN e NEWCOMER, 1997).

Em função desse cenário, esse trabalho possui relevância quando combina a teoria e

prática sobre a disciplina Replicação de Bases de Dados, facilitando, dessa forma, o

entendimento da área independente de tecnologia e, ao mesmo tempo, documentando os

passos necessários para a implantação efetiva de estratégias de replicação em alguns dos

principais Sistemas Gerenciadores de Bancos de Dados Relacionais.

1.3 Metodologia

Inicialmente, será realizado um levantamento bibliográfico sobre as principais

arquiteturas e estratégias de propagação de atualizações para replicação de bases de dados. A

partir desse levantamento, será escrito um capítulo que resume a teoria necessária para o

entendimento das soluções existentes. Em seguida, serão estudadas as arquiteturas e

estratégias disponíveis nos SGBDs Microsft SQL Server e PostgreSQL. Esse estudo envolve

a investigação de implementações nativas, assim como a utilização de componentes de

terceiros. Após esse estudo, serão criados ambientes e estudos de caso para apresentar, passo a

passo, como implantar a replicação nas tecnologias investigadas. As ferramentas de apoio

necessárias para a realização do trabalho serão os sistemas gerenciadores de banco de dados

utilizados, Microsoft SQL Server e PostgreSQL, e os componentes de terceiros necessários.

1.4 Estrutura do Trabalho

O Capítulo 2 deste trabalho apresenta os principais conceitos sobre Replicação de

Bases de Dados, resumindo as principais arquiteturas, estratégias de propagação de

atualizações e modelos de replicação.

17

O Capítulo 3, dedicado ao SGBD Microsoft SQL Server, apresenta o modelo de

replicação utilizado, os componentes envolvidos e os três tipos de replicação disponíveis:

Snapshot, Transactional e Merge.

O Capítulo 4 apresenta as soluções de replicação disponíveis para o SGBD

PostgreSQL. São abordados os seguintes componentes: Pgpool-II, Slony-I, PGCluster e

Postgres-R. Nos 3 e 4 são apresentados, respectivamente, o SQL Server e o PostgreSQL,

destacando como cada um implementa a replicação de banco de dados..

Finalmente, no capítulo 5, são apresentadas as conclusões sobre as investigações

efetuadas sobre as soluções de replicação das duas ferramentas utilizadas.

18

2 Replicação de Bases de Dados

Replicação é a técnica de usar múltiplas cópias de um servidor para melhor

disponibilidade e desempenho. Cada cópia do servidor é chamada de réplica (BERNSTEIN &

NEWCOMER, 1997). Deste modo, replicação de banco de dados são réplicas de servidores

de banco de dados que trabalham em paralelo para garantir maior disponibilidade do serviço.

Replicação em sistemas de banco de dados é realizada principalmente por razões de

desempenho. O objetivo é acessar os dados localmente para melhorar o tempo de resposta e

eliminar a sobrecarga de se comunicar com sites remotos. Esse objetivo é facilmente

alcançado quando as operações são apenas de leitura de dados. No entanto, quando existem

operações de atualização exige-se algum tipo de coordenação entre as réplicas (WIESMANN,

2000).

Existem diversos tipos de replicação. Esses tipos são definidos através da combinação

de arquiteturas que regulam as atualizações com estratégias de propagação de atualizações.

Essas várias combinações devem ser devidamente selecionadas de acordo com o ambiente no

qual será aplicada a replicação. As arquiteturas e estratégias apresentadas são implementadas

pelos principais sistemas gerenciadores de banco de dados. No entanto, cada sistema, em

função de sua arquitetura, apresenta características particulares.

Esse capítulo apresenta as principais arquiteturas de replicação, as principais

estratégias de atualização e os esquemas de replicação resultantes das combinações possíveis

entre arquitetura e estratégias.

19

2.1 Esquemas de Replicação

Os esquemas de replicação surgem a partir da combinação de tipos de replicação de

dados que são classificados a partir de dois principais parâmetros: Arquitetura do servidor e

estratégia de propagação de atualizações (WIESMANN, 2000). No decorrer deste capítulo

cada um desses parâmetros será abordado.

2.1.1 Arquitetura

O parâmetro arquitetura dá origem a dois tipos de replicação: Primary Copy e Update

Everywhere. A diferença entre os dois tipos está na determinação dos servidores que podem

iniciar modificações no banco de dados (WIESMANN, 2000).

2.1.1.1 Primary Copy

A arquitetura Primary Copy, como o nome sugere, requer uma cópia principal,

responsável por todas as atualizações que podem ocorrer na base de dados. O servidor

principal é responsável por organizar e ordenar as atualizações e em seguida replicar para as

demais cópias, que são chamadas de secundárias. As cópias secundárias só podem receber

atualizações replicadas da cópia primária. A Figura 1 é uma representação da arquitetura

Primary Copy.

Figura 1 – Arquitetura Primary Copy

20

Embora simples do ponto de vista de controle de replicação, essa arquitetura cria uma

grande dependência com a cópia primária, pois é a única responsável pelas atualizações. Para

solucionar esse problema, podem ser criadas mais de uma cópia primária. Nessa variação de

arquitetura, quando ocorre uma falha em uma cópia primária e a mesma fica indisponível,

existe um protocolo de eleição que elege uma nova cópia que assumirá a responsabilidade das

atualizações.

2.1.1.2 Update Everywhere

A arquitetura Update Everywhere permite que as atualizações de dados sejam feitas

em todas as cópias, podendo chegar simultaneamente de duas cópias diferentes, como mostra

a Figura 2.

Figura 2 – Arquitetura Update Everywhere

Essa arquitetura soluciona algumas questões de desempenho da arquitetura Primary

Copy, que só permite atualizações na cópia primária. Da mesma forma, essa arquitetura

também é mais eficiente ao lidar com falhas, já que não é necessário executar nenhum

protocolo de eleição em caso de falhas. Porém, essa arquitetura também pode comprometer o

desempenho da aplicação se não for bem projetada, exigindo que todas as cópias façam o

mesmo trabalho.

21

2.1.2 Estratégias de propagação

Quando uma atualização é feita em uma das cópias, ela precisa ser propagada para as

demais. A forma como essa propagação é feita, é chamada de estratégia de propagação de

atualizações. Existem duas estratégias de propagação de atualizações: Eager Replication

(síncrona) e Lazy Replication (assíncrona) (WIESMANN, 2000).

Na Eager Replication, a propagação das atualizações para os demais servidores faz

parte da transação. Assim, sempre que uma alteração é aplicada ela é imediatamente

propagada para os demais servidores, e só após a atualização de todos os servidores, o cliente

recebe a resposta. Isso garante maior consistência, porém a transação percorre um caminho

maior, deixando as alterações mais lentas.

Na Lazy Replication, a propagação não faz parte da transação. A transação é

executada na cópia principal e os registros de alterações são salvos. Após algum tempo, as

alterações são propagadas para as cópias secundárias. Nessa estratégia, o cliente recebe a

resposta assim que a alteração é feita na cópia primária. Essa estratégia é mais propícia a

causar inconsistências, pois os dados ficam divergentes durante um período de tempo.

2.1.3 Estratégias de Propagação x Arquitetura

Os esquemas de replicação surgem a partir da combinação entre estratégias de

propagação e arquitetura. Esta sessão apresenta os principais esquemas de replicação.

A Tabela 1 representa a matriz dessa combinação.

Esratégias de Propagação

Arq

uite

tura

Eager

Primary Copy

Lazy

Primary Copy

Eager

Update Everywhere

Lazy

Update Everywhere

Tabela 1 – Matriz Estratégias de Replicação X Arquitetura

Esta combinação gera 4 esquemas distintos: Eager Primary Copy, Eager Update

Everywhere, Lazy Primary Copy e Lazy Update Everywhere.

22

A seguir, será apresentada uma explicação mais detalhada sobre cada esquema.

2.1.3.1 Eager Primary Copy

No Eager Primary Copy, os nós mestres são donos dos objetos, sendo assim, apenas

eles podem fazer alterações, como mostra a Figura 3 (WIESMANN, 2000).

Figura 3 - Eager Primary Copy

Quando uma alteração é requisitada, é criada uma transação e a alteração é feita no nó

mestre. Em seguida, o nó mestre envia a réplica da atualização para os nós escravos. Assim

que todos os nós escravos são atualizados sem problemas, a transação é finalizada sem erros.

Caso uma réplica falhe, toda a transação falha e nenhuma atualização é feita.

2.1.3.2 Eager Update Everywhere

Neste esquema, representado pela Figura 4, todos os nós são donos do objeto, assim,

todos podem fazer alterações e replicar para todos os outros nós (WIESMANN, 2000).

23

Semelhante ao Eager Primary Copy, uma transação é iniciada quando uma requisição

de alteração chega a um nó. Essa alteração é marcada com o timestamp do objeto antigo.

Quando a alteração é feita neste nó, ele replica para os demais nós. Quando um nó recebe a

réplica de atualização, ele verifica se o timestamp do objeto replicado é igual ou maior que a

do objeto local. Se assim for, a atualização é segura e assim ela é aplicada e a transação

finalizada com êxito. Caso o timestamp do objeto replicado seja inferior ao do objeto local, a

atualização pode ser obsoleta. Então ela não é aplicada e é enviada para conciliação, podendo

falhar ou não a replicação. Caso falhe, a transação inteira falha e nenhuma alteração é

aplicada.

2.1.3.3 Lazy Primary Copy

Este esquema possui um proprietário para cada objeto (GRAY, HELLAND e O'NEIL,

1996). Cada proprietário possui o valor correto de objeto atual.

Figura 4 - Eager Update Everywhere

24

Como mostra a Figura 5, As atualizações são feitas primeiramente no proprietário e,

em seguida, propagadas para as outras réplicas. Objetos diferentes podem ter diferentes

proprietários. Quando uma transação quer atualizar um objeto, ela envia um RPC (Remote

Procedure Call) para o nó proprietário do objeto.. Para simplificar, assumimos que o nó de

origem transmite a réplica de atualização para todas as réplicas escravas após a transação

mestre ser finalizada.. Atualizações escravas são marcadas com timestamp para garantir que

todas as réplicas irão convergir para o mesmo estado final. Se o timestamp de uma réplica

escrava é maior que o timestamp da atualização, a atualização é obsoleta. Nesse caso a

atualização é ignorada.

2.1.3.4 Lazy Update Everywhere

O esquema de replicação Lazy Update Everywhere permite que qualquer nó atualize

qualquer dado local (GRAY, HELLAND e O'NEIL, 1996). Este modelo é representado na

Figura 6.

Figura 5 - Lazy Primary Copy

25

Quando a transação é confirmada, uma transação é enviada para os outros nós para

aplicar o conjunto de atualizações em cada nó de destino.

É possível que dois nós atualizem o mesmo objeto e concorram entre si para atualizar

o objeto em outros nós. O mecanismo de replicação deve detectar e conciliar as duas

transações de forma que suas alterações não sejam perdidas.

Timestamps são comumente usados para detectar e conciliar as atualizações. Cada

objeto traz a timestamp de sua atualização mais recente. Cada atualização replicada carrega o

novo valor e é marcado com o timestamp do objeto antigo. Cada nó detecta a entrada de

atualizações por replicação que possam sobrescrever atualizações anteriores. O nó testa se o

timestamp da réplica local é igual ao da atualização. Se assim for, a atualização é segura. Se o

timestamp atual da réplica não for igual ao timestamp antigo observado pela transação raiz,

então a atualização pode ser perigosa. Nesses casos o nó rejeita a transação de entrada e envia

para a reconciliação.

Figura 6 - Lazy Update Everywhere

26

Publicador

Distribuidor

As Publicações são transmitidas para os Distribuidores

3 Replicação no SGBD Microsoft SQL Server

O SGBD Microsoft SQL Server1 apresenta diferentes tipos de replicação de bases de

dados, que podem variar de acordo com a versão e edição do produto. Na versão e edição

analisada, 2008 Enterprise, o SQL Server oferece três tipos de replicação com base na

estratégia assíncrona (Lazy Replication): Snapshot, Transactional e Merge (PAUL, 2009).

Este capítulo apresenta o modelo de replicação utilizado pelo SGBD SQL Server,

assim como os vários componentes necessários para sua implantação. São apresentados,

também, os três tipos de replicação suportados. Ao final, é apresentado um estudo de caso

seguido de um passo a passo que mostra como configurar um ambiente de replicação.

3.1 Modelo de Replicação

Quando se faz replicação com o SQL Server, o primeiro conceito que se deve entender

é o modelo de replicação Publicador/Assinante. O modelo Publicador-Assinante é baseado em

uma metáfora do mercado da indústria de publicações. Segundo Yang, “Publicador/Assinante

é um modelo de distribuição de dados com propriedades muito úteis. Há três principais

entidades no modelo Publicador/Assinante: o Publicador, o Assinante e o Intermediário”

(2010, p. 66). Essa representação lógica é seguida por pelo SQL Server.

O modelo Publicador/Assinante pode ser representado pela seguinte representação:

Existe um Publicador que publica livros. Um livro (Publicação) com vários capítulos

(Artigo) foi lançado e um Assinante precisa adquirir esse livro. Para que o livro seja entregue

ao assinante, o publicador precisa de um meio de distribuição confiável que leve seu livro até

o assinante. Desta forma, o Publicador contrata um Distribuidor que será responsável por

fazer a entrega do livro ao assinante.

1 Lançado em 1989 através de uma parceira entre as empresas Microsoft e Sybase, o SGBD

SQL Server divide com seus principais concorrentes, Oracle e DB2, parcelas significativas do

mercado de SGBDs Relacionais (MULLINS, 2011)

Figura 7 – Modelo Publicador/Assinante

27

Na Figura 7 podem ser identificados alguns dos componentes de replicação do SQL

Server. A replicação é implementada por sete componentes: Distribuidor, Publicador,

Assinante, Publicação, Artigo, Assinatura e Agentes. Os tópicos a seguir detalham cada um

desses componentes.

Distribuidor

Este componente é responsável por fazer uma distribuição de forma transparente dos

dados, sem necessitar de intervenção do Publicador. Assim o publicador fica responsável

apenas por criar as publicações e artigos. O Distribuidor pode ser colocado no mesmo

servidor (Distribuidor Local) que o Publicador ou em servidores diferentes (Distribuidor

Remoto). O Distribuidor Remoto oferece maior desempenho, pois diminui tanto a quantidade

de I/O no Publicador, quanto a disputa por recursos de processamento.

Publicador

O Publisher é o servidor que contém os dados que serão replicados. É responsável por

fazer alterações nos dados e deve garantir a disponibilidade dos dados que serão replicados.

Assinante

O Assinante é o servidor que armazena as réplicas. Ele recebe atualizações do

Publicador, porém atualizações feitas no Assinante podem ser enviadas para o Publicador para

que sejam replicadas para os demais Assinantes.

Publicação

A Publicação é uma base de dados presente no Publicador. Essa base de dados possui

coleção de Artigos que devem ser replicados. Um Publicador pode conter uma ou mais

Publicações.

Artigo

Artigo é um conjunto de dados a serem replicados. Os Artigos podem conter uma série

de colunas, linhas, procedimentos armazenados, visões, visões indexadas ou funções.

28

Assinatura

O servidor de Assinatura deve mapear os Publicadores e os Assinantes e encaminhar

cada Snapshot de um Publicador para seus respectivos Assinantes. O servidor de assinatura

deve mapear os Artigos das novas atualizações para as tabelas dos Assinantes. No SQL Server

existem dois tipos de Assinatura: Assinatura Anônima e Assinatura Nomeada. Na Assinatura

Anônima, o Publicador não possui nenhuma informação sobre os Assinantes. Essas

informações serão passadas ao Distribuidor no momento da replicação. Já nas Assinaturas

Nomeadas, as Assinaturas são explícitas no Publicador e podem ser do tipo push ou pull. Nas

Assinaturas Nomeadas do tipo push, apenas o publicador pode fazer alterações nas

Publicações. Já nas Assinaturas Nomeadas do tipo pull, os Assinantes pode solicitar

alterações nas Publicações. Essas Alterações são enviadas ao Publicador e a todos os

Assinantes na próxima sincronização.

Agentes

Os Agentes são quem realizam quase todo o trabalho. São responsáveis por coletar os

dados e executar as ações necessárias. Funcionam como Jobs do SQL Server, dentro do

diretório de replicação. O SQL Server possui cinco Agentes: Snapshot Agent, Log Reader

Agent, Distribution Agent, Merge Argent e Queue Reader Agent.

Os tópicos abaixo descrevem cada um dos Agentes apresentados nesse tópico.

Snapshot Agent

Esse Agente é responsável por criar o arquivo de snapshot e é utilizado em todos os

tipos de replicação. O Snapshot Agent captura o schema e os dados que serão replicados; e

cria o arquivo de Snapshot no Distribuidor. Em seguida ele avisa sobre a sincronização ao

Distribuidor.

Log Reader Agent

Esse Agente é utilizado na replicação do tipo Transactional. Ele captura logs de

transação de alterações em dados que estão marcados para replicação. Após capturar os logs,

armazena na base de distribuição, no Distribuidor.

Distribution Agent

29

O Distriution Agent é responsável por enviar os snapshots ou transações guardadas aos

Assinantes. Esse Agente é utilizado nas replicações Snapshot e Transactional.

Merge Agent

Esse Agente é usado apenas na replicação do tipo Merge, e é executado no

Distribuidor. O Merge Agent é responsável por aplicar o snapshot inicial nos Assinantes,

monitorar e mesclar as atualizações após a sincronização inicial, e resolver conflitos.

Queue Reader Agent

Esse Agente é usado na replicação Transactional para atualizar as mensagens que

foram guardadas numa fila. Na replicação Transactional existem duas opções: atualizar

imediatamente as alterações ou atualizar quando os Assinantes estiverem disponíveis. Para

atualizar imediatamente, o Publicador e o Assinante precisam estar em constante conexão.

Para atualizar quando os Assinantes estiverem disponíveis, a mensagem é salva numa fila e

são entregues a cada assinante pelo Queue Reader Agent quando os mesmos estiverem

disponíveis.

A próxima seção apresenta os tipos de replicação que o SQL Server implementa.

3.2 Tipos de Replicação

O tipo de replicação que você escolhe para um sistema de informação depende de

muitos fatores, incluindo o ambiente físico da replicação, o tipo e a quantidade de dados a

serem replicados e se os dados serão ou não atualizados no Assinante (MSDN, 2010). Alguns

sistemas de informação precisam de uma replicação total em longos intervalos de tempo,

enquanto outros necessitam de replicação incremental. Também há possibilidade do Assinante

replicar para Publicador.

Existem três tipos de replicação: Snapshot, Transactional e Merge. Todos os tipos de

replicação iniciam com uma sincronização inicial, para garantir que todas as bases estarão

iguais. Essa replicação inicial é feita com a replicação Snapshot.

30

3.2.1 Snapshot Replication

Nesse tipo de replicação todos os dados são replicados exatamente como estão no

Publicador, sem fazer rastreamento de alterações. Dessa forma, os dados replicados pelo

Publicador sobrescrevem os dados do Assinante.

A replicação Snapshot só é indicada em casos onde a aplicação permita a existência de

bases desatualizadas, quando existem poucas alterações de dados ou o volume total de dados é

pequeno.

O SQL Server utiliza alguns componentes para implementar esse tipo de replicação.

Um dos componentes é o Snapshot Agent, que é responsável por preparar os arquivos da

replicação, armazená-los na pasta de distribuição e registrar uma nova replicação no banco de

dados do Distribuidor. A pasta de distribuição é escolhida assim que é configurado o

Distribuidor, podendo ser uma pasta local ou remota. Geralmente, os Snapshots são gerados e

replicados assim que a publicação é assinada. Em seguida, um outro serviço é acionado, o

Distribution Agent. Esse serviço também executa no Distribuidor e é responsável por

propagar a distribuição para todos os Assinantes. A Figura 8 mostra como funciona a

replicação Snapshot.

31

Figura 8 - Snapshot Replication

Este tipo de replicação gera um grande conjunto de dados contendo todos os objetos

que serão replicados, o que pode tornar esse processo lento, e consumir muitos recursos do

servidor. Por este motivo, replicação Snapshot não é apropriada para bases de dados que

sofrem muitas alterações.

3.2.2 Transactional Replication

Esse tipo de replicação é iniciado com uma replicação Snapshot para sincronizar todas

as bases e assegurar que estarão idênticas. Com a replicação Snapshot concluída, todas as

32

alterações que são feitas no Publicador são imediatamente replicadas para os Assinantes, na

mesma ordem e limite de transação, assegurando a integridade das bases de dados dos

Assinantes.

Essa replicação é indicada quando a aplicação requer um intervalo de tempo mínimo

entre as mudanças feitas no Publicador e nos Assinantes; a replicação seja feita de forma

incremental; e guarda todos os estados dos Artigos replicados. Por exemplo, se um Artigo

sofre 3 alterações em um intervalo pequeno de tempo, os três estados serão replicados ao

invés de apenas o último.

Nessa replicação, o SQL Server utiliza, além dos componentes Snapshot Agent e

Distribution Agent, o componente Log Reader Agent. O Snapshot agente só é executado

quando a assinatura é iniciada e executa as mesmas operações da replicação Snapshot . Em

seguida o Distribution Agent se encarrega de fazer a distribuição para todos os Assinantes.

Com todos os Assinantes sincronizados, o serviço Log Reader Agent é acionado. Esse serviço

monitora o log de transações de cada banco de dados configurado para a replicação

Transactional e copia as transações marcadas para replicação do log de transações no banco

de dados de distribuição, que atua como uma fila confiável para armazenar e avançar. Sempre

que o Log Reader Agent identifica uma nova atualização e armazena no banco de dados do

Distribuidor, essa atualização já pode ser distribuída pelo Distribution Agent aos Assinantes,

de acordo com o intervalo de tempo que foi configurado no Distribuidor. Os Assinantes

recebem as transações na mesma ordem em que foram aplicados no Publicador. Se uma

assinatura estiver marcada para validação, o Distribution Agent também verificará se os dados

do Publicador e do Assinante coincidem. A Figura 9 demonstra como o Transactional

Replication funciona.

33

Figura 9 - Transactional Replication

3.2.3 Merge Replication

A replicação to tipo Merge Replication inicia como a replicação to tipo Transactional,

fazendo primeiro uma replicação do tipo Snapshot do Publicador para os Assinantes,

sincronizando todas as bases. A partir daí, todas as alterações feitas no Publicador passam a

34

ser rastreadas. Sempre que o Assinante está conectado à rede, as alterações feitas após a

última sincronização são replicadas do Publicador para o Assinante. A Figura 10 demonstra o

funcionamento da Merge Replication.

Figura 10 - Merge Replication

Essa replicação utiliza o componente Snapshot Agent para criar o arquivo de

instantâneo e o componente Merge Agent para distribuir as Publicações entre os Assinantes.

O Merge Agent mescla as alterações de dados que ocorrem no Publicador com os dados dos

Assinantes quando os mesmos estão disponíveis.

Este tipo de replicação é bastante utilizado em sistemas que precisam trabalhar offline

por algum tempo, fazer modificações nos dados e depois replicar as alterações em todos os

bancos de dados da aplicação. A sincronização acontece de forma mais rápida que na

35

replicação Snapshot e é bastante utilizado em aplicações que requerem muitas alterações de

dados. Por permitir alterações de diferentes locais, podem ocorrer conflitos na sincronização

quando o mesmo dado é alterado em mais de um local. Os conflitos podem ser resolvidos com

a criação de uma política de conflitos no Conflict Policy Viewer2.

3.3 Estudo de Caso

Nesta seção será mostrado como configurar a replicação Snapshot no SQL Server

2008. A configuração dos três tipos de replicação são semelhantes, então no fim do estudo de

caso serão apresentadas as diferenças para configurar as replicações Transactional e Merge.

O ambiente em que será configurada a replicação é formado por uma máquina física

rodando Windows 7 e duas máquinas virtuais rodando Windows 7 e SQL Server 2008. As

duas máquinas virtuais estão conectadas por uma rede física.

As máquinas virtuais foram nomeadas windows7-1 e windows7-2. Cada uma

contendo uma instância do SQL Server 2008 Enterprise Edition, nomeadas como

MSSQLSERVER. A máquina windows7-1 será o Publicador/Distribuidor e a máquina

windows7-2 será o Assinante.

Para demonstrar a replicação, foi utilizado um esquema de banco de dados simples,

criado apenas para este fim.

2 O Conflict Policy Viewer é uma ferramenta integrada ao Microsoft SQL Server. Essa

ferramenta permite visualizar todos os conflitos que ocorreram durante a sincronização e permite que

seja escolhido uma solução diferente para o conflito .

36

Figura 11 – Modelo de dados de exemplo

3.3.1 Configurando a Replicação

Primeiramente deve-se configurar o Distribuidor. Como foi definido o mesmo servidor

para o Distribuidor e Publicador, deve-se abrir o SQL Server Management Studio (SSMS) e

clicar com o botão direito do mouse na pasta “Replication”. Em seguida clique em “Configure

Distribution”, como mostra a Figura 12.

37

Figura 12 – Configure Distribution

Na janela que se abrirá, será escolhido o próprio servidor (windows7-1) para ser o

Distribuidor, selecionando a primeira opção, como mostra a Figura 13.

38

Figura 13 – Selecionar Distribuidor

Na próxima tela, como mostra a Figura 14, será escolhida a pasta que guardará o

arquivo de snapshot do Distribuidor

39

Figura 14 – Selecionar pasta de Snapdshot

Em seguida devem ser escolhidas as pastas onde ficarão os arquivos de log e o arquivo

da base de dados do Distribuidor, como também o nome da base do Distribuidor. Figura 15.

40

Figura 15 – Selecionar Base de Distribuição

Na próxima tela, Figura 16, será escolhido um ou mais Publicadores para ter acesso ao

Distribuidor. Como definido anteriormente, o publicador adicionado será o servidor

windows7-1.

41

Figura 16 – Selecionar Publicador

Na próxima tela, Figura 17, será escolhida a opção “configure distribution” para que a

configuração seja executada.

42

Figura 17 – Finalizando configuração do Distribuidor

Se tudo ocorrer bem, a próxima tela deverá ser igual a Figura 18.

43

Figura 18 – Status da configuração do Distribuidor

A próxima etapa será criar uma Publicação. Para criar uma nova Publicação deve-se

clicar com o botão direito do mouse na pasta “Replication” e em seguida clicar em

“New/Publication...” (Figura 19).

44

Figura 19 – Nova Publicação

Na janela que se abrirá, deverá ser escolhida a base de dados onde estão os Artigos a

serem replicados (Figura 20).

45

Figura 20 – Selecionando Publicador para nova Publicação

A próxima tela é a parte mais importante da configuração. Nela será definido o tipo de

replicação a ser criado. Neste trabalho optamos pela Snapshot Replication. Então, como

mostra a Figura 21, deverá ser selecionada a opção “snapshot publication”.

46

Figura 21 – Selecionando tipo de Publicação

Na tela representada pela Figura 22, serão escolhidas as tabelas e/ou colunas que se

deseja replicar.

47

Figura 22 – Escolhendo Artigos

Na tela seguinte é possível escolher um filtro os dados que serão replicados. Como

queremos replicar todos os dados, deixe em branco, como na Figura 23.

48

Figura 23 – Filtrando Artigos

Como mostra a Figura 24, na tela seguinte é possível optar por uma única replicação

imediata, e/ou replicações programadas.

49

Figura 24 – Agendamento de Snapshot

A Figura 25 mostra a tela de replicação programada, onde é possível optar por

replicação em intervalos de tempo, escolher dias específicos e faixas de horário.

50

Figura 25 – Parâmetros para agendamento de Sanpshot

O próximo passo será localizar o servidor onde se encontra o Snapshot Agent. Nesse

caso o Snapshot Agent se encontra no servidor windows7-1, que é onde se localiza o

Distribuidor. Esse passo é demonstrado na Figura 26 e Figura 27.

51

Figura 26 – Configurações de segurança do Agente

52

Figura 27 – Parâmetros de login do Snapshot Agent

As próximas telas, Figura 28 e Figura 29, finalizam a criação da nova Publicação.

53

Figura 28 – Finalizando a configuração da nova Publicação

54

Figura 29 – Status da configuração da nova Publicação

O próximo passo é configurar uma nova Assinatura. É nessa etapa que será definido os

Assinantes da Publicação que criamos. Para adicionar uma nova Assinatura, deve-se clicar

com o botão direito do mouse em “Replication” e escolher a opção “New/Subscriptions...”,

como mostra a Figura 30.

55

Figura 30 – Nova Assinatura

Na primeira tela será pedido pra informar de qual Publicação será a Assinatura. Como

queremos assinar a Publicação que foi criada nos passos anteriores, deverá ser escolhida a

publicação “base_replicacao_snapshot”, como na Figura 31.

56

Figura 31 – Selecionando Publicador para a Assinatura

A tela seguinte pedirá pra escolher entre Assinatura Pull ou Push. A diferença

principal é o local onde ficarão os Agents. Na Assinatura Pull os Agents executarão no

Distribuidor, centralizando e tornando mais fácil a sincronização dos Assinantes. Já na

Assinatura Push, teremos um Agent executando em cada Assinante, fazendo com que cada

Assinante seja responsável por sua sincronização, diminuindo a sobrecarga no Distribuidor.

Escolheremos a Assinatura Push, como mostra a Figura 32.

57

Figura 32 – Local de execução do Agente

Agora devemos escolher os servidores Assinantes e qual a base que receberá as

Publicações em cada Assinante. Os Assinantes podem ser servidores locais ou remotos.

Escolheremos a outra máquina virtual que está ligada à rede, a máquina windows7-2, para ser

o Assinante e a base “base_replicacao” que é uma base vazia na máquina virtual windows7-2.

A Figura 33, Figura 34 e Figura 35 mostram como escolher os Assinantes.

58

Figura 33 - Assinantes

Figura 34 – Logando no servidor Assinante

59

Figura 35 – Base de Dados que receberá a Assinatura

O passo seguinte será definir a conexão entre o Assinante e o Distribuidor. Clicando

onde está o ponteiro do mouse na Figura 36, abrirá a tela que é exibida na Figura 37. Nessa

tela deverão ser preenchidos os parâmetros da conexão. Como nosso Distribuidor é a maquina

virtual windows7-1, devemos colocar um usuário e senha que tenha permissão para acessar

essa máquina.

60

Figura 36 – Configuração de segurança do Distribuidor

61

Figura 37 – Parâmetros de login do Distribuidor

A tela exibida na Figura 38 apresentará duas opções para Agent Scheduler, que é

como o Agente deve executar. As opções são “run continuously” para executar

continuamente, ou “run on demand” para executar sob intervenção do DBA. Escolheremos a

opção “run continuously”. As telas seguintes finalizam a configuração do Assinante. Se não

acontecer nenhuma falha, a ultima tela deve ser exibida como na Figura 40.

62

Figura 38 – Intervalo de sincronização

63

Figura 39 – Preparando a inicialização da Assinatura

64

Figura 40 – Status da configuração da Assinatura

65

Figura 41 – Tabelas replicadas no Assinante

Depois de seguir esses passos a configuração está concluída. Como mostra a Figura

41, é possível ver na máquina windows7-2 (Assinante) que o snapshot inicial já foi carregado

e o Assinante já possui as tabelas e os dados exatamente como no Publicador.

Para configurar as Replicações Transactional e Merge, na tela que é representada pela

Figura 21, deve-se escolher o tipo de publicação desejada: “Transactional publication”,

“Transactional publication with subscriptions” ou “Merge publication”. A diferença entre as

opções “Transactional publication” e a “Transactional publication with subscription” é que na

segunda opção as alterações feitas pelos Assinantes são replicadas para o Publicador e os

demais Assinantes. O restante da configuração é idêntico ao que foi apresentado neste

capítulo.

66

3.4 Considerações

O SQL Server 2008 utiliza uma arquitetura de replicação muito próxima do modelo

tradicional Primary Copy. Porém, há casos em que a replicação pode partir de uma cópia

secundária para a cópia primária, ferindo o modelo proposto pela literatura.

Apesar de implementar apenas a estratégia Lazy Replication, o SQL Server 2008

explora bastante essa estratégia com três tipos de replicação que podem atender a maioria das

situações em que é necessário uma replicação de base de dados.

Os pontos positivos encontrados no SQL Server são: a facilidade de configurar e

montar um ambiente de replicação; facilidade de personalizar a replicação através da

mudança de apenas alguns parâmetros; ferramentas de monitorando que permitem o

acompanhamento de todo o processo de replicação e o histórico de replicações anteriores;

apresenta dois meios para se fazer a replicação: através da interface gráfica, como foi

mostrado na seção anterior; e através de comandos T-SQL.

A desvantagem é não ter como garantir total integridade entre as bases de dados, já

que não é possível implementar a replicação síncrona (Eager Replication).

67

4 PostgreSQL

O PostgreSQL é um SGBD objeto-relacional que surgiu como evolução do

POSTGRES, SGBD objeto-relacional que surgiu a partir de um projeto de mesmo nome na

Universidade da Califórnia (THE POSTGRESQL GLOBAL DEVELOPMENT GROUP,

2005).

O PostgreSQL surgiu a partir do código-fonte do POSTGRES, que era distribuído sob

uma licença BSD. O objetivo era estabilizar o código que foi herdado e implementar novas

funcionalidades, pois o POSTGRES tinha se popularizado e havia uma grande demanda de

correções e novas funcionalidades. Um grande marco nesse novo projeto foi substituir a

linguagem de consulta QUEL pela linguagem SQL, tornando-o compatível com os demais

SGBDs.

Hoje o PostgreSQL é um SGBD robusto e gratuito, mantido por uma comunidade

online e disputa mercado com os grandes SGBDs proprietários.

Uma das principais limitações do PostgreSQL, nas versões utilizadas neste trabalho, é

não dar suporte nativo a replicação de dados. Os testes foram realizados nas versões 8.2 e 8.3

do PostgreSQL. Porém a replicação pode ser feita utilizando ferramentas que estendem esse

SGBD, oferecendo suporte a criação de ambientes de banco de dados distribuídos. Dentre

estas ferramentas, as que mais se destacam são: Pgpool-II, Slony-I, PGCluster e Postgres-R.

Os próximos tópicos detalham cada ferramenta citada acima.

4.1 Pgpool-II

Pgpool-II é na realidade um middleware entre o servidor de banco de dados

PostgreSQL e seus clientes, atuando de forma transparente tanto para o cliente como para o

servidor (PGPOOL, 2010). Isso significa que o cliente enxerga o pgpool-II como se fosse o

servidor PostgreSQL, enquanto que o servidor o enxerga como um de seus clientes. Essa

abordagem permite que aplicações utilizem o pgpool-II praticamente sem nenhuma

modificação em seus códigos. (PGPOOL, 2009). A Figura 42 demonstra como o Pgpool-II

interage com o PostgresSQL.

68

Figura 42 - Arquitetura do Pgpool

Além da Replicação de dados, o Pgpool oferece balanceamento de carga em consultas,

quebrando uma consulta em várias partes e executando cada parte em uma réplica.

O Pgpool pode operar em 5 modos diferentes: raw, connection pool, replication,

parallel, e master/slave.

No modo Raw, o Pgpool é apenas uma interface de conexão com o banco de dados.

Neste modo ele oferece limitação de número de conexões simultâneas e permite que uma

cópia secundária assuma em caso de falhas na cópia primária.

No modo Connection Poll, ele permite a reutilização de conexões. Quando um cliente

solicita uma conexão, o Pgpool verifica se já existe alguma conexão aberta com os mesmos

parâmetros. Caso exista, o Pgpool reaproveita a conexão aberta ao invés de criar uma nova

conexão com parâmetros idênticos, diminuindo a quantidade de conexões diretas no banco de

dados.

No modo Replication, o Pgpool replica todas as alterações de dados feitas na cópia

primária, para as demais cópias secundárias. Como sugere o modelo Eager Primary Copy,

todas as atualizações são replicadas instantaneamente para as cópias secundárias.

69

No modo parallel, as consultas grandes são divididas em partes menores e distribuídas

entre todas as cópias nas quais serão executadas, gerando um balanceamento de carga, o que

aumenta o desempenho em consultas mais pesadas, e diminuindo a utilização de memória de

cada servidor.

O modo Master/Slave (Mestre/Escravo) oferece uma alternativa de replicação, na qual

os dados serão atualizados na cópia principal (Mestre) e, quando possível, replicados nas

cópias secundárias (Escravo). Para oferecer suporte a este tipo de replicação, o Pgpool precisa

trabalhar em conjunto com outra ferramenta, o Slony-I. Os ganhos de performance no modo

mestre/escravo são superiores aos ganhos obtidos no modo paralelo (PARTIO, 2007).

A extensão pgpool-II apresenta uma série de limitações, se comparada a um servidor

PostgreSQL padrão, como, por exemplo, não possuir um sistema de controle de acesso. Caso

o acesso via TCP/IP ao servidor PostgreSQL esteja habilitado, pgpool-II aceitará conexões

provenientes de qualquer host, sendo necessária a utilização de outro método de controle

para limitar o acesso (iptables, por exemplo). (PGPOOL, 2009)

4.1.1 Configurando o Pgpool-II

Assumindo que já se conhece as operações básicas do PostreSQL, será mostrado nesse

capítulo como instalar e configurar a replicação usando pgpool-II e PostgreSQL 8.2.

O primeiro passo é baixar a pgpool-II na página oficial do pgpool, no site PgFoundry.

Neste trabalho foi utilizada a verão 3.0.5. No diretório que foi extraído o código-fonte, devem

ser executados os seguintes comandos.

$./configure

$ make

$ make install

“Configure” é um script que coleta informações do sistema necessárias para o

procedimento de compilação. Pode-se passar argumentos de linha de comando para alterar o

comportamento padrão, como o diretório de instalação. O diretório padrão é “/usr/local”.

“Make” é um comando que compila o código fonte e make install irá instalar os executáveis.

Você deve ter permissão de escrita no diretório de instalação. Será tomado como suposição

que foi escolhido o diretório padrão.

70

O pgpool-II exige biblioteca libpq do PostgreSQL 7.4 ou superior. Se o script de

configuração exibir uma mensagem de erro informando que falta tal biblioteca, a biblioteca

libpq não está instalada, ou não é a versão 3.

Os parâmetros de configuração do pgpool-II são salvos no arquivo pgpool.conf . O

arquivo no formato: "parameter = value". Quando pgpool-II é instalado, pgpool.conf.sample é

criado automaticamente. É recomendado copiar e renomear para “pgpool.conf” , e editá-lo

como quiser, pois o pgpoll irá buscar a configuração no arquivo “pgpool.conf”.

$ cp/usr/local/etc/pgpool.conf.sample/usr/local/etc/pgpool.conf

pgpool-II só aceita conexões a partir do host local usando a porta 9999. Se desejar

receber conexões de outras máquinas, é preciso definir listen_addresses para '*'.

listen_addresses = 'localhost'

port = 9999

É preciso configurar os servidores de backend do PostgreSQL para o pgpool-II. Esses

servidores podem ser colocados dentro do mesmo host que o pgpool-II, ou em máquinas

separadas. Se você decidir colocar os servidores na mesma máquina, devem ser atribuídos

números de porta diferentes para cada servidor. Se os servidores são colocados em máquinas

separadas, eles devem ser configurados corretamente para que possam aceitar conexões de

rede do pgpool-II.

Neste trabalho, vamos colocar três servidores dentro do mesmo host que o pgpool-II, e

atribuir as portas 5432, 5433, 5434, respectivamente. Para configurar pgpool-II, editar

pgpool.conf como é mostrado abaixo.

backend_hostname0 = 'localhost'backend_port0 = 5432backend_weight0 = 1backend_hostname1 = 'localhost'backend_port1 = 5433backend_weight1 = 1backend_hostname2 = 'localhost'backend_port2 = 5434backend_weight2 = 1

71

Para backend_hostname, backend_port, backend_weight, será definido o hostname do

nó, número de porta, e a razão para balanceamento de carga. No final de cada seqüência de

parâmetro, O ID do nó deve ser especificado pela adição de números inteiros positivos a partir

de 0 (ou seja, 0, 1, 2, ...).

Os parâmetros backend_weight são todos 1, o que significa que consultas SELECT

são igualmente distribuídos entre os três servidores, caso seja ativado o balanceamento de

carga. Para iniciar o processo pgpool-II, o comando a seguir deve ser executado no terminal.

$ Pgpool

O comando acima não imprime mensagens de log. Se você quer mostrar as mensagens

de log do pgpool, você passa o parâmetro “-n” para o comando pgpool. pgpool-II não executa

em segundo plano e deve ser iniciado pelo terminal.

$ Pgpool -n

As mensagens de log são impressas no terminal, por isso as opções recomendadas para

uso são como a seguir.

$ Pgpool-n -d> / tmp/pgpool.log 2> & 1 &

A opção -D permite que as mensagens de depuração sejam geradas.

Para parar o pgpool-II, execute o seguinte comando.

$ Pgpool stop

Se algum cliente ainda está conectado, pgpool-II espera por eles para desligar, em

seguida, encerrar-se. O comando a seguir força a parada do pgpool-II.

$ Pgpool-m fast stop

Para habilitar as funções de replicação e balanceamento de carga, é preciso setar o

valor “true” nos parâmetros “replication_mode” e load_balance_mode, no arquivo de

configurações. Após configurar e reiniciar o Pgpool, a replicação deve ser testada. Para testar,

é preciso criar uma nova base no servidor principal e observar se foi replicado nos outros

72

servidores. Abaixo segue um exemplo, em um ambiente onde foi criada uma base

“banco_replicacao”.

$ Createdb –p 9999 banco_replicacao

$ Pgbench –i –p 9999 banco_replicacao

O script acima cria uma base “banco_replicacao” com tabelas e dados padrão do

PostgresSQL. O script a seguir verifica que a base foi replicada nos outros servidores.

$ for port in 5432 5433 5434; do

> echo $port

> for table_name in branches tellers accounts history; do

> echo $table_name

> psql -c "SELECT count(*) FROM $table_name" -p $port

bench_replication

> done

> done

Após executar esses passos, a replicação com o Pgpool-II está configurada e

executando.

4.2 Slony-I

O Slony-I é uma ferramenta que estende o PostgreSQL e implementa Lazy Replication

em uma arquitetura Primary Copy, utilizando Triggers (PARTIO, 2007).

As atualizações são feitas diretamente na cópia primária. Quando uma atualização é

feita, uma trigger é executada. A trigger salva um log com as alterações. Ao perceber as

alterações no log, o servidor principal notifica os servidores secundários sobre as atualizações

e grava o evento de notificação na tabela “sl_event” (tabela de eventos específica do Slony-I).

Ao receber a notificação, o servidor secundário lê o arquivo de logs, aplica as alterações e em

seguida e notifica o mestre, que remove o evento da tabela.

73

O Slony-I é a única solução para replicação assíncrona no PostegreSQL sendo

mantida. Também é apontada pelo site do PostgreSQL como a melhor solução para replicação

assíncrona e vem inclusa no pacote de instalação oficial do PostegreSQL.

4.2.1 Configurando o Slony-I

Essa replicação foi testada um ambiente com CentOS, PostgreSQL-8.2.7,

PostgreSQL-8.2-slony1, PostgreSQL-contrib-8.2 (que traz o pgbench).

Esta seção foi escrita baseada no arquivo INSTALL que acompanha o código-fonte do

Slony-I

Foram criados três bancos: master, slave1 e slave2 e instalado o plpgsql em todos. No

banco máster, foi criado um schema do pgbench:

$ su – postgres

$ /usr/lib/postgresql/8.2/bin/pgbench -i -U postgres master -P postgres -p 5432

Foi adicionado na tabela history uma chave primária com nome history_pkey nos

campos tid, bid e aid. Depois foi gerado um dump, somente do schema do banco master e

importado nos bancos slave1 e slave2.

$ su – postgres

$ /usr/lib/postgresql/8.2/bin/pg_dump -s -U postgres master > schema.sql -p

5432

$ /usr/lib/postgresql/8.2/bin/psql -U postgres slave1 < schema.sql -p 5432

$ /usr/lib/postgresql/8.2/bin/psql -U postgres slave2 < schema.sql -p 5432

Foi criado um script de configuração para cada engine do Slony. Os arquivos contém

somente duas linhas. “slave1.conf” e “slave2.conf” foram configurado como a seguir:

cluster_name='pgbench'

conn_info='host=127.0.0.1 port=5432 user=postgres dbname=master

password=postgres'

74

Foi criado um arquivo para cada banco e ajustado o dbname. Em seguida cada arquivo

de configuração foi carregado.

su - postgres

slon -f /var/lib/postgresql/slony/master.conf > master.log 2>& 1 &

slon -f /var/lib/postgresql/slony/slave1.conf > slave1.log 2>& 1 &

slon -f /var/lib/postgresql/slony/slave2.conf > slave2.log 2>& 1 &

No PGAdmin, em “Arquivo – Opções – Caminho do slony”, foi indicado o caminho

“/usr/share/slony1”. No banco master, foi criado um novo cluster Slony-I usando as seguintes

opções:

Join existing cluster: Unchecked

Cluster name: pgbench

Local node: 1 Master node

Admin node: 99 Admin node

Em cada um dos bancos slave1 e slave2 foi criado um cluster de Replicação com as

opções:

slave1:

Join existing cluster: Checked

Server: <Select the server containing the master database>

Database: master


Local node: 10 Slave node 1

Admin node: 99 - Admin node

e slave2:

Join existing cluster: Checked

75

Server: <Select the server containing the master database>

Database: master


Local node: 20 Slave node 2

Admin node: 99 - Admin node

Foi criado no master, paths para ambos os slaves e em cada slave a volta para o

master. Em seguida os paths sob cada nó no master usando a string de conexão do script de

configuração.

host=127.0.0.1 port=5432 user=postgres dbname=master password=postgres

host=127.0.0.1 port=5432 user=postgres dbname=slave1 password=postgres

host=127.0.0.1 port=5432 user=postgres dbname=slave2 password=postgres

Observação: No banco master, no Nó master foram criados dois paths, um para cada

slave. Em cada Nó Slave, um path para o master. Repetir o procedimento para os bancos

slaves. Em seguida, foi criado um Replication Set no master usando as seguintes

configurações:

ID: 1

Comment: pgbench set

Em seguida foram adicionadas as tabelas para o Replication set (master) com

as configurações:

Table: public.accounts

ID: 1

Index: accounts_pkey

Table: public.branches

ID: 2

Index: branches_pkey

Table: public.history

ID: 3

76

Index: history_pkey

Table: public.tellers

ID: 4

Index: tellers_pkey

No master node foi criada uma nova subscrição para cada slave usando as seguintes

opções:

Origin: 1

Provider: 1 - Master node

Receiver: 10 - Slave node 1

Origin: 1

Provider: 1 - Master node

Receiver: 20 - Slave node 2

Seguindo esses passos, a configuração dos servidores está concluída. A replicação

inicial deve começar e pode ser monitorada na aba Estatística do PGAdmin para cada nó.

Basta selecionar o cluster pgbench, expandir os 4 nós e selecionar Estatística.

4.3 PGCluster

O PGCluster é uma ferramenta que oferece o modelo de replicação Eager Primary

Copy (CIPRIANI, 2009).

PGCluster é composto por três tipos de servidores distintos: o servidor de replicação

(Replication Server), o balanceador de carga (Load Balance Server) e o servidor PostgreSQL

em si. O balanceador de carga não é necessário apenas para realizar o balanceamento de carga

entre os servidores, mas também para criar um cluster de alta disponibilidade (PGCLUSTER,

2009).

O servidor de replicação envia as atualizações para os demais servidores, sempre

verificando a disponibilidade do mesmo. Quando um servidor secundário está indisponível,

ele é removido do cluster, até que seja corrigido. Já o servidor de balanceamento de carga

77

envia as solicitações de consultas para o servidor que tiver o menor número de conexões

ativas, pois este representa o servidor com menor carga.

O PGCluster opera em dois modos: normal e confiável. No modo normal o

balanceador de carga retorna o resultado de uma operação para o cliente assim que ele receber

a resposta do servidor PostgreSQL que a executou. No modo confiável o balanceador de carga

devolve a resposta ao cliente somente depois que a operação foi executada em todos os

servidores PostgreSQL do cluster (PGCLUSTER, 2009).

A principal vantagem do PGCluster sobre o Slony-I é que o PGCluster é um patch que

se integra ao PostgreSQL, passando a fazer parte dele. Isso faz com que o PGCluster tenha

acesso a todos os recursos do PostgreSQL com facilidade, não precisando implementar a

replicação através de triggers. Além disso, o PGCluster é indicado pelo site do PostgreSQL

como a principal ferramenta para este tipo de replicação.

4.3.1 Configurando o PGCluster

O PGCluster pode ser obtido em sua página no site oficial da PgFoundry. Neste

trabalho foi utilzada a versão 1.9.0 do PGCluster, PostgreSQL 8.3 com biblioteca RSync e

sistema operacional CentOS. A instalação foi feita seguindo o arquivo “INSTALL”, que

acompanha o código-fonte do PGCluster.

Será configurado um ambiente com três clusters, um replicador e um balanceador de

carga, todos rodando em máquinas diferentes. Neste caso em máquinas virtuais com o

CentOS.

Primeiramente é preciso compilar o código-fonte baixado na página do PGCluster,

excutando o script “Configure” no diretório o qual o código-fonte foi extraído, como é

demonstrado a seguir:

$ ./configure

Após a execução do comando, o PgCluster foi compilado. Em seguida deve ser

executado o comando “gmake install-strip”, que instala o PGCluster no diretório padrão

(/usr/local/pgsql). O próximo passo agora é iniciar o banco de dados. Para tal, é necessário

executar o comando abaixo.

$ initdb -D /usr/local/pgsql/data

78

É necessário criar editar criar ou editar ou ambos o arquivo “/etc/hots” em todas as

máquinas que irão compor o sistema. Abaixo segue um exemplo de configuração.

# Balanceador de carga

192.168.0.1 loadbalancer

# Nós de armazenamento

192.168.0.11 cluster_1

192.168.0.12 cluster_2

192.168.0.13 cluster_3

# Servidores de replicação

192.168.0.21 replicate_upper

92.168.0.22 replicate_lower

É necessário editar três arquivos de configuração: pgreplicate.conf, arquivo de

configuração do servidor de replicação; pglb.conf, arquivo de configuração do servidor de

balanceamento de carga; cluster.conf, arquivo de configuração do nó de armazenamento.

Esses arquivos estarão no diretório “etc” na pasta de instalação do PostgreSQL.

A configuração do “pglb.conf” ficará como descrito abaixo.

#==================================================

# Configuracao dos nós de armazenamento

#=================================================

<Cluster_Server_Info>

<Host_Name> clusterdb1 </Host_Name>

<Port> 5432 </Port>

<Max_Connect> 30 </Max_Connect>

</Cluster_Server_Info>


79


<Port> 5432 </Port>

<Max_Connect> 30 </Max_Connect>




<Port> 5432 </Port>

<Max_Connect> 30</Max_Connect>


#==================================================

# Configuracao do servidor de balanceamento de carga

#==================================================

<Receive_Port> 5432 </Receive_Port>

<Recovery_Port> 6101 </Recovery_Port>

<LifeCheck_Port> 6201 </LifeCheck_Port>

<Max_Cluster_Num> 128 </Max_Cluster_Num>

<Use_Connection_Pooling> no </Use_Connection_Pooling>

Agora será necessário configurar dois arquivos padrão do PostgreSQL,

“/usr/local/pgsql/data/pg_hba.conf” e “/usr/local/pgsql/data/postgresql.conf”

O arquivo “pg_hba.conf” ficará como o apresentado a seguir.

# "local" is for Unix domain socket connections only

local all all trust

# IPv4 local connections:

host all all 127.0.0.1/32 trust

# IPv6 local connections:

host all all ::1/128 trust

80

# incluir no final do arquivo (referente à sua rede)

host all all 10.209.0.0/23 trust

No arquivo “postgresql.conf” deve ser configurada a porta de recebimento e o número

máximo de conexões. Segue a configuração do arquivo:

listen_addresses = ’*’

port = 5432

max_connections = 100

Agora deve ser configurado o arquivo ”cluster.conf” em cada nó de armazenamento.

Esse arquivo se encontra no diretório de armazenamento. O arquivo ficou da seguinte forma:

#---------------------------------------

# Configuracao do servidor de replicacao

#---------------------------------------

<Replicate_Server_Info>

<Host_Name> replicador1 </Host_Name>

<Port>8001</Port>

<Recovery_Port>8101</Recovery_Port>

<LifeCheck_Port>8201</LifeCheck_Port>

</Replicate_Server_Info>

<Replicate_Server_Info>

<Host_Name> replicador2 </Host_Name>

<Port>8001</Port>



</Replicate_Server_Info>

#------------------------------------------

81

# Configuracao de nó de armazenamento

#------------------------------------------



<Rsync_Path> /usr/bin/rsync </Rsync_Path>

<Rsync_Option> ssh -1 </Rsync_Option>

<When_Stand_Alone> read_only </When_Stand_Alone>

<Status_Log_File> /var/log/pgcluster/cluster.sts </Status_Log_File>

<Error_Log_File> /var/log/pgcluster/cluster.err </Error_Log_File>

<Not_Replicate_Info>

<DB_Name>Local_DB</DB_Name>

<Table_Name>Log_Table</Table_Name>

</Not_Replicate_Info>

Configuração do arquivo “pgreplicate.sql”:



<Port> 5432 </Port>






<Port> 5432 </Port>





82


<Port> 5432 </Port>




#--------------------------------------------------------------------

# Configuracao do servidor de balanceamento de carga

#--------------------------------------------------------------------

<LoadBalance_Server_Info>

<Host_Name> LoadBalance1 </Host_Name>



</LoadBalance_Server_Info>

<LoadBalance_Server_Info>

<Host_Name> LoadBalance2 </Host_Name>



</LoadBalance_Server_Info>

#--------------------------------------------------------------------

# A setup of a replication server

#--------------------------------------------------------------------

<Status_Log_File> /var/log/pgcluster/cluster.log </Status_Log_File>

<Error_Log_File> /var/log/pgcluster/cluster.err </Error_Log_File>

<Replication_Port> 8001 </Replication_Port>



<RLOG_Port> 8301 </RLOG_Port>

83

<Response_Mode> normal </Response_Mode>

<Use_Replication_Log> no </Use_Replication_Log>

<Reserved_Connections> 1 </Reserved_Connections>

Com essas configurações o ambiente está pronto. A seguir é será descrito alguns

comandos para iniciar, parar e reiniciar os serviços.

Clustero Iniciando

$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -o "-i" starto Parando

$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data stopo Reiniciando

$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data restart Balanceamento

o Iniciando

$ /usr/local/pgsql/bin/pglb -D /usr/local/pgsql/etco Parando

$ /usr/local/pgsql/bin/pglb -D /usr/local/pgsql/etc stopo Reiniciando

$ /usr/local/pgsql/bin/pglb -D /usr/local/pgsql/etc restart Replicação

o Iniciando

$ /usr/local/pgsql/bin/pgreplicate -D /usr/local/pgsql/etco Parando

$ /usr/local/pgsql/bin/pgreplicate -D /usr/local/pgsql/etc stopo Reiniciando

$ /usr/local/pgsql/bin/pgreplicate -D /usr/local/pgsql/etc restart

Após seguir a configuração descrita nessa seção, os clusters estarão funcionando,

replicando e balanceando carga entre si.

4.4 Postgres-R

Postgres-R é uma extensão ao servidor de banco de dados PostgreSQL que fornece

replicação síncrona (vários mestres) e foi projetada para ser o mais transparente possível para

o cliente (WANNER, 2008). Comparado a um sistema de banco de dados de um único nó, um

84

cluster Postgres-R é mais confiável e pode ser ampliado facilmente, além de ser mais barato e

flexível (POSTGRESQL, 2008). O Postgres-R é adicionado ao PostgreSQL como um patch

que adiciona funcionalidades ao banco de dados.

A principal função do Postgres-R é criar um Cluster de alta disponibilidade com baixo

custo, pois não será necessário o uso de equipamentos especiais para esta finalidade.

Assim como a extensão PGCluster, a Postgres-R é um patch para o código fonte do

PostgreSQL. Postgres-R é disponibilizada sob a mesma licença do servidor PostgreSQL,

eliminando completamente quaisquer problemas relacionados a incompatibilidade de licenças

entre os códigos (POSTGRESQL, 2008).

A instalação do Postgres-R pode ser encontrada em (CIPRIANI, 2009).

4.5 Considerações

O PostgreSQL, por ser uma ferramenta de código aberto com muitos colaboradores,

possui mais soluções de replicação. O PostgreSQL, além de ferramentas que implementam

todos os esquemas de replicação apresentados no trabalho, possui ferramentas que trabalham

com conceitos mais avançados, como clustering.

Apesar de implementar replicação apenas através de ferramentas de terceiros, é

possível implementar todas as arquiteturas e estratégias de replicação apresentadas neste

trabalho. Porém, as ferramentas de replicação são menos customizáveis que a replicação do

SQL Server.

Com o Pgpool-II ou Slony-I é possível fazer Eager replication, que não é possível

utilizando o SQL Server.

O processo de configuração dos esquemas de replicação é simples, porém é menos

intuitivo, pois é realizado através de comandos e/ou arquivos de configuração.

85

5 Conclusões e Trabalhos Futuros

Este trabalho apresentou as arquiteturas, estratégias de propagação de atualizações e

esquemas de replicação de bases de dados propostos pela literatura. Foram apresentadas,

também, as implementações dessas estratégias por Sistemas Gerenciadores de Banco de

Dados. . Foi realizado um estudo de caso com os SGBDs Microsoft SQL Server e

PostgreSQL com o objetivo de documentar de forma detalhada a criação de ambientes com

replicação de bases de dados nessas duas tecnologias. Apesar dos dois SGBDs apresentarem

soluções de replicação, as implementações e estratégias disponíveis em cada produto difererm

em vários pontos.

A replicação no SQL Server se deu de forma mais intuitiva e com mais facilidade de

customização. Em contrapartida, ele oferece apenas uma estratégia de propagação, a

estratégia Lazy Replication. O PostgreSQL, por outro lado, pode trabalhar como com todos os

esquemas de replicação, porém não oferece suporte nativo. É necessário utilizar ferramentas

de terceiros, o que pode causar problemas devido a incompatibilidade de versões entre as

ferramenta de replicação e o PostgreSQL.

Dentre os SGBDs analisados, somente o PostgreSQL oferece suporte à estratégia

Eager Replication. Embora implemente somente variações da estratégia Lazy Replication, o

SGBD SQL Server oferece ferramentas e suporte para que a replicação ocorra sem erros, ou

que os conflitos da replicação possam ser resolvidos.

Este trabalho delineia como proposta de trabalhos futuros: a) o estudo da

implementação das estratégias de replicação de banco de dados em outros SGBDs do

mercado, como Oracle e DB2; b) um estudo sobre o suporte a estratégias de replicação em

SGBDs não relacionais.

86

6 Referências

BERNSTEIN, A. B.; NEWCOMER, E. Principles of Transaction Processing. San

Francisco: Morgan Kaufmann Publishers, 1997.

CIPRIANI, O. N. REPLICAÇÃO DE BASES DE DADOS. Lavras: [s.n.], 2009.

DESHPANDE, K. Oracle Streams 11g Data Replication. [S.l.]: McGraw-Hill

Osborne Media, 2010.

GARCIA-MOLINA, H.; ULLMAN, J. D.; EIDOM, J. Implementação de Sistemas

de Bancos de Dados. Rio de Janeiro: Editora Campus, 2000.

GRAY, J. N.; HELLAND, P.; O'NEIL, D. S. P. The dangers of replication and a

solution. Preceedings of the 1996 ACM SIGMOD Internacional Conference on Management

of Data. Montreal: SIGMOD. 1996. p. 173-182.

MISTRY, R.; MISNER, S. Introducing Microsoft SQL Server 2008 R2.

Washington: Microsoft Press, 2010.

MSDN. MSDN, 2010. Disponivel em: <http://msdn.microsoft.com>. Acesso em: 22

set. 2011.

MULLINS, C. S. The Database Report - October 2011, 01 Outubro 2011.

PARTIO, M. Evaluation of PostgreSQL Replication and Load Balancing. Helsinki

Polytechnic Stadia: [s.n.], 2007.

PAUL, S. Pro SQL Server 2008 Replication. 2. ed. New York: Apress, 2009.

PGCLUSTER. PGCluster. PgFoundry, 2009. Disponivel em:

<http://pgcluster.projects.postgresql.org/>. Acesso em: 25 out. 2011.

PGPOOL. PGPOOL. PgFOundary, 2009. Disponivel em:

<http://pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-en.html>. Acesso em: 28 out.

2011.

PGPOOL. Pgpool Official Documentation. Pgpool, 2010. Disponivel em:

<http://www.pgpool.net/mediawiki/index.php/Documentation>. Acesso em: 22 dez. 2010.

POSTGRESQL. PostgreSQL Global Development Group. PostgreSQL, 2008.

Disponivel em: <http://www.postgresql.org/files/documentation/pdf/8.3/postgresql-8.3-

A4.pdf>. Acesso em: 4 nov. 2011.

87

THE POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL 8.0.26

Documentation. PostgreSQL, 2005. Disponivel em:

<http://www.postgresql.org/docs/8.0/static/index.html>. Acesso em: 22 dez. 2010.

WANNER, R. Postgres-R: a database replication system for. Postgres Global

Development Group. ed. [S.l.]: [s.n.], 2008.

WIESMANN, M. Database Replication Techniques: A Three Parameter

Classification. Nurenberg: [s.n.], 2000.

WIESMANN, M. Understanding replication in databases and distributed systems.

Proceedings of 20th International Conference on Distributed Computing Systems. Taiwan:

[s.n.]. 2000. p. 264-274.

WIESMANN, M.; AL, E. Database Replication Techniques: A Three Parameter

Classification. Proceedings of 19th IEEE Symposium on Reliable Distributed Systems.

Nurenberg: [s.n.]. 2000.

WIESMANN, M.; AL., E. Understanding replication in databases and distributed

systems. Proceedings of 20th International Conference on Distributed Computing Systems.

Taiwan: [s.n.]. 2000. p. 264-274.

YANG, L. T. Mobile Intelligence. New Jersey: [s.n.], 2010.

88

carlos augusto paiva

Documents