UNIVERSIDADE FEDERAL DE SERGIPE

CAMPUS PROF. ALBERTO CARVALHO

DEPARTAMENTO DE SISTEMAS DE INFORMAO
MATHEUS DOS SANTOS LIMA

APLICAO DE ESTRATGIAS DE REPLICAO

DE BASES DE DADOS EM SISTEMAS GERENCIADORES
DE BANCO DE DADOS
ITABAIANA
2011

UNIVERSIDADE FEDERAL DE SERGIPE

CAMPUS PROF. ALBERTO CARVALHO
DEPARTAMENTO DE SISTEMAS DE INFORMAO
MATHEUS DOS SANTOS LIMA

APLICAO DE ESTRATGIAS DE REPLICAO

DE BASES DE DADOS EM SISTEMAS GERENCIADORES
DE BANCO DE DADOS
Trabalho de Concluso de
Curso submetido ao Departamento
de Sistemas de Informao da
Universidade Federal de Sergipe
como requisito parcial para a
obteno do ttulo de Bacharel em
Sistemas de Informao.
Orientador: Msc. Andr Vinicius Rodrigues Passos Nascimento

ITABAIANA
2011

Lima, Matheus do Santos.

Aplicao de Estratgias de Replicao de Bases de Dados
em Sistemas Gerenciadores de Banco de Dados / Matheus dos
Santos Lima Itabaiana: UFS, 2011.
49 f. 27 cm
Trabalho

de

Concluso

de

Curso

(graduao)

Universidade Federal de Sergipe, Curso de Sistemas de

Informao, 2011.

MATHEUS DOS SANTOS LIMA

APLICAO DE ESTRATGIAS DE REPLICAO
DE BASES DE DADOS EM SISTEMAS GERENCIADORES
DE BANCO DE DADOS

Trabalho de Concluso de Curso submetido ao corpo docente do Departamento de

Sistemas de Informao da Universidade Federal de Sergipe (DSIITA/UFS) como parte dos
requisitos para obteno do grau de Bacharel em Sistemas de Informao

Itabaiana, ([dia] , [ms] e [ano] da aprovao).

BANCA EXAMINADORA:

____________________________________________________
Prof Andr Vinicius Rodrigues Passos Nascimento, Msc.
Orientador
DSIITA/UFS

_______________________________________________
Prof Methanias Colao Jnior, Dr.
DSIITA/UFS

_______________________________________________
Prof Andrs Igncio Martnez Menndez, Msc.
DSIITA/UFS

Dedico a

Jordana Naftali Bomfim Lima

1.1.1.1

AGRADECIMENTOS

Agradeo, 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 dvidas e
sendo exemplo de dedicao.
Aos meus professores, pelo comprometimento com minha formao acadmica e dos
meus colegas; sendo verdadeiros mestres! E por terem me entusiasmado mais a cada dia,
durante minha formao.
Aos meus colegas de curso, que uniram foras, caminharam juntos e compartilharam
conhecimentos ao longo do curso.
minha namorada Jordana Naftali, pela ateno, apoio, amor e carinho dedicados a
mim. Por ter compreendido e aberto mo do nosso tempo para que pudesse me dedicar a este
trabalho.
minha famlia pelo apoio e cobrana, que foram fundamentais para concluso do
trabalho.

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

(Eddie Cantor)

LIMA, Matheus dos Santos. Aplicao de Estratgias de Replicao de Bases

de Dados em Sistemas Gerenciadores de Banco de Dados. 2011. Trabalho de
Concluso de Curso Curso de Sistemas de Informao, Departamento de Sistemas de
Informao, Universidade Federal de Sergipe, Itabaiana, 2011.

RESUMO

Replicao de Bases de Dados pode ser entendida como um conjunto de tcnicas

utilizadas para manter cpias consistentes de um mesmo item de dado em diferentes bancos
de dados. Os principais objetivos da replicao so: alcanar melhor desempenho e aumento
de disponibilidade. A melhoria do desempenho alcanada atravs da utilizao de cpias
locais, eliminando, dessa forma, a necessidade de conexes remotas. O aumento da
disponibilidade alcanado atravs da existncia de cpias de um mesmo item de dado. Uma
vez que uma base dados, por algum motivo, fica indisponvel, um sistema de informao pode
passar a consultar os dados na rplica at que o problema seja resolvido. Esse trabalho tem
por objetivo estudar as principais arquiteturas e estratgias de propagao de atualizaes
utilizadas no processo de replicao de bases de dados, e verificar a implementao dessas
arquiteturas e estratgias, ou suas variaes, nos principais Sistemas Gerenciadores de
Banco de Dados Relacionais.

Palavras-chave: Banco de Dados. Replicao. 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

or variations, among

the

some

implementation of
of

the

most

these architectures
widely

Management Systems.
Key-words: Database. Replication. Availability.

used

and

strategies,

Relational

Database

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 Distribuio................................................................41
Figura 16 Selecionar Publicador................................................................................42
Figura 17 Finalizando configurao do Distribuidor................................................43
Figura 18 Status da configurao do Distribuidor.....................................................44
Figura 19 Nova Publicao........................................................................................45
Figura 20 Selecionando Publicador para nova Publicao........................................46
Figura 21 Selecionando tipo de Publicao...............................................................47
Figura 22 Escolhendo Artigos....................................................................................48
Figura 23 Filtrando Artigos........................................................................................49
Figura 24 Agendamento de Snapshot.........................................................................50
Figura 25 Parmetros para agendamento de Sanpshot...............................................51
Figura 26 Configuraes de segurana do Agente.....................................................52
Figura 27 Parmetros de login do Snapshot Agent....................................................53
Figura 28 Finalizando a configurao da nova Publicao........................................54
Figura 29 Status da configurao da nova Publicao...............................................55
Figura 30 Nova Assinatura.........................................................................................56
Figura 31 Selecionando Publicador para a Assinatura...............................................57

Figura 32 Local de execuo 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 Configurao de segurana do Distribuidor..............................................61
Figura 37 Parmetros de login do Distribuidor..........................................................62
Figura 38 Intervalo de sincronizao.........................................................................63
Figura 39 Preparando a inicializao da Assinatura..................................................64
Figura 40 Status da configurao da Assinatura........................................................65
Figura 41 Tabelas replicadas no Assinante................................................................66
Figura 42 - Arquitetura do Pgpool................................................................................69

LISTA DE TABELAS
Tabela 1 Matriz Estratgias de Replicao X Arquitetura.........................................22

13

SUMRIO
1

Introduo...............................................................................................................15
1.1

Objetivos.........................................................................................................16

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

1.1.2 Objetivos especficos.................................................................................16

1.2

Relevncia do Trabalho...................................................................................16

1.3

Metodologia....................................................................................................17

1.4

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

Replicao de Bases de Dados...............................................................................19

2.1

Esquemas de Replicao.................................................................................20

2.1.1 Arquitetura.................................................................................................20
2.1.2 Estratgias de propagao.........................................................................22
2.1.3 Estratgias de Propagao x Arquitetura...................................................22
3

Replicao no SGBD Microsoft SQL Server.........................................................27

3.1

Modelo de Replicao.....................................................................................27

3.2

Tipos de Replicao........................................................................................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 Replicao.......................................................................37

3.4
4

Consideraes..................................................................................................67

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

4.3

14
PGCluster........................................................................................................77

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

4.4

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

4.5

Consideraes..................................................................................................85

Concluses e Trabalhos Futuros.............................................................................86

Referncias.............................................................................................................87

15

Introduo
Replicao de Bases de Dados pode ser entendida como um conjunto de tcnicas

