carlos augusto paiva
DESCRIPTION
Base de datosTRANSCRIPT
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
APLICAÇÃO DE ESTRATÉGIAS DE REPLICAÇÃO DE BASES DE DADOS EM SISTEMAS GERENCIADORES DE
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
APLICAÇÃO DE ESTRATÉGIAS DE REPLICAÇÃO DE BASES DE DADOS EM SISTEMAS GERENCIADORES DE
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
Cluster name: pgbench
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
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 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>
<Cluster_Server_Info>
79
<Host_Name> clusterdb2 </Host_Name>
<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á 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>
<Recovery_Port>8101</Recovery_Port>
<LifeCheck_Port>8201</LifeCheck_Port>
</Replicate_Server_Info>
#------------------------------------------
81
# Configuracao de nó de armazenamento
#------------------------------------------
<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>
Configuração 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>
82
<Host_Name> clusterdb3 </Host_Name>
<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>
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