Embed Size (px)
Citation preview
ESTUDO DE ALGORITMOS E TÉCNICAS DE
REPLICAÇÃO DE BANCO DE DADOS EM SOFTWARE
LIVRE
Daniel Afonso Heisler
Lajeado, junho de 2008
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
CENTRO UNIVERSITÁRIO UNIVATES
CURSO DE ENGENHARIA DA COMPUTAÇÃO
ESTUDO DE ALGORITMOS E TÉCNICAS DE
REPLICAÇÃO DE BANCO DE DADOS EM SOFTWARE
LIVRE
Daniel Afonso Heisler
Trabalho de Conclusão de Curso – Etapa II, apresentado ao Curso de Engenharia da Computação, do Centro Universitário UNIVATES, para a obtenção do título de Engenheiro de Computação.
Orientador: Maglan Cristiano Diemer
Lajeado, julho de 2008
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Dedico este trabalho aos meus pais
que me deram a educação
para que eu conseguisse fazer
minhas escolhas com sabedoria.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
AGRADECIMENTOS
Agradeço a Deus pela minha vida e toda a saúde para chegar até aqui;
agradeço a meus pais, à minha namorada, aos meu irmãos por todo o apoio e
amor necessário para chegar até aqui; agradeço a meus amigos e colegas de
aula pela ajuda e compreensão necessária; agradeço aos mestres por todos seus
ensinamentos e companheirismo; agradeço ao meu orientador por todo o apoio e
incentivo para conseguir elaborar este trabalho.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Quem quer fazer alguma coisaencontra um meio.
Quem não quer fazer nadaencontra uma desculpa.
Roberto Shinyashiki
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
RESUMO
A tecnologia de sistemas de bancos de dados distribuídos é a união de duas abordagens para processamento de dados: as tecnologias de sistemas de bancos de dados e de redes de computadores. Existem diversas técnicas para que seja possível a distribuição de bancos de dados, uma delas é a replicação. Este trabalho visa estudar os diferentes algoritmos e as técnicas de replicação para banco de dados em software livre.
PALAVRASCHAVE: Banco de dados distribuídos. Replicação.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
ABSTRACT
The tecnology of distributed database systems is a union of two approaches to processing data: the tecnology of databases systems and computer networks. There are several techniques in order to the database distribution, one of them is a replication. This paper aims to study the various algorithms and techniques of database replication in free softwares.
KEYWORDS: Distributed database. Replication.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE FIGURAS
FIGURA 1 Rede de computadores.......................................................................35
FIGURA 2 Modelo relacional................................................................................42
FIGURA 3 Arquitetura cliente/servidor de referência...........................................47
FIGURA 4 Arquitetura de banco de dados distribuído de referência...................48
FIGURA 5 Arquitetura de SVBD com um ECG....................................................49
FIGURA 6 Exemplo do modelo de replicação singlemaster...............................56
FIGURA 7 Exemplo do modelo de replicação multimaster.................................57
FIGURA 8 Exemplo de replicação utilizando a ferramenta DBLink com Triggers
.................................................................................................................................66
FIGURA 9 Exemplo de servidores de banco de dados utilizando a ferramenta
PgCluster para replicação.......................................................................................69
FIGURA 10 Exemplo de servidores com replicação de de banco de dados
cascateada utilizando a ferramenta SlonyI............................................................70
FIGURA 11 Exemplo de disposição dos computadores na rede do laboratório..74
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
8
FIGURA 12 Definição da estrutura do cenário 1..................................................76
FIGURA 13 Definição da estrutura do cenário 2..................................................77
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE GRÁFICOS
GRÁFICO 1 Dados coletados das ferramentas replicadoras, com 1 servidor
master replicando para 2 servidores slaves as alterações da base de dados,
geradas por 1 cliente, durante aproximadamente 10 minutos...............................85
GRÁFICO 2 Dados coletados das ferramentas replicadoras, com 1 servidor
master replicando para 2 servidores slaves, as alterações da base de dados
geradas por 5 clientes, durante aproximadamente 10 minutos..............................87
GRÁFICO 3 Dados coletados das ferramentas replicadoras, com 1 servidor
master replicando para 2 servidores slaves, as alterações da base de dados
geradas por 10 clientes, durante aproximadamente 10 minutos............................88
GRÁFICO 4 Dados coletados das ferramentas replicadoras, com 1 servidor
master replicando para 2 servidores slaves, as alterações da base de dados
geradas por 20 clientes, durante aproximadamente 10 minutos............................90
GRÁFICO 5 Dados coletados na replicação entre os três servidores, durante 10
minutos, onde suas bases de dados foram acessadas por apenas 1 cliente........94
GRÁFICO 6 Dados coletados na replicação entre os três servidores, durante 10
minutos, onde suas bases de dados foram acessadas por apenas 5 clientes......94
GRÁFICO 7 Dados coletados na replicação entre os três servidores, durante 10
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
10
minutos, onde suas bases de dados foram acessadas por apenas 10 clientes....95
GRÁFICO 8 Dados coletados na replicação entre os três servidores durante 10
minutos onde suas bases de dados era acessadas por apenas 20 clientes.........96
GRÁFICO 9 Dados coletados das ferramentas replicadoras, com 1 servidor
master replicando para 2 servidores slaves de forma assíncrona a cada 5, 10 e 20
minutos, as alterações da base de dados geradas por 1 cliente, durante
aproximadamente 41 minutos.................................................................................99
GRÁFICO 10 Dados coletados das ferramentas replicadoras, com 1 servidor
master replicando para 2 servidores slaves de forma assíncrona a cada 5, 10 e 20
minutos, as alterações da base de dados geradas por 5 clientes, durante
aproximadamente 41 minutos...............................................................................101
GRÁFICO 11 Dados coletados das ferramentas replicadoras, com 1 servidor
master replicando para 2 servidores slaves, de forma assíncrona, a cada 5, 10 e
20 minutos, as alterações da base de dados geradas por 10 clientes, durante
aproximadamente 41 minutos...............................................................................102
GRÁFICO 12 Dados coletados das ferramentas replicadoras, com 1 servidor
master replicando para 2 servidores slaves, de forma assíncrona, a cada 5, 10 e
20 minutos, as alterações da base de dados geradas por 20 clientes, durante
aproximadamente 41 minutos...............................................................................103
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE QUADROS
QUADRO 1 Avaliação dos SGBDs.......................................................................34
QUADRO 2 Características do uso de dblink e triggers.......................................65
QUADRO 3 Características da ferramenta PgCluster..........................................68
QUADRO 4 Características da ferramenta SlonyI..............................................72
QUADRO 5 Características dos computadores utilizados nos testes.................74
QUADRO 6 Médias dos dados, coletados das ferramentas replicadoras, com 1
servidor master replicando para 2 servidores slaves, as alterações da base de
dados geradas por 1 cliente....................................................................................85
QUADRO 7 Médias dos dados coletados das ferramentas replicadoras, com 1
servidor master replicando para 2 servidores slaves, as alterações da base de
dados geradas por 5 clientes..................................................................................86
QUADRO 8 Médias dos dados coletados, das ferramentas replicadoras, com 1
servidor master replicando para 2 servidores slaves, as alterações da base de
dados geradas por 10 clientes................................................................................88
QUADRO 9 Médias dos dados coletados das ferramentas replicadoras, com 1
servidor master replicando para 2 servidores slaves, as alterações da base de
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
12
dados geradas por 20 clientes................................................................................89
QUADRO 10 Médias das replicações coletadas nas simulações do cenário 2...96
QUADRO 11 Médias dos dados coletados das ferramentas replicadoras, com 1
servidor master replicando para 2 servidores slaves as alterações da base de
dados geradas por 1 cliente, no intervalo de tempo de 5, 10 e 20 minutos...........99
QUADRO 12 Médias dos dados coletados das ferramentas replicadoras, com 1
servidor master replicando para 2 servidores slaves as alterações da base de
dados geradas por 5 clientes, no intervalo de tempo de 5, 10 e 20 minutos.......100
QUADRO 13 Médias dos dados coletados das ferramentas replicadoras, com 1
servidor master replicando para 2 servidores slaves, as alterações da base de
dados geradas por 10 clientes, no intervalo de tempo de 5, 10 e 20 minutos.....102
QUADRO 14 Médias dos dados coletados das ferramentas replicadoras, com 1
servidor master replicando para 2 servidores slaves, as alterações da base de
dados geradas por 20 clientes, no intervalo de tempo de 5, 10 e 20 minutos.....103
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE ABREVIATURAS E SIGLAS
ACID Atomicidade, Consistência, Isolamento e Durabilidade.
Bps – bits por segundo.
DCL – Data Control Language (Linguagem de Controle de Dados)
DDL – Data Definition Language (Linguagem de Definição de Dados)
DML – Data Manipulation Language (Linguagem de Manipulação de
Dados)
DQL – Data Query Language (Linguagem de Consulta de Dados)
ECG – Esquema conceitual global
EEC Error Correction Code (Código de Correção de Erros)
EIL Esquema Interno Local
Kbps – Kilobits por segundo
KBps – Kilobytes por segundo
LAN – Local Area Network (Rede Local)
MANs – Metropolitan Area Networks (Redes metropolitanas)
Mbps – Megabits por segundo
MBps – Megabytes por segundo
QBE – Que é uma aplicação visual do cálculo de domínios
QUEL – Uma antiga linguagem de consulta para banco de dados
relacionais. É uma linguagem antecessora ao SQL
SGBD Sistema Gerenciador de Banco de Dados
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
14
SQL – Structured Query Language (Linguagem de Consulta Estruturada)
SVBD – Sistemas de vários bancos de dados
WAN – Wide Area Network (Rede que abrange grandes áreas)
XML – EXtensible Markup Language (Linguagem de marcação estendida)
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE EXEMPLOS
EXEMPLO 1 Consulta SQL..................................................................................42
EXEMPLO 2 Exemplo hipotético de instruções SQL para replicação síncrona. .54
EXEMPLO 3 Exemplo hipotético de instruções SQL para replicação assíncrona
.................................................................................................................................55
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
SUMÁRIO
1 INTRODUÇÃO.....................................................................................................20
2 FUNDAMENTAÇÃO TEÓRICA..........................................................................23
2.1 SGBD................................................................................................................24
2.1.1 Modelo de dados............................................................................................24
2.1.1.1 Modelos lógicos com base em objetos.......................................................25
2.1.1.2 Modelos lógicos com base em registros.....................................................25
2.1.1.3 Modelos físicos...........................................................................................25
2.1.2 Segurança e integridade................................................................................26
2.1.3 Recuperação e concorrência.........................................................................27
2.1.4 Linguagem de banco de dados......................................................................28
2.1.4.1 Álgebra relacional.......................................................................................28
2.1.4.2 Cálculo relacional........................................................................................29
2.1.4.3 SQL.............................................................................................................30
2.1.5 SGBDs em software livre...............................................................................32
2.2 Redes de computadores...................................................................................34
2.2.1 Escala das redes............................................................................................36
2.3 Sistema de banco de dados distribuídos..........................................................37
2.3.1 Sistemas distribuídos.....................................................................................37
2.3.2 Banco de dados distribuídos..........................................................................41
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
17
2.3.3 Transparência e formas de distribuição.........................................................42
2.3.3.1 Fragmentação de dados.............................................................................43
2.3.3.2 Replicação de dados...................................................................................44
2.3.3.3 Transparência.............................................................................................44
2.3.4 Arquitetura de SGBDDs.................................................................................46
2.3.4.1 Sistemas cliente/servidor............................................................................46
2.3.4.2 Sistemas distribuídos nãohierárquicos......................................................48
2.3.4.3 Arquitetura de SVBDs.................................................................................49
2.3.5 Tolerância a falhas.........................................................................................49
2.3.5.1 Dependabilidade.........................................................................................50
2.3.5.2 Tipos de falhas............................................................................................51
2.3.5.3 Mascarando falhas com redundância.........................................................51
2.4 Replicação.........................................................................................................53
2.4.1 Tipos de replicação........................................................................................53
2.4.1.1 Síncrona......................................................................................................53
2.4.1.2 Assíncrona..................................................................................................54
2.4.2 Modelos de replicação...................................................................................55
2.4.2.1 Singlemaster ou masterslave...................................................................55
2.4.2.2 Multimaster.................................................................................................56
2.4.3 Protocolo de controle de réplica....................................................................57
2.4.3.1 PrimaryCopy Method ................................................................................57
2.4.3.2 QuorumConsensus Method ......................................................................58
2.4.3.3 AvailableCopies Method ...........................................................................58
2.4.4 Métodos de replicação...................................................................................59
2.4.4.1 Arquivos de registros (logs)........................................................................59
2.4.4.2 Triggers.......................................................................................................60
2.4.5 Modelo de transações distribuídas................................................................60
2.4.5.1 Protocolo de efetivação em duas fases – 2PC...........................................61
2.4.5.2 Protocolo de efetivação em três fases – 3PC.............................................62
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
18
3 FERRAMENTAS UTILIZADAS...........................................................................63
3.1 DBLink e triggers...............................................................................................64
3.2 PgCluster...........................................................................................................67
3.3 SlonyI...............................................................................................................70
4 AVALIAÇÃO DAS FERRAMENTAS..................................................................73
4.1 Cenários............................................................................................................73
4.1.1 Cenário 1 – masterslave...............................................................................75
4.1.2 Cenário 2 – multimaster................................................................................76
4.2 Bases de dados................................................................................................78
4.3 Metodologia.......................................................................................................78
5 RESULTADOS OBTIDOS...................................................................................82
5.1 Replicação síncrona..........................................................................................82
5.1.1 Cenário 1 masterslave................................................................................83
5.1.1.1 Acesso à base de dados por um cliente.....................................................83
5.1.1.2 Acesso à base de dados por cinco clientes................................................85
5.1.1.3 Acesso à base de dados por dez clientes..................................................87
5.1.1.4 Acesso à base de dados por vinte clientes................................................88
5.1.1.5 Conclusões sobre o cenário 1 masterslave............................................90
5.1.2 Cenário 2 multimaster.................................................................................92
5.1.2.1 Acesso à base de dados por um cliente.....................................................93
5.1.2.2 Acesso à base de dados por cinco clientes................................................94
5.1.2.3 Acesso à base de dados por dez clientes..................................................95
5.1.2.4 Acesso à base de dados por vinte clientes................................................95
5.1.2.5 Conclusões sobre o cenário 2 – multimaster............................................96
5.2 Replicação assíncrona......................................................................................97
5.2.1 Cenário 1 masterslave................................................................................97
5.2.1.1 Acesso à base de dados por um cliente.....................................................98
5.2.1.2 Acesso à base de dados por cinco clientes..............................................100
5.2.1.3 Acesso à base de dados por dez clientes................................................101
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
19
5.2.1.4 Acesso à base de dados por vinte clientes..............................................102
5.2.1.5 Conclusões sobre o cenário 1 masterslave..........................................104
5.2.2 Cenário 2 multimaster...............................................................................105
6 CONCLUSÃO....................................................................................................106
REFERÊNCIAS.....................................................................................................108
GLOSSÁRIO.........................................................................................................111
APÊNDICES.........................................................................................................113
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
1 INTRODUÇÃO
Num ambiente de negócios não há tempo para atrasos, pois a perda de
tempo, resulta em perda de oportunidades. Os dados são a base crítica para
todas as organizações, porque é através da consulta dos mesmos que são
tomadas as decisões. Sendo assim, é extremamente necessário que os dados
estejam sempre disponíveis no local e velocidade desejados. Através dos
sistemas gerenciadores de banco de dados (SGBDs), é possível armazenar os
mesmos em banco de dados.
A grande vantagem na utilização de SGBDs está justamente na abstração
dos dados, isto é, na possibilidade de visualizar somente aquilo que é necessário
para tomar uma decisão. Enquanto que a distribuição dos bancos de dados
permite que os mesmos sejam acessados com maior velocidade e com um menor
risco de indisponibilidade. A maior velocidade está relacionada diretamente com a
possibilidade de distribuir os bancos de dados em diferents computadores e como
conseqüência também distribuir a carga de processamento entre os mesmos. O
menor risco de indisponibilidade através da utilização da distribuição dos bancos
de dados está relacionado com a quantidade de cópias idênticas dos mesmos
(Silberschatz, 1999).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
21
Segundo Özsu (2001), a tecnologia de sistemas de bancos de dados
distribuídos (SBDDs) é a união de duas abordagens para processamento de
dados: as tecnologias de sistemas de bancos de dados e a de redes de
computadores.
Existem diversas técnicas que possibilitam a distribuição de bancos de
dados, sendo que uma delas é a replicação. Os dois principais motivos para fazer
uma replicação são: a confiabilidade e a performance. No caso da confiabilidade,
existe a garantia de se ter sempre um backup (cópia de segurança) em tempo
real e, por conseqüência, alta disponibilidade do sistema. Já a performance, é
importante quando existem muitos acessos aos dados num mesmo intervalo de
tempo, ou quando os acessos são de lugares espalhados geograficamente, pois
dessa forma é possível balancear a carga de acessos através de paralelismo
(Tanenbaum, 2002; Silberschatz, 1999).
O próprio Google, o site de busca mais popular do mundo, especulase que
utiliza algumas centenas de milhares de computadores comuns, que rodam Linux
Red Hat com o Kernel modificado e fazem replicação de banco de dados. Pois,
com quantidade tão grande de computadores, é muito provável que
periodicamente ocorram falhas nos equipamentos. Contudo, usando replicação e
redundância, mesmo tendo múltiplas falhas, têmse sempre alta disponibilidade
(Gedda, 2006).
O objetivo desse trabalho é fazer um estudo dos algoritmos e das técnicas
de replicação de banco de dados, ou seja, estudar as possíveis formas de
replicação de banco de dados e, conseguir, através de métricas, fazer a análise
de alguns casos práticos de replicação. Assim, a seção 2 apresenta um
levantamento bibliográfico feito através de livros, revistas, trabalhos e artigos
científicos sobre assuntos pertinentes ao tema do mesmo. São apresentados
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
22
vários conceitos relacionados a SGDBs, sistemas distribuídos e replicação,
formando assim, a fundamentação teórica do trabalho.
Já a seção 3 do trabalho, apresenta as ferramentas replicadoras utilizadas
nesse estudo. Nessa seção são descritas suas características, classificandoas
conforme a fundamentação teórica vista na seção anterior.
A seção 4, descreve a metodologia adotada para fazer os testes e a
avaliação das diferentes técnicas, ferramentas e algoritmos, de replicação de
dados. Os resultados obtidos a partir dessas testes, são exibidos na seção 5.
Finalizando, são apresentadas as conclusões deste trabalho, contribuições
do mesmo e sugestões de trabalhos futuros.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2 FUNDAMENTAÇÃO TEÓRICA
Esta seção apresenta a fundamentação teórica necessária para o
desenvolvimento deste trabalho. A mesma é dividida em quatro subseções que
abordam os assuntos: SGBDs, redes de computadores, SGBDs distribuídos e
replicação.
Na subseção 2.1, são abordadas algumas características dos SGBDs,
como: integridade, segurança, transações, modelos de dados e linguagens para
manipulação de banco de dados. Além disso, também há um comparativo de
SGBDs livres para definição de qual deles será utilizado no desenvolvimento do
trabalho. Essas abordagens estudadas são fundamentais, pois na utilização de
replicação, além das diferentes técnicas, as características dos SGBDs também
influenciam no desempenho e na forma com que esses dados são replicados.
A subseção 2.2 traz definições e características de redes de computadores,
comunicação dos dados e as diferentes escalas de rede. Como já introduzido, a
distribuição de banco de dados é a união de duas abordagens: redes de
computadores e SGBDs. Assim, os conceitos definidos nesta subseção são
importantes, pois para cada modelo ou escala de rede, existem técnicas de
replicação que podem ou não ser aplicadas com ou sem a performance desejada.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
24
As subseções 2.3 e 2.4 detalham os conceitos de distribuição e replicação
de banco de dados. Apresentam desde as características necessárias para
alcançar a distribuição, até as diferentes técnicas existentes para fazer uma
replicação.
2.1 SGBD
De acordo com Sisberschatz (1999), um SGBD é constituído por dados e
programas que permitem seu acesso e sua manipulação. Sua principal finalidade
é permitir o armazenamento de dados de forma segura, íntegra e que a
recuperação dos mesmos possa ser feita de forma eficiente. Também é tarefa dos
sistemas gerenciadores de banco de dados, permitirem a criação de estruturas
para seu armazenamento, assim como, a gerência ao seu acesso, de forma que,
somente consigam acessálos quem tiver a devida autorização. O conjunto de
dados de uma estrutura de um sistema gerenciador de banco de dados,
normalmente é chamada de banco de dados.
2.1.1 Modelo de dados
Silberschatz (1999), diz que sobre a estrutura de um banco de dados está
definido um modelo de dados, isto é, um conjunto de regras que definem a
semântica, o relacionamento e a consistência dos mesmos. Esse modelo é
classificado em três grupos: lógicos com base em objetos, lógicos com base em
registros e físicos.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
25
2.1.1.1 Modelos lógicos com base em objetos
Modelos lógicos com base em objetos são modelos amplamente utilizados
e, inclusive alguns, ainda estão por surgir. Utilizados na descrição de dados no
nível lógico e de visões, possuem recursos de estruturação bem flexíveis, além de
viabilizarem a especificação explícita de restrições. Segundo Silberschatz (1999),
existem diversos modelos lógicos com base em objetos. Dentre os amplamente
conhecidos, destacamse o entidaderelacionamento e o orientado a objetos.
2.1.1.2 Modelos lógicos com base em registros
Modelos lógicos com base em registros são utilizados para descrever os
dados no nível lógico e de visão. Ao contrário do modelo lógico com base em
objetos, esse especifica a estrutura lógica do banco de dados quanto a
implementação de descrições de alto nível.
Esses modelos são assim chamados por possuírem a estrutura do banco
de dados em registros de formato fixo de todos os tipos. Cada registro define um
número fixo de campos, e cada campo possui normalmente tamanho fixo.
Os modelos de dados com base em registros mais utilizados, normalmente
são: modelo relacional, modelo de rede e modelo hierárquico (Silberschatz, 1999).
2.1.1.3 Modelos físicos
Os modelos físicos de dados são usados para descrever os dados num
nível mais baixo. Ao contrário dos modelos lógicos, existem poucos modelos
físicos de dados ainda em uso. Os dois mais conhecidos são o modelo unificado
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
26
(unifying model) e o modelo de partição de memória (framememory model)
(Silberschatz, 1999).
2.1.2 Segurança e integridade
Em banco de dados, é muito comum o uso dos termos segurança e
integridade dos dados. Embora os dois conceitos sejam bem distintos, em ambos
os casos, o sistema precisa estar ciente daquilo que o usuário não pode violar. De
forma geral, a segurança garante que os usuários tenham permissão de fazer o
que estiverem tentando fazer, enquanto a integridade garante que aquilo que os
usuários estão tentando fazer, está correto (Date, 1990).
A segurança dos dados inclui dois aspectos: a proteção dos dados e o
controle de autorização. A proteção dos dados é necessária para evitar que
usuários não autorizados conheçam o conteúdo físico dos mesmos e o principal
meio para conseguir isso é a criptografia. Já o controle de autorização deve
garantir que os usuários executem no banco de dados, apenas operações a que
eles têm permissão.
Diferentemente do controle de autorização dos sistemas operacionais, os
SGBDs possibilitam que as autorizações possam ser redefinidas, para que
usuários diferentes tenham direitos diferentes sobre os mesmos objetos. Isso
possibilita uma maior precisão no controle de autorização dos usuários perante os
objetos do banco de dados.
Manter um banco de dados consistente requer diversos mecanismos como
controle de concorrência, confiabilidade, proteção e controle de integridade
semântica. Este último, é um conjunto de restrições que, se satisfeitas, indicam
que um banco de dados está consistente.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
27
Existem dois tipos principais de restrições de integridade: restrições
estruturais e restrições comportamentais. As restrições estruturais expressam
propriedades semânticas básicas inerentes a um modelo. Como exemplo, num
modelo relacional, podese citar as restrições de chave exclusiva. Já as restrições
comportamentais permitem captar a semântica dos aplicativos, podendo
expressar as associações entre objetos, assim como, a dependência da inclusão
num modelo relacional (Özsu, 2001).
2.1.3 Recuperação e concorrência
Os problemas de concorrência e recuperação em banco de dados estão
fortemente ligados ao processamento de transações. Uma transação é uma única
unidade de trabalho lógica. A integridade de uma transação depende de 4
propriedades conhecidas como ACID (atomicidade, consistência, isolamento e
durabilidade) (Date, 1990).
Por exemplo, a transferência do valor de uma conta bancária A para uma
conta bancária B, implica em debitar o valor de A e creditar o mesmo valor em B.
O primeiro princípio é que, de forma alguma, o valor deve ser debitado de A se
não for creditado em B, isto é, ou a operação é executada como um todo, ou não
é executada. Este “tudo ou nada” é chamado de atomicidade. Além disso, o
somatório, após a transferência das contas A e B, deve ser o mesmo que era
antes da transferência. Essa exigência é conhecida como consistência. Se duas
transferências estiverem ocorrendo ao mesmo tempo, uma não deve interferir na
outra. Esta propriedade é conhecida como isolamento. Por fim, após a efetivação
da transferência, os novos valores de A e B devem persistir, a despeito das
possibilidades de falhas do sistema. Esta persistência é chamada de durabilidade.
Dessa forma, cada transação é uma unidade de ACID que não pode violar as
regras de consistência de um banco de dados (Silberschatz, 1999).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
28
Silberschatz (1999), segue afirmando que devido ao grande número de
possibilidades de falhas de um banco de dados durante a execução de uma
transação, uma transação pode não se completar com sucesso. Garantindo a
atomicidade do banco de dados, uma transação incompleta não poderá
comprometer o estado do banco de dados e dessa forma, o banco de dados
deverá retornar ao estado anterior ao da transação. Essa responsabilidade de
detectar eventuais falhas e de retornar ao estado anterior é responsabilidade do
SGBD.
Por fim, Silberschatz (1999) conclui que quando existem várias transações
num banco de dados sendo executadas ao mesmo tempo, é possível que
algumas delas violem as regras de consistência do banco de dados. Isso pode
ocorrer, mesmo que as transações individualmente sejam executadas de forma
correta. Essa responsabilidade de gerenciar as transações concorrentes também
pertence ao SGBD.
2.1.4 Linguagem de banco de dados
As linguagens para manipulação de dados em banco de dados relacionais,
entram em dois grupos fundamentais: As baseadas na álgebra relacional e as
baseadas em cálculo relacional (Özsu, 2001).
2.1.4.1 Álgebra relacional
A álgebra relacional é uma linguagem de consulta procedural formada por
um conjunto de operadores que operam sobre as relações. É derivada da teoria
dos conjuntos e é mais utilizada que o cálculo relacional. Cada operador toma
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
29
uma ou duas relações como operandos, produzindo uma nova relação resultante
(Silberschatz, 1999).
Segundo Özsu (2001), os operadores fundamentais da álgebra relacional
são: seleção, projeção, união, diferença de conjuntos e produto cartesiano. Além
desses operadores fundamentais, ainda existem outros operadores adicionais,
formados a partir dos fundamentais, que são: interseção, junção Ɵ (theta), junção
natural, semijunção e quociente. Na prática, a álgebra relacional é estendida com
operadores, para agrupar ou classificar os resultados, e para executar as funções
aritméticas de agregado. Outros operadores, como os de junção externa e
fechamento transitivo, também são utilizados algumas vezes para proporcionar
funcionalidades adicionais.
Uma das linguagens mais utilizadas entre as que seguem as definições da
álgebra relacional é a linguagem SQL1. Embora alguns autores definam essa
linguagem como um ponto entre a álgebra relacional e ao cálculo relacional de
tuplas, seus criadores a definem como linguagem de mapeamento.
2.1.4.2 Cálculo relacional
Nas linguagens de cálculo relacional, ao invés de especificar como obter
um resultado, especificase o que é o resultado. Um banco de dados pode ser
visto como uma coleção de tuplas ou de domínios, dessa forma existem dois
grupos sob os quais cai o cálculo relacional: cálculo relacional de tuplas e cálculo
relacional de domínios. A diferença entre os dois está basicamente sob a variável
primitiva da consulta (Özsu, 2001).
1 Structured Query Language ou Linguagem de Consulta Estruturada, é a linguagem para manipulação de banco de dados mais utilizada. Fonte: Silberschatz (1999).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
30
Em álgebra relacional, as consultas são escritas sob forma de uma
seqüência de procedimentos. Já no cálculo relacional de tuplas é uma linguagem
nãoprocedural. Ela permite a descrição da consulta desejada sem especificar os
procedimentos para obter essas informações. Há várias linguagens baseadas em
cálculo relacional de tuplas, sendo as mais populares SQL e QUEL (Silberschatz,
1999; Özsu, 2001).
O cálculo relacional de domínios utiliza variáveis de domínio, que tomam
valores do domínio de um atributo, em vez de valores da tupla inteira. Em outras
palavras, o intervalo de uma variável de domínios consiste nos domínios sobre os
quais a relação é definida. Mesmo assim, o cálculo relacional de domínios está
intimamente ligado ao cálculo relacional de tuplas. O sucesso desta linguagem
devese principalmente à QBE, que é uma aplicação visual do cálculo de
domínios (Özsu, 2001).
2.1.4.3 SQL
A SQL – Struct Query Language, é a linguagem de banco de dados que
surgiu no início dos anos 70 e hoje, é a linguagem de banco de dados mais
utilizada. Ela utiliza uma combinação de construtores em álgebra e cálculo
relacional e, dessa forma, é bastante fácil sua utilização. Embora conhecida como
uma linguagem de consulta, ela possui vários outros recursos (Silberschatz,
1999).
A SQL é uma sublinguagem do SGBD. Possui tanto uma linguagem para
definição de dados (DDL – data definition language), como uma linguagem para
manipulação de dados (DML – data manipulation language) e uma linguagem
para consulta de dados (DQL – data query language). Além disso possui recursos
especiais de controle de dados que não se enquandram nem na DDL, nem na
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
31
DML. Alguns autores chamam esses recursos de linguagem de controle de dados
(DCL – data control language) (Date, 1990).
Segundo Silberschatz (1999), a linguagem SQL pode ser dividida em
diversas partes:
Linguagem de definição de dados: possui comandos para criação,
alteração e exclusão de esquemas de relações, bem como a manipulação de
índices.
Linguagem interativa de manipulação de dados: é a linguagem baseada
na álgebra relacional e no cálculo relacional para criar consultas. Também
engloba comando para inserção, alteração e exclusão de tuplas no banco de
dados.
Incorporação DML: é a forma de comandos SQL incorporados para
permitir o uso de outras linguagens de uso geral como o C, PL/I, Cobol etc.
Definição de visões: comandos para definição de visões, isto é, relações
simbólicas criadas a partir de consultas.
Autorização: comandos para especificação de direitos ou restrições de
acesso e manipulação dos dados de relações e visões.
Integridade: comandos para especificação de regras de integridade, que
os dados que serão armazenados no banco de dados deverão satisfazer.
Controle de transações: comandos para a especificação de inicialização
e finalização de transações. Algumas implementações também permitem
explicitar o bloqueio de dados para controle de concorrência.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
32
O SQL foi revisto em 1992 e a esta versão foi dado o nome de SQL92. Foi
revisto novamente em 1999 e 2003 para se tornar SQL:1999 e SQL:2003,
respectivamente. O SQL:1999 utiliza expressões regulares de emparelhamento,
queries recursivas e triggers. Também foi feita uma adição controversa de tipos
nãoescalados e de algumas características de orientação a objetos. O SQL:2003
introduz características relacionadas ao XML, seqüências padronizadas e colunas
com valores de autogeneralização (inclusive colunasidentidade) (ISO/IEC 9075,
2006).
2.1.5 SGBDs em software livre
Atualmente existem diversos SGBDs, mas neste trabalho, optouse por
utilizar um que seja software livre. Dentre os diversos motivos que levaram a essa
escolha, o principal é a possibilidade de acessar o código fonte do mesmo,
podendose assim fazer um estudo mais aprofundado e até mesmo alterações.
Para decisão de qual banco de dados utilizar, foi realizada uma tabulação
comparativa entre alguns dos SGBDs em software livre, onde avaliouse várias
características técnicas dos mesmos.
Os seguintes SGBDs foram avaliados:
PostgreSQL: SGBDs objetorelacional, de código aberto. Optouse pela
versão 8.2.6 disponível em http://www.postgresql.org.
Firebird: SGBDs relacional, de código aberto. Optouse pela versão 2.0.3
disponível em http://www.firebirdsql.org .
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
33
MySQL: SGBDs relacional, de código aberto. Optouse pela versão 5.0.45
disponível em http://www.mysql.com.
O QUADRO 1 mostra a avaliação baseada apenas nas documentações
disponíveis nos respectivos sites, utilizando como referência a documentação da
última versão estável dos SGBDs. O acesso aos sites para coleta das
informações e para definição das versões dos SGBDs, foi realizado no dia
19/10/2007.
PostgreSQL MySQL Firebird
Sistema Operacional
Linux/Unix + + +
FreeBSD + + +
Windows + + +
Sun Solaris + + +
Mac OS X + + +
HP UX + + +
Características
ACID + * +
Integridade referencial + * +
Transações + * +
Tabelas temporárias + *
Materialize views * * *
Stored Procedures + * +
Cursores + + +
Triggers + + +
SQL92 + * +
SQL:1999 + * *
SQL:2003 * * *
Funções de linguagens + * *
Esquemas +
Expressões regulares + + *
Savepoints + * +
Pointintime recovery + + *
Efetivação em 2 fases + * ?
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
34
PostgreSQL MySQL Firebird
Efetivação em 3 fases ? ? ?
Inserções múltiplas + + +
Índices
R/R+ tree + *
Hash + *
Expression + +
Partial +
Reverse * *
Bitmap *
GIST +
GIN +
Particionamento
Range + *
Hash + *
Composite (Range + Hash) + *
List + *
Shadow ? ? +
Replication API + + +
Legenda:
(+) : característica é suportada inteiramente
() : característica não é implementada
(*) : característica é implementada parcialmente ou não em conformidade com o padrão
(?) : sem opinião clara sobre o suporte
QUADRO 1 Avaliação dos SGBDs
Fonte: Elaborado pelo autor com base em PostgreSQL (c19962008), MySQL (c19972008) e Firebird (c20002008).
2.2 Redes de computadores
Segundo Özsu (2001), redes de computadores são uma coleção de
computadores autônomos que conseguem trocar informação entre si. Nesta rede,
estes computadores normalmente são chamados de hosts ou nós, e, para
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
35
conseguirem trocar informações entre si, deve existir algum meio de interconexão
entre os mesmos. A FIGURA 1 faz essa ilustração.
FIGURA 1 Rede de computadores
Fonte: Elaborado pelo autor com base em (Özsu, 2001).
[...]dados [são definidos] como entidades que carregam algum significado. Sinais são a codificação elétrica ou eletromagnética dos dados. Sinalizar é o ato de propagar o sinal ao longo de algum meio apropriado. Por fim, transmissão é a comunicação dos dados pela propagação e pelo processamento de sinais (Stallings, 1988 apud Özsu, 2001).
Em uma rede de computadores, os equipamentos são conectados por
links. Cada link pode transportar um ou mais canais. O link é uma entidade física,
enquanto o canal é uma entidade lógica. Os canais de comunicação têm uma
capacidade que pode ser definida como a quantidade de dados, que pode ser
transmitida pelo canal em uma determinada unidade de tempo. Essa capacidade
é chamada de largura de banda do canal e geralmente é medida em bits por
segundo (bps) (Özsu, 2001).
Switches
hosts
Subrede de comunicações
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
36
2.2.1 Escala das redes
Segundo Özsu (2001), em termos de distribuição geográfica as redes são
classificadas como: redes locais, metropolitanas e remotas.
Uma rede remota (WAN – wide area network) é uma rede cuja distância
entre dois nós quaisquer varia entre aproximadamente 20 quilômetros e milhares
de quilômetros. Através de switches e/ou roteadores é possível a comunicação
sobre áreas mais extensas, contudo, quanto maior a distância, maior a perda de
desempenho.
Uma rede local (LAN – local area network) geralmente possui limite
geográfico inferior a 2 quilômetros. Dessa forma, proporciona comunicação de
grande largura de banda sobre os meios de comunicação pouco dispendiosos. Os
tipos de meios de transmissão empregadas em redes locais são geralmente
cabos coaxiais, fios de pares trançados ou fibras ópticas.
Uma rede metropolitana (MAN – metropolitan area network) está entre a
LAN e WAN em escala e abrange uma cidade, ou parte dela. A distância entre os
nós geralmente é de 10 quilômetros. As MANs têm semelhanças significativas
com as LANs e, de certa forma, podem ser consideradas versões maiores dessas
últimas. Porém, como nas MANs o número de usuários é maior, existem
problemas de igualdade de acesso e desempenho, independente da localização
física, que devem ser resolvidos.
A escala de uma rede de computadores conceitualmente não define a
largura de banda disponível. Parece lógico que quanto a menor distância, maior a
largura de banda. Contudo, a largura de banda é definida principalmente pelo
meio físico utilizado, que pode variar entre cabos coaxiais, cabos de fibra óptica,
cabos de par trançados e até canais de satélite. Tipicamente, as redes LAN são
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
37
formadas por cabos coaxiais, par trançados ou de fibra óptica e são conhecidas
como redes Ethernet, enquanto as redes WAN são formadas por cabos de fibra
óptica e canais de satélite, sendo que o maior exemplo desse tipo de rede é a
Internet (Silberschatz, 1999).
Para fazer uma distribuição de banco de dados é necessário que antes
seja avaliado a escala da rede, para saber qual a possível largura de banda
disponível. A importância disso se dá justamente para saber qual tipo de
replicação é apropriado para o meio de comunicação utilizado.
2.3 Sistema de banco de dados distribuídos
Nas subseções 2.1 e 2.2 foram vistos, de forma isolada, alguns conceitos
sobre SGBDs e redes de computadores. Esses conceitos são importantes para
uma melhor compreensão da união dessas duas abordagens, isto é, dos sistemas
gerenciadores de bancos de dados distribuídos (SGBDDs). Nesta seção serão
estudados os aspectos relativo aos SGBDDs que introduzirão a subseção 2.4,
que trata do estudo sobre replicações, principal objetivo deste trabalho.
2.3.1 Sistemas distribuídos
Para Tel (2000), o termo “sistema distribuído” significa um conjunto
autônomo de computadores, de processadores ou de processos interconectados.
Estes computadores, processadores ou processos são conhecidos como nodos
do sistema distribuído, e, precisam estar interconectados para possibilitar a troca
e compartilhamento de informações.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
38
Já Date (1990), diz que este termo se refere a qualquer sistema que pode
estar em várias localidades mas conectado através de uma rede de comunicação,
de forma que, independente de onde, possa ser possível o acesso aos dados de
qualquer localidade.
Segundo Tel (2000), as características de um sistema distribuído
dependem muito da motivação pela sua existência. A sua existência se dá na
tentativa de resolver alguns problemas computacionais. Algumas dessas
características são listados abaixo:
● Troca de informações: possibilidade de trocar informações entre
diferentes computadores.
● Compartilhamento de recursos: possibilidade de compartilhar recursos
do sistema, da mesma forma que são compartilhados periféricos como
impressoras e unidades de disco.
● Confiabilidade: possibilidade de continuar operando um sistema
mesmo que um host do sistema pare por algum motivo, ou seja, a
garantia do “sempre funcionamento em tempo real”.
● Paralelismo: possibilidade de distribuir as tarefas do sistema que serão
executadas em diversos processadores ou computadores.
● Flexibilidade na estrutura geográfica: possibilidade de ter o sistema
distribuído em diversos locais geograficamente afastados.
● Transparência: possibilidade de adotar/seguir padrões em sistemas de
forma que seja possível trocar informações com outros sistemas.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
39
Quando é criado/utilizado um sistema distribuído, deve ser levado em
consideração o meio pela qual ocorre a ligação entre os nodos, pois existem
diversos problemas que podem ocorrer em virtude dessas ligações. Contudo, os
problemas dos algoritmos distribuídos geralmente são similares, independendo do
tipo de rede. Assim, existem alguns aspectos ao qual os algoritmos distribuídos
devem ficar atentos, continua Tel (2000):
● Confiabilidade: durante uma troca de informações entre nodos, alguma
coisa pode dar errado e isso nunca pode ser ignorado.
● Tempo de comunicação: o tempo que leva a transmissão de
informações para redes que não são locais é maior que em redes
locais. Em redes não locais, o tempo de processamento da informação,
muitas vezes, é insignificante comparado ao tempo de transmissão da
mesma.
● Homogeneidade: possivelmente em uma rede local os protocolos de
comunicação entre os nodos sejam os mesmos. Contudo, na
comunicação em redes não locais, pode ser que não sejam os
mesmos. Assim, deve ser prevista a comunicação em padrões
diferentes.
● Confiança mútua: em redes locais todos os usuários podem ter acesso
livre ao sistema. Contudo, redes não locais requerem o
desenvolvimento de algoritmos com técnicas de segurança, cópias de
segurança e livre de ataques de usuários.
Além desses aspectos, no desenvolvimento de algoritmos distribuídos, que
devem ser levados em consideração, existem ainda alguns problemas de redes
que podem ocorrer e devem ser prevenidos. Há problemas comuns entre redes
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
40
LANs e WANs, mas há também os que são específicos de cada tipo de rede. Isso
ocorre em virtude das características físicas e lógicas da rede (Tel, 2000).
Alguns problemas comuns que precisam ser abordados/implementados por
algoritmos distribuídos que ocorrem em redes WANs e LANs são:
● Confiabilidade na troca de dados: durante a transmissão entre dois nós
podem ocorrer diversos problemas de conexão. Quantos mais
caminhos as informações tiverem que percorrer, maior a probabilidade
de que ocorram problemas. Contudo, as informações não podem ser
perdidas nem podem chegar na ordem incorreta.
● Controle de tráfego: quanto mais mensagens forem transmitidas, maior
será o congestionamento da rede. A geração de mensagens pelos nós
deve levar em consideração a capacidade da rede.
● Prevenção de deadlock: como o tráfego de mensagens entre os nós
pode ser grande e os nós possuem uma capacidade limite para
armazenamento das mesmas, podem ocorrer problemas de uma
mensagem esperar por outra, que está esperando por outra que pode
depender da mensagem anterior. Dessa forma, o sistema não deve
ficar esperando infinitamente.
● Segurança: fazse necessário um controle de abusos, principalmente
em redes de computadores que estão ligadas à redes de
computadores de proprietários diferentes. Além disso, os dados devem
ser transmitidos com segurança, utilizandose de técnicas de
criptografia e certificações digitais.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
41
● Sincronização: é necessário fazer a gerência da transmissão e do
acesso das informações, de forma que as mesmas mantenhamse
consistentes.
● Exclusão mútua: algumas vezes é necessário evitar que dois
processos acessem o mesmo recurso ao mesmo tempo, recurso esse
que é denominado seção crítica.
2.3.2 Banco de dados distribuídos
Bancos de dados distribuídos são considerados uma coleção de vários
bancos de dados logicamente interrelacionados, distribuídos em uma rede de
computadores. Um sistema gerenciador de banco de dados distribuído (SGBDD)
é um um software que gerencia os bancos de dados tornando a distribuição
transparente para o usuário (Özsu, 2001).
Segundo Silberschatz (1999), a principal diferença entre sistemas de
bancos de dados centralizados e distribuídos é que no primeiro caso os dados
estão localizados em apenas um local, enquanto que no segundo caso, os
mesmos podem estar em vários locais.
Algumas vezes a questão da distribuição geográfica dos dados não é vista
como a questão mais relevante para bancos de dados distribuídos. Os seguidores
desta visão, vêm como a questão mais importante o fato dos bancos serem inter
relacionados, mesmo estando no mesmo local. Contudo, é muito importante levar
em consideração a questão da distribuição física dos dados, pois isto pode levar a
uma série de problemas com os quais os sistemas gerenciadores de banco de
dados distribuídos devem estar preparados para lidar (Özsu, 2001).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
42
2.3.3 Transparência e formas de distribuição
Considere uma empresa de engenharia com negócios em Boston,
Edmonton, Paris e São Francisco, exemplifica Özsu (2001), em cada um desses
locais são desenvolvidos projetos e a empresa gostaria de manter os bancos de
dados dos projetos e seus funcionários interrelacionados. Supondo um banco de
dados relacional, as informações podem ser armazenadas em quatro entidades
conforme ilustrado na FIGURA 2. Uma tabela FUNC para armazenar os
funcionário, uma tabela PROJ para armazenar os projetos, uma tabela PAG para
armazenar as informações de salários e uma última tabela DSG para armazenar
quais funcionários foram designados a quais projetos.
FIGURA 2 Modelo relacional
Fonte: Elaborado pelo autor com base em (Özsu, 2001).
Se o banco de dados estivesse centralizado e fosse necessário descobrir
qual a relação dos funcionários que trabalharam em projetos por mais de 12
meses, poderia ser utilizada a consulta SQL do EXEMPLO 1 (Özsu 2001).
SELECT func.fnome, pag.sal FROM func, dsg, pag
WHERE dsg.dur > 12 AND func.fno = dsg.fno AND pag.cargo = func.cargo
EXEMPLO 1 Consulta SQL
Fonte: Elaborado pelo autor com base em (Özsu, 2001).
FNOFNOMECARGO
FUNCPNOPNOMEPRCAMEN
PROJ
CARGOSAL
PAGFNOPNORESPDUR
DSG
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
43
Contudo, segue Özsu (2001), dada a natureza distribuída da empresa, é
preferível que essa consulta retorne em Edmonton somente os dados de
Edmonton, ou seja, que os dados de Edmonton estejam armazenados somente
em Edmonton. O mesmo se aplica para os outros escritórios. Desta forma, têmse
um cenário onde os dados estão particionados e armazenados em locais
diferentes. Isto é conhecido como fragmentação. Além disso, pode ser preferível
duplicar alguns desses dados em outros locais por questões de desempenho e
confiabilidade, resultando num banco de dados distribuído fragmentado e
replicado.
Uma das premissas de um banco de dados distribuído, é que o acesso às
informações seja totalmente transparente, dessa forma, mesmo com os dados
distribuídos, os usuários ainda poderiam executar a consulta SQL do EXEMPLO
1, da mesma forma, ficando a cargo do SGBDD a resolução das questões de
fragmentação e replicação dos dados.
2.3.3.1 Fragmentação de dados
Silberschatz (1999) explica a fragmentação como uma divisão dos dados
em vários fragmentos, podendo estes, serem armazenados em locais físicos
diferentes. O conceito de fragmentação de dados parte do princípio de que, se
existe uma relação r que é fragmentada em r1, r2, ..., rn, esses fragmentos contêm
informações suficientes para permitir a reconstrução da relação original r. Essa
reconstrução pode ser feita por operações de união ou de um tipo especial de
junção.
Continua Silberschatz (1999) afirmando que, existem dois esquemas
diferentes de fragmentação, e segue explicando os mesmos:
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
44
1) Fragmentação horizontal: a relação r é particionada em um número de
subconjuntos r1, r2, ..., rn. Cada tupla da relação r deve pertencer a pelo menos um
fragmento, de forma que a relação original principal possa ser reconstruída. Um
desses fragmentos pode ser definido como uma seleção sobre a relação r. A
reconstrução da relação r pode ser feita pela união de todos os fragmentos.
2) Fragmentação vertical: em sua forma mais simples a fragmentação
vertical é como uma decomposição. Essa fragmentação de r(R) implica na
definição de vários subconjuntos de atributos R1, R2, ..., Rn do esquema R. A
fragmentação deve ser feita de tal forma que possamos reconstruir a relação r, a
partir dos fragmentos, por meio de uma junção natural.
2.3.3.2 Replicação de dados
Como o principal objetivo deste trabalho é o estudo de técnicas e
algoritmos de replicação, esse assunto será aprofundado na subseção 2.4.
2.3.3.3 Transparência
Para Özsu (2001), em bancos de dados centralizados, o único recurso que
precisa ser isolado dos usuários são os dados. Já em bancos de dados
distribuídos, existe um segundo recurso que precisa ser tratado da mesma forma:
a rede. Assim, o usuário não deveria perceber diferenças entre trabalhar com
bancos de dados distribuídos ou centralizados. Este isolamento é conhecido
como transparência de rede.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
45
Outra transparência que deve existir em bancos de dados distribuídos é a
independência dos dados. Essa independência é uma forma fundamental de
transparência que procurase em SGBD tanto centralizados como distribuídos,
pois é através dela que os aplicativos são imunes às mudanças na organização e
na definição dos dados, e viceversa. Por exemplo, se existirem dados que estão
armazenados em dois discos, com sistema de arquivos diferentes, ou
organizados de maneira diferente (acesso aleatório aos dados versus acesso
seqüencial indexado), ou mesmo se estivessem separados em hierarquias de
memórias diferentes (disco rígido versus fita), o aplicativo do usuário não deve se
preocupar com estes aspectos de organização física. Isso é o que define a
independência dos dados (Özsu, 2001).
Na transparência de replicação, justamente por causa da replicação de
uma base de dados, podese gerar um problema na atualização dos dados. A
questão da transparência está envolvida na necessidade ou não do usuário saber
se existem uma ou mais réplicas da base. A resposta para essa questão é: claro
que ele não precisa. Assim, existem diversas técnicas para o mesmo, que serão
discutidas na subseção 2.4.
A última transparência que deve existir é a transparência de fragmentação.
Levandose em consideração que as relações estão fragmentadas em vários
locais, as consultas devem acontecer como se o banco de dados fosse
centralizado. Pois, embora as consultas sejam especificadas sobre as relações, a
dificuldade está em encontrar uma estratégia para o processamentos das
mesmas em fragmentos, isto é, para a conversão de consultas globais em várias
consultas de fragmentos.
Por fim, conclui Özsu (2001) que a responsabilidade sobre as
transparências necessárias para a distribuição dos dados pertence ao SGBD.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
46
2.3.4 Arquitetura de SGBDDs
A arquitetura do SGBDD define sua estrutura, isto é, os componentes são
identificados, suas funções são especificadas e os interrelacionamentos entre os
componentes são definidos. Existem diversas arquiteturas possíveis para
SGBDDs, sendo que será realizada a análise de três que englobem os aspectos
mais relevantes delas.
2.3.4.1 Sistemas cliente/servidor
Os SGBDs cliente/servidor, conforme Özsu (2001), entraram no cenário da
computação no início da década de 1990. A idéia geral é simples e elegante:
separar as funcionalidades que precisam ser fornecidas em duas classes: funções
de servidores e funções de clientes. As funções de servidores devem funcionar
nos computadores servidores e as funções clientes devem funcionar nos
computadores clientes.
É importante observar que todo processamento e otimização das
consultas, gerenciamento de transações e gerenciamento de armazenamento de
dados fica no lado do servidor. Assim, no lado do cliente, apenas fica o cliente de
SGBD responsável pelo gerenciamento de dados que ficam em cache (Özsu,
2001).
Existem diferentes tipos de arquiteturas cliente/servidor. No caso mais
simples, apenas um servidor é acessado por um ou mais clientes. Essa
arquitetura é denominada vários clientesservidor único e segue os princípios dos
bancos de dados centralizados. Contudo, uma arquitetura cliente/servidor mais
sofisticada possui vários servidores que são acessados por diversos clientes.
Nessa arquitetura, vários clientesvários servidores, existem duas estratégias para
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
47
gerenciamento: ou cada cliente gerencia suas conexões com os servidores
adequados, ou cada cliente conhece apenas seu servidor local e este se
comunica com os demais servidores (Özsu, 2001). A FIGURA 3 mostra uma
arquitetura cliente/servidor.
Sis
tem
a op
erac
iona
lInterface do
usuárioPrograma aplicativo
...
SGBD cliente
Software de comunicação
Consultas
SQL
Relação
resultado
Sis
tem
a op
erac
iona
l
Software de comunicação
Controlador semântico de dados
Otimizador de consultas
Gerenciador de transações
Gerenciador de recuperação
Processador de suporte runtime
FIGURA 3 Arquitetura cliente/servidor de referência
Fonte: Özsu (2001, p. 95).
Banco dedados
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
48
2.3.4.2 Sistemas distribuídos nãohierárquicos
Nos sistemas distribuídos nãohierárquicos, geralmente a organização
física dos dados dos computadores é diferente. Assim, é necessário existir um
esquema interno local (EIL) para cada computador, com a definição da estrutura
local. A visão global dos dados é descrita por um esquema conceitual global
(ECG). Esse esquema descreve a estrutura lógica dos dados de todos os
computadores (Özsu, 2001).
Continua o autor explicando que, como em banco de dados distribuídos os
dados geralmente estão replicados ou fragmentados é necessário ter uma
descrição da organização lógica dos dados de cada computador numa terceira
camada, o esquema conceitual local (ECL). Dessa forma o esquema conceitual
global passa a ser a união dos dois esquemas locais.
Finaliza Özsu (2001), o acesso aos dados pelos usuários é através do
esquema externo (EE) que fica localizado uma camada acima do esquema
conceitual global. A FIGURA 4 mostra o modelo de arquitetura descrita.
FIGURA 4 Arquitetura de banco de dados distribuído de referência
Fonte: Özsu (2001, p. 97).
ECL2
EIL1
EIL2
EILn
EE2
EE1
ECL1
EEn
ECLn
ECG
...
...
...
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
49
2.3.4.3 Arquitetura de SVBDs
A diferença fundamental dos sistemas de vários bancos de dados (SVBDs)
distribuídos e dos SGBDs distribuídos se relaciona à definição do esquema
conceitual global. Enquanto nos SGBDs distribuídos logicamente integrados o
esquema conceitual global define a visão conceitual do banco de dados inteiro,
nos SVBDs distribuídos ele define apenas a coleção de alguns dos bancos de
dados locais de cada SVBD que se quer compartilhar. Assim, nos SGBDs
distribuídos o banco de dados global é a união dos bancos de dados locais,
enquanto que nos SVBDs distribuídos, ele é apenas um subconjunto da mesma
união (Özsu, 2001). A FIGURA 5 mostra o modelo de arquitetura descrita.
FIGURA 5 Arquitetura de SVBD com um ECG
Fonte: Özsu (2001, p. 101).
2.3.5 Tolerância a falhas
A tolerância a falhas é uma abordagem muito importante em bancos de
dados distribuídos. Ela é definida como uma característica pela qual o sistema
pode mascarar a ocorrência de falhas para se ter alta disponibilidade de um
sistema. Em outras palavras, um sistema gerenciador de banco de dados, ou
EIL1
EILn
ECL1
ECLn
ECG
...
...
EEG2
EEG1
EEG3
EEL12
EEL11
EEL13
EELn2EEL
n1
EELn3
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
50
mesmo qualquer sistema, é tolerante a falhas se consegue continuar operando
em caso de ocorrerem falhas (Tanenbaum, 2002).
Na seqüência são descritas as principais métricas de avaliação da
tolerância a falhas, os possíveis tipos de falhas e formas de mascarar as
possíveis falhas de um sistema.
2.3.5.1 Dependabilidade
O principal objetivo da tolerância a falhas é alcançar dependabilidade
(dependability), que indica a qualidade do serviço fornecido por um determinado
sistema e a confiança depositada nesse serviço. As principais métricas de
avaliação da tolerância a falhas são (Weber, 2001):
● Confiabilidade (reliability): É a capacidade de atender as
especificações, dentro das condições definidas, durante certo período
de funcionamento e condicionado a estar operacional no início do
período;
● Disponibilidade (availability): Probabilidade do sistema estar
operacional num instante de tempo determinado;
● Segurança (safety): probabilidade do sistema ser ou estar operacional
e executar suas funções corretamente, ou descontinuar suas funções
de forma que não provoque danos a outros sistemas ou pessoas que
dele dependam;
● Segurança (security): proteção contra falhas maliciosas, visando
privacidade, autenticidade, integridade e irrepudiabilidade dos dados.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
51
2.3.5.2 Tipos de falhas
Segundo Tanenbaum (2002), existem diversas categorias de falhas que
podem ocorrer:
● Crash failure: ocorre quando um processo está sendo executado
normalmente, mas inesperadamente termina/morre;
● Omission failure: ocorre quando um processo não responde a uma
requisição;
● Performance failure: ocorre quando uma requisição demora demais a
ser atendida;
● Timing failure: ocorre quando um reposta de uma requisição está fora
do intervalo de tempo especificado;
● Response failure: ocorre quando o valor da resposta de uma
requisição está incorreto ou quando um processo é desviado do correto
fluxo de controle;
● Arbitrary failure: um servidor produz respostas arbitrárias em tempos
arbitrários.
2.3.5.3 Mascarando falhas com redundância
Partindo do princípio de que nenhum sistema está livre de falhas, o melhor
que pode ser feito é esconder/mascarar estas falhas, para que o sistema não
retorne um erro. A chave para conseguir isto é a redundância, que pode ser
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
52
conseguida através quatro formas: redundância de hardware, redundância de
software, redundância de tempo e redundância de informação (Weber, 2001).
Para Tanenbaum (2002), a técnica para prover tolerância a falhas mais
conhecida é a redundância de hardware. Ela é aplicada na biologia (seres
humanos possuem dois olhos, duas orelhas, dois rins), na aviação (alguns aviões
possuem quatro motores, mas pode voar com menos) e até nos esportes (vários
jogadores reservas).
Weber (2001) afirma que a redundância de informação é provida por
códigos de correção de erros, como EEC (error correction code) que vem sendo
usados na comunicação das memórias e nos processadores.
Como a codificação da informação implica no aumento do número de bits,
e os bits adicionais não aumentam a capacidade de representação de dados do
código, é fácil perceber a razão da codificação também ser considerada uma
forma de redundância.
A redundância de tempo repete a computação no tempo, ou seja, evita o
custo de hardware adicional, aumentando o tempo necessário para realizar uma
computação. É bastante usada em sistemas cujos processadores passam boa
parte do tempo ociosos e onde o tempo não é um fator crítico.
A cópia de um sistema, como se faz com o hardware, não é uma
alternativa inteligente, pois a cópia é idêntica e vai apresentar os mesmos erros.
Contudo, existem algumas técnicas de programação que podem criar
redundância a nível de software, como por exemplo a criação de programas
escritos de forma diferente, a criação de blocos de recuperação e a verificação de
consistência (Weber, 2001).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
53
2.4 Replicação
Uma replicação pode ser feita por diversos motivos. Independente do
motivo – se for para aumentar o desempenho de consultas; ter uma cópia de
segurança; ter alta disponibilidade e tolerância a falhas; ou resolver problemas
geográficos de acesso – o importante é saber escolher a forma como será feita a
replicação, pois a replicação implica na sincronização permanente dos bancos de
dados. De forma geral, as replicações aumentam o desempenho para operações
de leitura da base de dados, entretanto as atualizações geram um grande
overhead (custo adicional de processamento ou armazenamento). Cada
informação replicada é chamada de objeto (Özsu, 2001).
2.4.1 Tipos de replicação
Na utilização de banco de dados distribuídos, replicados, é preciso avaliar
o delay de atualização dos bancos de dados. Assim, existem dois tipos de
replicação: síncrona e assíncrona.
2.4.1.1 Síncrona
Para Pedroni e Ribeiro (2006), replicação síncrona é aquela em que os
dados são replicados em tempo real, ou seja, ao inserir dados num determinado
banco, os mesmos são replicados para os demais, no mesmo momento. Isso é
feito de forma garantida com a utilização de transações. Este tipo de replicação é
ideal para aplicações que necessitam ter os dados atualizados de forma muito
precisa.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
54
A grande desvantagem no uso desse tipo de replicação, é que existe uma
perda significativa de performance, pois os processos tornamse mais lentos e
ainda dependentes da estrutura da rede, caso os bancos de dados estejam em
hosts diferentes.
Outro problema que pode ocorrer é que um host pode estar indisponível e
dessa forma, a transação não seria efetivada.
Um exemplo hipotético de instruções para esse tipo de replicação seria o
exemplificado no EXEMPLO 2.
BEGIN TRANSACTION;INSERT INTO foo (1, 'banco de dados');REPLICAR();
END TRANSACTION;
EXEMPLO 2 Exemplo hipotético de instruções SQL para replicação síncrona
Fonte: Elaborado pelo autor com base em Pedroni e Ribeiro (2006).
2.4.1.2 Assíncrona
Também conhecida como replicação não sincronizada, a replicação
assíncrona faz a réplica dos dados não instantaneamente. Essa replicação é feita
dentro de uma transação separada, onde a partir do momento que a transação é
executada, o replicador lê um histórico das ações executadas no banco de dados
a ser replicado e replica para o(s) outro(s). Assim, a réplica pode ser feita a
qualquer momento (Pedroni; Ribeiro, 2006).
A grande desvantagem nessa replicação, explicam as autoras, é que
eventuais erros ou conflitos não são detectados imediatamente, pois a cópia será
efetivada como um todo somente no final da transação. Outra desvantagem é que
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
55
as informações dos bancos de dados dos hosts envolvidos não estarão sempre
atualizados.
Um exemplo hipotético de instruções para esse tipo de replicação é
mostrado no EXEMPLO 3.
INSERT INTO foo (1, 'banco de dados');INSERT INTO foo (2, 'replicação assíncrona');UPDATE ...
BEGIN TRANSACTION;REPLICAR();
END TRANSACTION;
EXEMPLO 3 Exemplo hipotético de instruções SQL para replicação assíncrona
Fonte: Elaborado pelo autor com base em Pedroni e Ribeiro (2006).
2.4.2 Modelos de replicação
Os modelos de replicação definem uma estrutura que especifica quais
servidores poderão replicar para os demais. Os modelos de replicação são:
singlemaster ou masterslave e multimaster (Elnikety; Dropsho; Zwaenepoel,
2006).
2.4.2.1 Singlemaster ou masterslave
Nessa forma de replicação, existe um servidor mestre que faz somente a
replicação para os demais escravos. Enquanto o servidor mestre possibilita a
leitura e a escrita de dados por parte dos usuários, os servidores escravos
permitem somente a leitura, sendo que a escrita é feita através das replicações do
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
56
servidor mestre. As operações de réplica para os servidores escravos, são
executadas na mesma ordem que foram executadas no servidor mestre. Esse
modelo de replicação pode ser tanto síncrono como assíncrono (Elnikety;
Dropsho; Zwaenepoel, 2006). A FIGURA 6 mostra um exemplo dessa estrutura.
FIGURA 6 Exemplo do modelo de replicação singlemaster
Fonte: Elaborado pelo autor com base em Elnikety, Dropsho e Zwaenepoel (2006).
2.4.2.2 Multimaster
Elnikety, Dropsho e Zwaenepoel (2006) afirmam que na replicação multi
master, os usuários podem ler e escrever em qualquer servidor. Os servidores por
sua vez, terão que replicar as informações para os demais servidores. Isso exige
um mecanismo mais elaborado para as transações e replicações. Esse modelo de
replicação também pode ser tanto síncrono como assíncrono. A FIGURA 7 mostra
um exemplo dessa estrutura.
USUÁRIO
leitura leituraleiturae
escrita
replicação replicaçãoSERVIDORESCRAVO
SERVIDORESCRAVO
SERVIDORMESTRE
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
57
FIGURA 7 Exemplo do modelo de replicação multimaster
Fonte: Elaborado pelo autor com base em Elnikety, Dropsho e Zwaenepoel (2006).
2.4.3 Protocolo de controle de réplica
Além de existir um modelo de replicação, é necessário também que exista
um controle sobre as transações dos bancos de dados replicados, para garantir
que as informações sejam armazenadas serialmente, equivalente a uma
execução real do usuário no banco de dados. Isso é realizado através dos
protocolos de controle de réplica, que são descritos na seqüência (Monteiro et all,
2006).
2.4.3.1 PrimaryCopy Method
Segundo Monteiro et all (2006), nesse esquema é identificado um servidor
primário e qualquer alteração sempre será executada primeiro nesse servidor. Os
demais servidores, chamados servidores secundários, recebem uma numeração
que é a ordem pela qual o servidor primário fará as replicações para os mesmos.
Dessa forma, é o protocolo que se encarrega de propagar as alterações aos
demais servidores seguindo a ordem estabelecida.
USUÁRIO
leiturae
escrita
replicação replicação
leiturae
escrita
leiturae
escrita
replicação
SERVIDOR SERVIDORSERVIDOR
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
58
As operações de leitura podem ser executadas sobre qualquer cópia. Caso
o servidor principal esteja indisponível, o próximo servidor secundário assume o
papel do servidor principal (Monteiro et all, 2006).
2.4.3.2 QuorumConsensus Method
Monteiro et all (2006) explicam que através desse método, todos os
servidores podem ter seus dados alterados, pois as operações de leitura e escrita
só são efetivadas se receberem um determinado número de votos de permissão
do grupo de servidores. Além disso, não é necessário atualizar todos os
servidores, pois é definido um número mínimo de réplicas para que o estado
global seja considerado consistente.
Em caso de haver inconsistência durante a votação, um processo de
sincronização é inicializado para igualar os valores das cópias e a transação
corrente geralmente é abortada. Este protocolo apresenta sérios problemas de
performance além de grande overhead de comunicação entre os hosts.
2.4.3.3 AvailableCopies Method
Através desse método, continuam Monteiro et all (2006), é possível fazer
atualizações em qualquer servidor ativo, pois os objetos do banco de dados serão
replicados para todos os servidores que estiverem ativos. Assim, as transações
podem ser efetivadas mesmo com servidores inacessíveis, sendo que os objetos
serão replicados para os servidores ativos.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
59
Quando um servidor inativo se tornar ativo novamente, algumas operações
de sincronização terão que ser executadas. As transações que acessarem dados
inconsistentes deverão ser abortadas.
Concluem, assim, Monteiro et all (2006), que os problemas de performance
nesse método se devem a grande quantidade troca de mensagens para validação
e reconciliação das informações dos diferentes servidores.
2.4.4 Métodos de replicação
Para conseguir replicar bancos de dados, existem alguns métodos que
podem ser utilizados. Os dois principais são: logs e triggers.
2.4.4.1 Arquivos de registros (logs)
Nesse método, cada operação realizada no banco de dados tem uma
registro numa tabela de registros (logs). Quando o processo de replicação tem
início, essa tabela é lida em ordem cronológica e os mesmos comandos são
executados nos demais servidores.
Para utilização de logs, é necessário que o SGBD tenha suporte a este
recurso, pois o mesmo não é uma especificação da linguagem SQL, ao contrário
dos triggers. (Oliveira, 2006).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
60
2.4.4.2 Triggers
Através desse método, explica Oliveira (2006), as regras para replicação
podem ser definidas pelo próprio dono do banco de dados. Os triggers são
comandos que são executados quando ocorrem determinados eventos no banco
de dados. Dessa forma, próprio dono do banco de dados pode definir o que deve
ser replicado e quando isso será executado.
Cada trigger é definido para uma entidade do banco de dados. Ao ocorrer
algum evento numa das entidade no qual esse trigger foi definido, o mesmo é
disparado. O disparo do trigger, é a execução de uma função previamente
armazenada no banco de dados. A ação de disparar um trigger é conseguida
antes ou depois da execução de comandos como a inserção, atualização ou
exclusão de objetos do banco de dados.
2.4.5 Modelo de transações distribuídas
Como já visto anteriormente, todas as transações devem respeitar as
propriedades ACID. Na utilização de replicação, existem dois tipos de transações:
as transações locais e as transações globais. Silberschatz (1999) afirma que as
transações locais preocupamse somente com o acesso e atualização da base de
dados local. As transações globais preocupamse em manter o acesso e atualizar
diversas bases de dados locais ao mesmo tempo e dessa forma, essa tarefa
tornase muito mais complexa.
Para garantir as propriedades ACID de forma global, é necessário a
utilização de protocolos de efetivação de transações. Entre os protocolos de
efetivação mais simples e utilizados, estão os protocolos de efetivação em duas
fases (twophase commit protocol – 2PC) e o protocolo de efetivação em três
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
61
fases (threephase commit protocol – 3PC), este último elimina as desvantagens
do 2PC, mas aumenta o overhead.
Cada host contém dois subsistemas:
● Gerenciador de transações: responsável por administrar a execução
de transações locais que podem ser transações realmente locais, ou
parte de transações globais.
● Coordenador de transações: responsável por coordenar a execução
de várias transações iniciadas no próprio host, mas que podem ser
locais ou globais.
2.4.5.1 Protocolo de efetivação em duas fases – 2PC
Se uma transação T é iniciada no host S1 e tem C1 como seu coordenador,
ao término de T, ou seja, quando todos os hosts onde T é executada informam a
C1 que T está completa, tem início o protocolo 2PC. Este protocolo é
caracterizado pelas duas fases (Silberschatz, 1999):
● Fase 1: C1 adiciona um registro <prepare T> no log e envia a
mensagem prepare T para todos gerenciadores de transações dos
hosts onde T é executada. Se o host não pode efetivar sua porção da
transação T, ele adiciona um registro <no T> no log e retorna abort T.
Caso a resposta seja positiva, adiciona <ready T> no log e retorna
ready T para C1.
● Fase 2: Quando C1 receber todas as mensagens de resposta de
prepare T ou quando o tempo de execução estipulado estiver
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
62
completo, C1 pode determinar se a transação será efetivada ou não. Se
C1 receber somente mensagens de ready T, um registro <commit T>
será adicionado ao log, caso contrário, será inserido um registro <abort
T>. Após esse último registro a transação T é ou não efetivada nos
hosts.
2.4.5.2 Protocolo de efetivação em três fases – 3PC
Esse protocolo foi criado para evitar a possibilidade de obstrução nos
casos restritos de falhas possíveis. As três fases do mesmo listadas abaixo, são
explicadas por Silberschatz (1999):
● Fase 1: idêntica à fase 1 do 2PC.
● Fase 2: difere da fase 2 do 2PC, onde se C1 receber somente
mensagens de ready T, um registro <precommit T> é inserido no log e
os hosts são avisados através de uma mensagem precommit T que é
enviada por C1. Quando um host receber a mensagem precommit T
ou abort T de C1, ele a registra em seu log e manda uma mensagem
acknowledge T (reconhecimento) para o coordenador C1.
● Fase 3: é executada somente se na fase 2 a preefetivação
(precommit T) é executada. Após o coordenador receber o número de
hosts a replicar e de mensagens acknowledge T, o coordenador
adiciona um registro <commit T> a seu log e manda uma mensagem
de commit T para todos os hosts. Quando um host recebe a
mensagem, ele registra a operação em seu log efetivando a operação.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
3 FERRAMENTAS UTILIZADAS
Para fazer o estudo dos diferentes algoritmos e técnicas de replicação,
optouse por fazer testes com ferramentas replicadoras já existentes. Dessa
forma, o primeiro passo para a realização dos testes foi a definição de qual SGBD
e de quais ferramentas replicadoras seriam utilizadas. Como existem diversos
SGBDs em software livre, optouse por escolher apenas um que tivesse os
devidos recursos e que possibilitasse fazer o estudo da melhor forma possível.
Assim, foi feito um comparativo entre as principais características dos principais
SGBDs existentes em software livre e, de acordo com as características vistas no
QUADRO 1, foi escolhido o PostgreSQL.
Após a definição do SGBD, foi necessário fazer a escolha das ferramentas
replicadoras. Diversas delas foram pesquisadas no próprio site do PostgreSQL
(http://www.postgresql.org), assim como no site de projetos relacionados ao
mesmo (http://pgfoundry.org). Nessa pesquisa foram encontrados diversos
projetos, muitos deles ainda sem arquivos para download, como o RepDB
(http://pgfoundry.org/projects/repdb) e o DBMirror (http://pgfoundry.org/projects/
dbmirror), outros com licença comercial, como o MMRSObject (http://www.object .
com.br/content/view/26/40) e o Mammoth (http://www.commandprompt.com), e
muitos já descontinuados, como o PostgresR (http://pgfoundry.org/projects/
postgresr) e o PgReplicator (http://pgreplicator.sourceforge.net).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
64
Como foram encontradas várias ferramentas, dentre as mais populares
foram escolhidas somente as ferramentas em software livre, com arquivos
disponíveis para download, e que fossem de projetos não descontinuados. Além
disso, foram selecionadas somente ferramentas que apresentassem
características diferentes entre si.
A seguir, são descritas as ferramentas de replicação que foram avaliadas.
Os comandos de instalação do PostgreSQL e das ferramentas replicadoras são
encontrados no APÊNDICE B – Instalação e configuração dos programas.
3.1 DBLink e triggers
A DBLink é uma contribuição do projeto PostgreSQL. Essa contribuição
permite que, quando conectado a uma base de dados, seja possível executar
comandos SQL em outras bases de dados. Usando esse recurso juntamente com
triggers, é possível fazer a replicação dos dados de uma base para outra, ou seja,
é possível que ao inserir, excluir ou alterar uma informação seja executado o
mesmo comando SQL em outra base de dados (PostgreSQL, c19962008).
As características da utilização destes recursos como ferramenta de
replicação são descritas no QUADRO 2.
DBLink e Triggers
Tipo Síncrono.
Modelo Masterslave.
ControleNão há controle. Neste trabalho desenvolveuse controle pela política PrimaryCopy Method)
Método Triggers.
Objetos replicados Dados de tabelas e seqüências, menos dados do tipo blob ou largeobject.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
65
DBLink e Triggers
Segurança É possível utilizar SSL2.
Versão A mesma do PostgreSQL.
Versão do PostgreSQL utilizada 8.2.6.
Sistema operacional Qualquer um que rode o PostgreSQL.
QUADRO 2 Características do uso de dblink e triggers
Fonte: Elaborado pelo autor com base em PostgreSQL ( c19962008).
Conforme PostgreSQL (c19962008), a utilização de triggers com dblink
deve ter políticas de transação a nível global para manter as propriedades ACID.
Contudo, a utilização desse mecanismo, num primeiro momento, é uma solução
incompleta, pois o controle de transação sempre fica a nível local, isto é, cada
base de dados possui seu próprio controle, sem a existência de um controle
global. Isso permite que, ao fazer a replicação para dois bancos de dados, por
exemplo, caso um deles esteja inacessível por algum motivo, os dados sejam
replicados para um e para outro não, tornando falho o controle de transação
global. Em virtude dessas deficiências, todo o controle transacional global deve
ser criado em código dentro do próprio trigger.
O mesmo ocorre para o protocolo de efetivação. Deve ser definida qual
regra de efetivação o trigger deve seguir, por exemplo, se um banco de dados
estiver inacessível por algum motivo, a regra definida deve indicar se a replicação
será efetivada ou não nos outros bancos. Esse protocolo de efetivação também é
definido no código fonte do trigger.
2 SSL – Secure Sockets Layer é um protocolo criptográfico que provê a comunicação com privacidade e integridade na transferência de dados pela internet. Fonte: PostgreSQL (c19962008).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
66
Para fazer a conexão com os bancos de dados, a DBLink utiliza a
biblioteca libpq3. Como essa biblioteca permite conexões SSL através do uso da
opção sslmode numa conexão, qualquer aplicação que utilize as conexões via
dblink pode usufruir deste recurso de segurança. Assim, é possível configurar a
dblink para negociar conexões, obrigatoriamente ou não, com SSL. Para
utilização desse recurso de segurança, o PostgreSQL deve ter sido compilado
com suporte ao mesmo (PostgreSQL, c19962008).
A FIGURA 8 ilustra uma replicação entre três servidores utilizando esta
ferramenta.
FIGURA 8 Exemplo de replicação utilizando a ferramenta DBLink com Triggers
Fonte: Elaborado pelo autor com base em PostgreSQL (c19962008).
É importante salientar que, para utilizar esta forma de replicação, é
necessário criar triggers em cada uma das tabelas do servidor master, sendo que,
somente os dados das tabelas são replicados.
Outra característica importante é que os demais triggers que possam existir
no servidor master devem ser desabilitados nos servidores slaves. Isso porque,
3 Libpq é a biblioteca padrão para as conexões do PostgreSQL. Fonte: PostgreSQL (c19962008).
SERVIDOR 1 DEBANCO DE DADOS
MASTER
SERVIDOR 2 DEBANCO DE DADOS
SLAVE
SERVIDOR 3 DEBANCO DE DADOS
SLAVE
CLIENTE
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
67
se através de triggers, dados do servidor master forem inseridos em outras
tabelas do mesmo, as próprias tabelas fazem o trabalho de replicar os seus
dados. Isso é importante para evitar a duplicidade de dados.
3.2 PgCluster
Segundo PgCluster (2008), o PgCluster é uma ferramenta que permite o
balanceamento de carga e a replicação de banco de dados. Esta ferramenta não
é apenas uma ferramenta replicadora, mas sim, toda uma versão do SGBD
PostgreSQL, com algumas modificações específicas para poder fazer o
balanceamento de carga e as replicações. Dessa forma, cada versão do
PgCluster traz em seu código uma versão do PostgreSQL.
Para utilizar essa ferramenta, é necessário que, tanto os servidores
masters quanto os slaves, possuam a mesma versão do PgCluster instalados.
Como o balanceamento de carga, não sendo objetivo de estudo deste trabalho,
foi abstraído o máximo possível, concentrandose assim, no estudo da replicação
de banco de dados.
O funcionamento do PgCluster utilizado como ferramenta replicadora de
banco de dados, se dá da seguinte forma: o servidor replicador envia um sinal
para os demais servidores do cluster4 esperando uma resposta dos mesmos.
Após determinado tempo, o servidor replicador consegue identificar quais os
servidores acessíveis para efetuar replicação e, guarda a ordem em que recebeu
cada um dos sinais de resposta para definir a ordem de replicação. Aqueles que
não responderam são deixados de lado e um status é gravado no registro de log,
informando que os mesmos não obtiveram a replicação. Quando os servidores de
4 Cluster é um conjunto ou aglomerado de computadores que se comunicam através de uma rede de computadores em sistemas distribuídos, trabalhando como se fossem um único computador. Fonte: PgCluster Trac (2008).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
68
banco de dados inacessíveis reingressarem ou mesmo quando um novo servidor
de banco de dados for adicionado ao cluster, o servidor replicador conseguirá
sincronizar os mesmos (PgCluster, 2008).
A replicação, com o uso desta ferramenta, é obtida através de logs e com a
utilização do rsync5. Neste caso, a ferramenta sincroniza (replica) toda a estrutura
de arquivos e diretórios do local onde ficam as bases de dados. Para
sincronizações de um computador servidor para outro, o PgCluster utiliza o rsync
juntamente com o ssh6, para a conexão com outro computador. Isso garante a
segurança e criptografia dos dados (PgCluster Trac, 2008).
As características da utilização desta ferramenta de replicação são
descritas no QUADRO 3.
PgCluster
Tipo Síncrono.
Modelo Multimaster.
Controle AvailableCopies Method.
Método Logs usando o comando rsync.
Objetos replicados Todos.
Segurança SSH.
Versão 1.7.0rc12.
Versão do PostgreSQL utilizada 8.2.6.
Sistema operacional Qualquer um que rode o PostgreSQL.
QUADRO 3 Características da ferramenta PgCluster
Fonte: Elaborado pelo autor com base em (PgCluster Trac, 2008).
5 Rsync é um utilitário, em código aberto, específico para sincronizar arquivos e diretórios entre locais diferentes. Fonte: PgCluster Trac (2008).
6 SSH – Secure Shel é simultaneamente um programa de computador e um protocolo de rede que permite a conexão com outro computador na rede, que possibilita a execução de comandos na unidade remota com a garantia de uma conexão criptografada entre os computadores. Fonte: PgCluster Trac (2008).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
69
A FIGURA 9 ilustra o funcionamento da ferramenta e através dela é
possível perceber que além dos servidores de banco de dados, existem o servidor
de balanceamento de carga e o servidor de replicação. Estes três serviços
também podem funcionar, perfeitamente, no mesmo computador.
FIGURA 9 Exemplo de servidores de banco de dados utilizando a ferramenta PgCluster para replicação
Fonte: Elaborado pelo autor com base em PgCluster Trac (2008).
Pela FIGURA 9 ilustra uma estrutura de servidores utilizando os recursos
do PgCluster através de um servidor de balanceamento de carga, três servidores
de banco de dados e um servidor de replicação. Pela estrutura, é possível
perceber que após um cliente executar um comando SQL, o servidor de
balanceamento de carga escolherá um dos servidores de banco de dados para
executar o comando e, somente após isso, o mesmo comando é replicado para
os demais bancos, através do servidor de replicação (PgCluster Trac, 2008).
É importante salientar que um mesmo computador poderia ser um servidor
de balanceamento de carga, servidor de replicação e servidor de banco de dados.
Também é importante considerar que o PgCluster utiliza uma base de dados para
saber para quem foi ou não replicado (PgCluster Trac, 2008).
SERVIDOR 1 DEBANCO DE DADOS
SERVIDOR 2 DEBANCO DE DADOS
SERVIDOR 3 DEBANCO DE DADOS
SERVIDOR DEREPLICAÇÃO
SERVIDOR DEBALANCEAMENTO
DE CARGA
CLIENTE
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
70
3.3 SlonyI
O SlonyI é uma ferramenta assíncrona para replicações multimaster, que
além dessa funcionalidade permite o “cascateamento” nas replicações. Esse
“cascateamento” é a possibilidade de um servidor slave poder ser o servidor
master de outro servidor slave, e assim sucessivamente (Wieck, 2007).
Segundo Oliveira Júnior (2007), para utilização dessa ferramenta deve
existir sempre um servidor master para receber todas as transações de entrada
do banco de dados, sendo que podem existir n servidores slaves. Como já dito,
um desses servidores slaves também poderá assumir o papel de master de
outros servidores slaves. Isso é muito importante, pois além de possibilitar o
“cascateamento” nas replicações, é também um mecanismo de tolerância a falhas
uma vez que um servidor slave pode assumir o papel de master caso for
necessário. A FIGURA 10 ilustra a replicação com servidores “cascateados”.
FIGURA 10 Exemplo de servidores com replicação de de banco de dados cascateada utilizando a ferramenta SlonyI
Fonte: Elaborado pelo autor com base em Oliveira Júnior (2007).
Pode acontecer de o servidor master ficar inacessível por algum motivo.
Nesses casos, outro servidor slave poderá ser promovido, manualmente, a esse
SERVIDOR 3 DEBANCO DE DADOS
SLAVE
SERVIDOR 2 DEBANCO DE DADOS
SLAVE
SERVIDOR 1 DEBANCO DE DADOS
MASTER
TABELAS
TABELASDE LOG
TABELAS
TABELASDE LOG
TABELAS
TABELASDE LOG
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
71
papel. Assim, todos os servidores slaves seriam resincronizados conforme o
novo servidor master.
A replicação do banco de dados, com o uso dessa ferramenta, é feita com
a utilização de triggers que lêem tabelas de logs. Esse é um dos motivos que faz
com que o SlonyI não permita a propagação das mudanças relativas ao esquema
do banco de dados. Contudo, essa deficiência é suprida pela possibilidade de
enviar arquivos contendo as alterações do esquema, para serem executadas nas
réplicas (Wieck, 2007).
As tabelas de logs guardam as informações do que foi alterado no banco
de dados do servidor master e da situação em que se encontram esses dados
nos servidores slaves. Assim, periodicamente é executado um processo de
sincronização, que lê as tabelas de logs e faz as devidas replicações na ordem
em que foram executadas no servidor master, eliminando a possibilidade de
ocorrência de deadlocks. Esse modelo de replicação também permite que
servidores slaves estejam inacessíveis por algum tempo e, que após ficarem
novamente acessíveis, os dados continuem a ser replicados (Wieck, 2007).
Como os triggers são recursos do próprio PostgreSQL, eles utilizam as
mesma funções de conexão do PostgreSQL e sendo assim, toda questão relativa
à segurança dos dados replicados entre os bancos de dados, é tratada pelo
próprio SGBD. Como já visto anteriormente, é possível a utilização de conexões
com SSL, desde que o SGBD tenha sido compilado para tal (Browne,
c20042006).
As características da utilização desta ferramenta de replicação são
descritas no QUADRO 4.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
72
SlonyI
Tipo Assíncrono.
Modelo Masterslave sendo que os slaves também podem ser configurados para replicar para os demais
Controle AvailableCopies Method.
Método Triggers.
Objetos replicados Dados de tabelas e seqüências, menos dados do tipo blob ou largeobject.
Segurança SSL
Versão 1.2.13.
Versão do PostgreSQL utilizada 8.2.6.
Sistema operacional Qualquer um que rode o PostgreSQL.
QUADRO 4 Características da ferramenta SlonyI
Fonte: Elaborado pelo autor com base em Browne (c20042006).
Vale lembrar que essa ferramenta, assim como o uso de DBLink com
Trigger, permite a replicação parcial dos dados, sendo que permite configurar
quais dados devem ser replicados (Browne, c20042006).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
4 AVALIAÇÃO DAS FERRAMENTAS
Uma das formas de avaliação das ferramentas replicadoras, vistas na
seção 3, é fazendo os testes com as mesmas, mensurando os resultados obtidos,
e é esta a forma adotada neste trabalho. Para tanto criouse ambientes
específicos, capazes de simular o uso de banco de dados. Nesses ambientes ou
cenários, definiuse como os servidores de banco de dados, estão distribuídos na
rede de computadores, qual a velocidade de tráfego dos dados pela mesma e
quais os servidores masters e/ou slaves.
4.1 Cenários
Para realização dos testes de replicação, criouse cenários com a
finalidade de definir a disposição e relação dos servidores de banco de dados
entre si. Assim, propôsse dois cenários, exemplificando casos reais, de forma
que, além da avaliação das ferramentas replicadoras, os resultados obtidos
também pudessem ser aproveitados como base para definição da melhor técnica
e da melhor ferramenta de replicação em aplicações reais.
Em ambos os cenários, realizouse, os testes, em laboratórios, com
computadores utilizando o sistema operacional GNU/Linux. As características
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
74
tanto dos computadores utilizados como servidores, como dos utilizados como
clientes, são descritas no QUADRO 5.
Características dos computadores utilizados nos cenários das simulações
Processador Pentium 4 com 2 processadores de 3Ghz
Memória RAM 1 GB
Disco rígido 80 GB
QUADRO 5 Características dos computadores utilizados nos testes
Fonte: Elaborado pelo autor com base nas características dos computadores utilizados nos testes.
A disposição dos computadores na rede do laboratório é ilustrado na
FIGURA 11.
FIGURA 11 Exemplo de disposição dos computadores na rede do laboratório
Fonte: Elaborado pelo autor com base no laboratório utilizado.
SERVIDOR 1IP: 10.3.17.12
CLIENTE 20IP: 10.3.17.36
CLIENTE 19IP: 10.3.17.35
CLIENTE 18IP: 10.3.17.34
CLIENTE 17IP: 10.3.17.33
CLIENTE 16IP: 10.3.17.32
CLIENTE 15IP: 10.3.17.31
CLIENTE 14IP: 10.3.17.30
CLIENTE 13IP: 10.3.17.29
CLIENTE 12IP: 10.3.17.28
CLIENTE 11IP: 10.3.17.27
CLIENTE 10IP: 10.3.17.26
CLIENTE 9IP: 10.3.17.25
CLIENTE 8IP: 10.3.17.24
CLIENTE 7IP: 10.3.17.23
CLIENTE 6IP: 10.3.17.22
CLIENTE 5IP: 10.3.17.21
CLIENTE 4IP: 10.3.17.20
CLIENTE 3IP: 10.3.17.19
CLIENTE 2IP: 10.3.17.18
CLIENTE 1IP: 10.3.17.17
SERVIDOR 2IP: 10.3.17.13
SERVIDOR 3IP: 10.3.17.14
SWITCH
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
75
Princípio para os dois cenários: todos os computadores, servidores de
banco de dados, devem possuir, inicialmente, o mesmo banco de dados; os
outros computadores, que simulam clientes, devem manipular as informações. O
acesso dos clientes, tanto para leitura quanto para escrita de dados, nos
computadores servidores, é conseguido através de um script, desenvolvido na
linguagem php (www.php.net), que estabelece a conexão com os bancos de
dados dos servidores masters e executa instruções de entrada e saída de dados
aleatoriamente. Dessa forma, simulouse um ambiente real, com servidores de
banco de dados, sendo acessados pelos clientes, o que possibilitou diversos
testes com as ferramentas replicadoras. O APÊNDICE H – Script de leitura e
escrita de dados para simulação dos clientes, contém o código fonte do script
para simulação de clientes.
4.1.1 Cenário 1 – masterslave
No primeiro cenário ilustrouse um ambiente de intranet de uma empresa,
isto é, servidores e clientes de banco de dados distribuídos numa rede com
velocidade de 100 Mbps, interligados por um switch7. Composto por três
servidores e vários clientes, designouse um dos servidores como master e
apelidadose o de SERVIDOR1, os outros dois designouse como slaves.
Permitiuse a entrada de dados, apenas ao servidor master, a um dos slaves
permitiuse apenas consultas, este apelidouse de SERVIDOR2, já o terceiro,
utilizouse como backup, e apelidouse de SERVIDOR3. O servidor master faz a
replicação dos dados para os dois servidores slaves. A FIGURA 12 exemplifica
este cenário.
7 SWITCH – Dispositivo utilizado em redes de computadores para reencaminhar quadros entre os diversos nós. Fonte: Silberschatz (1999).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
76
FIGURA 12 Definição da estrutura do cenário 1
Fonte: Elaborado pelo autor com base em (Elnikety; Dropsho; Zwaenepoel, 2006).
Nas simulações, neste cenário, utilizouse as ferramentas replicadoras
DBLink por Triggers, PgCluster e SlonyI, esta última, assíncrona, teve suas
configurações alteradas para replicar os dados de forma síncrona.
4.1.2 Cenário 2 – multimaster
No segundo cenário descreveuse um ambiente formado também por três
servidores e vários clientes, mas neste, distribuise os servidores em uma rede,
simulando a Internet, com largura de banda limitada a 1 Mbps. Neste cenário,
designouse todos os servidores como masters, de forma que, todos os
servidores replicassem os dados para todos, e apelidouse os de SERVIDOR1,
SERVIDOR2 e SERVIDOR3. A FIGURA 13 exemplifica a estrutura deste cenário.
USUÁRIO
leitura leiturae
escrita
SERVIDOR 2 SERVIDOR 3SERVIDOR 1replicação
alta velocidade
replicação
alta velocidade
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
77
FIGURA 13 Definição da estrutura do cenário 2
Fonte: Elaborado pelo autor com base em (Elnikety; Dropsho; Zwaenepoel, 2006).
Nas simulações, neste cenário, utilizouse somente a ferramenta
PgCluster, pois esta é a única que utiliza o modelo de replicação multimaster,
necessário para este cenário.
Nos testes utilizouse o mesmo laboratório do cenário anterior. Contudo,
como neste cenário a largura de banda entre os servidores de banco de dados é
diferente, fezse necessário a simulação de uma largura de banda de rede menor.
Para tal, utilizouse o recurso de limitação de banda do kernel do linux, chamado
CBQ (Class Based Queueing). Através deste recurso, é possível definir a largura
de banda disponível para a comunicação entre computadores. Assim, para os
testes neste cenário, definiuse algumas regras limitando a saída de dados a uma
velocidade de apenas 1 Mbps, de cada um dos servidores. A instalação e
configuração desse recurso é descrita nos apêndices B – Instalação e
configuração dos programas, e F – Configuração da largura de banda do cenário
2, respectivamente.
USUÁRIO
leiturae
escrita
replicação replicação
leiturae
escrita
leiturae
escrita
replicação
SERVIDOR 1 SERVIDOR 3SERVIDOR 2
baixa velocidade
baixa velocidade
baixa velocidade
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
78
4.2 Bases de dados
Nomeouse a base de dados inicial dos servidores como DBTESTE, esta
contem apenas uma tabela que chamada PESSOAS. Essa tabela é composta por
dois campos, o primeiro, a chave primária, que chamouse de CODIGO, é do tipo
inteiro e, o segundo, chamouse de NOME, e é do tipo textual. O APÊNDICE A –
Criação das bases de dados, contém a estrutura de comandos utilizado na
criação destes bancos de dados.
Com os cenários e as bases de dados definidas, fezse necessária a
definição da metodologia para utilizar nas simulações.
4.3 Metodologia
Antes de qualquer teste, necessitouse definir de que forma eles seriam
realizados, em cada um dos cenários, e o que deveria ser avaliado.
Como a abordagem de bancos de dados distribuídos é a união de banco
de dados com rede de computadores, é trivial que o objetivo principal dos testes
com as ferramentas replicadoras é verificar duas situações:
1) Se os bancos de dados são replicados de forma correta conforme para
cada técnica de replicação implementada e;
2) Qual o comportamento do recurso de rede de computadores para cada
uma das técnicas implementadas.
Para conseguir avaliar estes dois aspectos nos dois Cenários propostos,
devem ser definidas diversas variáveis como, a quantidade de clientes que
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
79
acessa a base dos servidores, os comandos que podem ser executados nela, de
quanto em quanto tempo podem ser feitas replicações e quais os dados que
devem ser coletados e avaliados em cada simulação.
Todos os testes realizados com as diferentes ferramentas replicadoras
devem ser idênticos, a não ser os testes de intervalo de tempo de replicação, que
somente podem ser realizados com a ferramenta SlonyI. Isso ocorre devido o
fato de que as outras ferramentas são síncronas e dessa forma não replicam
utilizando intervalos de tempos prédefinidos.
Para ser possível executar os testes, primeiramente é necessário instalar e
configurar os computadores servidores de banco de dados e os clientes,
conforme os cenários propostos. Os servidores de banco de dados devem ter o
SGBD PostgreSQL e as ferramentas replicadoras devidamente instaladas e
configuradas, além da definição de quais servidores serão masters e quais serão
os slaves. As instalações das ferramentas para os testes deve ser feita
separadamente para cada um cenários de modo que os testes de um uma não
interfiram no do outro
Nos servidores também fazse necessário instalar a ferramenta Wireshark
(http://www.wireshark.org) para a captura dos pacotes da replicação. Esta
ferramenta é uma opções de ferramentas que existem com esse propósito. A
mesma é utilizada por ser software livre e porque além de capturar os pacotes
que trafegam na rede de computadores, a mesma possibilita facilmente definir
quais deles devem ser capturados ou ignorados com a possibilidade de até gerar
informações estatísticas e gráficos. Através das informações coletadas por essa
ferramenta podese verificar a eficiência das replicações com relação a
quantidade de dados que trafegam pela rede durante as replicações. Essas
estatísticas são extremamente importantes uma vez que uma replicação está
diretamente ligada à de rede de computadores. Os comandos de instalação
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
80
dessas ferramentas encontramse no APÊNDICE B – Instalação e configuração
dos programas (WIRESHARK, 2008).
Após a instalação e configuração dos servidores, os computadores clientes
devem ter a linguagem php instalada, bem como o script de simulação de acesso
dos usuários aos banco de dados dos servidores masters.
Num primeiro teste, apenas um computador cliente deve ficar com o script
simulador de clientes sendo executado.
Esse script simulador de clientes executa apenas uma operação de leitura
ou escrita, a cada X segundos, sendo X um valor sorteado entre 0.0 e 5.0
segundos, para cada nova operação. Também está definido nesse script que a
probabilidade de ser um acesso para inserção de dados representasse 20%,
atualização de dados 20%, exclusão de dados 10% e para consulta de ddos 50%,
do total dos acessos.
Nos testes subseqüentes, devem ser testados simultaneamente o acesso
por 5, 10 e 20 computadores clientes, respeitando a mesma probabilidade, de
quantidade de operações, no mesmo intervalo de tempo, descrito anteriormente.
Nesses primeiros testes, a ferramenta replicadora utilizada deve ser
configurada para replicar os dados para os servidores slaves em tempo real, isto
é, no mesmo instante que a entrada de dados foi executado no servidor master.
Para a ferramenta SlonyI, também realizase um teste para replicar os
dados para os slaves de 5 em 5, 10 em 10 e 20 em 20 minutos. Este teste pode
ser feito somente no primeiro cenário, pois o segundo é multimaster e dessa
forma, muitos conflitos entre os bancos devem ocorrer.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
81
Por fim, no cenário 2, os clientes devem fazer acessos aos 3 servidores
para manipular os dados. Dessa forma, todos servidores replicam dados para
todos.
Os testes devem ser feitos mantendo a configuração original das
ferramentas, sem a otimização das mesmas, para cada simulação. Para cada
teste realizado de forma síncrona, a ferramenta Wireshark deve ser configurada
para capturar os pacotes relativos a replicação durante 10 minutos. Nos testes de
forma assíncrona, a mesma deve capturar os pacotes relativos a replicação
durante 41 minutos. Estes tempos foram estipulados de forma que em cada teste
fosse possível fazer uma média da quantidade de dados replicados por unidade
de tempo. Além disso, para os testes assíncronos, a média de replicações deve
ser maior que uma execução do processo de replicação.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
5 RESULTADOS OBTIDOS
Durante as simulações com as ferramentas replicadoras, foi possível
observar o comportamento de cada uma delas, conforme o teste proposto e a
técnica de replicação implementada pela mesma. Dessa forma, além da simples
observação e do estudo da técnica utilizada, alguns dados da simulação puderam
ser coletados e tabulados gerando índices e gráficos.
Como o objetivo principal do presente trabalho não é estudar uma
ferramenta específica em si, mas sim a técnica utilizada pela mesma, os testes
foram divididos por ferramentas que implementavam o tipo de replicação Síncrona
e Assíncrona. Dentro dessa divisão, os testes ainda foram segmentados dentro
de cada cenário.
5.1 Replicação síncrona
Neste primeiro momento foram feitas observações sobre ferramentas que
utilizavam o tipo de replicação síncrona. Para esse tipo de replicação, as
simulações foram feitas em dois cenários: cenário 1, que segue o modelo master
slave e o cenário 2, que segue o modelo multimaster. Para o cenário 1 foram
testadas as ferramentas DBLink com Triggers, PgCluster e SlonyI e, para o
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
83
cenário 2, foi testada somente a ferramenta PgCluster por ser a única ferramenta
multimaster.
5.1.1 Cenário 1 masterslave
Seguindo a metodologia definida anteriormente, foram feitos os testes no
respectivo cenário.
Ao final de cada teste, os dados da base de dados do servidor master
foram comparados aos dados da base de dados dos servidores slaves. Em todos
os casos testados, os dados estavam idênticos.
Na seqüência são descritos os testes realizados neste cenário.
5.1.1.1 Acesso à base de dados por um cliente
Simulando o acesso para leitura e escrita de dados por apenas um cliente
à base de dados do servidor master, a ferramenta DBLink com Triggers replicou
os dados para o banco de dados de cada um dos dois servidores slaves, em
média com a taxa de 1,87 KBps, o que representou cerca de 0,0118% de uso da
largura de banda disponível. Nesta análise não foi considerado o fluxo de dados
de acesso do cliente ao servidor do banco de dados, somente o fluxo de dados do
servidor 1 para os outros dois servidores que contem réplicas.
Fazendo o filtro dos pacotes relativos às replicações entre apenas um
servidor slave com o servidor master, a taxa média de transferência de dados foi
de 0,93 Kbps, o que representou praticamente a metade da taxa da banda
utilizada para replicação do servidor master com os dois slaves. Isso mostra que a
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
84
taxa de utilização da rede tende a aumentar ou diminuir linearmente para cada
servidor slave adicionado ou removido do cluster.
O mesmo teste também foi realizado com a ferramenta PgCluster. A taxa
média de transferência de dados, na replicação do servidor master para os dois
servidores slaves, foi de 1,89 KBps, o que representou cerca de 0,0148% de uso
da largura de banda disponível.
Assim como foi feito com a ferramenta DBLink com Triggers, neste testes
também foram filtrados somente os pacotes relativos a replicação de um servidor
slave com o servidor master. A taxa de transmissão de dados para replicação do
PgCluster também apresentou resultados lineares.
Embora a ferramenta SlonyI seja assíncrona, o mesmo teste feito com as
anteriores foi feito com a mesma. A ferramenta foi configurada para replicar os
dados a cada 0 segundos, ou seja, teoricamente de forma instantânea. Os
resultados da utilização do recurso de rede, foram um pouco maiores que nos
casos anteriores. Isso se deve ao fato da ferramenta não apenas trocar
informações quando dados do servidor master forem modificados, mas sim,
trocando informações de controle de forma contínua.
A taxa média de uso da largura de banda disponível foi de 4,14 KBps
correspondendo a 0,0323% da largura de banda disponível.
Diferente das ferramentas anteriores, a taxa de transmissão de dados para
replicação do SlonyI não se demonstrou linear quando adicionado um novo
servidor slave ao cluster. Isso se deve ao fato de que para cada servidor slave
adicionado, a quantidade de dados de controle das réplicas aumenta.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
85
As taxas médias, de transmissão dos dados, desta simulação com as três
ferramentas, podem ser vistas na comparação no QUADRO 6. O GRÁFICO 1
exibe o resultado completo dos testes realizados com as três ferramentas, na
relação de bytes por segundo.
DBLink com Triggers
PgCluster SlonyI
Taxa média de uso em uma rede de 100 Mbps
1,87 KBps 1,89 KBps 4,14 KBps
Percentual médio de uso em uma rede de 100 Mbps
0,0118% 0,0148% 0,0323%
QUADRO 6 Médias dos dados, coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, as alterações da base de dados geradas por 1 cliente.
Fonte: Elaborado pelo autor com base nos dados coletados durante as simulações.
GRÁFICO 1 Dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves as alterações da base de dados, geradas por 1 cliente, durante aproximadamente 10 minutos.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
5.1.1.2 Acesso à base de dados por cinco clientes
Nessa simulação verificouse o comportamento das ferramentas, com 5
computadores clientes, fazendo acessos à base de dados do servidor master,
para leitura e escrita de dados.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
86
A ferramenta DBLink com Triggers replicou os dados para os 2 servidores
slaves, utilizando em média a taxa de 8,98 KBps, o que representa cerca de
0,0702% de uso da largura de banda disponível.
Já a ferramenta PgCluster, no mesmo teste, obteve uma taxa média de
transferência de dados, na replicação para os servidores slaves, de 7,56 KBps, o
que representa cerca de 0,0591% de uso da largura de banda disponível.
Por fim, a ferramenta SlonyI, obteve uma taxa média de uso da largura de
banda disponível de 6,86 Kbps, o que correspondeu a 0,0536% da largura de
banda disponível.
Diferente do primeiro teste realizado, neste teste é perceptível que a
ferramenta SlonyI teve um melhor desempenho que as demais. Isso certamente
ocorreu devido ao fato de que a quantidade de dados transmitidos fosse bem
maior da quantidade de dados de controle, trocadas entre os servidores.
Através dos dados comparativos do QUADRO 7, é possível perceber que
com o aumento do número de clientes acessando, para leitura e escrita, a base
de dados do servidor master, a taxa média da ferramenta SlonyI, foi menor que
as outras ferramentas. O GRÁFICO 2 exibe o resultado completo das simulações,
na relação bytes por segundo, das replicações.
DBLink com Triggers
PgCluster SlonyI
Taxa média de uso em uma rede de 100 Mbps
8,98 KBps 7,56 KBps 6,86 KBps
Percentual médio de uso em uma rede de 100 Mbps
0,0702% 0,0591% 0,0536%
QUADRO 7 Médias dos dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, as alterações da base de dados geradas por 5 clientes.
Fonte: Elaborado pelo autor com base nos dados coletados durante as simulações.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
87
GRÁFICO 2 Dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, as alterações da base de dados geradas por 5 clientes, durante aproximadamente 10 minutos.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
5.1.1.3 Acesso à base de dados por dez clientes
Prosseguindo com as simulações, foi verificado o comportamento das
ferramentas, nas replicações aos dois servidores slaves, com 10 computadores
clientes fazendo acessos à base de dados do servidor master para leitura e
escrita de dados.
A ferramenta DBLink com Triggers replicou os dados para os 2 servidores
slaves utilizando, em média, a taxa de 17,88 KBps, o que representou
aproximadamente 0,1397% de uso da largura de banda disponível.
Já a ferramenta PgCluster, no mesmo teste, obteve uma taxa média de
transferência de dados, na replicação para os servidores slaves, de 14,19 KBps, o
que representou cerca de 0,1109% de uso da largura de banda disponível.
Por fim, o teste foi feito com a ferramenta SlonyI, que obteve uma taxa
média, de uso da largura de banda disponível, de 8,87 Kbps, o que correspondeu
a 0,0693% da largura de banda disponível.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
88
Através dos dados comparativos do QUADRO 8, é possível perceber que,
com o aumento do número de clientes acessando, para leitura e escrita, a base
de dados do servidor master, a taxa média da ferramenta SlonyI foi menor que as
outras ferramentas. O GRÁFICO 3 exibe o resultado completo das simulações, na
relação bytes por segundo, das replicações.
DBLink com Triggers
PgCluster SlonyI
Taxa média de uso em uma rede de 100 Mbps
17,88 KBps 14,19 KBps 8,87 KBps
Percentual médio de uso em uma rede de 100 Mbps
0,1397% 0,1109% 0,0693%
QUADRO 8 Médias dos dados coletados, das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, as alterações da base de dados geradas por 10 clientes.
Fonte: Elaborado pelo autor com base nos dados coletados durante as simulações.
GRÁFICO 3 Dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, as alterações da base de dados geradas por 10 clientes, durante aproximadamente 10 minutos.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
5.1.1.4 Acesso à base de dados por vinte clientes
Seguindo esta mesma metodologia de testes, foram feitos os mesmos
testes das três subseções anteriores, modificando apenas o número de
computadores clientes, que acessam o servidor master, para 20.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
89
Foi constatado que a ferramenta DBLink com Triggers replicou os dados
para os 2 servidores slaves utilizando, na média, a taxa de 31,71 KBps, o que
representou cerca de 0,2477% de uso da largura de banda disponível.
A ferramenta PgCluster, por sua vez, obteve uma taxa média, de
transferência de dados na replicação para os dois servidores slaves, de 28,92
KBps, o que representou cerca de 0,2259% de uso da largura de banda
disponível.
O último teste com 20 clientes, foi com a ferramenta SlonyI, que obteve
uma taxa média, de uso da largura de banda disponível, de 9,56 Kbps, o que
correspondeu a 0,0747% da largura de banda disponível.
Através dos dados comparativos do QUADRO 9, é possível perceber que,
com o aumento do número de clientes acessando, para leitura e escrita, a base
de dados do servidor master, a taxa média da ferramenta SlonyI foi menor que
das outras ferramentas. O GRÁFICO 4 exibe o resultado completo das
simulações, na relação bytes por segundo, das replicações.
DBLink com Triggers
PgCluster SlonyI
Taxa média de uso em uma rede de 100 Mbps
32,71 KBps 28,92 KBps 9,56 KBps
Percentual médio de uso em uma rede de 100 Mbps
0,2477% 0,2259% 0,0747%
QUADRO 9 Médias dos dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, as alterações da base de dados geradas por 20 clientes.
Fonte: Elaborado pelo autor com base nos dados coletados durante as simulações.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
90
GRÁFICO 4 Dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, as alterações da base de dados geradas por 20 clientes, durante aproximadamente 10 minutos.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
5.1.1.5 Conclusões sobre o cenário 1 masterslave
Através dos testes foi possível perceber uma série de características e
comportamentos diferentes para cada técnica de replicação utilizada. Foi possível
perceber que a técnica de replicação utilizada, a quantidade de usuários
manipulando dados e a quantidade de réplicas, influenciam diretamente no
desempenho da taxa média da largura de banda disponível para rede de
computadores.
Fazendo a leitura dos gráficos e tabelas, é perceptível que quanto maior o
número de usuários manipulando informações no servidor master, melhor é o
desempenho relacionado a taxa média de transferência de dados da ferramenta
SlonyI. Também foi possível perceber que nos gráficos, os resultados relativos a
esta ferramenta, são muito mais homogêneas que as demais. Isso se deve
principalmente ao fato desta ferramenta ser assíncrona e não síncrona.
As ferramentas DBLink com Triggers e PgCluster, tiveram resultados bem
próximos, sendo que a primeira, foi um pouco menos eficiente na transferência de
dados, que a segunda. Essa eficiência está relacionada a forma como foi
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
91
programada a ferramenta. A ferramenta PgCluster utiliza um controle de réplica,
como o AvailableCopies Method, que replica os dados somente para as réplicas
ativas, diferentemente da ferramenta DBLink com Triggers, que foi programada
para replicar para todos, e caso um esteja inativo, para nenhum. Esse controle
diferente pode influenciar. Além disso, o método de replicação também é
diferente. Enquanto a ferramenta PgCluster utiliza o recurso de logs replicando os
dados através do comando rsync, a ferramenta DBLink com Triggers utiliza o
recurso de triggers replicando os dados através de comandos SQL. Esse método
também pode afetar no desempenho.
Um último teste realizado com as três ferramentas foi simular a queda de
conexão de um dos servidores slaves durante as replicações. Enquanto as
ferramentas DBLink com Triggers e PgCluster simplesmente pararam de fazer
entrada de dados em todos os servidores, a ferramenta SlonyI continuou fazendo
para o outro servidor slave ativo.
Ao reestabelecer novamente a conexão dos servidor slave, as ferramentas
DBLink com Triggers e PgCluster passaram a fazer novamente as manipulações
de dados no banco de dados do servidor master e a replicar normalmente para os
servidores slaves. A outra ferramenta sincronizou primeiramente o servidor slave
que estava inacessível e continuou fazendo as replicações normalmente.
É importante salientar que os testes foram feitos com a configuração
padrão das ferramentas, e que a ferramenta PgCluster pode ter sua configuração
alterada para operar da mesma forma que a ferramenta SlonyI, continuar
replicando os dados para o servidor slave ativo. Também, que todas as
ferramentas possuem o recurso de replicação parcial de banco de dados mas,
não sendo foco deste trabalho, não foram feitas simulações nessa linha.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
92
5.1.2 Cenário 2 multimaster
Para o cenário 2, utilizouse uma ferramenta que trabalhasse no modelo
multimaster. Foram feitas simulações de replicações com 1, 5, 10 e 20 clientes
acessando a base de dados dos servidores master. Neste cenário, os três
servidores são masters, isto é, os três replicam seus dados e recebem a réplica
dos demais. Dessa foma, em cada computador cliente o script, que simula os
acessos aos servidores masters foi executado 3 vezes, simultaneamente para
cada teste. Em cada uma das execuções, foi feita com uma cópia desse script,
sendo que cada cópia foi configurada para acessar e manipular os dados de um
dos servidores. Assim, para cada simulação, os três servidores tinham seus
dados manipulados.
Como no cenário 2, os três servidores eram masters, diferente do cenário
1, onde apenas um era sendo que os outros dois eram slaves, foi necessário
configurar a ferramenta replicadora PgCluster de forma diferente. O APÊNDICE G
– Configurações para uso do PgCluster no Cenário 2, mostra como foi feita a
configuração. Embora o princípio seja o mesmo do cenário anterior, neste, cada
servidor possui não somente a base de dados, mas também o replicador do
PgCluster configurado para replicar os dados da sua réplica para os demais
servidores.
Uma particularidade do cenário 2, é que o mesmo foi definido com o
propósito de simular replicações entre servidores interligados por uma rede de
baixa velocidade, como a Internet. Assim, o acesso dos computadores clientes
aos servidores continua numa rede de 100 Mbps, mas para os dados que
trafegam pela rede de computadores, entre os servidores, foi definida apenas com
a largura de banda de 1Mbps. Essa configuração foi possível através da utilização
do recurso de limitação de banda do kernel do linux, chamado CBQ.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
93
Para cada teste feito, foram coletados os pacotes que trafegaram pela rede
de computadores, de apenas um dos três servidores e somente os pacotes
pertinentes as trocas de informações relativas as replicações dos mesmos. Assim
foi possível estimar a quantidade de dados trocados entre os mesmos, ignorando
o tráfego gerado na rede de computadores, dos computadores clientes.
Da mesma forma que no cenário anterior, ao final de cada teste realizado,
os dados, das bases de dados de todos os servidores, foram comparados. Em
todos os testes estavam idênticos, isto é, as replicações foram efetivadas com
sucesso.
Na seqüência são descritos os testes definidos na metodologia para este
cenário.
5.1.2.1 Acesso à base de dados por um cliente
Quando foi feita a simulação de replicação entre os três servidores tendo
suas bases de dados acessadas por apenas um computador cliente, a taxa média
de utilização da largura de banda disponível foi de 5,43 KBps, o que representou
cerca de 4,2422% do total da largura de banda disponível, entre os três
servidores.
O GRÁFICO 5 exibe o resultado completo da relação bytes por segundo,
durante os 10 minutos da simulação.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
94
GRÁFICO 5 Dados coletados na replicação entre os três servidores, durante 10 minutos, onde suas bases de dados foram acessadas por apenas 1 cliente.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
5.1.2.2 Acesso à base de dados por cinco clientes
A segunda simulação foi realizada, utilizando 5 computadores clientes,
acessando os bancos de dados dos três servidores masters. A taxa média de
utilização da largura de banda disponível para este teste foi de 24,69 KBps, o que
representou cerca de 19,2891% do total da largura de banda disponível entre os
três servidores.
O GRÁFICO 6 exibe o resultado completo, na relação bytes por segundo,
durante os 10 minutos da simulação.
GRÁFICO 6 Dados coletados na replicação entre os três servidores, durante 10 minutos, onde suas bases de dados foram acessadas por apenas 5 clientes.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
95
5.1.2.3 Acesso à base de dados por dez clientes
Com a simulação de replicação entre os três servidores, tendo suas bases
de dados acessadas por 10 computadores clientes, a taxa média de utilização da
largura de banda disponível foi de 49,03 KBps. Essa taxa representa cerca de
38,3047% do total da largura de banda disponível, entre os três servidores.
O GRÁFICO 7 exibe o resultado completo da relação bytes por segundo,
durante os 10 minutos da simulação.
GRÁFICO 7 Dados coletados na replicação entre os três servidores, durante 10 minutos, onde suas bases de dados foram acessadas por apenas 10 clientes.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
5.1.2.4 Acesso à base de dados por vinte clientes
A última simulação feita foi com 20 computadores clientes, acessando os 3
servidores masters. A taxa média de utilização da largura de banda disponível foi
de 96,87 KBps. Essa taxa representou cerca de 75,6797% do total da largura de
banda disponível entre os três servidores.
O GRÁFICO 8 exibe o gráfico completo da relação bytes por segundo
durante os 10 minutos da simulação.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
96
GRÁFICO 8 Dados coletados na replicação entre os três servidores durante 10 minutos onde suas bases de dados era acessadas por apenas 20 clientes.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
5.1.2.5 Conclusões sobre o cenário 2 – multimaster
O QUADRO 10 faz um comparativo entre as médias coletadas em todos os
testes realizados neste cenário. Através desses dados é possível perceber que na
simulação com 20 clientes, praticamente 75% da largura de banda disponível foi
utilizada pelas ferramentas replicadoras. Isso certamente inviabilizaria a adição de
mais servidores masters ao cluster, ou mesmo, a adição de mais computadores
clientes ao mesmo.
1 cliente 5 clientes 10 clientes 20 clientes
Taxa média de uso de uma rede de 1 Mbps
5,43 KBps 24,69 KBps 49,03 KBps 96,87 KBps
Percentual médio de uso de uma rede de 1 Mbps
4,2422% 19,2891% 38,3047% 75,6797%
QUADRO 10 Médias das replicações coletadas nas simulações do cenário 2.
Fonte: Elaborado pelo autor com base nos dados coletados durante as simulações.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
97
5.2 Replicação assíncrona
Após as simulações anteriores com as ferramentas síncronas, foram feitas
as simulações com a ferramenta assíncrona. Para esse tipo de replicação, as
simulações foram feitas em dois cenários: cenário 1, que seguia o modelo
masterslave e o cenário 2, que seguia o modelo multimaster. Para ambos
cenários foi testada somente a ferramenta SlonyI, pois somente esta que é
assíncrona.
Assim como nas simulações síncronas, foram capturados os pacotes
relativos a replicação das bases de dados dos servidores. Neste tipo de
replicação, os dados foram coletados durante aproximadamente 41 minutos de
cada teste. Isso garantiu que em todos os intervalos de replicação propostos na
metodologia, fosse executada pelo menos mais de uma vez a replicação.
5.2.1 Cenário 1 masterslave
Para as replicações assíncronas no modelo masterslave, no cenário 1,
foram feitas observações quanto a utilização da largura de banda disponível.
Dessa mesma forma, foram feitos os testes com a ferramenta SlonyI replicando
os dados, da base de dados, de um servidor master para dois slaves. Nestes
testes, os dados foram replicados sempre em intervalos de tempo de 5, 10 e 20
minutos, com a simulação de 1, 5, 10 e 20 computadores clientes acessando o
servidor master.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
98
5.2.1.1 Acesso à base de dados por um cliente
O primeiro teste realizado foi a simulação de apenas um computador
cliente acessando o banco de dados do servidor master para entrada e saída de
dados. A ferramenta replicadora SlonyI inicialmente foi configurada para replicar
os dados do servidor master para os dois servidores slaves de 5 em 5 minutos.
Para este teste, a taxa média de utilização da largura de banda foi de 0,85 KBps,
o que representou cerca de 0,0066% de uso da largura de banda disponível. Para
este teste, os dados foram replicados na média em 4 segundos.
Após esse teste, a ferramenta foi configurada para replicar os dados em
intervalos de tempo de 10 minutos. A taxa média de utilização da largura de
banda foi de 0,70 KBps, o que representou cerca de 0,0055% de uso da largura
de banda disponível. Os dados foram replicados, em média, durante 4 segundos
após o início de cada replicação.
Um último teste foi realizado com a ferramenta configurada para replicar os
dados a cada 20 minutos. A taxa média de utilização da largura de banda foi de
0,55 KBps, o que representou cerca de 0,0043% de uso da largura de banda
disponível. Neste teste, a média nas replicações dos dados, foi de 5 segundos.
Nos dados replicados coletados, em nenhum momento foi considerado o
fluxo de dados de acesso do cliente ao servidor do banco de dados, somente o
fluxo de dados do servidor master para os dois servidores slaves.
Através dos dados comparativos do QUADRO 11 é possível perceber que,
com o aumento do intervalo de tempo de replicações, cai a taxa média de
utilização do recurso de rede. Teoricamente, a quantidade de dados replicados é
a mesma. Contudo, quanto mais vezes o processo de replicação é executado,
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
99
maior é a quantidade de dados de controle que são trocados entre os servidores.
Isso explica as taxas de utilização da rede.
O GRÁFICO 9 é um comparativo dos três testes de replicação, acima
descritos, exibindo a relação bytes por segundos.
5 minutos 10 minutos 20 minutos
Taxa média de uso em uma rede de 100 Mbps
0,85 KBps 0,71 KBps 0,55 KBps
Percentual médio de uso em uma rede de 100 Mbps
0,0066% 0,0055% 0,0043%
Tempo médio para replicação dos dados
4 segundos 4 segundos 5 segundos
QUADRO 11 Médias dos dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves as alterações da base de dados geradas por 1 cliente, no intervalo de tempo de 5, 10 e 20 minutos.
Fonte: Elaborado pelo autor com base nos dados coletados durante as simulações.
GRÁFICO 9 Dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves de forma assíncrona a cada 5, 10 e 20 minutos, as alterações da base de dados geradas por 1 cliente, durante aproximadamente 41 minutos.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
100
5.2.1.2 Acesso à base de dados por cinco clientes
Da mesma forma que no teste anterior, foi feita uma simulação das
ferramentas replicando os dados em intervalos de tempos de 5, 10 e 20 minutos.
Contudo, desta vez os testes foram feitos com 5 clientes acessando a base de
dados do servidor master para a manipulação dos dados. As taxas médias de
utilização da largura de banda da rede foram respectivamente de 1,38 KBps, 1,11
KBps e 0,92 KBps, o que representou os percentual de utilização do recurso de
rede também respectivamente de 0,0108%, 0,0087% e 0,0072%. O tempo médio
para a replicação dos dados, nas replicações de 5 minutos foi de 4 segundos, nas
de 10 minutos foi de 4 segundos e nas de 20 minutos foi de 5 segundos.
Os dados representados no GRÁFICO 10 foram coletados e os valores
médio foram tabulados no QUADRO 12.
5 minutos 10 minutos 20 minutos
Taxa média de uso em uma rede de 100 Mbps
1,38 KBps 1,11 KBps 0,92 KBps
Percentual médio de uso em uma rede de 100 Mbps
0,0108% 0,0087% 0,0072%
Tempo médio para replicação dos dados
4 segundos 4 segundos 5 segundos
QUADRO 12 Médias dos dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves as alterações da base de dados geradas por 5 clientes, no intervalo de tempo de 5, 10 e 20 minutos.
Fonte: Elaborado pelo autor com base nos dados coletados durante as simulações.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
101
GRÁFICO 10 Dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves de forma assíncrona a cada 5, 10 e 20 minutos, as alterações da base de dados geradas por 5 clientes, durante aproximadamente 41 minutos.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
5.2.1.3 Acesso à base de dados por dez clientes
Seguindo a mesma metodologia dos dois testes anteriores, foi realizado o
mesmo teste mas desta vez com 10 computadores clientes acessando a base de
dados do servidor master para entrada e saída de dados.
A taxa média de utilização do recurso da rede para replicações de
intervalos de tempos de 5 minutos foi de 1,84 KBps, correspondendo 0,0144% do
total da largura de banda disponível. Os dados deste teste foram replicados na
média durante 5 segundos.
Para o teste com replicações a cada 10 minutos nestes mesmos
aproximados 41 minutos, a taxa média de utilização da banda disponível foi de
1,59 KBps, o que representou 0,0124% da utilização do recurso de rede. Neste
teste, a média nas replicações dos dados, foi de 6 segundos.
Ainda foi feito o mesmo teste com replicações a cada 20 minutos. Os
valores médios deste teste e dos 2 anteriores podem ser vistos no QUADRO 13.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
102
O gráfico com a relação de bytes por segundos das replicações, para os três
testes feitos, com os 10 computadores clientes acessando o servidor master,
pode ser visto no GRÁFICO 11. Os dados deste teste, foram replicados em
média, durante 6 segundos.
5 minutos 10 minutos 20 minutos
Taxa média de uso em uma rede de 100 Mbps
1,84 KBps 1,59 KBps 1,42 KBps
Percentual médio de uso em uma rede de 100 Mbps
0,0144% 0,0124% 0,0111%
Tempo médio para replicação dos dados
5 segundos 6 segundos 6 segundos
QUADRO 13 Médias dos dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, as alterações da base de dados geradas por 10 clientes, no intervalo de tempo de 5, 10 e 20 minutos.
Fonte: Elaborado pelo autor com base nos dados coletados durante as simulações.
GRÁFICO 11 Dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, de forma assíncrona, a cada 5, 10 e 20 minutos, as alterações da base de dados geradas por 10 clientes, durante aproximadamente 41 minutos.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
5.2.1.4 Acesso à base de dados por vinte clientes
Semelhante aos dados coletados nos testes com com a ferramenta
assíncrona, no cenário 1, os valores médios de utilização do recurso de rede na
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
103
replicação do servidor master para os slaves, com acessos de 20 computadores
ao servidor master, podem ser vistos no QUADRO 14. O GRÁFICO 12 exibe o
comparativo, durante aproximados 41 minutos para 5, 10 e 20 clientes,
manipulando dados do servidor master.
5 minutos 10 minutos 20 minutos
Taxa média de uso em uma rede de 100 Mbps
2,47 KBps 2,27 KBps 2,19 KBps
Percentual médio de uso em uma rede de 100 Mbps
0,0193% 0,0177% 0,0171%
Tempo médio para replicação dos dados
5 segundos 8 segundos 8 segundos
QUADRO 14 Médias dos dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, as alterações da base de dados geradas por 20 clientes, no intervalo de tempo de 5, 10 e 20 minutos.
Fonte: Elaborado pelo autor com base nos dados coletados durante as simulações.
GRÁFICO 12 Dados coletados das ferramentas replicadoras, com 1 servidor master replicando para 2 servidores slaves, de forma assíncrona, a cada 5, 10 e 20 minutos, as alterações da base de dados geradas por 20 clientes, durante aproximadamente 41 minutos.
Fonte: Elaborado pelo autor com base nos gráficos gerados pela ferramenta Wireshark durante as simulações.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
104
5.2.1.5 Conclusões sobre o cenário 1 masterslave
Através dos resultados coletados nas simulações, com a ferramenta
assíncrona, no cenário 1, foi possível gerar vários gráficos e dados que foram
tabulados. Através dos mesmos algumas conclusões tornamse bem perceptíveis.
A primeira conclusão que pode ser observada é que quanto maior o
intervalo de tempo para as replicações, menor é a taxa média de utilização da
replicação da largura de banda disponível. Isso se deve principalmente ao fato de
que para cada replicação, deve ser replicada também, a estrutura de controle
dessa replicação, para a réplica. Assim, para cada vez que o processo replicador
for executado, será executado também o processo que replica a estrutura de
controle das réplicas. Além disso, para cada vez que é executado o processo de
replicação, vários dados de troca de informações, como quais são os servidores
ativos, são trocados.
Outro dado que pode ser observado é que, quanto maior é o intervalo de
tempo para as replicações, maior é o pico no gráfico que representa a quantidade
de bytes por segundos. Isso indica que as replicações assíncronas não possuem
um comportamento homogêneo, e conforme a largura de banda da rede dos
computadores, isso poderia representar um problema.
Ainda é possível perceber que, a diferença entre os valores médios de
utilização do recurso de rede, das replicações de intervalos de tempo de 5, 10 e
20 minutos, diminuem a medida que aumenta o número de computadores que
fazem acesso ao servidor master. Isto pode ser percebido nos quadros,
calculando a diferença dessas médias para todos os testes. Quanto menor o
número de computadores, maior é a diferença entre as médias.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
105
5.2.2 Cenário 2 multimaster
Não foi encontrada nenhuma ferramenta assíncrona em Software Livre que
fizesse a replicação multimaster. Essa técnica de replicação, com certeza, é a
mais complexa, principalmente porque os dados são manipulados isoladamente
em cada servidor master e após um período, existe a tentativa de replicação entre
os mesmos.
A replicação é extremamente complexa, pois os dados de um servidor
podem conflitar com os dados de outro, e dessa forma, devem existir algoritmos
de resolução de conflitos altamente eficientes. Mesmo assim, a utilização dessa
técnica fica mais no formalismo, pois em ambientes reais é praticamente inviável
a utilização da mesma.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
6 CONCLUSÃO
Este trabalho apresentou um estudo sobre as diferentes técnicas de
replicação de banco de dados em software livre. Foram descritos os conceitos
pertinentes a banco de dados, redes de computadores, bancos de dados
distribuídos a replicação, aprofundado o assunto replicação em banco de dados.
Após esse embasamento teórico, foi definido que seria escolhido um
SGBD, existente em software livre, para que as diferentes técnicas e algoritmos
pudessem ser estudadas, utilizandose do mesmo. Para escolha desse SGBD, foi
feito um quadro comparativo, entre os principais existentes no mercado, e através
desses dados comparativos que optouse pelo PostgreSQL.
Uma vez o SGBD definido, foram pesquisadas as diferentes técnicas e
ferramentas de replicação que o mesmo implementava. Como o recurso de
replicação, de forma nativa, implementava apenas uma das diferentes técnicas,
foram pesquisadas diversas ferramentas, também em software livre. Dessa forma,
através de várias ferramentas, foi possível estudar as diferentes formas de
replicação. As ferramentas utilizadas foram PgCluster e SlonyI, além do recurso
nativo de Trigger com a contribuição DBLink do próprio SGBD.
Para fazer o estudo das diferentes formas de replicação, utilizando as
ferramentas citadas no parágrafo anterior, foi necessário simular alguns
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
107
ambientes corporativos. Assim, foram criados dois ambientes, cenário 1 e cenário
2, com diferentes características, o que tornou possível esse estudo.
A partir dos testes realizadas com as ferramentas replicadoras, foi possível
coletar várias informações que foram exibidas através de gráficos e quadros
comparativos.
A contribuição que fica com este trabalho é um estudo apurado sobre os
diferentes algoritmos e técnicas de replicação em banco de dados. O trabalho
também mostrou a viabilidade da utilização de cada uma das diferentes técnicas
conforme alguns cenários propostos. Além disso, fica como contribuição um
estudo aprofundado das diferentes características das ferramentas PgCluster,
SlonyI e o próprio recurso de triggers aliado a contribuição DBLink do
PostgreSQL.
Ficam como sugestões para trabalhos futuros:
● Aplicar as técnicas estudadas em uma empresa.
● Estudo de ferramentas multimaster, assíncronas, com algoritmos de
resolução de conflitos.
● Desenvolver uma ferramenta unificada para o PostgreSQL.
● Fazer testes com maior quantidade de usuários acessando as bases
de dados.
● Fazer testes capturando os pacotes relativos às replicações durante
um intervalo de tempo maior.
● Fazer testes com bases de dados maiores.
● Pesquisar e avaliar ferramentas ou recursos de outros SGBDs.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
REFERÊNCIAS
BROWNE, Christopher. SlonyI 1.2.13 Documentation. The PostgreSQL Global Development Group. c20042006. Disponível em: <http://slony.info/documentation /index.html>. Acesso em: 20 abr. 2008.
DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus, 1990.
ELNIKETY, Sameh; DROPSHO, Steven; ZWAENEPOEL, Willy. Predicting Replicated Database Speedup from Standalone Database Measurements: SingleMaster vs. MultiMaster. Technical report. EPFL. Nov. 2006. Disponível em: <http://labos.epfl.ch/webdav/site/labos/users/157494/public/papers/SinglevsMultiMaster.pdf>. Acesso em: 14 set. 2007.
FireBird. Firebird SQL Conformance. The Firebird Documentation Team. c20002008. Disponível em: http://www.firebirdsql.org/?op=doc>. Acesso em: 20 abr. 2008.
GEDDA, Rodney. Computerworld. Google talks up smart software for reliability. 2006. Disponível em: <http://www.linuxworld.com.au/index.php/id;1225434946; fp;16;fpid;0>. Acesso em: 18 ago. 2007.
ISO/IEC 9075 (revisão 14, publicada em 2006). Disponível em <http://www.iso. org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=38647>. Acesso em: 03 dez. 2007.
LAMPING, Ulf; SHARPE, Richard; WARNICKE, Ed. Wireshark User's Guide: 25443 for Wireshark 1.0.0. NS Computer Software and Services P/L . C
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
109
20042008. Disponível em: <http://www.wireshark.org/download/docs/userguidea4.pdf> Acesso em: 20 abr. 2008.
MONTEIRO, José Maria; ENDLER, Markus; LIFSCHITZ, Sérgio; BRAYNER, Ângelo. Um Mecanismo para a Consistência de Dados Replicados em Computação Móvel. Monografias em Ciência da Computação. Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro. 2006. Disponível em: <ftp://ftp.inf.pucrio.br/pub/docs/techreports/06_21_monteiro.pdf>. Acesso em: 14 Set. 2007.
MySQL. MySQL 5.0 Reference Manual. The MySQL Documentation Team. c19972008. Disponível em: http://dev.mysql.com/doc/>. Acesso em: 20 abr. 2008.
OLIVEIRA JÚNIOR, João Cosme de. Configurando o SlonyI. Artigo. 2007. Disponível em: <http://www.postgresql.org.br/Documenta%C3%A7%C3%A3o?action=AttachFile&do=get&target=slony.pdf>. Acesso em: 20 abr. 2008.
OLIVEIRA, Alexandre Pereira de. Modelo de replicação de dados entre SGBD Heterogêneos. Monografia – (Graduação) Curso de Ciência da Computação da Universidade Luterana do Brasil, Gravataí, 2006.
ÖZSU, M. Tamer; VALDURIEZ, Patrick. Princípios de sistemas de banco de dados distribuídos. Rio de Janeiro: Campus, 2001.
PEDRONI, Lisiane M.; RIBEIRO, Helena G. Replicação em Banco de Dados PostgreSQL – Escola Regional de Banco de Dados, Caxias, 2006. Disponível em: <http://www.upf.br/erbd/download/16138.pdf>. Acesso em: 14 set. 2007.
PgCluster Trac. PgCluster Trac: Integrated SCM & Project Management. Disponível em: <http://www.pgcluster.org/>. Acesso em: 20 abr. 2008.
PgCluster. PGCluster: The multimaster and synchronous replication system of for PostgreSQL. Disponível em: <http://pgcluster.projects.postgresql.org/>. Acesso em: 20 abr. 2008.
PostgreSQL. PostgreSQL 8.2 Documentation. The PostgreSQL Global Development Group. c19962006. Disponível em: http://www.postgresql.org/docs/manuals/>. Acesso em: 20 abr. 2008.
RIBEIRO, Uirá Endy. Sistemas Distribuídos Desenvolvendo Aplicações de Alta Performance no Linux. Rio de Janeiro: Axcel Books do Brasil Editora, 2005.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
110
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de Dados. São Paulo: Makron Books, 1999.
TANENBAUM, Andrew S.; van Steen, Maarten. Distributed Systems. Amsterdam, Holanda: Prentice Hall, 2002.
TEL, Gerard. Introduction to distributed algorithms. Cambridge, Inglaterra: Cambridge University Press, 2000.
WEBER, Taisy Silva. Tolerância a falhas: conceitos e exemplos. Programa de PósGraduação em Computação Instituto de Informática – UFRGS. 2001. Disponível em: <http://www.inf.ufrgs.br/~taisy/disciplinas/textos/Conceitos Dependabilidade.PDF>. Acesso em: 14 Set. 2007.
WIECK, Jan. SlonyI – A replication system for PostgreSQL. Afilias USA INC Horsham, Pennsylvania, USA, 2007. Disponível em: <http://developer.postgresql. org/~wieck/slony1/SlonyIconcept.pdf>. Acesso em: 20 abr. 2008.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
GLOSSÁRIO
Backup – Cópia de segurança
Bits – Menor unidade de informação usada em computação
Bytes – Conjunto de 8 bits
Cache – Memória de acesso rápido
Criptografia – Técnicas pela qual a informação pode ser transformada da
sua forma original para outra forma ilegível, de forma que possa ser novamente
convertida ao texto original
Delay – Retardo de tempo
Ethernet – Tecnologia de interconexão de redes locais
Framememory model – Modelo de partição de memória
hosts – Computadores de uma rede
Internet Conglomerado de redes em escala mundial de milhões de
computadores interligados pelo Protocolo de Internet
Kilobit – Conjunto de 1024 bits
Kilobyte – Conjunto de 1024 bytes
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
112
Linguagem C Linguagem de programação
Linguagem Cobol Linguagem de programação
Linguagem PL/I – Linguagem de programação
Link – Entidade física que interliga os hosts de uma rede
Linux Red Hat com o Kernel – Distribuição do GNU/Linux com o núcleo do
sistema
Megabit – Conjunto de 1024 kilobits
Megabyte – Conjunto de 1024 kilobytes
Overhead – Custo adicionar de processamento ou armazenamento
Queries – Consultas
Switches – Comutador ou dispositivo para reencaminhar quadros em uma
rede de computadores
Triggers – Recurso de programação sempre que um evento associado
ocorrer
Tupla – Elemento formado por um conjunto de objetos e que pode ser
acessado por um índice
Unifying model – Modelo unificado
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICES
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE APÊNDICES
APÊNDICE A – Criação das bases de dados......................................................115
APÊNDICE B – Instalação e configuração dos programas..................................116
APÊNDICE C – Código fonte do trigger com dblink.............................................119
APÊNDICE D – Configurações para uso do PgCluster no cenário 1...................123
APÊNDICE E – Configurações para uso do SlonyI.............................................126
APÊNDICE F – Configuração da largura de banda do cenário 2.........................130
APÊNDICE G – Configurações para uso do PgCluster no cenário 2..................139
APÊNDICE H – Script de leitura e escrita de dados para simulação dos clientes
...............................................................................................................................145
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE A – Criação das bases de dados
As bases de dados e a linguagem procedural foram criadas
respectivamente através dos comandos:
1 /usr/local/pgsql8.2.6/bin/createdb dbteste Upostgres E LATIN12 /usr/local/pgsql8.2.6/bin/createlang plpgsql dbteste Upostgres
Inicialmente todas as bases de dados foram inicializadas com a seguinte
estrutura:
1 create sequence seq_codigo_pessoas;2 create table pessoas ( codigo integer not null primary key default
nextval('seq_codigo_pessoas'), nome text not null );
Para acessar a base de dados dbteste para digitar os comandos acima,
podese usar o comando:
1 /usr/local/pgsql8.2.6/bin/psql dbteste Upostgres
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE B – Instalação e configuração dos programas
A instalação dos servidores de banco de dados e das ferramentas foi feita
em computadores rodando o sistema operacional GNU/Linux. Na seqüência está
descrito como os pacotes foram instalados. Todos os pacotes foram previamente
baixados para o diretório /usr/local/src.
Instalação e inicialização do SGBD PostgreSQL:
1 cd /usr/local/src2 tar zxvf postgresql8.2.6.tar.gz3 cd postgresql8.2.64 ./configure prefix=/usr/local/pgsql8.2.6 withtcl enablenls
withopenssl5 make6 make install7 useradd postgres8 mkdir /usr/local/pgsql8.2.6/data9 chown postgres /usr/local/pgsql8.2.6/data10 export LANG=pt_BR11 export LC_ALL=pt_BR12 su postgres c '/usr/local/pgsql8.2.6/bin/initdb D
/usr/local/pgsql8.2.6/data E LATIN1'13 su postgres c '/usr/local/pgsql8.2.6/bin/postmaster i D
/usr/local/pgsql8.2.6/data' //inicializar o SGBD
Além disso, é seja necessário configurar o
arquivo /usr/local/pgsql8.2.6/data/pg_hba.conf habilitando o acesso dos demais
servidores.
Instalação do DBLink:
1 cd /usr/local/src/postgresql8.2.6/contrib/dblink/2 make3 make install4 /usr/local/pgsql8.2.6/bin/psql template1 Upostgres < dblink.sql5 /usr/local/pgsql8.2.6/bin/createlang plpgsql template1 Upostgres;
Instalação e inicialização do PgCluster:
1 cd /usr/local/src/2 tar zxvf pgcluster1.7.0rc12.tar.gz3 cd pgcluster1.7.0rc124 ./configure prefix=/usr/local/pgcluster1.7.0rc125 make all6 make install7 useradd postgres8 mkdir /usr/local/pgcluster1.7.0rc12/data9 mkdir /usr/local/pgcluster1.7.0rc12/etc10 chown postgres /usr/local/pgcluster1.7.0rc12/data
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
117
11 chown postgres /usr/local/pgcluster1.7.0rc12/etc12 export LANG=pt_BR13 export LC_ALL=pt_BR14 su postgres c '/usr/local/pgcluster1.7.0rc12/bin/initdb D /usr/local/
pgcluster1.7.0rc12/data E LATIN1'15 su postgres c ' /usr/local/pgcluster1.7.0rc12/bin/pg_ctl D
/usr/local/pgcluster1.7.0rc12/data o "i" start' //inicializar os servidores de banco de dados
16 su postgres c '/usr/local/pgcluster1.7.0rc12/bin/pgreplicate D /usr/local/pgcluster1.7.0rc12/etc' //inicializar os servidores replicadores de banco de dados (somente masters)
17 su postgres c '/usr/local/pgcluster1.7.0rc12/bin/pglb D /usr/local/pgcluster1.7.0rc12/etc' //inicializar os servidores de balanceamento de carga dos bancos de dados (somente masters)
Instalação e inicialização do SlonyI:
1 cd /usr/local/src/2 tar jxvf slony11.2.13.tar.bz23 cd slony11.2.134 ./configure prefix=/usr/local/slony11.2.13 –with
pgconfigdir=/usr/local/pgsql8.2.6/bin5 gmake all6 gmake install7 ln s /usr/local/pgsql8.2.6/share /usr/local/slony11.2.13
Instalação do PHP para linha de comando com suporte a PostgreSQL:
1 cd /usr/local/src/2 tar zxvf php5.2.5.tar.gz3 cd php5.2.54 ./configure prefix=/usr/local/php5.2.5 disableall with
pgsql=/usr/local/pgsql8.2.65 make6 make install
Para instalação do CBQ é necessário que os servidores tenham kernel
2.4.7 ou mais recente e que tenham o pacote iproute2 instalado. Para o kernel, é
necessário ter ativado as opções relativas a QOS / CBQ e NETFILTER /
IPTABLES.
Para instalação do CBQ, é utilizado o pacote cbqinit que pode ser baixado
pelo site http://www.sourceforge.net Abaixo seguem os comandos de instalação e
inicialização do mesmo.
1 mkdir /etc/cbq2 cd /etc/cbq3 cp /usr/local/src/cbq.initv0.7.3 /sbin/cbq4 chmod +x /sbin/cbq5 touch /etc/cbq/cbq00026 cbq stop7 cbq compile8 cbq start
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
118
Instalação do Wireshark para campturar os pacotes a PostgreSQL:
1 cd /usr/local/src/2 tar zxvf wireshark1.0.0.tar.gz3 cd wireshark1.0.04 ./configure prefix=/usr/local/wireshark1.0.05 make6 make install
Para capturar o tráfego da replicação, podese adicionar o filtro de pacotes
ao Wireshark:
host 10.3.17.13 or host 10.3.17.14
Para tornar transparente a parte de endereços de IPs dos computadores,
convém adicionar no arquivo /etc/hosts dos computadores as linhas abaixo:
10.3.17.12 servidor110.3.17.13 servidor210.3.17.14 servidor310.3.17.17 cliente110.3.17.18 cliente210.3.17.19 cliente310.3.17.20 cliente410.3.17.21 cliente510.3.17.22 cliente610.3.17.23 cliente710.3.17.24 cliente810.3.17.25 cliente910.3.17.26 cliente1010.3.17.27 cliente1110.3.17.28 cliente1210.3.17.29 cliente1310.3.17.30 cliente1410.3.17.31 cliente1510.3.17.32 cliente1610.3.17.33 cliente1710.3.17.34 cliente1810.3.17.35 cliente1910.3.17.36 cliente20
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE C – Código fonte do trigger com dblink
Abaixo segue o código fonte do trigger com dblink que foi desenvolvido
para a replicação via trigger e dblink.
1 CREATE OR REPLACE FUNCTION atualiza_servidores()2 RETURNS TRIGGER AS $atualiza_servidores$34 DECLARE56 servidor2 VARCHAR;7 servidor3 VARCHAR;8 errorMsg2 VARCHAR;9 errorMsg3 VARCHAR;10 conections TEXT[];1112 BEGIN1314 servidor2 := 'dbname=dbteste hostaddr=10.3.17.13 user=postgres
password=postgres port=5432';15 PERFORM dblink_connect('conn2', servidor2);16 PERFORM dblink_exec('conn2','BEGIN;', true);1718 servidor3 := 'dbname=dbteste hostaddr=10.3.17.14 user=postgres
password=postgres port=5432';19 PERFORM dblink_connect('conn3', servidor3);20 PERFORM dblink_exec('conn3','BEGIN;', true);2122 IF TG_OP = 'INSERT' THEN2324 PERFORM dblink_exec('conn2','INSERT INTO pessoas ( codigo,
nome )25 VALUES (' || NEW.codigo || ',''' ||
NEW.nome || ''');', true);2627 PERFORM dblink_exec('conn3','INSERT INTO pessoas ( codigo,
nome )28 VALUES (' || NEW.codigo || ',''' ||
NEW.nome || ''');', true);2930 SELECT * FROM dblink_error_message('conn2') INTO errorMsg2;31 SELECT * FROM dblink_error_message('conn3') INTO errorMsg3;3233 IF POSITION('ERROR' IN errorMsg2) > 0 OR POSITION('WARNING' IN
errorMsg2) > 0 OR POSITION('ERROR' IN errorMsg3) > 0 OR POSITION('WARNING' IN errorMsg3) > 0 THEN
3435 PERFORM dblink_exec('conn2','ROLLBACK;', true);36 PERFORM dblink_disconnect('conn2');3738 PERFORM dblink_exec('conn3','ROLLBACK;', true);39 PERFORM dblink_disconnect('conn3');4041 RAISE EXCEPTION '%', errorMsg;4243 ELSE4445 PERFORM dblink_exec('conn2','COMMIT', true);46 PERFORM dblink_disconnect('conn2');4748 PERFORM dblink_exec('conn3','COMMIT', true);
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
120
49 PERFORM dblink_disconnect('conn3');5051 END IF;5253 RETURN NEW;5455 END IF;5657 IF TG_OP = 'UPDATE' THEN5859 PERFORM dblink_exec('conn2','UPDATE pessoas SET codigo = ' ||
NEW.codigo || ',' ||60 'nome = ''' || NEW.nome || '''
WHERE codigo = ' || OLD.codigo || ';', true);6162 PERFORM dblink_exec('conn3','UPDATE pessoas SET codigo = ' ||
NEW.codigo || ',' ||63 'nome = ''' || NEW.nome || '''
WHERE codigo = ' || OLD.codigo || ';', true);6465 SELECT * FROM dblink_error_message('conn2') INTO errorMsg2;66 SELECT * FROM dblink_error_message('conn3') INTO errorMsg3;6768 IF POSITION('ERROR' IN errorMsg2) > 0 OR POSITION('WARNING' IN
errorMsg2) > 0 OR POSITION('ERROR' IN errorMsg3) > 0 OR POSITION('WARNING' IN errorMsg3) > 0 THEN
6970 PERFORM dblink_exec('conn2','ROLLBACK;', true);71 PERFORM dblink_disconnect('conn2');7273 PERFORM dblink_exec('conn3','ROLLBACK;', true);74 PERFORM dblink_disconnect('conn3');7576 RAISE EXCEPTION '%', errorMsg;7778 ELSE7980 PERFORM dblink_exec('conn2','COMMIT', true);81 PERFORM dblink_disconnect('conn2');8283 PERFORM dblink_exec('conn3','COMMIT', true);84 PERFORM dblink_disconnect('conn3');8586 END IF;8788 RETURN NEW;8990 END IF;9192 IF TG_OP = 'DELETE' THEN9394 PERFORM dblink_exec('conn2','DELETE FROM pessoas WHERE codigo =
' || OLD.codigo || ';', true);95 PERFORM dblink_exec('conn3','DELETE FROM pessoas WHERE codigo =
' || OLD.codigo || ';', true);9697 SELECT * FROM dblink_error_message('conn2') INTO errorMsg2;98 SELECT * FROM dblink_error_message('conn3') INTO errorMsg3;99100 IF POSITION('ERROR' IN errorMsg2) > 0 OR POSITION('WARNING' IN
errorMsg2) > 0 OR POSITION('ERROR' IN errorMsg3) > 0 OR POSITION('WARNING' IN errorMsg3) > 0 THEN
101102 PERFORM dblink_exec('conn2','ROLLBACK;', true);103 PERFORM dblink_disconnect('conn2');104105 PERFORM dblink_exec('conn3','ROLLBACK;', true);106 PERFORM dblink_disconnect('conn3');107
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
121
108 RAISE EXCEPTION '%', errorMsg;109110 ELSE111112 PERFORM dblink_exec('conn2','COMMIT', true);113 PERFORM dblink_disconnect('conn2');114115 PERFORM dblink_exec('conn3','COMMIT', true);116 PERFORM dblink_disconnect('conn3');117118 END IF;119120 RETURN OLD;121122 END IF;123124 EXCEPTION125126 WHEN others THEN127128 SELECT dblink_get_connections() INTO conections;129 IF 'conn2' = ANY (conections) THEN130 PERFORM dblink_disconnect('conn2');131 END IF;132133 SELECT dblink_get_connections() INTO conections;134 IF 'conn3' = ANY (conections) THEN135 PERFORM dblink_disconnect('conn3');136 END IF;137138 RAISE EXCEPTION'(%)', sqlerrm;139140 END;141 $atualiza_servidores$ LANGUAGE plpgsql;142143 CREATE TRIGGER atualiza_servidores144 BEFORE INSERT OR UPDATE OR DELETE ON pessoas145 FOR EACH ROW EXECUTE PROCEDURE atualiza_servidores();
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE D – Configurações para uso do PgCluster no cenário 1
Neste apêndice é descrito um modelo de configuração do PgCluster
levando em consideração que o mesmo irá replicar do servidor1 para o servidor2.
Devese configurar o arquivo de /etc/hosts com os endereços dos
servidores em cada um dos servidores.
10.3.17.12 servidor110.3.17.13 servidor210.3.17.14 servidor3
Configurar o arquivo que identifica o servidor que obtem a réplica e o
replicador, em cada um dos servidores. O arquivo que fica em
/usr/local/pgcluster1.7.0rc12/data/cluster.conf. Abaixo o exemplo do mesmo.
1 <Replicate_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 8001 </Port>4 <Recovery_Port> 8101 </Recovery_Port>5 </Replicate_Server_Info>67 <Replicate_Server_Info>8 <Host_Name> servidor2 </Host_Name>9 <Port> 8002 </Port>10 <Recovery_Port> 8102 </Recovery_Port>11 </Replicate_Server_Info>1213 <Replicate_Server_Info>14 <Host_Name> servidor3 </Host_Name>15 <Port> 8003 </Port>16 <Recovery_Port> 8103 </Recovery_Port>17 </Replicate_Server_Info>1819 <Host_Name> servidor1 </Host_Name>20 <Recovery_Port> 7001 </Recovery_Port>21 <Rsync_Path> /usr/bin/rsync </Rsync_Path>22 <Rsync_Option> ssh 1 </Rsync_Option>23 <Rsync_Compress> yes </Rsync_Compress>24 <Pg_Dump_Path> /usr/local/pgcluster1.7.0rc12/bin/pg_dump
</Pg_Dump_Path>25 <When_Stand_Alone> read_only </When_Stand_Alone>26 <Replication_Timeout> 1min </Replication_Timeout>27 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>28 <LifeCheck_Interval> 11s </LifeCheck_Interval>
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
123
Configurar o arquivo /usr/local/pgcluster1.7.0rc12/etc/pgreplicate.conf do
servidor master com o código relativo as configurações de replicações
1 <Cluster_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 5432 </Port>4 <Recovery_Port> 7001 </Recovery_Port>5 </Cluster_Server_Info>67 <Cluster_Server_Info>8 <Host_Name> servidor2 </Host_Name>9 <Port> 5432 </Port>10 <Recovery_Port> 7001 </Recovery_Port>11 </Cluster_Server_Info>1213 <Cluster_Server_Info>14 <Host_Name> servidor3 </Host_Name>15 <Port> 5432 </Port>16 <Recovery_Port> 7001 </Recovery_Port>17 </Cluster_Server_Info>1819 <LoadBalance_Server_Info>20 <Host_Name> servidor1 </Host_Name>21 <Recovery_Port> 6101 </Recovery_Port>22 </LoadBalance_Server_Info>2324 <Host_Name> servidor1 </Host_Name>25 <Replication_Port> 8001 </Replication_Port>26 <Recovery_Port> 8101 </Recovery_Port>27 <RLOG_Port> 8301 </RLOG_Port>28 <Response_Mode> normal </Response_Mode>29 <Use_Replication_Log> no </Use_Replication_Log>30 <Replication_Timeout> 1min </Replication_Timeout>31 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>32 <LifeCheck_Interval> 15s </LifeCheck_Interval>33 <Log_File_Info>34 <File_Name> /var/log/postgresql/pgreplicate.log </File_Name>35 <File_Size> 1M </File_Size>36 <Rotate> 3 </Rotate>37 </Log_File_Info>
Configurar o arquivo /usr/local/pgcluster1.7.0rc12/etc/pglb.conf do servidor
master com o código relativo ao balanceamento de carga dos servidores.
1 <Cluster_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 5432 </Port>4 <Max_Connect> 30 </Max_Connect> 5 </Cluster_Server_Info>67 <Cluster_Server_Info>8 <Host_Name> servidor2 </Host_Name>9 <Port> 5432 </Port>10 <Max_Connect> 30 </Max_Connect> 11 </Cluster_Server_Info>1213 <Cluster_Server_Info>14 <Host_Name> servidor3 </Host_Name>15 <Port> 5432 </Port>16 <Max_Connect> 30 </Max_Connect> 17 </Cluster_Server_Info>18
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
124
19 <Host_Name> servidor1 </Host_Name>20 <Backend_Socket_Dir> /tmp </Backend_Socket_Dir>21 <Receive_Port> 5433 </Receive_Port>22 <Recovery_Port> 6101 </Recovery_Port>23 <Max_Cluster_Num> 128 </Max_Cluster_Num>24 <Use_Connection_Pooling> no </Use_Connection_Pooling>25 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>26 <LifeCheck_Interval> 15s </LifeCheck_Interval>2728 <Log_File_Info>29 <File_Name> /var/log/postgresql/pglb.log </File_Name>30 <File_Size> 1M </File_Size>31 <Rotate> 3 </Rotate>32 </Log_File_Info>
Além disso, é necessário configurar o arquivo /usr/local/pgcluster1.7.0rc12/
data/pg_hba.conf habilitando o acesso dos demais servidores e clientes.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE E – Configurações para uso do SlonyI
Neste apêndice é descrito um modelo de configuração do SlonyI levando
em consideração que o mesmo irá replicar do servidor1 para o servidor2.
Antes de configurar este programa é necessário certificarse de que o
PostgreSQL está com as seguintes configurações:
● O arquivo pg_hba.conf deve ter o IP de todos os computadores que
farão acesso ao mesmo;
● O arquivo postgresql.conf deve ter a opção tcpip_socket definida
com a opção true;
● A base de dados já deve estar instalada nos servidores juntamente
com a linguagem plpgsql.
Configurar o arquivo /usr/local/pgsql8.2.6/etc/pg_service.conf com as
informações de conexão entre os computadores servidores.
1 [servidor1]2 dbname=dbteste3 host=10.3.17.124 user=postgres5 [servidor2]6 dbname=dbteste7 host=10.3.17.138 user=postgres9 [servidor3]10 dbname=dbteste11 host=10.3.17.1412 user=postgres
Configurar o arquivo /usr/local/slony11.2.3/preamble.sk que é o
arquivo que vai possibilitar o slonik se conectar nos hosts e a construir toda
a estrutura de replicação necessária.
1 define CLUSTER teste;2 define servidor1 1;3 define servidor2 2;4 define servidor3 3;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
126
5 define fqn fully qualified name;67 cluster name = @CLUSTER;8 node @servidor1 admin conninfo='service=servidor1';9 node @servidor2 admin conninfo='service=servidor2';10 node @servidor3 admin conninfo='service=servidor3';
Configurar o arquivo /usr/local/slony11.2.13/initcluster.sk com os nós
escravos e mestres.
1 #!/usr/local/slony11.2.13/bin/slonik2 include <preamble.sk>;34 ### Indica quem é o nó de origem da replicação5 init cluster(id=@servidor1, comment='no de origem');67 ### Indica quem são os nós escravos8 store node(id=@servidor2, comment='no escravo servidor2');9 store node(id=@servidor3, comment='no escravo servidor3');1011 Configurar o arquivo /usr/local/slony11.2.13/path.sk com a configuração
de comunicação entre os nós.12 #!/usr/local/slony11.2.13/bin/slonik13 include <preamble.sk>;1415 store path(server = @servidor1, client = @servidor2,
conninfo='service=servidor1');16 store path(server = @servidor1, client = @servidor3,
conninfo='service=servidor1');17 store path(server = @servidor2, client = @servidor1,
conninfo='service=servidor2');18 store path(server = @servidor2, client = @servidor3,
conninfo='service=servidor2');19 store path(server = @servidor3, client = @servidor1,
conninfo='service=servidor3');20 store path(server = @servidor3, client = @servidor2,
conninfo='service=servidor3');
Configurar o arquivo /usr/local/slony11.2.13/sets.sk com a definição de
quais tabelas e seqüências deverão ser replicadas.
1 #!/usr/local/slony11.2.13/bin/slonik2 include <preamble.sk>;34 ### Criando o nosso SET!5 create set(id = 1, origin = @servidor1, comment='objetos replicados');67 ### Quais sequencias e tabelas devem ser replicadas.8 set add table(set id = 1, origin= @servidor1, id = 1, @fqn
='public.pessoas', comment='Tabela de pessoas');9 set add sequence(set id = 1, origin= @servidor1, id = 1, @fqn
='public.seq_codigo_pessoas');
Após essas configurações o SlonyI já pode inicializar a estrutura para o
controle das réplicas, para isso é importante que:
● Todos os servidores possuam o slonyI instalado;
● O arquivo pg_services deve estar no diretório
/usr/local/pgsql8.2.6/data de cada servidor.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
127
Para criar o esquema do replicador dessa base, devese executar os
comandos abaixo:
1 chmod 744 preamble.sk initcluster.sk path.sk sets.sk2 ./initcluster.sk3 ./path.sk4 ./set.sk
Nos três servidores devem ser criados os arquivos servidor1.slon,
servidor2.slon e servidor3.slon no servidor1, servidor2 e servidor3,
respectivamente. O arquivo servidor1.slon deve conter as linhas de código:
1 cluster_name = 'teste'2 conn_info='service=servidor1'
O arquivo servidor2.slon deve conter as linhas de código:
1 cluster_name = 'teste'2 conn_info='service=servidor2'
O arquivo servidor3.slon deve conter as linhas de código:
1 cluster_name = 'teste'2 conn_info='service=servidor3'
Ainda devese configurar o arquivo /usr/local/slony11.2.13/subscribe.sk
para definir a topologia do cluster :
1 #!/usr/local/slony11.2.13/bin/slonik2 include <preamble.sk>;34 subscribe
set(id=1,provider=@servidor1,receiver=@servidor2,forward=TRUE);5 subscribe
set(id=1,provider=@servidor1,receiver=@servidor3,forward=TRUE);
Por fim, devese dar as permissões e executar o arquivo abaixo:
1 chmod 700 subscribe.sk2 ./subscribe.sk
Para inicializar o processo de replicação devese executar os comandos
abaixo nos respectivos servidores:
1 slon f servidor3.slon2 slon f servidor2.slon3 slon f servidor1.slon
É possível configurar o servidor 1 para replicar os dados a cada n
segundos. Para isso, basta configurar a execução do comando slon f
servidor1.slon na crontab do servidor master.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE F – Configuração da largura de banda do cenário 2
O arquivo /sbin/cbq é um script responsável por executar as regras
definidas no arquivo /etc/cbq/cbq0002. Esse script deve ser editado para definir o
caminho correto dos arquivos das regras. O parâmetro que deve ser definido é o
CBQ_PATH que deve receber o conteúdo “/etc/cbq”. O arquivo com as regras
deve ser editado e receber o seguinte conteúdo abaixo
1 DEVICE=eth0,100Mbit,10Mbit #"nome da interface que vai para o cliente","banda","banda/10"
2 RATE=1024Kbit #"velocidade"3 WEIGHT=102Kbit #"velocidade/10"4 PRIO=5 #"prioridade (5 é um valor excelente)"5 RULE=172.16.0.1/24 #"ip ou rede a ser controlado" 6 BOUNDED=yes #”yes/no se setado para yes o usuário estará limitado mesmo
que o link esteja com folga.“7 ISOLATED=yes #”yes/no se setado para yes indica que o cliente não poderá
emprestar banda pra ninguém.”
O conteúdo do arquivo cbq.ini é o seguinte:
1 #!/bin/bash2 #3 # cbq.init v0.7.34 # Copyright (C) 1999 Pavel Golubev <pg@ksilinux.com>5 # Copyright (C) 20012004 Lubomir Bulej <[email protected]>6 #7 # chkconfig: 2345 11 898 # description: sets up CBQbased traffic control9 #10 # This program is free software; you can redistribute it and/or
modify11 # it under the terms of the GNU General Public License as published
by12 # the Free Software Foundation; either version 2 of the License, or13 # (at your option) any later version.14 #15 # This program is distributed in the hope that it will be useful,16 # but WITHOUT ANY WARRANTY; without even the implied warranty of17 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the18 # GNU General Public License for more details.19 #20 # You should have received a copy of the GNU General Public License21 # along with this program; if not, write to the Free Software22 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
021111307 USA23 #24 # To get the latest version, check on Freshmeat for actual location:25 #26 # http://freshmeat.net/projects/cbq.init27 #28 #29 export LC_ALL=C3031 ### Command locations32 TC=/sbin/tc
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
129
33 IP=/sbin/ip34 MP=/sbin/modprobe3536 ### Default filter priorities (must be different)37 PRIO_RULE_DEFAULT=${PRIO_RULE:100}38 PRIO_MARK_DEFAULT=${PRIO_MARK:200}39 PRIO_REALM_DEFAULT=${PRIO_REALM:300}4041 ### Default CBQ_PATH & CBQ_CACHE settings42 #CBQ_PATH=${CBQ_PATH:/etc/sysconfig/cbq}43 CBQ_PATH="/etc/cbq"44 CBQ_CACHE=${CBQ_CACHE:/var/cache/cbq.init}4546 ### Uncomment to enable logfile for debugging47 #CBQ_DEBUG="/var/run/cbq$1"4849 ### Modules to probe for. Uncomment the last CBQ_PROBE50 ### line if you have QoS support compiled into kernel51 CBQ_PROBE="sch_cbq sch_tbf sch_sfq sch_prio"52 CBQ_PROBE="$CBQ_PROBE cls_fw cls_u32 cls_route"53 #CBQ_PROBE=""5455 ### Keywords required for qdisc & class configuration56 CBQ_WORDS="DEVICE|RATE|WEIGHT|PRIO|PARENT|LEAF|BOUNDED|ISOLATED"57 CBQ_WORDS="$CBQ_WORDS|PRIO_MARK|PRIO_RULE|PRIO_REALM|BUFFER"58 CBQ_WORDS="$CBQ_WORDS|LIMIT|PEAK|MTU|QUANTUM|PERTURB"596061 ########################################################################
#####62 ############################# SUPPORT FUNCTIONS
#############################63 ########################################################################
#####6465 ### Get list of network devices66 cbq_device_list () {67 ip link show| sed n "/^[09]/ \68 { s/^[09]\+: \([az09._]\+\)[:@].*/\1/; p; }"69 } # cbq_device_list707172 ### Remove root class from device $173 cbq_device_off () {74 tc qdisc del dev $1 root 2> /dev/null75 } # cbq_device_off767778 ### Remove CBQ from all devices79 cbq_off () {80 for dev in `cbq_device_list`; do81 cbq_device_off $dev82 done83 } # cbq_off848586 ### Prefixed message87 cbq_message () {88 echo e "**CBQ: $@"89 } # cbq_message9091 ### Failure message92 cbq_failure () {93 cbq_message "$@"94 exit 195 } # cbq_failure9697 ### Failure w/ cbqoff98 cbq_fail_off () {
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
130
99 cbq_message "$@"100 cbq_off101 exit 1102 } # cbq_fail_off103104105 ### Convert time to absolute value106 cbq_time2abs () {107 local min=${1##*:}; min=${min##0}108 local hrs=${1%%:*}; hrs=${hrs##0}109 echo $[hrs*60 + min]110 } # cbq_time2abs111112113 ### Display CBQ setup114 cbq_show () {115 for dev in `cbq_device_list`; do116 [ `tc qdisc show dev $dev| wc l` eq 0 ] && continue117 echo e "### $dev: queueing disciplines\n"118 tc $1 qdisc show dev $dev; echo119120 [ `tc class show dev $dev| wc l` eq 0 ] && continue121 echo e "### $dev: traffic classes\n"122 tc $1 class show dev $dev; echo123124 [ `tc filter show dev $dev| wc l` eq 0 ] && continue125 echo e "### $dev: filtering rules\n"126 tc $1 filter show dev $dev; echo127 done128 } # cbq_show129130131 ### Check configuration and load DEVICES, DEVFIELDS and CLASSLIST from
$1132 cbq_init () {133 ### Get a list of configured classes134 CLASSLIST=`find $1 \( type f or type l \) name 'cbq*' \135 not name '*~' maxdepth 1 printf "%f\n"| sort`136 [ z "$CLASSLIST" ] &&137 cbq_failure "no configuration files found in $1!"138139 ### Gather all DEVICE fields from $1/cbq*140 DEVFIELDS=`find $1 \( type f or type l \) name 'cbq*' \141 not name '*~' maxdepth 1| xargs sed n 's/#.*//; \142 s/[[:space:]]//g; /^DEVICE=[^,]*,[^,]*\(,[^,]*\)\?/ \143 { s/.*=//; p; }'| sort u`144 [ z "$DEVFIELDS" ] &&145 cbq_failure "no DEVICE field found in $1/cbq*!"146147 ### Check for different DEVICE fields for the same device148 DEVICES=`echo "$DEVFIELDS"| sed 's/,.*//'| sort u`149 [ `echo "$DEVICES"| wc l` ne `echo "$DEVFIELDS"| wc l` ] &&150 cbq_failure "different DEVICE fields for single
device!\n$DEVFIELDS"151 } # cbq_init152153154 ### Load class configuration from $1/$2155 cbq_load_class () {156 CLASS=`echo $2| sed 's/^cbq0*//; s/^\([09afAF]\+\).*/\1/'`157 CFILE=`sed n 's/#.*//; s/[[:space:]]//g; /^[[:alnum:]_]\
+=[[:alnum:].,:;/*@_]\+$/ p' $1/$2`158159 ### Check class number160 IDVAL=`/usr/bin/printf "%d" 0x$CLASS 2> /dev/null`161 [ $? ne 0 o $IDVAL lt 2 o $IDVAL gt 65535 ] &&162 cbq_fail_off "class ID of $2 must be in range <0002
FFFF>!"163
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
131
164 ### Set defaults & load class165 RATE=""; WEIGHT=""; PARENT=""; PRIO=5166 LEAF=tbf; BOUNDED=yes; ISOLATED=no167 BUFFER=10Kb/8; LIMIT=15Kb; MTU=1500168 PEAK=""; PERTURB=10; QUANTUM=""169170 PRIO_RULE=$PRIO_RULE_DEFAULT171 PRIO_MARK=$PRIO_MARK_DEFAULT172 PRIO_REALM=$PRIO_REALM_DEFAULT173174 eval `echo "$CFILE"| grep E "^($CBQ_WORDS)="`175176 ### Require RATE/WEIGHT177 [ z "$RATE" o z "$WEIGHT" ] &&178 cbq_fail_off "missing RATE or WEIGHT in $2!"179180 ### Class device181 DEVICE=${DEVICE%%,*}182 [ z "$DEVICE" ] && cbq_fail_off "missing DEVICE field in $2!"183184 BANDWIDTH=`echo "$DEVFIELDS"| sed n "/^$DEVICE,/ \185 { s/[^,]*,\([^,]*\).*/\1/; p; q; }"`186187 ### Convert to "tc" options188 PEAK=${PEAK:+peakrate $PEAK}189 PERTURB=${PERTURB:+perturb $PERTURB}190 QUANTUM=${QUANTUM:+quantum $QUANTUM}191192 [ "$BOUNDED" = "no" ] && BOUNDED="" || BOUNDED="bounded"193 [ "$ISOLATED" = "yes" ] && ISOLATED="isolated" || ISOLATED=""194 } # cbq_load_class195196197 ########################################################################
#####198 #################################### INIT
###################################199 ########################################################################
#####200201 ### Check for presence of iproute2 in usual place202 [ x $TC a x $IP ] ||203 cbq_failure "iproute2 utilities not installed or executable!"204205206 ### ip/tc wrappers207 if [ "$1" = "compile" ]; then208 ### no module probing209 CBQ_PROBE=""210211 ip () {212 $IP "$@"213 } # ip214215 ### echoonly version of "tc" command216 tc () {217 echo "$TC $@"218 } # tc219220 elif [ n "$CBQ_DEBUG" ]; then221 echo e "# `date`" > $CBQ_DEBUG222223 ### Logging version of "ip" command224 ip () {225 echo e "\n# ip $@" >> $CBQ_DEBUG226 $IP "$@" 2>&1 | tee a $CBQ_DEBUG227 } # ip228229 ### Logging version of "tc" command
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
132
230 tc () {231 echo e "\n# tc $@" >> $CBQ_DEBUG232 $TC "$@" 2>&1 | tee a $CBQ_DEBUG233 } # tc234 else235 ### Default wrappers236237 ip () {238 $IP "$@"239 } # ip240241 tc () {242 $TC "$@"243 } # tc244 fi # ip/tc wrappers245246247 case "$1" in248249 ########################################################################
#####250 ############################### START/COMPILE
###############################251 ########################################################################
#####252253 start|compile)254255 ### Probe QoS modules (start only)256 for module in $CBQ_PROBE; do257 $MP $module || cbq_failure "failed to load module $module"258 done259260 ### If we are in compile/nocache/logging mode, don't bother with cache261 if [ "$1" != "compile" a "$2" != "nocache" a z "$CBQ_DEBUG" ]; then262 VALID=1263264 ### validate the cache265 [ "$2" = "invalidate" o ! f $CBQ_CACHE ] && VALID=0266 if [ $VALID eq 1 ]; then267 [ `find $CBQ_PATH maxdepth 1 newer $CBQ_CACHE| \268 wc l` gt 0 ] && VALID=0269 fi270271 ### compile the config if the cache is invalid272 if [ $VALID ne 1 ]; then273 $0 compile > $CBQ_CACHE ||274 cbq_fail_off "failed to compile CBQ configuration!"275 fi276277 ### run the cached commands278 exec /bin/sh $CBQ_CACHE 2> /dev/null279 fi280281 ### Load DEVICES, DEVFIELDS and CLASSLIST282 cbq_init $CBQ_PATH283284285 ### Setup root qdisc on all configured devices286 for dev in $DEVICES; do287 ### Retrieve device bandwidth and, optionally, weight288 DEVTEMP=`echo "$DEVFIELDS"| sed n "/^$dev,/ { s/$dev,//; p;
q; }"`289 DEVBWDT=${DEVTEMP%%,*}; DEVWGHT=${DEVTEMP##*,}290 [ "$DEVBWDT" = "$DEVWGHT" ] && DEVWGHT=""291292 ### Device bandwidth is required293 if [ z "$DEVBWDT" ]; then294 cbq_message "could not determine bandwidth for device
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
133
$dev!"295 cbq_failure "please set up the DEVICE fields properly!"296 fi297298 ### Check if the device is there299 ip link show $dev &> /dev/null ||300 cbq_fail_off "device $dev not found!"301302 ### Remove old root qdisc from device303 cbq_device_off $dev304305306 ### Setup root qdisc + class for device307 tc qdisc add dev $dev root handle 1 cbq \308 bandwidth $DEVBWDT avpkt 1000 cell 8309310 ### Set weight of the root class if set311 [ n "$DEVWGHT" ] &&312 tc class change dev $dev root cbq weight $DEVWGHT allot
1514313314 [ "$1" = "compile" ] && echo315 done # dev316317318 ### Setup traffic classes319 for classfile in $CLASSLIST; do320 cbq_load_class $CBQ_PATH $classfile321322 ### Create the class323 tc class add dev $DEVICE parent 1:$PARENT classid 1:$CLASS cbq \324 bandwidth $BANDWIDTH rate $RATE weight $WEIGHT prio $PRIO \325 allot 1514 cell 8 maxburst 20 avpkt 1000 $BOUNDED $ISOLATED ||326 cbq_fail_off "failed to add class $CLASS with parent
$PARENT on $DEVICE!"327328 ### Create leaf qdisc if set329 if [ "$LEAF" = "tbf" ]; then330 tc qdisc add dev $DEVICE parent 1:$CLASS handle $CLASS tbf
\331 rate $RATE buffer $BUFFER limit $LIMIT mtu $MTU $PEAK332 elif [ "$LEAF" = "sfq" ]; then333 tc qdisc add dev $DEVICE parent 1:$CLASS handle $CLASS sfq
\334 $PERTURB $QUANTUM335 fi336337338 ### Create fw filter for MARK fields339 for mark in `echo "$CFILE"| sed n '/^MARK/ { s/.*=//; p; }'`; do340 ### Attach fw filter to root class341 tc filter add dev $DEVICE parent 1:0 protocol ip \342 prio $PRIO_MARK handle $mark fw classid 1:$CLASS343 done ### mark344345 ### Create route filter for REALM fields346 for realm in `echo "$CFILE"| sed n '/^REALM/ { s/.*=//; p; }'`;
do347 ### Split realm into source & destination realms348 SREALM=${realm%%,*}; DREALM=${realm##*,}349 [ "$SREALM" = "$DREALM" ] && SREALM=""350351 ### Convert asterisks to empty strings352 SREALM=${SREALM#\*}; DREALM=${DREALM#\*}353354 ### Attach route filter to the root class355 tc filter add dev $DEVICE parent 1:0 protocol ip \356 prio $PRIO_REALM route ${SREALM:+from $SREALM} \357 ${DREALM:+to $DREALM} classid 1:$CLASS
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
134
358 done ### realm359360 ### Create u32 filter for RULE fields361 for rule in `echo "$CFILE"| sed n '/^RULE/ { s/.*=//; p; }'`; do362 ### Split rule into source & destination363 SRC=${rule%%,*}; DST=${rule##*,}364 [ "$SRC" = "$rule" ] && SRC=""365366367 ### Split destination into address, port & mask fields368 DADDR=${DST%%:*}; DTEMP=${DST##*:}369 [ "$DADDR" = "$DST" ] && DTEMP=""370371 DPORT=${DTEMP%%/*}; DMASK=${DTEMP##*/}372 [ "$DPORT" = "$DTEMP" ] && DMASK="0xffff"373374375 ### Split up source (if specified)376 SADDR=""; SPORT=""377 if [ n "$SRC" ]; then378 SADDR=${SRC%%:*}; STEMP=${SRC##*:}379 [ "$SADDR" = "$SRC" ] && STEMP=""380381 SPORT=${STEMP%%/*}; SMASK=${STEMP##*/}382 [ "$SPORT" = "$STEMP" ] && SMASK="0xffff"383 fi384385386 ### Convert asterisks to empty strings387 SADDR=${SADDR#\*}; DADDR=${DADDR#\*}388389 ### Compose u32 filter rules390 u32_s="${SPORT:+match ip sport $SPORT $SMASK}"391 u32_s="${SADDR:+match ip src $SADDR} $u32_s"392 u32_d="${DPORT:+match ip dport $DPORT $DMASK}"393 u32_d="${DADDR:+match ip dst $DADDR} $u32_d"394395 ### Uncomment the following if you want to see parsed
rules396 #echo "$rule: $u32_s $u32_d"397398 ### Attach u32 filter to the appropriate class399 tc filter add dev $DEVICE parent 1:0 protocol ip \400 prio $PRIO_RULE u32 $u32_s $u32_d classid 1:$CLASS401 done ### rule402403 [ "$1" = "compile" ] && echo404 done ### classfile405 ;;406407408 ########################################################################
#####409 ################################# TIME CHECK
################################410 ########################################################################
#####411412 timecheck)413414 ### Get time + weekday415 TIME_TMP=`date +%w/%k:%M`416 TIME_DOW=${TIME_TMP%%/*}417 TIME_NOW=${TIME_TMP##*/}418419 ### Load DEVICES, DEVFIELDS and CLASSLIST420 cbq_init $CBQ_PATH421422 ### Run through all classes
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
135
423 for classfile in $CLASSLIST; do424 ### Gather all TIME rules from class config425 TIMESET=`sed n 's/#.*//; s/[[:space:]]//g; /^TIME/ { s/.*=//; p;
}' \426 $CBQ_PATH/$classfile`427 [ z "$TIMESET" ] && continue428429 MATCH=0; CHANGE=0430 for timerule in $TIMESET; do431 TIME_ABS=`cbq_time2abs $TIME_NOW`432433 ### Split TIME rule to pieces434 TIMESPEC=${timerule%%;*}; PARAMS=${timerule##*;}435 WEEKDAYS=${TIMESPEC%%/*}; INTERVAL=${TIMESPEC##*/}436 BEG_TIME=${INTERVAL%%*}; END_TIME=${INTERVAL##*}437438 ### Check the dayofweek (if present)439 [ "$WEEKDAYS" != "$INTERVAL" a \440 n "${WEEKDAYS##*$TIME_DOW*}" ] && continue441442 ### Compute interval boundaries443 BEG_ABS=`cbq_time2abs $BEG_TIME`444 END_ABS=`cbq_time2abs $END_TIME`445446 ### Midnight wrap fixup447 if [ $BEG_ABS gt $END_ABS ]; then448 [ $TIME_ABS le $END_ABS ] &&449 TIME_ABS=$[TIME_ABS + 24*60]450451 END_ABS=$[END_ABS + 24*60]452 fi453454 ### If the time matches, remember params and set MATCH
flag455 if [ $TIME_ABS ge $BEG_ABS a $TIME_ABS lt $END_ABS ];
then456 TMP_RATE=${PARAMS%%/*}; PARAMS=${PARAMS#*/}457 TMP_WGHT=${PARAMS%%/*}; TMP_PEAK=${PARAMS##*/}458459 [ "$TMP_PEAK" = "$TMP_WGHT" ] && TMP_PEAK=""460 TMP_PEAK=${TMP_PEAK:+peakrate $TMP_PEAK}461462 MATCH=1463 fi464 done ### timerule465466467 cbq_load_class $CBQ_PATH $classfile468469 ### Get current RATE of CBQ class470 RATE_NOW=`tc class show dev $DEVICE| sed n \471 "/cbq 1:$CLASS / { s/.*rate //; s/ .*//; p; q; }"`472 [ z "$RATE_NOW" ] && continue473474 ### Time interval matched475 if [ $MATCH ne 0 ]; then476477 ### Check if there is any change in class RATE478 if [ "$RATE_NOW" != "$TMP_RATE" ]; then479 NEW_RATE="$TMP_RATE"480 NEW_WGHT="$TMP_WGHT"481 NEW_PEAK="$TMP_PEAK"482 CHANGE=1483 fi484485 ### Match not found, reset to default RATE if necessary486 elif [ "$RATE_NOW" != "$RATE" ]; then487 NEW_WGHT="$WEIGHT"488 NEW_RATE="$RATE"
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
136
489 NEW_PEAK="$PEAK"490 CHANGE=1491 fi492493 ### If there are no changes, go for next class494 [ $CHANGE eq 0 ] && continue495496 ### Replace CBQ class497 tc class replace dev $DEVICE classid 1:$CLASS cbq \498 bandwidth $BANDWIDTH rate $NEW_RATE weight $NEW_WGHT prio $PRIO \499 allot 1514 cell 8 maxburst 20 avpkt 1000 $BOUNDED $ISOLATED500501 ### Replace leaf qdisc (if any)502 if [ "$LEAF" = "tbf" ]; then503 tc qdisc replace dev $DEVICE handle $CLASS tbf \504 rate $NEW_RATE buffer $BUFFER limit $LIMIT mtu $MTU
$NEW_PEAK505 fi506507 cbq_message "$TIME_NOW: class $CLASS on $DEVICE changed rate
($RATE_NOW > $NEW_RATE)"508 done ### class file509 ;;510511512 ########################################################################
#####513 ################################## THE REST
#################################514 ########################################################################
#####515516 stop)517 cbq_off518 ;;519520 list)521 cbq_show522 ;;523524 stats)525 cbq_show s526 ;;527528 restart)529 shift530 $0 stop531 $0 start "$@"532 ;;533534 *)535 echo "Usage: `basename $0` {start|compile|stop|restart|timecheck|
list|stats}"536 esac
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE G – Configurações para uso do PgCluster no cenário 2
Neste apêndice é descrito um modelo de configuração do PgCluster
levando em consideração que o mesmo irá replicar entre os 3.
Devese configurar o arquivo de /etc/hosts com os endereços em cada um
dos três servidores.
10.3.17.12 servidor110.3.17.13 servidor210.3.17.14 servidor3
O arquivo que indica quais servidores fazem parte do cluster e qual é o
servidor que irá replicar para os demais também deve ser configurado. Esse
arquivo que fica em /usr/local/pgcluster1.7.0rc12/data/cluster.conf.
Na seqüência segue o conteúdo do arquivo cluster.conf do servidor 1:
1 <Replicate_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 8001 </Port>4 <Recovery_Port> 8101 </Recovery_Port>5 </Replicate_Server_Info>6 <Replicate_Server_Info>7 <Host_Name> servidor2 </Host_Name>8 <Port> 8001 </Port>9 <Recovery_Port> 8101 </Recovery_Port>10 </Replicate_Server_Info>11 <Replicate_Server_Info>12 <Host_Name> servior3 </Host_Name>13 <Port> 8001 </Port>14 <Recovery_Port> 8101 </Recovery_Port>15 </Replicate_Server_Info>1617 <Host_Name> servidor1 </Host_Name>18 <Recovery_Port> 7001 </Recovery_Port>19 <Rsync_Path> /usr/bin/rsync </Rsync_Path>20 <Rsync_Option> ssh 1 </Rsync_Option>21 <Rsync_Compress> yes </Rsync_Compress>22 <Rsync_Timeout> 10min </Rsync_Timeout>23 <Rsync_Bwlimit> 0KB </Rsync_Bwlimit>24 <Pg_Dump_Path> /usr/local/pgcluster1.7.0rc12/bin/pg_dump
</Pg_Dump_Path>25 <Ping_Path> /bin/ping </Ping_Path>26 <When_Stand_Alone> read_only </When_Stand_Alone>27 <Replication_Timeout> 1min </Replication_Timeout>28 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>29 <LifeCheck_Interval> 11s </LifeCheck_Interval>
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
138
Na seqüência segue o conteúdo do arquivo cluster.conf do servidor 2:
1 <Replicate_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 8001 </Port>4 <Recovery_Port> 8101 </Recovery_Port>5 </Replicate_Server_Info>6 <Replicate_Server_Info>7 <Host_Name> servidor2 </Host_Name>8 <Port> 8001 </Port>9 <Recovery_Port> 8101 </Recovery_Port>10 </Replicate_Server_Info>11 <Replicate_Server_Info>12 <Host_Name> servior3 </Host_Name>13 <Port> 8001 </Port>14 <Recovery_Port> 8101 </Recovery_Port>15 </Replicate_Server_Info>1617 <Host_Name> servidor2 </Host_Name>18 <Recovery_Port> 7001 </Recovery_Port>19 <Rsync_Path> /usr/bin/rsync </Rsync_Path>20 <Rsync_Option> ssh 1 </Rsync_Option>21 <Rsync_Compress> yes </Rsync_Compress>22 <Rsync_Timeout> 10min </Rsync_Timeout>23 <Rsync_Bwlimit> 0KB </Rsync_Bwlimit>24 <Pg_Dump_Path> /usr/local/pgcluster1.7.0rc12/bin/pg_dump
</Pg_Dump_Path>25 <Ping_Path> /bin/ping </Ping_Path>26 <When_Stand_Alone> read_only </When_Stand_Alone>27 <Replication_Timeout> 1min </Replication_Timeout>28 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>29 <LifeCheck_Interval> 11s </LifeCheck_Interval>
Na seqüência segue o conteúdo do arquivo cluster.conf do servidor 3:
1 <Replicate_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 8001 </Port>4 <Recovery_Port> 8101 </Recovery_Port>5 </Replicate_Server_Info>6 <Replicate_Server_Info>7 <Host_Name> servidor2 </Host_Name>8 <Port> 8001 </Port>9 <Recovery_Port> 8101 </Recovery_Port>10 </Replicate_Server_Info>11 <Replicate_Server_Info>12 <Host_Name> servior3 </Host_Name>13 <Port> 8001 </Port>14 <Recovery_Port> 8101 </Recovery_Port>15 </Replicate_Server_Info>1617 <Host_Name> servidor3 </Host_Name>18 <Recovery_Port> 7001 </Recovery_Port>19 <Rsync_Path> /usr/bin/rsync </Rsync_Path>20 <Rsync_Option> ssh 1 </Rsync_Option>21 <Rsync_Compress> yes </Rsync_Compress>22 <Rsync_Timeout> 10min </Rsync_Timeout>23 <Rsync_Bwlimit> 0KB </Rsync_Bwlimit>24 <Pg_Dump_Path> /usr/local/pgcluster1.7.0rc12/bin/pg_dump
</Pg_Dump_Path>25 <Ping_Path> /bin/ping </Ping_Path>26 <When_Stand_Alone> read_only </When_Stand_Alone>27 <Replication_Timeout> 1min </Replication_Timeout>28 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>29 <LifeCheck_Interval> 11s </LifeCheck_Interval>
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
139
Após configurar esse arquivo nos três servidores anteriores, devese
configurar o arquivo /usr/local/pgcluster1.7.0rc12/etc/pgreplicate.conf novamente
dos três servidores. Este arquivo de configuração indica para quais a servidores o
replicador deste servidor fará a replicação.
Na seqüência segue o conteúdo deste arquivo no servidor 1:
1 <Cluster_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 5432 </Port>4 <Recovery_Port> 7001 </Recovery_Port>5 </Cluster_Server_Info>6 <Cluster_Server_Info>7 <Host_Name> servidor2 </Host_Name>8 <Port> 5432 </Port>9 <Recovery_Port> 7001 </Recovery_Port>10 </Cluster_Server_Info>11 <Cluster_Server_Info>12 <Host_Name> servidor3 </Host_Name>13 <Port> 5432 </Port>14 <Recovery_Port> 7001 </Recovery_Port>15 </Cluster_Server_Info>1617 <LoadBalance_Server_Info>18 <Host_Name> servidor1 </Host_Name>19 <Recovery_Port> 6101 </Recovery_Port>20 </LoadBalance_Server_Info>21 <LoadBalance_Server_Info>22 <Host_Name> servidor2 </Host_Name>23 <Recovery_Port> 6101 </Recovery_Port>24 </LoadBalance_Server_Info>25 <LoadBalance_Server_Info>26 <Host_Name> servidor3 </Host_Name>27 <Recovery_Port> 6101 </Recovery_Port>28 </LoadBalance_Server_Info>2930 <Host_Name> servidor1 </Host_Name>31 <Replication_Port> 8001 </Replication_Port>32 <Recovery_Port> 8101 </Recovery_Port>33 <RLOG_Port> 8301 </RLOG_Port>34 <Response_Mode> normal </Response_Mode>35 <Use_Replication_Log> no </Use_Replication_Log>36 <Replication_Timeout> 1min </Replication_Timeout>37 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>38 <LifeCheck_Interval> 15s </LifeCheck_Interval>3940 <Log_File_Info>41 <File_Name> /var/log/postgresql/pgreplicate.log </File_Name>42 <File_Size> 1M </File_Size>43 <Rotate> 3 </Rotate>44 </Log_File_Info>
Na seqüência segue o conteúdo deste arquivo no servidor 2:
1 <Cluster_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 5432 </Port>4 <Recovery_Port> 7001 </Recovery_Port>5 </Cluster_Server_Info>6 <Cluster_Server_Info>7 <Host_Name> servidor2 </Host_Name>8 <Port> 5432 </Port>
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
140
9 <Recovery_Port> 7001 </Recovery_Port>10 </Cluster_Server_Info>11 <Cluster_Server_Info>12 <Host_Name> servidor3 </Host_Name>13 <Port> 5432 </Port>14 <Recovery_Port> 7001 </Recovery_Port>15 </Cluster_Server_Info>1617 <LoadBalance_Server_Info>18 <Host_Name> servidor1 </Host_Name>19 <Recovery_Port> 6101 </Recovery_Port>20 </LoadBalance_Server_Info>21 <LoadBalance_Server_Info>22 <Host_Name> servidor2 </Host_Name>23 <Recovery_Port> 6101 </Recovery_Port>24 </LoadBalance_Server_Info>25 <LoadBalance_Server_Info>26 <Host_Name> servidor3 </Host_Name>27 <Recovery_Port> 6101 </Recovery_Port>28 </LoadBalance_Server_Info>2930 <Host_Name> servidor2 </Host_Name>31 <Replication_Port> 8001 </Replication_Port>32 <Recovery_Port> 8101 </Recovery_Port>33 <RLOG_Port> 8301 </RLOG_Port>34 <Response_Mode> normal </Response_Mode>35 <Use_Replication_Log> no </Use_Replication_Log>36 <Replication_Timeout> 1min </Replication_Timeout>37 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>38 <LifeCheck_Interval> 15s </LifeCheck_Interval>3940 <Log_File_Info>41 <File_Name> /var/log/postgresql/pgreplicate.log </File_Name>42 <File_Size> 1M </File_Size>43 <Rotate> 3 </Rotate>44 </Log_File_Info>
Na seqüência segue o conteúdo deste arquivo no servidor 3:
1 <Cluster_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 5432 </Port>4 <Recovery_Port> 7001 </Recovery_Port>5 </Cluster_Server_Info>6 <Cluster_Server_Info>7 <Host_Name> servidor2 </Host_Name>8 <Port> 5432 </Port>9 <Recovery_Port> 7001 </Recovery_Port>10 </Cluster_Server_Info>11 <Cluster_Server_Info> 12 <Host_Name> servidor3 </Host_Name>13 <Port> 5432 </Port>14 <Recovery_Port> 7001 </Recovery_Port>15 </Cluster_Server_Info>1617 <LoadBalance_Server_Info>18 <Host_Name> servidor1 </Host_Name>19 <Recovery_Port> 6101 </Recovery_Port>20 </LoadBalance_Server_Info>21 <LoadBalance_Server_Info>22 <Host_Name> servidor2 </Host_Name>23 <Recovery_Port> 6101 </Recovery_Port>24 </LoadBalance_Server_Info>25 <LoadBalance_Server_Info>26 <Host_Name> servidor3 </Host_Name>27 <Recovery_Port> 6101 </Recovery_Port>28 </LoadBalance_Server_Info>2930 <Host_Name> servidor3 </Host_Name>
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
141
31 <Replication_Port> 8001 </Replication_Port>32 <Recovery_Port> 8101 </Recovery_Port>33 <RLOG_Port> 8301 </RLOG_Port>34 <Response_Mode> normal </Response_Mode>35 <Use_Replication_Log> no </Use_Replication_Log>36 <Replication_Timeout> 1min </Replication_Timeout>37 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>38 <LifeCheck_Interval> 15s </LifeCheck_Interval>3940 <Log_File_Info>41 <File_Name> /var/log/postgresql/pgreplicate.log </File_Name>42 <File_Size> 1M </File_Size>43 <Rotate> 3 </Rotate>44 </Log_File_Info>
Em seguida devese configurar também nos três servidores o arquivo
/usr/local/pgcluster1.7.0rc12/etc/pglb.conf com o código relativo ao
balanceamento de carga dos servidores.
No servidor 1 o conteúdo do arquivo é:
1 <Cluster_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 5432 </Port>4 <Max_Connect> 30 </Max_Connect> 5 </Cluster_Server_Info>6 <Cluster_Server_Info>7 <Host_Name> servidor2 </Host_Name>8 <Port> 5432 </Port>9 <Max_Connect> 30 </Max_Connect> 10 </Cluster_Server_Info> 11 <Cluster_Server_Info>12 <Host_Name> servidor3 </Host_Name>13 <Port> 5432 </Port>14 <Max_Connect> 30 </Max_Connect> 15 </Cluster_Server_Info> 1617 <Host_Name> servidor1 </Host_Name>18 <Backend_Socket_Dir> /tmp </Backend_Socket_Dir>19 <Receive_Port> 5433 </Receive_Port>20 <Recovery_Port> 6101 </Recovery_Port>21 <Max_Cluster_Num> 128 </Max_Cluster_Num>22 <Use_Connection_Pooling> no </Use_Connection_Pooling>23 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>24 <LifeCheck_Interval> 15s </LifeCheck_Interval>2526 <Log_File_Info>27 <File_Name> /var/log/postgresql/pglb.log </File_Name>28 <File_Size> 1M </File_Size>29 <Rotate> 3 </Rotate>30 </Log_File_Info>
No servidor 2 o conteúdo do arquivo é:
1 <Cluster_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 5432 </Port>4 <Max_Connect> 30 </Max_Connect> 5 </Cluster_Server_Info>6 <Cluster_Server_Info>7 <Host_Name> servidor2 </Host_Name>8 <Port> 5432 </Port>9 <Max_Connect> 30 </Max_Connect> 10 </Cluster_Server_Info>
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
142
11 <Cluster_Server_Info>12 <Host_Name> servidor3 </Host_Name>13 <Port> 5432 </Port>14 <Max_Connect> 30 </Max_Connect> 15 </Cluster_Server_Info> 1617 <Host_Name> servidor2 </Host_Name>18 <Backend_Socket_Dir> /tmp </Backend_Socket_Dir>19 <Receive_Port> 5433 </Receive_Port>20 <Recovery_Port> 6101 </Recovery_Port>21 <Max_Cluster_Num> 128 </Max_Cluster_Num>22 <Use_Connection_Pooling> no </Use_Connection_Pooling>23 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>24 <LifeCheck_Interval> 15s </LifeCheck_Interval>2526 <Log_File_Info>27 <File_Name> /var/log/postgresql/pglb.log </File_Name>28 <File_Size> 1M </File_Size>29 <Rotate> 3 </Rotate>30 </Log_File_Info>
No servidor 3 o conteúdo do arquivo é:
1 <Cluster_Server_Info>2 <Host_Name> servidor1 </Host_Name>3 <Port> 5432 </Port>4 <Max_Connect> 30 </Max_Connect> 5 </Cluster_Server_Info>6 <Cluster_Server_Info>7 <Host_Name> servidor2 </Host_Name>8 <Port> 5432 </Port>9 <Max_Connect> 30 </Max_Connect> 10 </Cluster_Server_Info> 11 <Cluster_Server_Info>12 <Host_Name> servidor3 </Host_Name>13 <Port> 5432 </Port>14 <Max_Connect> 30 </Max_Connect> 15 </Cluster_Server_Info> 1617 <Host_Name> servidor3 </Host_Name>18 <Backend_Socket_Dir> /tmp </Backend_Socket_Dir>19 <Receive_Port> 5433 </Receive_Port>20 <Recovery_Port> 6101 </Recovery_Port>21 <Max_Cluster_Num> 128 </Max_Cluster_Num>22 <Use_Connection_Pooling> no </Use_Connection_Pooling>23 <LifeCheck_Timeout> 3s </LifeCheck_Timeout>24 <LifeCheck_Interval> 15s </LifeCheck_Interval>2526 <Log_File_Info>27 <File_Name> /var/log/postgresql/pglb.log </File_Name>28 <File_Size> 1M </File_Size>29 <Rotate> 3 </Rotate>30 </Log_File_Info>
Além disso, é necessário configurar o arquivo /usr/local/pgcluster1.7.0rc12/
data/pg_hba.conf de cada servidor habilitando o acesso dos demais servidores e
clientes aos mesmos.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE H – Script de leitura e escrita de dados para simulação dos clientes
O script de configuração de largura de banda dos servidores de banco de
dados é:
1 #!/usr/local/php5.2.5/bin/php2 <?php34 //definições para o banco de dados5 define(DB, 'dbteste');6 define(USER, 'postgres');7 define(PASS, 'postgres');8 define(PORT, '5432');9 define(HOST, '10.3.17.12');1011 /*12 * Classe para conexão, consulta e execução de comandos no banco de
dados13 */14 class Sql15 {1617 //atributo para guardar a conexão18 var $conn;1920 /*21 * Método construtor22 */23 function Sql()24 {25 }2627 /*28 * Método para abrir uma conexão29 */30 function Open()31 {32 $this>conn = pg_connect(' host = ' . HOST . 33 ' port = ' . PORT . 34 ' dbname = ' . DB . 35 ' user = ' . USER . 36 ' password = ' . PASS );37 if ( $this>conn )38 {39 return true;40 }41 else42 {43 return false;44 }45 }4647 /*48 * Método para fazer consultas49 */50 function Query($sql)51 {52 $result = pg_query($this>conn, $sql);53 if ( $result )
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
144
54 {55 $x = 0;56 while ( $l = pg_fetch_array($result) )57 {58 $y = 0;59 for ( $z=0; $z<count($l); $z+=2 )60 {61 $data[$x][$y] = $l[$y];62 $y++;63 }64 $x++;65 }66 }67 return $data;68 }6970 /*71 * Método para executar comandos72 */73 function Execute($sql)74 {75 if ( pg_exec($this>conn, $sql) )76 {77 return true;78 }79 else80 {81 return false;82 }83 }8485 /*86 * Método para fechar a conexão87 */88 function Close()89 {90 if ( pg_close($this>conn) )91 {92 return true;93 }94 else95 {96 return false;97 }98 }99 }100101 /*102 * Classe para gerar as operações de leitura e escrita na base de
dados103 */104 class Operation105 {106107 //atributo com os nomes a serem inseridos, atualizados ou excluídos108 var $nomes;109110 /*111 * Método construtor112 */113 function Operation()114 {115 $this>nomes = array ( 0 => 'Daniel',116 1 => 'Arquimedes',117 2 => 'Maglan',118 3 => 'Sereno',119 4 => 'Clarice',120 5 => 'Caroline',121 6 => 'Juliano',
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
145
122 7 => 'Samuel',123 8 => 'Angela',124 9 => 'Tatiane' );125 }126127 /*128 * Método para gerar um índice aleatório entre 0 e 9129 */130 function getRanIndex()131 {132 return rand(0, 9);133 }134135 /*136 * Método para gerar um comando de inserção na base de dados137 */138 function getInsert()139 {140 $sql = "INSERT INTO pessoas ( codigo, nome ) VALUES
( nextval('seq_codigo_pessoas'), '" . $this>nomes[$this>getRanIndex()] . "' );";
141 echo date('d/m/Y H:i:s ') . "$sql\n";142 return $sql;143 }144145 /*146 * Método para gerar um comando de atualização na base de dados147 */148 function getUpdate()149 {150 $sql = "UPDATE pessoas SET nome = '" . $this>nomes[$this
>getRanIndex()] . "' WHERE nome = '" . $this>nomes[$this>getRanIndex()] . "';";
151 echo date('d/m/Y H:i:s ') . "$sql\n";152 return $sql;153 }154155 /*156 * Método para gerar um comando de exclusão na base de dados157 */158 function getDelete()159 {160 $sql = "DELETE FROM pessoas WHERE nome = '" . $this>nomes[$this
>getRanIndex()] . "';";161 echo date('d/m/Y H:i:s ') . "$sql\n";162 return $sql;163 }164165 /*166 * Método para gerar um comando de seleção de dados na base de dados167 */168 function getSelect()169 {170 $sql = "SELECT codigo, nome FROM pessoas WHERE nome = '" . $this
>nomes[$this>getRanIndex()] . "';";171 echo date('d/m/Y H:i:s ') . "$sql\n";172 return $sql;173 }174 }175176 /*177 * Início do programa178 */179180 //sem tempo máximo de execução181 set_time_limit(0);182183 while ( true )184 {
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
146
185 //Instancia a classe do banco186 $DB = new Sql();187188 //Abre uma conexão com o banco189 if ( $res = $DB>Open() )190 {191 //Instancia a classe para gerar os comandos SQL192 $OP = new Operation();193194 //Sortei qual será o comando a ser executado. 195 //Os comandos de inserção tem 30% deSumário chance196 //Os comandos de atualização tem 20% de chance197 //Os comandos de exclusão tem 10% de chance198 //Os comandos de consulta tem 40% de chance199 $i = rand(0, 9);200201 switch ( $i )202 {203 //Insere dados no banco204 case 0:205 case 1:206 case 2:207 $res = $DB>Execute($OP>getInsert());208 break;209 //Atualiza dados no banco210 case 3:211 case 4:212 $res = $DB>Execute($OP>getUpdate());213 break;214 //Exclui dados no banco215 case 5:216 $res = $DB>Execute($OP>getDelete());217 break;218 //Consulta dados do banco219 case 6:220 case 7:221 case 8:222 case 9:223 $res = $DB>Query($OP>getSelect());224 break;225 }226227 //Fecha a conexão com o banco228 $res = $DB>Close();229 }230 231 //Aqui o comando de espera de 0 a 5 segundos com cálculos em
microsegundos232 // 5000000 microsegundos = 5 segundos (usleep = microsegundos e
sleep = segundos)233 $tempo = rand(0, 50);234 if ( $tempo != 0 )235 {236 echo sprintf("Esperando %.2f segundos...\n", $tempo/10);237 usleep($tempo * 100000);238 }239 }240241 ?>