utilizadas para manter cpias consistentes de um mesmo item de dado em diferentes bancos
de dados. A utilizao dessas tcnicas possui como principais objetivos a melhoria do
desempenho na execuo de operaes e o aumento da disponibilidade (BERNSTEIN ,1997).
A melhoria do desempenho alcanada atravs da utilizao de cpias locais,
eliminando, dessa forma, a necessidade de conexes remotas. Nesses casos, as operaes de
leitura apresentam um comportamento semelhante s operaes em bases sem replicao. As
operaes de escrita, no entanto, precisam de algum tipo de coordenao entre as diferentes
rplicas para que as informaes permaneam consistentes em todas as bases envolvidas no
processo de replicao. (WIESMANN,2000a).
O aumento da disponibilidade tambm alcanado atravs da existncia de cpias de
um mesmo item de dado. Uma vez que uma base dados, por algum motivo, fica indisponvel,
um sistema de informao pode passar a consultar os dados na rplica at que o problema seja
resolvido. Tudo isso deve ocorrer de forma transparente para o cliente, seja ele um usurio ou
aplicao. (WIESMANN, 2000b).
Existem diferentes classificaes ou parmetros que categorizam os tipos de
replicao existentes (GRAY, 1996) (WIESMANN, 2000b) (BERNSTEIN ,1997). No
entanto, possvel identificar dois critrios comuns para classificar os tipos de replicao: a)
Arquitetura e b) Estratgia de Propagao de Atualizaes.
Esse trabalho, portanto, tem por objetivo estudar as principais arquiteturas e
estratgias de propagao de atualizaes utilizadas no processo de replicao de bases de
dados, e verificar a implementao dessas arquiteturas e estratgias, ou suas variaes, nos
principais Sistemas Gerenciadores de Banco de Dados Relacionais.

2.1 Objetivos
2.1.1

Objetivo Geral
Estudar a disciplina Replicao de Bases de Dados, suas principais arquiteturas e

estratgias de propagao de atualizaes, e apresentar a implementao dessas arquiteturas e

estratgias em alguns dos principais Sistemas Gerenciadores de Banco de Dados Relacionais.

16
2.1.2

Objetivos especficos

Realizar uma reviso bibliogrfica e reunir conhecimento sobre abordagens de

replicao de bases de dados;

Analisar a implementao de replicao ou variaes das estratgias 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 implementaes ou variaes
em relao arquitetura, caractersticas e conformidade com as estratgias
apontadas na reviso da literatura.

2.2 Relevncia do Trabalho

Os sistemas de informao esto cada vez mais presentes no cotidiano das pessoas,
sejam em sistemas corporativos, softwares de entretenimento, comrcios eletrnicos e muitos
outros ambientes. Os sistemas computacionais vm sendo introduzidos em tarefas bsicas e
essenciais, tornando pessoas e corporaes dependentes dessas tecnologias.
A falta de operao de um servio computacional pode trazer muitos transtornos e
prejuzos. Para solucionar esse problema, surgem os sistemas de alta disponibilidade, nos
quais a idia manter o servio funcionando, mesmo em caso de falha em um dos
componentes. Uma forma comum de se alcanar sistemas de alta disponibilidade usar
tcnicas de replicao de banco de dados, visto que uma das falhas de maior impacto ocorre
quando o acesso aos dados se torna indisponvel.
As literaturas direcionadas para determinadas tecnologias relacionais apresentam
apenas as solues implementadas e carecem de uma explicao das vrias solues de
replicao existentes. Essa falta pode induzir utilizao de arquiteturas e estratgias no
adequadas em funo do casamento com determinado produto (CIPRIANI, 2009) (PARTIO,
2007) (PAUL, 2009) (DESHPANDE, 2010).
Por outro lado, as literaturas que apresentam a disciplina de replicao de bases de
dados independente de tecnologia carecem de estudos de caso prticos que apresentem as
particularidades de determinado produto e os passos necessrios para implementar
efetivamente uma estratgia de replicao (WIESMANN, 2000) (GRAY, HELLAND e
O'NEIL, 1996) (BERNSTEIN e NEWCOMER, 1997).

17
Em funo desse cenrio, esse trabalho possui relevncia quando combina a
teoria e prtica sobre a disciplina Replicao de Bases de Dados, facilitando, dessa forma, o
entendimento da rea independente de tecnologia e, ao mesmo tempo, documentando os
passos necessrios para a implantao efetiva de estratgias de replicao em alguns dos
principais Sistemas Gerenciadores de Bancos de Dados Relacionais.

2.3 Metodologia
Inicialmente, ser realizado um levantamento bibliogrfico sobre as principais
arquiteturas e estratgias de propagao de atualizaes para replicao de bases de dados. A
partir desse levantamento, ser escrito um captulo que resume a teoria necessria para o
entendimento das solues existentes. Em seguida, sero estudadas as arquiteturas e
estratgias disponveis nos SGBDs Microsft SQL Server e PostgreSQL. Esse estudo envolve a
investigao de implementaes nativas, assim como a utilizao de componentes de
terceiros. Aps esse estudo, sero criados ambientes e estudos de caso para apresentar, passo a
passo, como implantar a replicao nas tecnologias investigadas. As ferramentas de apoio
necessrias para a realizao do trabalho sero os sistemas gerenciadores de banco de dados
utilizados, Microsoft SQL Server e PostgreSQL, e os componentes de terceiros necessrios.

2.4 Estrutura do Trabalho

O Captulo 3 deste trabalho apresenta os principais conceitos sobre Replicao de
Bases de Dados, resumindo as principais arquiteturas, estratgias de propagao de
atualizaes e modelos de replicao.
O Captulo 3, dedicado ao SGBD Microsoft SQL Server, apresenta o modelo de
replicao utilizado, os componentes envolvidos e os trs tipos de replicao disponveis:
Snapshot, Transactional e Merge.
O Captulo 4 apresenta as solues de replicao disponveis para o SGBD
PostgreSQL. So abordados os seguintes componentes: Pgpool-II, Slony-I, PGCluster e
Postgres-R. Nos 4 e 5 so apresentados, respectivamente, o SQL Server e o PostgreSQL,
destacando como cada um implementa a replicao de banco de dados..
Finalmente, no captulo 5, so apresentadas as concluses sobre as investigaes
efetuadas sobre as solues de replicao das duas ferramentas utilizadas.

18

Replicao de Bases de Dados

Replicao a tcnica de usar mltiplas cpias de um servidor para melhor

disponibilidade e desempenho. Cada cpia do servidor chamada de rplica (BERNSTEIN &

NEWCOMER, 1997). Deste modo, replicao de banco de dados so rplicas de servidores
de banco de dados que trabalham em paralelo para garantir maior disponibilidade do servio.
Replicao em sistemas de banco de dados realizada principalmente por razes 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
alcanado quando as operaes so apenas de leitura de dados. No entanto, quando existem
operaes de atualizao exige-se algum tipo de coordenao entre as rplicas (WIESMANN,
2000).
Existem diversos tipos de replicao. Esses tipos so definidos atravs da combinao
de arquiteturas que regulam as atualizaes com estratgias de propagao de atualizaes.
Essas vrias combinaes devem ser devidamente selecionadas de acordo com o ambiente no
qual ser aplicada a replicao. As arquiteturas e estratgias apresentadas so implementadas
pelos principais sistemas gerenciadores de banco de dados. No entanto, cada sistema, em
funo de sua arquitetura, apresenta caractersticas particulares.
Esse captulo apresenta as principais arquiteturas de replicao, as principais
estratgias de atualizao e os esquemas de replicao resultantes das combinaes possveis
entre arquitetura e estratgias.

19

3.1 Esquemas de Replicao

Os esquemas de replicao surgem a partir da combinao de tipos de replicao de
dados que so classificados a partir de dois principais parmetros: Arquitetura do servidor e
estratgia de propagao de atualizaes (WIESMANN, 2000). No decorrer deste captulo
cada um desses parmetros ser abordado.

3.1.1 Arquitetura
O parmetro arquitetura d origem a dois tipos de replicao: Primary Copy e Update
Everywhere. A diferena entre os dois tipos est na determinao dos servidores que podem
iniciar modificaes no banco de dados (WIESMANN, 2000).

3.1.1.1 Primary Copy

A arquitetura Primary Copy, como o nome sugere, requer uma cpia principal,
responsvel por todas as atualizaes que podem ocorrer na base de dados. O servidor
principal responsvel por organizar e ordenar as atualizaes e em seguida replicar para as
demais cpias, que so chamadas de secundrias. As cpias secundrias s podem receber
atualizaes replicadas da cpia primria. A Figura 1 uma representao da arquitetura
Primary Copy.

Figura 1 Arquitetura Primary Copy

20
Embora simples do ponto de vista de controle de replicao, essa arquitetura
cria

uma grande dependncia com a cpia primria, pois a nica responsvel pelas

atualizaes. Para solucionar esse problema, podem ser criadas mais de uma cpia primria.
Nessa variao de arquitetura, quando ocorre uma falha em uma cpia primria e a mesma
fica indisponvel, existe um protocolo de eleio que elege uma nova cpia que assumir a
responsabilidade das atualizaes.

3.1.1.2 Update Everywhere

A arquitetura Update Everywhere permite que as atualizaes de dados sejam feitas
em todas as cpias, podendo chegar simultaneamente de duas cpias diferentes, como mostra
a Figura 2.

Figura 2 Arquitetura Update Everywhere

Essa arquitetura soluciona algumas questes de desempenho da arquitetura Primary

Copy, que s permite atualizaes na cpia primria. Da mesma forma, essa arquitetura
tambm mais eficiente ao lidar com falhas, j que no necessrio executar nenhum
protocolo de eleio em caso de falhas. Porm, essa arquitetura tambm pode comprometer o
desempenho da aplicao se no for bem projetada, exigindo que todas as cpias faam o
mesmo trabalho.

21

3.1.2 Estratgias de propagao

Quando uma atualizao feita em uma das cpias, ela precisa ser propagada para as
demais. A forma como essa propagao feita, chamada de estratgia de propagao de
atualizaes. Existem duas estratgias de propagao de atualizaes: Eager Replication
(sncrona) e Lazy Replication (assncrona) (WIESMANN, 2000).
Na Eager Replication, a propagao das atualizaes para os demais servidores faz
parte da transao. Assim, sempre que uma alterao aplicada ela imediatamente
propagada para os demais servidores, e s aps a atualizao de todos os servidores, o cliente
recebe a resposta. Isso garante maior consistncia, porm a transao percorre um caminho
maior, deixando as alteraes mais lentas.
Na Lazy Replication, a propagao no faz parte da transao. A transao executada
na cpia principal e os registros de alteraes so salvos. Aps algum tempo, as alteraes so
propagadas para as cpias secundrias. Nessa estratgia, o cliente recebe a resposta assim que
a alterao feita na cpia primria. Essa estratgia mais propcia a causar inconsistncias,
pois os dados ficam divergentes durante um perodo de tempo.

3.1.3 Estratgias de Propagao x Arquitetura

Os esquemas de replicao surgem a partir da combinao entre estratgias de
propagao e arquitetura. Esta sesso apresenta os principais esquemas de replicao.
A Tabela 1 representa a matriz dessa combinao.

Arquitetura

Esratgias de Propagao
Eager

Lazy

Primary Copy

Primary Copy

Eager

Lazy

Update Everywhere

Update Everywhere

Tabela 1 Matriz Estratgias de Replicao X Arquitetura

Esta combinao gera 4 esquemas distintos: Eager Primary Copy, Eager Update
Everywhere, Lazy Primary Copy e Lazy Update Everywhere.
A seguir, ser apresentada uma explicao mais detalhada sobre cada esquema.

22

3.1.3.1 Eager Primary Copy

No Eager Primary Copy, os ns mestres so donos dos objetos, sendo assim, apenas
eles podem fazer alteraes, como mostra a Figura 3 (WIESMANN, 2000).

Figura 3 - Eager Primary Copy

Quando uma alterao requisitada, criada uma transao e a alterao feita no n

mestre. Em seguida, o n mestre envia a rplica da atualizao para os ns escravos. Assim
que todos os ns escravos so atualizados sem problemas, a transao finalizada sem erros.
Caso uma rplica falhe, toda a transao falha e nenhuma atualizao feita.

3.1.3.2 Eager Update Everywhere

Neste esquema, representado pela Figura 4, todos os ns so donos do objeto, assim,
todos podem fazer alteraes e replicar para todos os outros ns (WIESMANN, 2000).
Semelhante ao Eager Primary Copy, uma transao iniciada quando uma requisio
de alterao chega a um n. Essa alterao marcada com o timestamp do objeto antigo.

23

Figura 4 - Eager Update Everywhere

Quando a alterao feita neste n, ele replica para os demais ns. Quando um n recebe a
rplica de atualizao, ele verifica se o timestamp do objeto replicado igual ou maior que a
do objeto local. Se assim for, a atualizao segura e assim ela aplicada e a transao
finalizada com xito. Caso o timestamp do objeto replicado seja inferior ao do objeto local, a
atualizao pode ser obsoleta. Ento ela no aplicada e enviada para conciliao, podendo
falhar ou no a replicao. Caso falhe, a transao inteira falha e nenhuma alterao
aplicada.

3.1.3.3 Lazy Primary Copy

Este esquema possui um proprietrio para cada objeto (GRAY, HELLAND e O'NEIL,
1996). Cada proprietrio possui o valor correto de objeto atual.

Como mostra a Figura 5, As atualizaes so feitas primeiramente no proprietrio e,

em seguida, propagadas para as outras rplicas. Objetos diferentes podem ter diferentes
proprietrios. Quando uma transao quer atualizar um objeto, ela envia um RPC (Remote
Procedure Call) para o n proprietrio do objeto.. Para simplificar, assumimos que o n de

24

Figura 5 - Lazy Primary Copy

origem transmite a rplica de atualizao para todas as rplicas escravas aps a transao
mestre ser finalizada.. Atualizaes escravas so marcadas com timestamp para garantir que
todas as rplicas iro convergir para o mesmo estado final. Se o timestamp de uma rplica
escrava maior que o timestamp da atualizao, a atualizao obsoleta. Nesse caso a
atualizao ignorada.

3.1.3.4 Lazy Update Everywhere

O esquema de replicao Lazy Update Everywhere permite que qualquer n atualize
qualquer dado local (GRAY, HELLAND e O'NEIL, 1996). Este modelo representado na
Figura 6.

Figura 6 - Lazy Update Everywhere

25

Quando a transao confirmada, uma transao enviada para os outros ns para

aplicar o conjunto de atualizaes em cada n de destino.
possvel que dois ns atualizem o mesmo objeto e concorram entre si para atualizar
o objeto em outros ns. O mecanismo de replicao deve detectar e conciliar as duas
transaes de forma que suas alteraes no sejam perdidas.
Timestamps so comumente usados para detectar e conciliar as atualizaes. Cada
objeto traz a timestamp de sua atualizao mais recente. Cada atualizao replicada carrega o
novo valor e marcado com o timestamp do objeto antigo. Cada n detecta a entrada de
atualizaes por replicao que possam sobrescrever atualizaes anteriores. O n testa se o
timestamp da rplica local igual ao da atualizao. Se assim for, a atualizao segura. Se o
timestamp atual da rplica no for igual ao timestamp antigo observado pela transao raiz,
ento a atualizao pode ser perigosa. Nesses casos o n rejeita a transao de entrada e envia
para a reconciliao.

26

Replicao no SGBD Microsoft SQL Server

O SGBD Microsoft SQL Server1 apresenta diferentes tipos de replicao de bases de

dados, que podem variar de acordo com a verso e edio do produto. Na verso e edio
analisada, 2008 Enterprise, o SQL Server oferece trs tipos de replicao com base na
estratgia assncrona (Lazy Replication): Snapshot, Transactional e Merge (PAUL, 2009).
Este captulo apresenta o modelo de replicao utilizado pelo SGBD SQL Server,
assim como os vrios componentes necessrios para sua implantao. So apresentados,
tambm, os trs tipos de replicao suportados. Ao final, apresentado um estudo de caso
seguido de um passo a passo que mostra como configurar um ambiente de replicao.

Modelo de Replicao
Quando se faz replicao com o SQL Server, o primeiro conceito que se deve entender

o modelo de replicao Publicador/Assinante. O modelo Publicador-Assinante baseado em

uma metfora do mercado da indstria de publicaes. Segundo Yang, Publicador/Assinante
um modelo de distribuio de dados com propriedades muito teis. H trs principais
entidades no modelo Publicador/Assinante: o Publicador, o Assinante e o Intermedirio
(2010, p. 66). Essa representao lgica seguida por pelo SQL Server.
O modelo Publicador/Assinante pode ser representado pela seguinte representao:
Existe um Publicador que publica livros. Um livro (Publicao) com vrios captulos
(Artigo) foi lanado e um Assinante precisa adquirir esse livro. Para que o livro seja entregue
ao assinante, o publicador precisa de um meio de distribuio confivel que leve seu livro at
o assinante. Desta forma, o Publicador contrata um Distribuidor que ser responsvel por
fazer a entrega do livro ao assinante.
Publicador

As Publicaes so transmitidas para os Distribuidores

Distribuidor
Os Agentes
Assinaturas
1 Lanado em 1989 atravs
de umacontrolam
parceiraasentre
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)
Assinante
Figura 7 Modelo Publicador/Assinante

27

Na Figura 7 podem ser identificados alguns dos componentes de replicao do SQL

Server. A replicao implementada por sete componentes: Distribuidor, Publicador,
Assinante, Publicao, Artigo, Assinatura e Agentes. Os tpicos a seguir detalham cada um
desses componentes.
Distribuidor
Este componente responsvel por fazer uma distribuio de forma transparente dos
dados, sem necessitar de interveno do Publicador. Assim o publicador fica responsvel
apenas por criar as publicaes 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 contm os dados que sero replicados. responsvel por
fazer alteraes nos dados e deve garantir a disponibilidade dos dados que sero replicados.
Assinante
O Assinante o servidor que armazena as rplicas. Ele recebe atualizaes do
Publicador, porm atualizaes feitas no Assinante podem ser enviadas para o Publicador para
que sejam replicadas para os demais Assinantes.
Publicao
A Publicao uma base de dados presente no Publicador. Essa base de dados possui
coleo de Artigos que devem ser replicados. Um Publicador pode conter uma ou mais
Publicaes.
Artigo
Artigo um conjunto de dados a serem replicados. Os Artigos podem conter uma srie
de colunas, linhas, procedimentos armazenados, vises, vises indexadas ou funes.

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 atualizaes para as tabelas dos Assinantes. No SQL Server
existem dois tipos de Assinatura: Assinatura Annima e Assinatura Nomeada. Na Assinatura
Annima, o Publicador no possui nenhuma informao sobre os Assinantes. Essas
informaes sero passadas ao Distribuidor no momento da replicao. J nas Assinaturas
Nomeadas, as Assinaturas so explcitas no Publicador e podem ser do tipo push ou pull. Nas
Assinaturas Nomeadas do tipo push, apenas o publicador pode fazer alteraes nas
Publicaes. J nas Assinaturas Nomeadas do tipo pull, os Assinantes pode solicitar alteraes
nas Publicaes. Essas Alteraes so enviadas ao Publicador e a todos os Assinantes na
prxima sincronizao.
Agentes
Os Agentes so quem realizam quase todo o trabalho. So responsveis por coletar os
dados e executar as aes necessrias. Funcionam como Jobs do SQL Server, dentro do
diretrio de replicao. O SQL Server possui cinco Agentes: Snapshot Agent, Log Reader
Agent, Distribution Agent, Merge Argent e Queue Reader Agent.
Os tpicos abaixo descrevem cada um dos Agentes apresentados nesse tpico.
Snapshot Agent
Esse Agente responsvel por criar o arquivo de snapshot e utilizado em todos os
tipos de replicao. O Snapshot Agent captura o schema e os dados que sero replicados; e
cria o arquivo de Snapshot no Distribuidor. Em seguida ele avisa sobre a sincronizao ao
Distribuidor.
Log Reader Agent
Esse Agente utilizado na replicao do tipo Transactional. Ele captura logs de
transao de alteraes em dados que esto marcados para replicao. Aps capturar os logs,
armazena na base de distribuio, no Distribuidor.
Distribution Agent

29
O Distriution Agent responsvel por enviar os snapshots ou transaes
guardadas aos Assinantes. Esse Agente utilizado nas replicaes Snapshot e Transactional.
Merge Agent
Esse Agente usado apenas na replicao do tipo Merge, e executado no
Distribuidor. O Merge Agent responsvel por aplicar o snapshot inicial nos Assinantes,
monitorar e mesclar as atualizaes aps a sincronizao inicial, e resolver conflitos.
Queue Reader Agent
Esse Agente usado na replicao Transactional para atualizar as mensagens que
foram guardadas numa fila. Na replicao Transactional existem duas opes: atualizar
imediatamente as alteraes ou atualizar quando os Assinantes estiverem disponveis. Para
atualizar imediatamente, o Publicador e o Assinante precisam estar em constante conexo.
Para atualizar quando os Assinantes estiverem disponveis, a mensagem salva numa fila e
so entregues a cada assinante pelo Queue Reader Agent quando os mesmos estiverem
disponveis.
A prxima seo apresenta os tipos de replicao que o SQL Server implementa.

Tipos de Replicao
O tipo de replicao que voc escolhe para um sistema de informao depende de

muitos fatores, incluindo o ambiente fsico da replicao, o tipo e a quantidade de dados a

serem replicados e se os dados sero ou no atualizados no Assinante (MSDN, 2010). Alguns
sistemas de informao precisam de uma replicao total em longos intervalos de tempo,
enquanto outros necessitam de replicao incremental. Tambm h possibilidade do Assinante
replicar para Publicador.
Existem trs tipos de replicao: Snapshot, Transactional e Merge. Todos os tipos de
replicao iniciam com uma sincronizao inicial, para garantir que todas as bases estaro
iguais. Essa replicao inicial feita com a replicao Snapshot.

30

Snapshot Replication
Nesse tipo de replicao todos os dados so replicados exatamente como esto no

Publicador, sem fazer rastreamento de alteraes. Dessa forma, os dados replicados pelo
Publicador sobrescrevem os dados do Assinante.
A replicao Snapshot s indicada em casos onde a aplicao permita a existncia de
bases desatualizadas, quando existem poucas alteraes de dados ou o volume total de dados
pequeno.
O SQL Server utiliza alguns componentes para implementar esse tipo de replicao.
Um dos componentes o Snapshot Agent, que responsvel por preparar os arquivos da
replicao, armazen-los na pasta de distribuio e registrar uma nova replicao no banco de
dados do Distribuidor. A pasta de distribuio escolhida assim que configurado o
Distribuidor, podendo ser uma pasta local ou remota. Geralmente, os Snapshots so gerados e
replicados assim que a publicao assinada. Em seguida, um outro servio acionado, o
Distribution Agent. Esse servio tambm executa no Distribuidor e responsvel por
propagar a distribuio para todos os Assinantes. A Figura 8 mostra como funciona a
replicao Snapshot.

31

Figura 8 - Snapshot Replication

Este tipo de replicao gera um grande conjunto de dados contendo todos os objetos
que sero replicados, o que pode tornar esse processo lento, e consumir muitos recursos do
servidor. Por este motivo, replicao Snapshot no apropriada para bases de dados que
sofrem muitas alteraes.

Transactional Replication
Esse tipo de replicao iniciado com uma replicao Snapshot para sincronizar todas

as bases e assegurar que estaro idnticas. Com a replicao Snapshot concluda, todas as

32
alteraes que so feitas no Publicador so imediatamente replicadas para os
Assinantes, na mesma ordem e limite de transao, assegurando a integridade das bases de
dados dos Assinantes.
Essa replicao indicada quando a aplicao requer um intervalo de tempo mnimo
entre as mudanas feitas no Publicador e nos Assinantes; a replicao seja feita de forma
incremental; e guarda todos os estados dos Artigos replicados. Por exemplo, se um Artigo
sofre 3 alteraes em um intervalo pequeno de tempo, os trs estados sero replicados ao
invs de apenas o ltimo.
Nessa replicao, o SQL Server utiliza, alm 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 operaes da replicao Snapshot . Em
seguida o Distribution Agent se encarrega de fazer a distribuio para todos os Assinantes.
Com todos os Assinantes sincronizados, o servio Log Reader Agent acionado. Esse servio
monitora o log de transaes de cada banco de dados configurado para a replicao
Transactional e copia as transaes marcadas para replicao do log de transaes no banco
de dados de distribuio, que atua como uma fila confivel para armazenar e avanar. Sempre
que o Log Reader Agent identifica uma nova atualizao e armazena no banco de dados do
Distribuidor, essa atualizao j pode ser distribuda pelo Distribution Agent aos Assinantes,
de acordo com o intervalo de tempo que foi configurado no Distribuidor. Os Assinantes
recebem as transaes na mesma ordem em que foram aplicados no Publicador. Se uma
assinatura estiver marcada para validao, o Distribution Agent tambm verificar se os dados
do Publicador e do Assinante coincidem. A Figura 9 demonstra como o Transactional
Replication funciona.

33

Figura 9 - Transactional Replication

Merge Replication
A replicao to tipo Merge Replication inicia como a replicao to tipo Transactional,

fazendo primeiro uma replicao do tipo Snapshot do Publicador para os Assinantes,

sincronizando todas as bases. A partir da, todas as alteraes feitas no Publicador passam a

34
ser rastreadas. Sempre que o Assinante est conectado rede, as alteraes feitas
aps a ltima sincronizao so replicadas do Publicador para o Assinante. A Figura 10
demonstra o funcionamento da Merge Replication.

Figura 10 - Merge Replication

Essa replicao utiliza o componente Snapshot Agent para criar o arquivo de

instantneo e o componente Merge Agent para distribuir as Publicaes entre os Assinantes. O
Merge Agent mescla as alteraes de dados que ocorrem no Publicador com os dados dos
Assinantes quando os mesmos esto disponveis.
Este tipo de replicao bastante utilizado em sistemas que precisam trabalhar offline
por algum tempo, fazer modificaes nos dados e depois replicar as alteraes em todos os
bancos de dados da aplicao. A sincronizao acontece de forma mais rpida que na

35
replicao Snapshot e bastante utilizado em aplicaes que requerem muitas
alteraes de dados. Por permitir alteraes de diferentes locais, podem ocorrer conflitos na
sincronizao quando o mesmo dado alterado em mais de um local. Os conflitos podem ser
resolvidos

com

criao

de

uma

poltica

de

conflitos

no

Conflict

Policy

Viewer CITATION Mul11 \l 1046 .

4.1 Estudo de Caso

Nesta seo ser mostrado como configurar a replicao Snapshot no SQL Server
2008. A configurao dos trs tipos de replicao so semelhantes, ento no fim do estudo de
caso sero apresentadas as diferenas para configurar as replicaes Transactional e Merge.
O ambiente em que ser configurada a replicao formado por uma mquina fsica
rodando Windows 7 e duas mquinas virtuais rodando Windows 7 e SQL Server 2008. As
duas mquinas virtuais esto conectadas por uma rede fsica.
As mquinas virtuais foram nomeadas windows7-1 e windows7-2. Cada uma
contendo uma instncia do SQL Server 2008 Enterprise Edition, nomeadas como
MSSQLSERVER. A mquina windows7-1 ser o Publicador/Distribuidor e a mquina
windows7-2 ser o Assinante.
Para demonstrar a replicao, foi utilizado um esquema de banco de dados simples,
criado apenas para este fim.

CITATION Mul11 \l 1046 O Conflict Policy Viewer uma ferramenta integrada ao

Microsoft SQL Server. Essa ferramenta permite visualizar todos os conflitos que ocorreram
durante a sincronizao e permite que seja escolhido uma soluo diferente para o conflito .

36

Figura 11 Modelo de dados de exemplo

4.1.1 Configurando a Replicao

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 boto 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 prprio servidor (windows7-1) para ser o
Distribuidor, selecionando a primeira opo, como mostra a Figura 13.

38

Figura 13 Selecionar Distribuidor

Na prxima 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 ficaro os arquivos de log e o arquivo
da base de dados do Distribuidor, como tambm o nome da base do Distribuidor. Figura 15.

40

Figura 15 Selecionar Base de Distribuio

Na prxima 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 prxima tela, Figura 17, ser escolhida a opo configure distribution para que a
configurao seja executada.

42

Figura 17 Finalizando configurao do Distribuidor

Se tudo ocorrer bem, a prxima tela dever ser igual a Figura 18.

43

Figura 18 Status da configurao do Distribuidor

A prxima etapa ser criar uma Publicao. Para criar uma nova Publicao deve-se
clicar com o boto direito do mouse na pasta Replication e em seguida clicar em
New/Publication... (Figura 19).

44

Figura 19 Nova Publicao

Na janela que se abrir, dever ser escolhida a base de dados onde esto os Artigos a
serem replicados (Figura 20).

45

Figura 20 Selecionando Publicador para nova Publicao

A prxima tela a parte mais importante da configurao. Nela ser definido o tipo de
replicao a ser criado. Neste trabalho optamos pela Snapshot Replication. Ento, como
mostra a Figura 21, dever ser selecionada a opo snapshot publication.

46

Figura 21 Selecionando tipo de Publicao

Na tela representada pela Figura 22, sero escolhidas as tabelas e/ou colunas que se
deseja replicar.

47

Figura 22 Escolhendo Artigos

Na tela seguinte possvel escolher um filtro os dados que sero 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 possvel optar por uma nica replicao
imediata, e/ou replicaes programadas.

49

Figura 24 Agendamento de Snapshot

A Figura 25 mostra a tela de replicao programada, onde possvel optar por

replicao em intervalos de tempo, escolher dias especficos e faixas de horrio.

50

Figura 25 Parmetros para agendamento de Sanpshot

O prximo 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 Configuraes de segurana do Agente

52

Figura 27 Parmetros de login do Snapshot Agent

As prximas telas, Figura 28 e Figura 29, finalizam a criao da nova Publicao.

53

Figura 28 Finalizando a configurao da nova Publicao

54

Figura 29 Status da configurao da nova Publicao

O prximo passo configurar uma nova Assinatura. nessa etapa que ser definido os
Assinantes da Publicao que criamos. Para adicionar uma nova Assinatura, deve-se clicar
com o boto direito do mouse em Replication e escolher a opo New/Subscriptions...,
como mostra a Figura 30.

55

Figura 30 Nova Assinatura

Na primeira tela ser pedido pra informar de qual Publicao ser a Assinatura. Como
queremos assinar a Publicao que foi criada nos passos anteriores, dever ser escolhida a
publicao 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 diferena principal
o local onde ficaro os Agents. Na Assinatura Pull os Agents executaro no Distribuidor,
centralizando e tornando mais fcil a sincronizao dos Assinantes. J na Assinatura Push,
teremos um Agent executando em cada Assinante, fazendo com que cada Assinante seja
responsvel por sua sincronizao, diminuindo a sobrecarga no Distribuidor. Escolheremos a
Assinatura Push, como mostra a Figura 32.

57

Figura 32 Local de execuo do Agente

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

Publicaes em cada Assinante. Os Assinantes podem ser servidores locais ou remotos.
Escolheremos a outra mquina virtual que est ligada rede, a mquina windows7-2, para ser
o Assinante e a base base_replicacao que uma base vazia na mquina 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 conexo 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 devero ser preenchidos os parmetros da conexo. Como nosso Distribuidor a maquina
virtual windows7-1, devemos colocar um usurio e senha que tenha permisso para acessar
essa mquina.

60

Figura 36 Configurao de segurana do Distribuidor

61

Figura 37 Parmetros de login do Distribuidor

A tela exibida na Figura 38 apresentar duas opes para Agent Scheduler, que como
o Agente deve executar. As opes so run continuously para executar continuamente, ou
run on demand para executar sob interveno do DBA. Escolheremos a opo run
continuously. As telas seguintes finalizam a configurao do Assinante. Se no acontecer
nenhuma falha, a ultima tela deve ser exibida como na Figura 40.

62

Figura 38 Intervalo de sincronizao

63

Figura 39 Preparando a inicializao da Assinatura

64

Figura 40 Status da configurao da Assinatura

65

Figura 41 Tabelas replicadas no Assinante

Depois de seguir esses passos a configurao est concluda. Como mostra a Figura
41, possvel ver na mquina 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 Replicaes Transactional e Merge, na tela que representada pela
Figura 21, deve-se escolher o tipo de publicao desejada: Transactional publication,
Transactional publication with subscriptions ou Merge publication. A diferena entre as
opes Transactional publication e a Transactional publication with subscription que na
segunda opo as alteraes feitas pelos Assinantes so replicadas para o Publicador e os
demais Assinantes. O restante da configurao idntico ao que foi apresentado neste
captulo.

66

4.2 Consideraes
O SQL Server 2008 utiliza uma arquitetura de replicao muito prxima do modelo
tradicional Primary Copy. Porm, h casos em que a replicao pode partir de uma cpia
secundria para a cpia primria, ferindo o modelo proposto pela literatura.
Apesar de implementar apenas a estratgia Lazy Replication, o SQL Server 2008
explora bastante essa estratgia com trs tipos de replicao que podem atender a maioria das
situaes em que necessrio uma replicao de base de dados.
Os pontos positivos encontrados no SQL Server so: a facilidade de configurar e
montar um ambiente de replicao; facilidade de personalizar a replicao atravs da
mudana de

apenas alguns parmetros; ferramentas de monitorando que permitem o

acompanhamento de todo o processo de replicao e o histrico de replicaes anteriores;

apresenta dois meios para se fazer a replicao: atravs da interface grfica, como foi
mostrado na seo anterior; e atravs de comandos T-SQL.
A desvantagem no ter como garantir total integridade entre as bases de dados, j
que no possvel implementar a replicao sncrona (Eager Replication).

67

PostgreSQL
O PostgreSQL um SGBD objeto-relacional que surgiu como evoluo do

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

Universidade da Califrnia (THE POSTGRESQL GLOBAL DEVELOPMENT GROUP,
2005).
O PostgreSQL surgiu a partir do cdigo-fonte do POSTGRES, que era distribudo sob
uma licena BSD. O objetivo era estabilizar o cdigo que foi herdado e implementar novas
funcionalidades, pois o POSTGRES tinha se popularizado e havia uma grande demanda de
correes e novas funcionalidades. Um grande marco nesse novo projeto foi substituir a
linguagem de consulta QUEL pela linguagem SQL, tornando-o compatvel com os demais
SGBDs.
Hoje o PostgreSQL um SGBD robusto e gratuito, mantido por uma comunidade
online e disputa mercado com os grandes SGBDs proprietrios.
Uma das principais limitaes do PostgreSQL, nas verses utilizadas neste trabalho,
no dar suporte nativo a replicao de dados. Os testes foram realizados nas verses 8.2 e 8.3
do PostgreSQL. Porm a replicao pode ser feita utilizando ferramentas que estendem esse
SGBD, oferecendo suporte a criao de ambientes de banco de dados distribudos. Dentre
estas ferramentas, as que mais se destacam so: Pgpool-II, Slony-I, PGCluster e Postgres-R.
Os prximos tpicos detalham cada ferramenta citada acima.

5.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 aplicaes utilizem o pgpool-II praticamente sem nenhuma
modificao em seus cdigos. (PGPOOL, 2009). A Figura 42 demonstra como o Pgpool-II
interage com o PostgresSQL.

68

Figura 42 - Arquitetura do Pgpool

Alm da Replicao de dados, o Pgpool oferece balanceamento de carga em consultas,

quebrando uma consulta em vrias partes e executando cada parte em uma rplica.
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 conexo com o banco de dados.
Neste modo ele oferece limitao de nmero de conexes simultneas e permite que uma
cpia secundria assuma em caso de falhas na cpia primria.
No modo Connection Poll, ele permite a reutilizao de conexes. Quando um cliente
solicita uma conexo, o Pgpool verifica se j existe alguma conexo aberta com os mesmos
parmetros. Caso exista, o Pgpool reaproveita a conexo aberta ao invs de criar uma nova

69
conexo com parmetros idnticos, diminuindo a quantidade de conexes diretas no
banco de dados.
No modo Replication, o Pgpool replica todas as alteraes de dados feitas na cpia
primria, para as demais cpias secundrias. Como sugere o modelo Eager Primary Copy,
todas as atualizaes so replicadas instantaneamente para as cpias secundrias.
No modo parallel, as consultas grandes so divididas em partes menores e distribudas
entre todas as cpias nas quais sero executadas, gerando um balanceamento de carga, o que
aumenta o desempenho em consultas mais pesadas, e diminuindo a utilizao de memria de
cada servidor.
O modo Master/Slave (Mestre/Escravo) oferece uma alternativa de replicao, na qual
os dados sero atualizados na cpia principal (Mestre) e, quando possvel, replicados nas
cpias secundrias (Escravo). Para oferecer suporte a este tipo de replicao, o Pgpool precisa
trabalhar em conjunto com outra ferramenta, o Slony-I. Os ganhos de performance no modo
mestre/escravo so superiores aos ganhos obtidos no modo paralelo (PARTIO, 2007).
A extenso pgpool-II apresenta uma srie de limitaes, se comparada a um servidor
PostgreSQL padro, como, por exemplo, no possuir um sistema de controle de acesso. Caso
o acesso via TCP/IP ao servidor PostgreSQL esteja habilitado, pgpool-II aceitar conexes
provenientes de qualquer host, sendo necessria a utilizao de outro mtodo de controle
para limitar o acesso (iptables, por exemplo). (PGPOOL, 2009)

5.1.1 Configurando o Pgpool-II

Assumindo que j se conhece as operaes bsicas do PostreSQL, ser mostrado nesse
captulo como instalar e configurar a replicao usando pgpool-II e PostgreSQL 8.2.
O primeiro passo baixar a pgpool-II na pgina oficial do pgpool, no site PgFoundry.
Neste trabalho foi utilizada a vero 3.0.5. No diretrio que foi extrado o cdigo-fonte, devem
ser executados os seguintes comandos.
$./configure
$ make
$ make install
Configure um script que coleta informaes do sistema necessrias para o
procedimento de compilao. Pode-se passar argumentos de linha de comando para alterar o

70
comportamento padro, como o diretrio de instalao. O diretrio padro
/usr/local. Make um comando que compila o cdigo fonte e make install ir instalar os
executveis. Voc deve ter permisso de escrita no diretrio de instalao. Ser tomado como
suposio que foi escolhido o diretrio padro.
O pgpool-II exige biblioteca libpq do PostgreSQL 7.4 ou superior. Se o script de
configurao exibir uma mensagem de erro informando que falta tal biblioteca, a biblioteca
libpq no est instalada, ou no a verso 3.
Os parmetros de configurao do pgpool-II so 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 configurao no arquivo pgpool.conf.
$ cp/usr/local/etc/pgpool.conf.sample/usr/local/etc/pgpool.conf
pgpool-II s aceita conexes a partir do host local usando a porta 9999. Se desejar
receber conexes de outras mquinas, 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 mquinas
separadas. Se voc decidir colocar os servidores na mesma mquina, devem ser atribudos
nmeros de porta diferentes para cada servidor. Se os servidores so colocados em mquinas
separadas, eles devem ser configurados corretamente para que possam aceitar conexes de
rede do pgpool-II.
Neste trabalho, vamos colocar trs 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 = 5432
backend_weight0 = 1
backend_hostname1 = 'localhost'
backend_port1 = 5433

71
backend_weight1 = 1
backend_hostname2 = 'localhost'
backend_port2 = 5434
backend_weight2 = 1
Para backend_hostname, backend_port, backend_weight, ser definido o hostname do
n, nmero de porta, e a razo para balanceamento de carga. No final de cada seqncia de
parmetro, O ID do n deve ser especificado pela adio de nmeros inteiros positivos a partir
de 0 (ou seja, 0, 1, 2, ...).
Os parmetros backend_weight so todos 1, o que significa que consultas SELECT
so igualmente distribudos entre os trs 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 no imprime mensagens de log. Se voc quer mostrar as mensagens
de log do pgpool, voc passa o parmetro -n para o comando pgpool. pgpool-II no executa
em segundo plano e deve ser iniciado pelo terminal.
$ Pgpool -n
As mensagens de log so impressas no terminal, por isso as opes recomendadas para
uso so como a seguir.
$ Pgpool-n -d> / tmp/pgpool.log 2> & 1 &
A opo -D permite que as mensagens de depurao 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 fora a parada do pgpool-II.
$ Pgpool-m fast stop
Para habilitar as funes de replicao e balanceamento de carga, preciso setar o
valor true nos parmetros replication_mode e load_balance_mode, no arquivo de

72
configuraes. Aps configurar e reiniciar o Pgpool, a replicao deve ser testada.
Para testar, preciso criar uma nova base no servidor principal e observar se foi replicado nos
outros 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 padro 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
Aps executar esses passos, a replicao com o Pgpool-II est configurada e
executando.

5.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 atualizaes so feitas diretamente na cpia primria. Quando uma atualizao
feita, uma trigger executada. A trigger salva um log com as alteraes. Ao perceber as
alteraes no log, o servidor principal notifica os servidores secundrios sobre as atualizaes
e grava o evento de notificao na tabela sl_event (tabela de eventos especfica do Slony-I).
Ao receber a notificao, o servidor secundrio l o arquivo de logs, aplica as alteraes e em
seguida e notifica o mestre, que remove o evento da tabela.

73
O Slony-I a nica soluo para replicao assncrona no PostegreSQL
sendo mantida. Tambm apontada pelo site do PostgreSQL como a melhor soluo para
replicao assncrona e vem inclusa no pacote de instalao oficial do PostegreSQL.

5.2.1 Configurando o Slony-I

Essa replicao foi testada um ambiente com CentOS, PostgreSQL-8.2.7,
PostgreSQL-8.2-slony1, PostgreSQL-contrib-8.2 (que traz o pgbench).
Esta seo foi escrita baseada no arquivo INSTALL que acompanha o cdigo-fonte do
Slony-I
Foram criados trs bancos: master, slave1 e slave2 e instalado o plpgsql em todos. No
banco mster, 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 primria 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 configurao para cada engine do Slony. Os arquivos contm
somente duas linhas. slave1.conf e slave2.conf foram configurado como a seguir:
cluster_name='pgbench'
conn_info='host=127.0.0.1
password=postgres'

port=5432

user=postgres

dbname=master

74
Foi criado um arquivo para cada banco e ajustado o dbname. Em seguida
cada arquivo de configurao 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 Opes Caminho do slony, foi indicado o caminho

/usr/share/slony1. No banco master, foi criado um novo cluster Slony-I usando as seguintes
opes:
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 Replicao com as
opes:
slave1:
Join existing cluster: Checked
Server: <Select the server containing the master database>
Database: master
Cluster name: pgbench
Local node: 10 Slave node 1
Admin node: 99 - Admin node
e slave2:
Join existing cluster: Checked
Server: <Select the server containing the master database>

75
Database: master
Cluster name: pgbench
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 conexo do script de
configurao.
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
Observao: 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
configuraes:
ID: 1
Comment: pgbench set
Em seguida foram adicionadas as tabelas para o Replication set (master) com
as configuraes:
Table: public.accounts
ID: 1
Index: accounts_pkey
Table: public.branches
ID: 2
Index: branches_pkey
Table: public.history
ID: 3
Index: history_pkey

76
Table: public.tellers
ID: 4
Index: tellers_pkey
No master node foi criada uma nova subscrio para cada slave usando as seguintes
opes:
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 configurao dos servidores est concluda. A replicao

inicial deve comear e pode ser monitorada na aba Estatstica do PGAdmin para cada n.
Basta selecionar o cluster pgbench, expandir os 4 ns e selecionar Estatstica.

5.3 PGCluster
O PGCluster uma ferramenta que oferece o modelo de replicao Eager Primary
Copy (CIPRIANI, 2009).
PGCluster composto por trs tipos de servidores distintos: o servidor de replicao
(Replication Server), o balanceador de carga (Load Balance Server) e o servidor PostgreSQL
em si. O balanceador de carga no necessrio apenas para realizar o balanceamento de carga
entre os servidores, mas tambm para criar um cluster de alta disponibilidade (PGCLUSTER,
2009).
O servidor de replicao envia as atualizaes para os demais servidores, sempre
verificando a disponibilidade do mesmo. Quando um servidor secundrio est indisponvel,
ele removido do cluster, at que seja corrigido. J o servidor de balanceamento de carga
envia as solicitaes de consultas para o servidor que tiver o menor nmero de conexes
ativas, pois este representa o servidor com menor carga.

77
O PGCluster opera em dois modos: normal e confivel. No modo normal o
balanceador de carga retorna o resultado de uma operao para o cliente assim que ele receber
a resposta do servidor PostgreSQL que a executou. No modo confivel o balanceador de carga
devolve a resposta ao cliente somente depois que a operao 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, no precisando implementar a
replicao atravs de triggers. Alm disso, o PGCluster indicado pelo site do PostgreSQL
como a principal ferramenta para este tipo de replicao.

5.3.1 Configurando o PGCluster

O PGCluster pode ser obtido em sua pgina no site oficial da PgFoundry. Neste
trabalho foi utilzada a verso 1.9.0 do PGCluster, PostgreSQL 8.3 com biblioteca RSync e
sistema operacional CentOS. A instalao foi feita seguindo o arquivo INSTALL, que
acompanha o cdigo-fonte do PGCluster.
Ser configurado um ambiente com trs clusters, um replicador e um balanceador de
carga, todos rodando em mquinas diferentes. Neste caso em mquinas virtuais com o
CentOS.
Primeiramente preciso compilar o cdigo-fonte baixado na pgina do PGCluster,
excutando o script Configure no diretrio o qual o cdigo-fonte foi extrado, como
demonstrado a seguir:
$ ./configure

Aps a execuo do comando, o PgCluster foi compilado. Em seguida deve ser

executado o comando gmake install-strip, que instala o PGCluster no diretrio padro
(/usr/local/pgsql). O prximo passo agora iniciar o banco de dados. Para tal, necessrio
executar o comando abaixo.
$ initdb -D /usr/local/pgsql/data

78
necessrio criar editar criar ou editar ou ambos o arquivo /etc/hots em
todas as mquinas que iro compor o sistema. Abaixo segue um exemplo de configurao.
# Balanceador de carga
192.168.0.1 loadbalancer
# Ns de armazenamento
192.168.0.11 cluster_1
192.168.0.12 cluster_2
192.168.0.13 cluster_3
# Servidores de replicao
192.168.0.21 replicate_upper
92.168.0.22 replicate_lower
necessrio editar trs arquivos de configurao: pgreplicate.conf, arquivo de
configurao do servidor de replicao; pglb.conf, arquivo de configurao do servidor de
balanceamento de carga; cluster.conf, arquivo de configurao do n de armazenamento.
Esses arquivos estaro no diretrio etc na pasta de instalao do PostgreSQL.
A configurao do pglb.conf ficar como descrito abaixo.
#==================================================
# Configuracao dos ns de armazenamento
#=================================================
<Cluster_Server_Info>
<Host_Name> clusterdb1 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> clusterdb2 </Host_Name>

79
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> clusterdb3 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30</Max_Connect>
</Cluster_Server_Info>
#==================================================
# 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 necessrio configurar dois arquivos padro
/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

do PostgreSQL,

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 nmero

mximo de conexes. Segue a configurao 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 diretrio 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>
<Recovery_Port>8101</Recovery_Port>
<LifeCheck_Port>8201</LifeCheck_Port>
</Replicate_Server_Info>
#-----------------------------------------# Configuracao de n de armazenamento

81
#-----------------------------------------<Recovery_Port> 7101 </Recovery_Port>
<LifeCheck_Port> 7201 </LifeCheck_Port>
<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>
Configurao do arquivo pgreplicate.sql:
<Cluster_Server_Info>
<Host_Name> clusterdb1 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7101 </Recovery_Port>
<LifeCheck_Port> 7201 </LifeCheck_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> clusterdb2 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7101 </Recovery_Port>
<LifeCheck_Port> 7201 </LifeCheck_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> clusterdb3 </Host_Name>

82
<Port> 5432 </Port>
<Recovery_Port> 7101 </Recovery_Port>
<LifeCheck_Port> 7201 </LifeCheck_Port>
</Cluster_Server_Info>
#-------------------------------------------------------------------# Configuracao do servidor de balanceamento de carga
#-------------------------------------------------------------------<LoadBalance_Server_Info>
<Host_Name> LoadBalance1 </Host_Name>
<Recovery_Port>8101</Recovery_Port>
<LifeCheck_Port>8201</LifeCheck_Port>
</LoadBalance_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> LoadBalance2 </Host_Name>
<Recovery_Port>8101</Recovery_Port>
<LifeCheck_Port>8201</LifeCheck_Port>
</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>
<Recovery_Port> 8101 </Recovery_Port>
<LifeCheck_Port> 8201 </LifeCheck_Port>
<RLOG_Port> 8301 </RLOG_Port>
<Response_Mode> normal </Response_Mode>

83
<Use_Replication_Log> no </Use_Replication_Log>
<Reserved_Connections> 1 </Reserved_Connections>
Com essas configuraes o ambiente est pronto. A seguir ser descrito alguns
comandos para iniciar, parar e reiniciar os servios.

Cluster
o Iniciando
$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -o "-i" start
o Parando
$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data stop
o 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/etc
o Parando
$ /usr/local/pgsql/bin/pglb -D /usr/local/pgsql/etc stop
o Reiniciando
$ /usr/local/pgsql/bin/pglb -D /usr/local/pgsql/etc restart
Replicao
o Iniciando
$ /usr/local/pgsql/bin/pgreplicate -D /usr/local/pgsql/etc
o Parando
$ /usr/local/pgsql/bin/pgreplicate -D /usr/local/pgsql/etc stop
o Reiniciando
$ /usr/local/pgsql/bin/pgreplicate -D /usr/local/pgsql/etc restart

Aps seguir a configurao descrita nessa seo, os clusters estaro funcionando,

replicando e balanceando carga entre si.

5.4 Postgres-R
Postgres-R uma extenso ao servidor de banco de dados PostgreSQL que fornece
replicao sncrona (vrios mestres) e foi projetada para ser o mais transparente possvel para
o cliente (WANNER, 2008). Comparado a um sistema de banco de dados de um nico n, um
cluster Postgres-R mais confivel e pode ser ampliado facilmente, alm de ser mais barato e

84
flexvel (POSTGRESQL, 2008). O Postgres-R adicionado ao PostgreSQL como
um patch que adiciona funcionalidades ao banco de dados.
A principal funo do Postgres-R criar um Cluster de alta disponibilidade com baixo
custo, pois no ser necessrio o uso de equipamentos especiais para esta finalidade.
Assim como a extenso PGCluster, a Postgres-R um patch para o cdigo fonte do
PostgreSQL. Postgres-R disponibilizada sob a mesma licena do servidor PostgreSQL,
eliminando completamente quaisquer problemas relacionados a incompatibilidade de licenas
entre os cdigos (POSTGRESQL, 2008).
A instalao do Postgres-R pode ser encontrada em (CIPRIANI, 2009).

5.5 Consideraes
O PostgreSQL, por ser uma ferramenta de cdigo aberto com muitos colaboradores,
possui mais solues de replicao. O PostgreSQL, alm de ferramentas que implementam
todos os esquemas de replicao apresentados no trabalho, possui ferramentas que trabalham
com conceitos mais avanados, como clustering.
Apesar de implementar replicao apenas

atravs de ferramentas de terceiros,

possvel implementar todas as arquiteturas e estratgias de replicao apresentadas neste

trabalho. Porm, as ferramentas de replicao so menos customizveis que a replicao do
SQL Server.
Com o Pgpool-II ou Slony-I possvel fazer Eager replication, que no possvel
utilizando o SQL Server.
O processo de configurao dos esquemas de replicao simples, porm menos
intuitivo, pois realizado atravs de comandos e/ou arquivos de configurao.

85

Concluses e Trabalhos Futuros

Este trabalho apresentou as arquiteturas, estratgias de propagao de atualizaes e

esquemas de replicao de bases de dados propostos pela literatura. Foram apresentadas,

tambm, as implementaes dessas estratgias 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 criao de ambientes com
replicao de bases de dados nessas duas tecnologias. Apesar dos dois SGBDs apresentarem
solues de replicao, as implementaes e estratgias disponveis em cada produto difererm
em vrios pontos.
A replicao no SQL Server se deu de forma mais intuitiva e com mais facilidade de
customizao. Em contrapartida, ele oferece apenas uma estratgia de propagao, a
estratgia Lazy Replication. O PostgreSQL, por outro lado, pode trabalhar como com todos os
esquemas de replicao, porm no oferece suporte nativo. necessrio utilizar ferramentas
de terceiros, o que pode causar problemas devido a incompatibilidade de verses entre as
ferramenta de replicao e o PostgreSQL.
Dentre os SGBDs analisados, somente o PostgreSQL oferece suporte estratgia
Eager Replication. Embora implemente somente variaes da estratgia Lazy Replication, o
SGBD SQL Server oferece ferramentas e suporte para que a replicao ocorra sem erros, ou
que os conflitos da replicao possam ser resolvidos.
Este trabalho delineia como proposta de trabalhos futuros: a) o estudo da
implementao das estratgias de replicao de banco de dados em outros SGBDs do
mercado, como Oracle e DB2; b) um estudo sobre o suporte a estratgias de replicao em
SGBDs no relacionais.

86

Referncias

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

Francisco: Morgan Kaufmann Publishers, 1997.
CIPRIANI, O. N. REPLICAO 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. Implementao 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:

Disponivel

em:

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

PGPOOL.

PGPOOL.

PgFOundary,

2009.

<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.

THE POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL 8.0.26
Documentation.

PostgreSQL,

2005.

Disponivel

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

em:

87
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.