estudo de algoritmos e técnicas de replicação de banco de dados

ESTUDO DE ALGORITMOS E TÉCNICAS DE REPLICAÇÃO DE BANCO DE DADOS EM SOFTWARE LIVRE
Daniel Afonso Heisler
Lajeado, junho de 2008
CENTRO UNIVERSITÁRIO UNIVATES
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
Dedico este trabalho aos meus pais
que me deram a educação
para que eu conseguisse fazer
minhas escolhas com sabedoria.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
Quem quer fazer alguma coisa
encontra um meio.
Quem não quer fazer nada
encontra uma desculpa.
Roberto Shinyashiki
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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.
PALAVRAS­CHAVE: Banco de dados distribuídos. Replicação.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 single­master...............................56
FIGURA 7 ­ Exemplo do modelo de replicação multi­master.................................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 Slony­I............................................................70
FIGURA 11 ­ Exemplo de disposição dos computadores na rede do laboratório..74
8
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
FIGURA 12 ­ Definição da estrutura do cenário 1..................................................76
FIGURA 13 ­ Definição da estrutura do cenário 2..................................................77
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 10
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 Slony­I..............................................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 12
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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
14
SQL – Structured Query Language (Linguagem de Consulta Estruturada)
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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)
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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
17
2.3.3 Transparência e formas de distribuição.........................................................42
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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ão­hierá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 Single­master ou master­slave...................................................................55
2.4.2.2 Multi­master.................................................................................................56
2.4.3 Protocolo de controle de réplica....................................................................57
2.4.3.1 Primary­Copy Method ................................................................................57
2.4.3.2 Quorum­Consensus Method ......................................................................58
2.4.3.3 Available­Copies 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
18
3 FERRAMENTAS UTILIZADAS...........................................................................63
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
3.1 DBLink e triggers...............................................................................................64
3.2 PgCluster...........................................................................................................67
3.3 Slony­I...............................................................................................................70
4 AVALIAÇÃO DAS FERRAMENTAS..................................................................73
4.1 Cenários............................................................................................................73
4.1.1 Cenário 1 – master­slave...............................................................................75
4.1.2 Cenário 2 – multi­master................................................................................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 ­ master­slave................................................................................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 ­ master­slave............................................90
5.1.2 Cenário 2 ­ multi­master.................................................................................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 – multi­master............................................96
5.2 Replicação assíncrona......................................................................................97
5.2.1 Cenário 1 ­ master­slave................................................................................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
19
5.2.1.4 Acesso à base de dados por vinte clientes..............................................102
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
5.2.1.5 Conclusões sobre o cenário 1 ­ master­slave..........................................104
5.2.2 Cenário 2 ­ multi­master...............................................................................105
6 CONCLUSÃO....................................................................................................106
REFERÊNCIAS.....................................................................................................108
GLOSSÁRIO.........................................................................................................111
APÊNDICES.........................................................................................................113
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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).
21
Segundo Özsu (2001), a tecnologia de sistemas de bancos de dados BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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, especula­se 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êm­se 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 22
vários conceitos relacionados a SGDBs, sistemas distribuídos e replicação, BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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, classificando­as 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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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.
24
As subseções 2.3 e 2.4 detalham os conceitos de distribuição e replicação BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
25
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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, destacam­se o entidade­relacionamento 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 26
(unifying model) e o modelo de partição de memória (frame­memory model) BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
(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.
27
Existem dois tipos principais de restrições de integridade: restrições BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
estruturais e restrições comportamentais. As restrições estruturais expressam propriedades semânticas básicas inerentes a um modelo. Como exemplo, num modelo relacional, pode­se 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).
28
Silberschatz (1999), segue afirmando que devido ao grande número de BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 29
uma ou duas relações como operandos, produzindo uma nova relação resultante BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
(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, especifica­se 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).
30
Em álgebra relacional, as consultas são escritas sob forma de uma BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
seqüência de procedimentos. Já no cálculo relacional de tuplas é uma linguagem não­procedural. 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 deve­se 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 31
DML. Alguns autores chamam esses recursos de linguagem de controle de dados BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
(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.
32
O SQL foi revisto em 1992 e a esta versão foi dado o nome de SQL­92. Foi BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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ão­escalados 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 auto­generalização (inclusive colunas­identidade) (ISO/IEC 9075, 2006).
2.1.5 SGBDs em software livre
Atualmente existem diversos SGBDs, mas neste trabalho, optou­se 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, podendo­se 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 avaliou­se várias características técnicas dos mesmos.
Os seguintes SGBDs foram avaliados:
PostgreSQL: SGBDs objeto­relacional, de código aberto. Optou­se pela versão 8.2.6 disponível em http://www.postgresql.org.
Firebird: SGBDs relacional, de código aberto. Optou­se pela versão 2.0.3 disponível em http://www.firebirdsql.org
. 33
MySQL: SGBDs relacional, de código aberto. Optou­se pela versão 5.0.45 BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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
+
+
+
SQL­92
+
*
+
SQL:1999
+
*
*
SQL:2003
*
*
*
Funções de linguagens
+
*
*
Esquemas
+
­
­
Expressões regulares
+
+
*
Savepoints
+
*
+
Point­in­time recovery
+
+
*
Efetivação em 2 fases
+
*
?
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 (c1996­2008), MySQL (c1997­2008) e Firebird (c2000­2008).
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 35
conseguirem trocar informações entre si, deve existir algum meio de interconexão BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
entre os mesmos. A FIGURA 1 faz essa ilustração.
Sub­rede de comunicações
hosts
Switches
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).
36
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 37
formadas por cabos coaxiais, par trançados ou de fibra óptica e são conhecidas BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
38
Já Date (1990), diz que este termo se refere a qualquer sistema que pode BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
39
Quando é criado/utilizado um sistema distribuído, deve ser levado em BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 40
LANs e WANs, mas há também os que são específicos de cada tipo de rede. Isso BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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: faz­se 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, utilizando­se de técnicas de criptografia e certificações digitais.
41
●
Sincronização: é necessário fazer a gerência da transmissão e do BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
acesso das informações, de forma que as mesmas mantenham­se 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 inter­relacionados, 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).
42
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 inter­relacionados. 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.
FUNC
FNO
FNOME
CARGO
PROJ
PNO
PNOME
PRCAMEN
PAG
CARGO
SAL
DSG
FNO
PNO
RESP
DUR
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).
43
Contudo, segue Özsu (2001), dada a natureza distribuída da empresa, é BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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êm­se 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:
44
1) Fragmentação horizontal: a relação r é particionada em um número de BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
45
Outra transparência que deve existir em bancos de dados distribuídos é a BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
independência dos dados. Essa independência é uma forma fundamental de transparência que procura­se 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 vice­versa. 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, pode­se 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. Levando­se 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.
46
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 inter­relacionamentos 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 clientes­servidor ú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 clientes­vários servidores, existem duas estratégias para 47
gerenciamento: ou cada cliente gerencia suas conexões com os servidores comunica com os demais servidores (Özsu, 2001). A FIGURA 3 mostra uma Sistema operacional
arquitetura cliente/servidor.
Interface do usuário
Programa aplicativo
...
SGBD cliente
Software de comunicação
Consultas
Relação
SQL
resultado
Sistema operacional
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
adequados, ou cada cliente conhece apenas seu servidor local e este se Software de comunicação
Controlador semântico de dados
Otimizador de consultas
Gerenciador de transações
Gerenciador de recuperação
Processador de suporte runtime
Banco de
dados
FIGURA 3 ­ Arquitetura cliente/servidor de referência
Fonte: Özsu (2001, p. 95).
48
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
2.3.4.2 Sistemas distribuídos não­hierárquicos
Nos sistemas distribuídos não­hierá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.
EE1
EE2
...
EEn
ECG
ECL1
ECL2
...
ECLn
EIL1
EIL2
...
EILn
FIGURA 4 ­ Arquitetura de banco de dados distribuído de referência
Fonte: Özsu (2001, p. 97).
49
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
EEG1
EEL12
EEL13
EEL11
EEG2
ECG
EEG3
EELn1
EELn2
EELn3
ECL1
...
ECLn
EIL1
...
EILn
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 50
mesmo qualquer sistema, é tolerante a falhas se consegue continuar operando BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
51
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 52
conseguida através quatro formas: redundância de hardware, redundância de BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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).
53
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
54
A grande desvantagem no uso desse tipo de replicação, é que existe uma BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
perda significativa de performance, pois os processos tornam­se 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 55
as informações dos bancos de dados dos hosts envolvidos não estarão sempre BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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: single­master ou master­slave e multi­master (Elnikety; Dropsho; Zwaenepoel, 2006).
2.4.2.1 Single­master ou master­slave
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 56
servidor mestre. As operações de réplica para os servidores escravos, são BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
USUÁRIO
leitura
SERVIDOR
ESCRAVO
replicação
leitura
e
escrita
SERVIDOR
MESTRE
leitura
replicação
SERVIDOR
ESCRAVO
FIGURA 6 ­ Exemplo do modelo de replicação single­master
Fonte: Elaborado pelo autor com base em Elnikety, Dropsho e Zwaenepoel (2006).
2.4.2.2 Multi­master
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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
57
leitura
e
escrita
SERVIDOR
replicação
USUÁRIO
leitura
e
escrita
leitura
e
escrita
SERVIDOR
replicação
SERVIDOR
replicação
FIGURA 7 ­ Exemplo do modelo de replicação multi­master
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 Primary­Copy 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.
58
As operações de leitura podem ser executadas sobre qualquer cópia. Caso BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 Quorum­Consensus 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 Available­Copies 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.
59
Quando um servidor inativo se tornar ativo novamente, algumas operações BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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).
60
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 preocupam­se somente com o acesso e atualização da base de dados local. As transações globais preocupam­se em manter o acesso e atualizar diversas bases de dados locais ao mesmo tempo e dessa forma, essa tarefa torna­se 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 (two­phase commit protocol – 2PC) e o protocolo de efetivação em três 61
fases (three­phase commit protocol – 3PC), este último elimina as desvantagens BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 62
completo, C1 pode determinar se a transação será efetivada ou não. Se BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 pre­efetivaçã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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
3 FERRAMENTAS UTILIZADAS
Para fazer o estudo dos diferentes algoritmos e técnicas de replicação, optou­se 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, optou­se 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 Postgres­R (http://pgfoundry.org/projects/ postgres­r) e o PgReplicator (http://pgreplicator.sourceforge.net). 64
Como foram encontradas várias ferramentas, dentre as mais populares BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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, c1996­2008).
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
Master­slave.
Controle
Não há controle. Neste trabalho desenvolveu­
se controle pela política Primary­Copy Method)
Método
Triggers.
Objetos replicados
Dados de tabelas e seqüências, menos dados do tipo blob ou large­object.
65
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 ( c1996­2008).
Conforme PostgreSQL (c1996­2008), 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 (c1996­2008).
66
Para fazer a conexão com os bancos de dados, a DBLink utiliza a BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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, c1996­2008).
A FIGURA 8 ilustra uma replicação entre três servidores utilizando esta ferramenta.
SERVIDOR 1 DE
BANCO DE DADOS
MASTER
CLIENTE SERVIDOR 2 DE
BANCO DE DADOS
SLAVE
SERVIDOR 3 DE
BANCO DE DADOS
SLAVE
FIGURA 8 ­ Exemplo de replicação utilizando a ferramenta DBLink com Triggers
Fonte: Elaborado pelo autor com base em PostgreSQL (c1996­2008).
É 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 (c1996­2008).
67
se através de triggers, dados do servidor master forem inseridos em outras BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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, concentrando­se 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).
68
banco de dados inacessíveis reingressarem ou mesmo quando um novo servidor BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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
Multi­master.
Controle
Available­Copies 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).
69
A FIGURA 9 ilustra o funcionamento da ferramenta e através dela é BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
CLIENTE SERVIDOR 1 DE
BANCO DE DADOS
SERVIDOR 2 DE
BANCO DE DADOS
SERVIDOR DE
BALANCEAMENTO
DE CARGA
SERVIDOR 3 DE
BANCO DE DADOS
SERVIDOR DE
REPLICAÇÃO
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).
70
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
3.3 Slony­I
O Slony­I é uma ferramenta assíncrona para replicações multi­master, 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”.
SERVIDOR 1 DE
BANCO DE DADOS
MASTER
SERVIDOR 2 DE
BANCO DE DADOS
SLAVE
SERVIDOR 3 DE
BANCO DE DADOS
SLAVE
TABELAS
TABELAS
TABELAS
TABELAS
DE LOG
TABELAS
DE LOG
TABELAS
DE LOG
FIGURA 10 ­ Exemplo de servidores com replicação de de banco de dados cascateada utilizando a ferramenta Slony­I
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 71
papel. Assim, todos os servidores slaves seriam re­sincronizados conforme o BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 Slony­I 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, c2004­2006).
As características da utilização desta ferramenta de replicação são descritas no QUADRO 4.
72
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
Slony­I
Tipo
Assíncrono.
Modelo
Master­slave sendo que os slaves também podem ser configurados para replicar para os demais Controle
Available­Copies Method.
Método
Triggers.
Objetos replicados
Dados de tabelas e seqüências, menos dados do tipo blob ou large­object.
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 Slony­I
Fonte: Elaborado pelo autor com base em Browne (c2004­2006).
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, c2004­2006).
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 criou­se ambientes específicos, capazes de simular o uso de banco de dados. Nesses ambientes ou cenários, definiu­se 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, criou­se cenários com a finalidade de definir a disposição e relação dos servidores de banco de dados entre si. Assim, propôs­se 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, realizou­se, os testes, em laboratórios, com computadores utilizando o sistema operacional GNU/Linux. As características 74
tanto dos computadores utilizados como servidores, como dos utilizados como BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
SWITCH
SERVIDOR 3
IP: 10.3.17.14
SERVIDOR 2
IP: 10.3.17.13
SERVIDOR 1
IP: 10.3.17.12
CLIENTE 5
IP: 10.3.17.21
CLIENTE 4
IP: 10.3.17.20
CLIENTE 3
IP: 10.3.17.19
CLIENTE 2
IP: 10.3.17.18
CLIENTE 1
IP: 10.3.17.17
CLIENTE 10
IP: 10.3.17.26
CLIENTE 9
IP: 10.3.17.25
CLIENTE 8
IP: 10.3.17.24
CLIENTE 7
IP: 10.3.17.23
CLIENTE 6
IP: 10.3.17.22
CLIENTE 15
IP: 10.3.17.31
CLIENTE 14
IP: 10.3.17.30
CLIENTE 13
IP: 10.3.17.29
CLIENTE 12
IP: 10.3.17.28
CLIENTE 11
IP: 10.3.17.27
CLIENTE 20
IP: 10.3.17.36
CLIENTE 19
IP: 10.3.17.35
CLIENTE 18
IP: 10.3.17.34
CLIENTE 17
IP: 10.3.17.33
CLIENTE 16
IP: 10.3.17.32
FIGURA 11 ­ Exemplo de disposição dos computadores na rede do laboratório
Fonte: Elaborado pelo autor com base no laboratório utilizado.
75
Princípio para os dois cenários: todos os computadores, servidores de BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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, simulou­se 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 – master­slave
No primeiro cenário ilustrou­se 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, designou­se um dos servidores como master e apelidado­se o de SERVIDOR1, os outros dois designou­se como slaves. Permitiu­se a entrada de dados, apenas ao servidor master, a um dos slaves permitiu­se apenas consultas, este apelidou­se de SERVIDOR2, já o terceiro, utilizou­se como backup, e apelidou­se 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).
76
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
USUÁRIO
leitura
SERVIDOR 2
replicação
leitura
e
escrita
SERVIDOR 1
alta velocidade
replicação
SERVIDOR 3
alta velocidade
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, utilizou­se as ferramentas replicadoras DBLink por Triggers, PgCluster e Slony­I, esta última, assíncrona, teve suas configurações alteradas para replicar os dados de forma síncrona.
4.1.2 Cenário 2 – multi­master
No segundo cenário descreveu­se um ambiente formado também por três servidores e vários clientes, mas neste, distribui­se os servidores em uma rede, simulando a Internet, com largura de banda limitada a 1 Mbps. Neste cenário, designou­se todos os servidores como masters, de forma que, todos os servidores replicassem os dados para todos, e apelidou­se os de SERVIDOR1, SERVIDOR2 e SERVIDOR3. A FIGURA 13 exemplifica a estrutura deste cenário. BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
77
USUÁRIO
leitura
e
escrita
SERVIDOR 1
replicação
leitura
e
escrita
leitura
e
escrita
SERVIDOR 2
baixa velocidade
replicação
SERVIDOR 3
baixa velocidade
replicação
baixa velocidade
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, utilizou­se somente a ferramenta PgCluster, pois esta é a única que utiliza o modelo de replicação multi­master, necessário para este cenário.
Nos testes utilizou­se 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, fez­se necessário a simulação de uma largura de banda de rede menor. Para tal, utilizou­se 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, definiu­se 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. 78
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
4.2 Bases de dados
Nomeou­se 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 chamou­se de CODIGO, é do tipo inteiro e, o segundo, chamou­se 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, fez­se necessária a definição da metodologia para utilizar nas simulações.
4.3 Metodologia
Antes de qualquer teste, necessitou­se 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 79
acessa a base dos servidores, os comandos que podem ser executados nela, de BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 Slony­I. 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 faz­se 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 pode­se 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 80
dessas ferramentas encontram­se no APÊNDICE B – Instalação e configuração BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 Slony­I, também realiza­se 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 é multi­master e dessa forma, muitos conflitos entre os bancos devem ocorrer.
81
Por fim, no cenário 2, os clientes devem fazer acessos aos 3 servidores BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 multi­master. Para o cenário 1 foram testadas as ferramentas DBLink com Triggers, PgCluster e Slony­I e, para o 83
cenário 2, foi testada somente a ferramenta PgCluster por ser a única ferramenta BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
multi­master.
5.1.1 Cenário 1 ­ master­slave
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 84
taxa de utilização da rede tende a aumentar ou diminuir linearmente para cada BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 Slony­I 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 Slony­I 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.
85
As taxas médias, de transmissão dos dados, desta simulação com as três BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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
Slony­I
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 verificou­se o comportamento das ferramentas, com 5 computadores clientes, fazendo acessos à base de dados do servidor master, para leitura e escrita de dados.
86
A ferramenta DBLink com Triggers replicou os dados para os 2 servidores BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 Slony­I, 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 Slony­I 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 Slony­I, 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.
Taxa média de uso em uma rede de 100 Mbps
Percentual médio de uso em uma rede de 100 Mbps
DBLink com Triggers
PgCluster
Slony­I
8,98 KBps
7,56 KBps
6,86 KBps
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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 Slony­I, 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.
88
Através dos dados comparativos do QUADRO 8, é possível perceber que, BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 Slony­I 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.
Taxa média de uso em uma rede de 100 Mbps
Percentual médio de uso em uma rede de 100 Mbps
DBLink com Triggers
PgCluster
Slony­I
17,88 KBps
14,19 KBps
8,87 KBps
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.
89
Foi constatado que a ferramenta DBLink com Triggers replicou os dados BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 Slony­I, 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 Slony­I 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.
Taxa média de uso em uma rede de 100 Mbps
Percentual médio de uso em uma rede de 100 Mbps
DBLink com Triggers
PgCluster
Slony­I
32,71 KBps
28,92 KBps
9,56 KBps
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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 ­ master­slave
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 Slony­I. 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 91
programada a ferramenta. A ferramenta PgCluster utiliza um controle de réplica, BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
como o Available­Copies 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 Slony­I 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 Slony­I, 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.
92
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
5.1.2 Cenário 2 ­ multi­master
Para o cenário 2, utilizou­se uma ferramenta que trabalhasse no modelo multi­master. 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.
93
Para cada teste feito, foram coletados os pacotes que trafegaram pela rede BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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.
95
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 – multi­master
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.
97
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 master­slave e o cenário 2, que seguia o modelo multi­master. Para ambos cenários foi testada somente a ferramenta Slony­I, 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 ­ master­slave
Para as replicações assíncronas no modelo master­slave, 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 Slony­I 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.
98
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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 Slony­I 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, 99
maior é a quantidade de dados de controle que são trocados entre os servidores. BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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. Taxa média de uso em uma rede de 100 Mbps
Percentual médio de uso em uma rede de 100 Mbps
Tempo médio para replicação dos dados
5 minutos
10 minutos
20 minutos
0,85 KBps
0,71 KBps
0,55 KBps
0,0066%
0,0055%
0,0043%
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.
100
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
Taxa média de uso em uma rede de 100 Mbps
Percentual médio de uso em uma rede de 100 Mbps
Tempo médio para replicação dos dados
5 minutos
10 minutos
20 minutos
1,38 KBps
1,11 KBps
0,92 KBps
0,0108%
0,0087%
0,0072%
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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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. 102
O gráfico com a relação de bytes por segundos das replicações, para os três BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
Taxa média de uso em uma rede de 100 Mbps
Percentual médio de uso em uma rede de 100 Mbps
Tempo médio para replicação dos dados
5 minutos
10 minutos
20 minutos
1,84 KBps
1,59 KBps
1,42 KBps
0,0144%
0,0124%
0,0111%
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 103
replicação do servidor master para os slaves, com acessos de 20 computadores BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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.
Taxa média de uso em uma rede de 100 Mbps
Percentual médio de uso em uma rede de 100 Mbps
Tempo médio para replicação dos dados
5 minutos
10 minutos
20 minutos
2,47 KBps
2,27 KBps
2,19 KBps
0,0193%
0,0177%
0,0171%
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.
104
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
5.2.1.5 Conclusões sobre o cenário 1 ­ master­slave
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 tornam­se 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.
105
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
5.2.2 Cenário 2 ­ multi­master
Não foi encontrada nenhuma ferramenta assíncrona em Software Livre que fizesse a replicação multi­master. 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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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, utilizando­se do mesmo. Para escolha desse SGBD, foi feito um quadro comparativo, entre os principais existentes no mercado, e através desses dados comparativos que optou­se 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 Slony­I, 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 107
ambientes corporativos. Assim, foram criados dois ambientes, cenário 1 e cenário BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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, Slony­I 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 multi­master, 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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
REFERÊNCIAS
BROWNE, Christopher. Slony­I 1.2.13 Documentation. The PostgreSQL Global Development Group. c2004­2006. 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: Single­Master vs. Multi­Master. Technical report. EPFL. Nov. 2006. Disponível em: <http://labos.epfl.ch/webdav/site/labos/users/157494/public/papers/Single­vs­
Multi­Master.pdf>. Acesso em: 14 set. 2007.
FireBird. Firebird SQL Conformance. The Firebird Documentation Team. c2000­2008. 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 109
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
2004­2008. Disponível em: <http://www.wireshark.org/download/docs/user­guide­
a4.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.puc­rio.br/pub/docs/techreports/06_21_monteiro.pdf>. Acesso em: 14 Set. 2007.
MySQL. MySQL 5.0 Reference Manual. The MySQL Documentation Team. c1997­2008. Disponível em: http://dev.mysql.com/doc/>. Acesso em: 20 abr. 2008.
OLIVEIRA JÚNIOR, João Cosme de. Configurando o Slony­I. 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 multi­master 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. c1996­2006. 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.
110
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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ós­Graduaçã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. Slony­I – A replication system for PostgreSQL. Afilias USA INC ­ Horsham, Pennsylvania, USA, 2007. Disponível em: <http://developer.postgresql. org/~wieck/slony1/Slony­I­concept.pdf>. Acesso em: 20 abr. 2008.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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
Frame­memory 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
112
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
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
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
APÊNDICES
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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 Slony­I.............................................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
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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
2
/usr/local/pgsql­8.2.6/bin/createdb dbteste ­Upostgres ­E LATIN1
/usr/local/pgsql­8.2.6/bin/createlang plpgsql dbteste ­Upostgres
Inicialmente todas as bases de dados foram inicializadas com a seguinte estrutura:
1
2
create sequence seq_codigo_pessoas;
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, pode­se usar o comando:
1
/usr/local/pgsql­8.2.6/bin/psql dbteste ­Upostgres
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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
2
3
4
5
6
7
8
9
10
11
12
13
Além
cd /usr/local/src
tar ­zxvf postgresql­8.2.6.tar.gz
cd postgresql­8.2.6
./configure ­­prefix=/usr/local/pgsql­8.2.6 ­­with­tcl ­­enable­nls ­­with­openssl
make
make install
useradd postgres
mkdir /usr/local/pgsql­8.2.6/data
chown postgres /usr/local/pgsql­8.2.6/data
export LANG=pt_BR
export LC_ALL=pt_BR
su postgres ­c '/usr/local/pgsql­8.2.6/bin/initdb ­D /usr/local/pgsql­8.2.6/data ­E LATIN1'
su postgres ­c '/usr/local/pgsql­8.2.6/bin/postmaster ­i ­D /usr/local/pgsql­8.2.6/data' //inicializar o SGBD
disso,
é
seja
necessário
configurar
o arquivo /usr/local/pgsql­8.2.6/data/pg_hba.conf habilitando o acesso dos demais servidores.
Instalação do DBLink:
1
2
3
4
5
cd /usr/local/src/postgresql­8.2.6/contrib/dblink/
make
make install
/usr/local/pgsql­8.2.6/bin/psql template1 ­Upostgres < dblink.sql
/usr/local/pgsql­8.2.6/bin/createlang plpgsql template1 ­Upostgres;
Instalação e inicialização do PgCluster:
1
2
3
4
5
6
7
8
9
10
cd /usr/local/src/
tar ­zxvf pgcluster­1.7.0rc12.tar.gz
cd pgcluster­1.7.0rc12
./configure ­­prefix=/usr/local/pgcluster­1.7.0rc12
make all
make install
useradd postgres
mkdir /usr/local/pgcluster­1.7.0rc12/data
mkdir /usr/local/pgcluster­1.7.0rc12/etc
chown postgres /usr/local/pgcluster­1.7.0rc12/data
117
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
11
12
13
14
chown postgres /usr/local/pgcluster­1.7.0rc12/etc
export LANG=pt_BR
export LC_ALL=pt_BR
su postgres ­c '/usr/local/pgcluster­1.7.0rc12/bin/initdb ­D /usr/local/
pgcluster­1.7.0rc12/data ­E LATIN1'
15 su postgres ­c ' /usr/local/pgcluster­1.7.0rc12/bin/pg_ctl ­D /usr/local/pgcluster­1.7.0rc12/data ­o "­i" start' //inicializar os servidores de banco de dados
16 su postgres ­c '/usr/local/pgcluster­1.7.0rc12/bin/pgreplicate ­D /usr/local/pgcluster­1.7.0rc12/etc' //inicializar os servidores replicadores de banco de dados (somente masters)
17 su postgres ­c '/usr/local/pgcluster­1.7.0rc12/bin/pglb ­D /usr/local/pgcluster­1.7.0rc12/etc' //inicializar os servidores de balanceamento de carga dos bancos de dados (somente masters)
Instalação e inicialização do Slony­I:
1
2
3
4
5
6
7
cd /usr/local/src/
tar ­jxvf slony1­1.2.13.tar.bz2
cd slony1­1.2.13
./configure ­­prefix=/usr/local/slony1­1.2.13 –with­
pgconfigdir=/usr/local/pgsql­8.2.6/bin
gmake all
gmake install
ln ­s /usr/local/pgsql­8.2.6/share /usr/local/slony1­1.2.13
Instalação do PHP para linha de comando com suporte a PostgreSQL:
1
2
3
4
5
6
cd /usr/local/src/
tar ­zxvf php­5.2.5.tar.gz
cd php­5.2.5
./configure ­­prefix=/usr/local/php­5.2.5 ­­disable­all ­­with­
pgsql=/usr/local/pgsql­8.2.6
make
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
2
3
4
5
6
7
8
mkdir /etc/cbq
cd /etc/cbq
cp /usr/local/src/cbq.init­v0.7.3 /sbin/cbq
chmod +x /sbin/cbq
touch /etc/cbq/cbq­0002
cbq stop
cbq compile
cbq start
118
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
Instalação do Wireshark para campturar os pacotes a PostgreSQL:
1
2
3
4
5
6
cd /usr/local/src/
tar ­zxvf wireshark­1.0.0.tar.gz
cd wireshark­1.0.0
./configure ­­prefix=/usr/local/wireshark­1.0.0
make
make install
Para capturar o tráfego da replicação, pode­se 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 servidor1
10.3.17.13 servidor2
10.3.17.14 servidor3
10.3.17.17 cliente1
10.3.17.18 cliente2
10.3.17.19 cliente3
10.3.17.20 cliente4
10.3.17.21 cliente5
10.3.17.22 cliente6
10.3.17.23 cliente7
10.3.17.24 cliente8
10.3.17.25 cliente9
10.3.17.26 cliente10
10.3.17.27 cliente11
10.3.17.28 cliente12
10.3.17.29 cliente13
10.3.17.30 cliente14
10.3.17.31 cliente15
10.3.17.32 cliente16
10.3.17.33 cliente17
10.3.17.34 cliente18
10.3.17.35 cliente19
10.3.17.36 cliente20
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE OR REPLACE FUNCTION atualiza_servidores()
RETURNS TRIGGER AS $atualiza_servidores$
DECLARE
servidor2 VARCHAR;
servidor3 VARCHAR;
errorMsg2 VARCHAR;
errorMsg3 VARCHAR;
conections TEXT[];
BEGIN
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);
17
18 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);
21
22 IF TG_OP = 'INSERT' THEN
23
24 PERFORM dblink_exec('conn2','INSERT INTO pessoas ( codigo, nome )
25 VALUES (' || NEW.codigo || ',''' || NEW.nome || ''');', true);
26
27 PERFORM dblink_exec('conn3','INSERT INTO pessoas ( codigo, nome )
28 VALUES (' || NEW.codigo || ',''' || NEW.nome || ''');', true);
29
30 SELECT * FROM dblink_error_message('conn2') INTO errorMsg2;
31 SELECT * FROM dblink_error_message('conn3') INTO errorMsg3;
32
33 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
34
35 PERFORM dblink_exec('conn2','ROLLBACK;', true);
36 PERFORM dblink_disconnect('conn2');
37
38 PERFORM dblink_exec('conn3','ROLLBACK;', true);
39 PERFORM dblink_disconnect('conn3');
40
41 RAISE EXCEPTION '%', errorMsg;
42
43 ELSE
44
45 PERFORM dblink_exec('conn2','COMMIT', true);
46 PERFORM dblink_disconnect('conn2');
47
48 PERFORM dblink_exec('conn3','COMMIT', true);
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
120
49
50
51
52
53
54
55
56
57
58
59
PERFORM dblink_disconnect('conn3');
END IF;
RETURN NEW;
END IF;
IF TG_OP = 'UPDATE' THEN
PERFORM dblink_exec('conn2','UPDATE pessoas SET codigo = ' || NEW.codigo || ',' ||
60 'nome = ''' || NEW.nome || ''' WHERE codigo = ' || OLD.codigo || ';', true);
61
62 PERFORM dblink_exec('conn3','UPDATE pessoas SET codigo = ' || NEW.codigo || ',' ||
63 'nome = ''' || NEW.nome || ''' WHERE codigo = ' || OLD.codigo || ';', true);
64
65 SELECT * FROM dblink_error_message('conn2') INTO errorMsg2;
66 SELECT * FROM dblink_error_message('conn3') INTO errorMsg3;
67
68 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
69
70 PERFORM dblink_exec('conn2','ROLLBACK;', true);
71 PERFORM dblink_disconnect('conn2');
72
73 PERFORM dblink_exec('conn3','ROLLBACK;', true);
74 PERFORM dblink_disconnect('conn3');
75
76 RAISE EXCEPTION '%', errorMsg;
77
78 ELSE
79
80 PERFORM dblink_exec('conn2','COMMIT', true);
81 PERFORM dblink_disconnect('conn2');
82
83 PERFORM dblink_exec('conn3','COMMIT', true);
84 PERFORM dblink_disconnect('conn3');
85
86 END IF;
87
88 RETURN NEW;
89
90 END IF;
91
92 IF TG_OP = 'DELETE' THEN
93
94 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);
96
97 SELECT * FROM dblink_error_message('conn2') INTO errorMsg2;
98 SELECT * FROM dblink_error_message('conn3') INTO errorMsg3;
99
100 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
101
102 PERFORM dblink_exec('conn2','ROLLBACK;', true);
103 PERFORM dblink_disconnect('conn2');
104
105 PERFORM dblink_exec('conn3','ROLLBACK;', true);
106 PERFORM dblink_disconnect('conn3');
107
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
121
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
RAISE EXCEPTION '%', errorMsg;
ELSE
PERFORM dblink_exec('conn2','COMMIT', true);
PERFORM dblink_disconnect('conn2');
PERFORM dblink_exec('conn3','COMMIT', true);
PERFORM dblink_disconnect('conn3');
END IF;
RETURN OLD;
END IF;
EXCEPTION
WHEN others THEN
SELECT dblink_get_connections() INTO conections;
IF 'conn2' = ANY (conections) THEN
PERFORM dblink_disconnect('conn2');
END IF;
SELECT dblink_get_connections() INTO conections;
IF 'conn3' = ANY (conections) THEN
PERFORM dblink_disconnect('conn3');
END IF;
RAISE EXCEPTION'(%)', sqlerrm;
END;
$atualiza_servidores$ LANGUAGE plpgsql;
CREATE TRIGGER atualiza_servidores
BEFORE INSERT OR UPDATE OR DELETE ON pessoas
FOR EACH ROW EXECUTE PROCEDURE atualiza_servidores();
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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. Deve­se configurar o arquivo de /etc/hosts com os endereços dos servidores em cada um dos servidores.
10.3.17.12 servidor1
10.3.17.13 servidor2
10.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/pgcluster­1.7.0rc12/data/cluster.conf. Abaixo o exemplo do mesmo.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<Replicate_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 8002 </Port>
<Recovery_Port> 8102 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Port> 8003 </Port>
<Recovery_Port> 8103 </Recovery_Port>
</Replicate_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Recovery_Port> 7001 </Recovery_Port>
<Rsync_Path> /usr/bin/rsync </Rsync_Path>
<Rsync_Option> ssh ­1 </Rsync_Option>
<Rsync_Compress> yes </Rsync_Compress>
<Pg_Dump_Path> /usr/local/pgcluster­1.7.0rc12/bin/pg_dump </Pg_Dump_Path>
<When_Stand_Alone> read_only </When_Stand_Alone>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 11s </LifeCheck_Interval>
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
123
Configurar o arquivo /usr/local/pgcluster­1.7.0rc12/etc/pgreplicate.conf do servidor master com o código relativo as configurações de replicações
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
<Cluster_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Replication_Port> 8001 </Replication_Port>
<Recovery_Port> 8101 </Recovery_Port>
<RLOG_Port> 8301 </RLOG_Port>
<Response_Mode> normal </Response_Mode>
<Use_Replication_Log> no </Use_Replication_Log>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>
<Log_File_Info>
<File_Name> /var/log/postgresql/pgreplicate.log </File_Name>
<File_Size> 1M </File_Size>
<Rotate> 3 </Rotate>
</Log_File_Info>
Configurar o arquivo /usr/local/pgcluster­1.7.0rc12/etc/pglb.conf do servidor master com o código relativo ao balanceamento de carga dos servidores.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<Cluster_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info>
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
124
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<Host_Name> servidor1 </Host_Name>
<Backend_Socket_Dir> /tmp </Backend_Socket_Dir>
<Receive_Port> 5433 </Receive_Port>
<Recovery_Port> 6101 </Recovery_Port>
<Max_Cluster_Num> 128 </Max_Cluster_Num>
<Use_Connection_Pooling> no </Use_Connection_Pooling>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>
<Log_File_Info>
<File_Name> /var/log/postgresql/pglb.log </File_Name>
<File_Size> 1M </File_Size>
<Rotate> 3 </Rotate>
</Log_File_Info>
Além disso, é necessário configurar o arquivo /usr/local/pgcluster­1.7.0rc12/
data/pg_hba.conf habilitando o acesso dos demais servidores e clientes.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
APÊNDICE E – Configurações para uso do Slony­I
Neste apêndice é descrito um modelo de configuração do Slony­I levando em consideração que o mesmo irá replicar do servidor1 para o servidor2. Antes de configurar este programa é necessário certificar­se 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/pgsql­8.2.6/etc/pg_service.conf com as informações de conexão entre os computadores servidores.
1
2
3
4
5
6
7
8
9
10
11
12
[servidor1]
dbname=dbteste
host=10.3.17.12
user=postgres
[servidor2]
dbname=dbteste
host=10.3.17.13
user=postgres
[servidor3]
dbname=dbteste
host=10.3.17.14
user=postgres
Configurar o arquivo /usr/local/slony1­1.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
2
3
4
define CLUSTER teste;
define servidor1 1;
define servidor2 2;
define servidor3 3;
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
126
5
6
7
8
9
10
define fqn fully qualified name;
cluster name = @CLUSTER;
node @servidor1 admin conninfo='service=servidor1';
node @servidor2 admin conninfo='service=servidor2';
node @servidor3 admin conninfo='service=servidor3';
Configurar o arquivo /usr/local/slony1­1.2.13/initcluster.sk com os nós escravos e mestres.
1
2
3
4
5
6
7
8
9
10
11
#!/usr/local/slony1­1.2.13/bin/slonik
include <preamble.sk>;
### Indica quem é o nó de origem da replicação
init cluster(id=@servidor1, comment='no de origem');
### Indica quem são os nós escravos
store node(id=@servidor2, comment='no escravo servidor2');
store node(id=@servidor3, comment='no escravo servidor3');
Configurar o arquivo /usr/local/slony1­1.2.13/path.sk com a configuração de comunicação entre os nós.
12 #!/usr/local/slony1­1.2.13/bin/slonik
13 include <preamble.sk>;
14
15 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/slony1­1.2.13/sets.sk com a definição de quais tabelas e seqüências deverão ser replicadas.
1
2
3
4
5
6
7
8
9
#!/usr/local/slony1­1.2.13/bin/slonik
include <preamble.sk>;
### Criando o nosso SET!
create set(id = 1, origin = @servidor1, comment='objetos replicados');
### Quais sequencias e tabelas devem ser replicadas.
set add table(set id = 1, origin= @servidor1, id = 1, @fqn ='public.pessoas', comment='Tabela de pessoas');
set add sequence(set id = 1, origin= @servidor1, id = 1, @fqn ='public.seq_codigo_pessoas');
Após essas configurações o Slony­I já pode inicializar a estrutura para o controle das réplicas, para isso é importante que:
●
Todos os servidores possuam o slony­I instalado;
●
O
arquivo pg_services deve estar no diretório /usr/local/pgsql­8.2.6/data de cada servidor.
127
Para criar o esquema do replicador dessa base, deve­se executar os BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
comandos abaixo:
1
2
3
4
chmod 744 preamble.sk initcluster.sk path.sk sets.sk
./initcluster.sk
./path.sk
./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
2
cluster_name = 'teste'
conn_info='service=servidor1'
O arquivo servidor2.slon deve conter as linhas de código:
1
2
cluster_name = 'teste'
conn_info='service=servidor2'
O arquivo servidor3.slon deve conter as linhas de código:
1
2
cluster_name = 'teste'
conn_info='service=servidor3'
Ainda deve­se configurar o arquivo /usr/local/slony1­1.2.13/subscribe.sk para definir a topologia do cluster :
1
2
3
4
5
#!/usr/local/slony1­1.2.13/bin/slonik
include <preamble.sk>;
subscribe set(id=1,provider=@servidor1,receiver=@servidor2,forward=TRUE);
subscribe set(id=1,provider=@servidor1,receiver=@servidor3,forward=TRUE);
Por fim, deve­se dar as permissões e executar o arquivo abaixo:
1
2
chmod 700 subscribe.sk
./subscribe.sk
Para inicializar o processo de replicação deve­se executar os comandos abaixo nos respectivos servidores:
1
2
3
slon ­f servidor3.slon
slon ­f servidor2.slon
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.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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/cbq­0002. 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
2
3
4
5
6
7
DEVICE=eth0,100Mbit,10Mbit #"nome da interface que vai para o cliente","banda","banda/10"
RATE=1024Kbit #"velocidade"
WEIGHT=102Kbit #"velocidade/10"
PRIO=5 #"prioridade (5 é um valor excelente)"
RULE=172.16.0.1/24 #"ip ou rede a ser controlado" BOUNDED=yes #”yes/no se setado para yes o usuário estará limitado mesmo que o link esteja com folga.“
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#!/bin/bash
#
# cbq.init v0.7.3
# Copyright (C) 1999 Pavel Golubev <pg@ksi­linux.com>
# Copyright (C) 2001­2004 Lubomir Bulej <[email protected]>
#
# chkconfig: 2345 11 89
# description: sets up CBQ­based traffic control
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111­1307 USA
#
# To get the latest version, check on Freshmeat for actual location:
#
#
http://freshmeat.net/projects/cbq.init
#
#
export LC_ALL=C
23
24
25
26
27
28
29
30
31 ### Command locations
32 TC=/sbin/tc
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
129
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
IP=/sbin/ip
MP=/sbin/modprobe
### Default filter priorities (must be different)
PRIO_RULE_DEFAULT=${PRIO_RULE:­100}
PRIO_MARK_DEFAULT=${PRIO_MARK:­200}
PRIO_REALM_DEFAULT=${PRIO_REALM:­300}
### Default CBQ_PATH & CBQ_CACHE settings
#CBQ_PATH=${CBQ_PATH:­/etc/sysconfig/cbq}
CBQ_PATH="/etc/cbq"
CBQ_CACHE=${CBQ_CACHE:­/var/cache/cbq.init}
### Uncomment to enable logfile for debugging
#CBQ_DEBUG="/var/run/cbq­$1"
### Modules to probe for. Uncomment the last CBQ_PROBE
### line if you have QoS support compiled into kernel
CBQ_PROBE="sch_cbq sch_tbf sch_sfq sch_prio"
CBQ_PROBE="$CBQ_PROBE cls_fw cls_u32 cls_route"
#CBQ_PROBE=""
### Keywords required for qdisc & class configuration
CBQ_WORDS="DEVICE|RATE|WEIGHT|PRIO|PARENT|LEAF|BOUNDED|ISOLATED"
CBQ_WORDS="$CBQ_WORDS|PRIO_MARK|PRIO_RULE|PRIO_REALM|BUFFER"
CBQ_WORDS="$CBQ_WORDS|LIMIT|PEAK|MTU|QUANTUM|PERTURB"
########################################################################
#####
62 ############################# SUPPORT FUNCTIONS #############################
63 ########################################################################
#####
64
65 ### Get list of network devices
66 cbq_device_list () {
67
ip link show| sed ­n "/^[0­9]/ \
68
{ s/^[0­9]\+: \([a­z0­9._]\+\)[:@].*/\1/; p; }"
69 } # cbq_device_list
70
71
72 ### Remove root class from device $1
73 cbq_device_off () {
74
tc qdisc del dev $1 root 2> /dev/null
75 } # cbq_device_off
76
77
78 ### Remove CBQ from all devices
79 cbq_off () {
80
for dev in `cbq_device_list`; do
81
cbq_device_off $dev
82
done
83 } # cbq_off
84
85
86 ### Prefixed message
87 cbq_message () {
88
echo ­e "**CBQ: $@"
89 } # cbq_message
90
91 ### Failure message
92 cbq_failure () {
93
cbq_message "$@"
94
exit 1
95 } # cbq_failure
96
97 ### Failure w/ cbq­off
98 cbq_fail_off () {
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
130
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
cbq_message "$@"
cbq_off
exit 1
} # cbq_fail_off
### Convert time to absolute value
cbq_time2abs () {
local min=${1##*:}; min=${min##0}
local hrs=${1%%:*}; hrs=${hrs##0}
echo $[hrs*60 + min]
} # cbq_time2abs
### Display CBQ setup
cbq_show () {
for dev in `cbq_device_list`; do
[ `tc qdisc show dev $dev| wc ­l` ­eq 0 ] && continue
echo ­e "### $dev: queueing disciplines\n"
tc $1 qdisc show dev $dev; echo
[ `tc class show dev $dev| wc ­l` ­eq 0 ] && continue
echo ­e "### $dev: traffic classes\n"
tc $1 class show dev $dev; echo
done
} # cbq_show
[ `tc filter show dev $dev| wc ­l` ­eq 0 ] && continue
echo ­e "### $dev: filtering rules\n"
tc $1 filter show dev $dev; echo
### Check configuration and load DEVICES, DEVFIELDS and CLASSLIST from $1
cbq_init () {
### Get a list of configured classes
CLASSLIST=`find $1 \( ­type f ­or ­type l \) ­name 'cbq­*' \
­not ­name '*~' ­maxdepth 1 ­printf "%f\n"| sort`
[ ­z "$CLASSLIST" ] &&
cbq_failure "no configuration files found in $1!"
### Gather all DEVICE fields from $1/cbq­*
DEVFIELDS=`find $1 \( ­type f ­or ­type l \) ­name 'cbq­*' \
­not ­name '*~' ­maxdepth 1| xargs sed ­n 's/#.*//; \
s/[[:space:]]//g; /^DEVICE=[^,]*,[^,]*\(,[^,]*\)\?/ \
{ s/.*=//; p; }'| sort ­u`
[ ­z "$DEVFIELDS" ] &&
cbq_failure "no DEVICE field found in $1/cbq­*!"
### Check for different DEVICE fields for the same device
DEVICES=`echo "$DEVFIELDS"| sed 's/,.*//'| sort ­u`
[ `echo "$DEVICES"| wc ­l` ­ne `echo "$DEVFIELDS"| wc ­l` ] &&
cbq_failure "different DEVICE fields for single device!\n$DEVFIELDS"
151 } # cbq_init
152
153
154 ### Load class configuration from $1/$2
155 cbq_load_class () {
156
CLASS=`echo $2| sed 's/^cbq­0*//; s/^\([0­9a­fA­F]\+\).*/\1/'`
157
CFILE=`sed ­n 's/#.*//; s/[[:space:]]//g; /^[[:alnum:]_]\
+=[[:alnum:].,:;/*@­_]\+$/ p' $1/$2`
158
159
### Check class number
160
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
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
131
164
### Set defaults & load class
165
RATE=""; WEIGHT=""; PARENT=""; PRIO=5
166
LEAF=tbf; BOUNDED=yes; ISOLATED=no
167
BUFFER=10Kb/8; LIMIT=15Kb; MTU=1500
168
PEAK=""; PERTURB=10; QUANTUM=""
169
170
PRIO_RULE=$PRIO_RULE_DEFAULT
171
PRIO_MARK=$PRIO_MARK_DEFAULT
172
PRIO_REALM=$PRIO_REALM_DEFAULT
173
174
eval `echo "$CFILE"| grep ­E "^($CBQ_WORDS)="`
175
176
### Require RATE/WEIGHT
177
[ ­z "$RATE" ­o ­z "$WEIGHT" ] &&
178
cbq_fail_off "missing RATE or WEIGHT in $2!"
179
180
### Class device
181
DEVICE=${DEVICE%%,*}
182
[ ­z "$DEVICE" ] && cbq_fail_off "missing DEVICE field in $2!"
183
184
BANDWIDTH=`echo "$DEVFIELDS"| sed ­n "/^$DEVICE,/ \
185
{ s/[^,]*,\([^,]*\).*/\1/; p; q; }"`
186
187
### Convert to "tc" options
188
PEAK=${PEAK:+peakrate $PEAK}
189
PERTURB=${PERTURB:+perturb $PERTURB}
190
QUANTUM=${QUANTUM:+quantum $QUANTUM}
191
192
[ "$BOUNDED" = "no" ] && BOUNDED="" || BOUNDED="bounded"
193
[ "$ISOLATED" = "yes" ] && ISOLATED="isolated" || ISOLATED=""
194 } # cbq_load_class
195
196
197 ########################################################################
#####
198 #################################### INIT ###################################
199 ########################################################################
#####
200
201 ### Check for presence of ip­route2 in usual place
202 [ ­x $TC ­a ­x $IP ] ||
203
cbq_failure "ip­route2 utilities not installed or executable!"
204
205
206 ### ip/tc wrappers
207 if [ "$1" = "compile" ]; then
208
### no module probing
209
CBQ_PROBE=""
210
211
ip () {
212
$IP "$@"
213
} # ip
214
215
### echo­only version of "tc" command
216
tc () {
217
echo "$TC $@"
218
} # tc
219
220 elif [ ­n "$CBQ_DEBUG" ]; then
221
echo ­e "# `date`" > $CBQ_DEBUG
222
223
### Logging version of "ip" command
224
ip () {
225
echo ­e "\n# ip $@" >> $CBQ_DEBUG
226
$IP "$@" 2>&1 | tee ­a $CBQ_DEBUG
227
} # ip
228
229
### Logging version of "tc" command
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
132
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
tc () {
else
} # tc
echo ­e "\n# tc $@" >> $CBQ_DEBUG
$TC "$@" 2>&1 | tee ­a $CBQ_DEBUG
### Default wrappers
ip () {
} # ip
$IP "$@"
tc () {
$TC "$@"
} # tc
fi # ip/tc wrappers
case "$1" in
########################################################################
#####
250 ############################### START/COMPILE ###############################
251 ########################################################################
#####
252
253 start|compile)
254
255 ### Probe QoS modules (start only)
256 for module in $CBQ_PROBE; do
257
$MP $module || cbq_failure "failed to load module $module"
258 done
259
260 ### If we are in compile/nocache/logging mode, don't bother with cache
261 if [ "$1" != "compile" ­a "$2" != "nocache" ­a ­z "$CBQ_DEBUG" ]; then
262
VALID=1
263
264
### validate the cache
265
[ "$2" = "invalidate" ­o ! ­f $CBQ_CACHE ] && VALID=0
266
if [ $VALID ­eq 1 ]; then
267
[ `find $CBQ_PATH ­maxdepth 1 ­newer $CBQ_CACHE| \
268
wc ­l` ­gt 0 ] && VALID=0
269
fi
270
271
### compile the config if the cache is invalid
272
if [ $VALID ­ne 1 ]; then
273
$0 compile > $CBQ_CACHE ||
274
cbq_fail_off "failed to compile CBQ configuration!"
275
fi
276
277
### run the cached commands
278
exec /bin/sh $CBQ_CACHE 2> /dev/null
279 fi
280
281 ### Load DEVICES, DEVFIELDS and CLASSLIST
282 cbq_init $CBQ_PATH
283
284
285 ### Setup root qdisc on all configured devices
286 for dev in $DEVICES; do
287
### Retrieve device bandwidth and, optionally, weight
288
DEVTEMP=`echo "$DEVFIELDS"| sed ­n "/^$dev,/ { s/$dev,//; p; q; }"`
289
DEVBWDT=${DEVTEMP%%,*};
DEVWGHT=${DEVTEMP##*,}
290
[ "$DEVBWDT" = "$DEVWGHT" ] && DEVWGHT=""
291
292
### Device bandwidth is required
293
if [ ­z "$DEVBWDT" ]; then
294
cbq_message "could not determine bandwidth for device BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
133
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
$dev!"
fi
cbq_failure "please set up the DEVICE fields properly!"
### Check if the device is there
ip link show $dev &> /dev/null ||
cbq_fail_off "device $dev not found!"
### Remove old root qdisc from device
cbq_device_off $dev
### Setup root qdisc + class for device
tc qdisc add dev $dev root handle 1 cbq \
bandwidth $DEVBWDT avpkt 1000 cell 8
### Set weight of the root class if set
[ ­n "$DEVWGHT" ] &&
tc class change dev $dev root cbq weight $DEVWGHT allot 1514
313
314
[ "$1" = "compile" ] && echo
315 done # dev
316
317
318 ### Setup traffic classes
319 for classfile in $CLASSLIST; do
320
cbq_load_class $CBQ_PATH $classfile
321
322
### Create the class
323
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!"
327
328
### Create leaf qdisc if set
329
if [ "$LEAF" = "tbf" ]; then
330
tc qdisc add dev $DEVICE parent 1:$CLASS handle $CLASS tbf \
331
rate $RATE buffer $BUFFER limit $LIMIT mtu $MTU $PEAK
332
elif [ "$LEAF" = "sfq" ]; then
333
tc qdisc add dev $DEVICE parent 1:$CLASS handle $CLASS sfq \
334
$PERTURB $QUANTUM
335
fi
336
337
338
### Create fw filter for MARK fields
339
for mark in `echo "$CFILE"| sed ­n '/^MARK/ { s/.*=//; p; }'`; do
340
### Attach fw filter to root class
341
tc filter add dev $DEVICE parent 1:0 protocol ip \
342
prio $PRIO_MARK handle $mark fw classid 1:$CLASS
343
done ### mark
344
345
### Create route filter for REALM fields
346
for realm in `echo "$CFILE"| sed ­n '/^REALM/ { s/.*=//; p; }'`; do
347
### Split realm into source & destination realms
348
SREALM=${realm%%,*}; DREALM=${realm##*,}
349
[ "$SREALM" = "$DREALM" ] && SREALM=""
350
351
### Convert asterisks to empty strings
352
SREALM=${SREALM#\*}; DREALM=${DREALM#\*}
353
354
### Attach route filter to the root class
355
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
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
134
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
done ### realm
### Create u32 filter for RULE fields
for rule in `echo "$CFILE"| sed ­n '/^RULE/ { s/.*=//; p; }'`; do
### Split rule into source & destination
SRC=${rule%%,*}; DST=${rule##*,}
[ "$SRC" = "$rule" ] && SRC=""
### Split destination into address, port & mask fields
DADDR=${DST%%:*}; DTEMP=${DST##*:}
[ "$DADDR" = "$DST" ] && DTEMP=""
DPORT=${DTEMP%%/*}; DMASK=${DTEMP##*/}
[ "$DPORT" = "$DTEMP" ] && DMASK="0xffff"
### Split up source (if specified)
SADDR=""; SPORT=""
if [ ­n "$SRC" ]; then
SADDR=${SRC%%:*}; STEMP=${SRC##*:}
[ "$SADDR" = "$SRC" ] && STEMP=""
fi
SPORT=${STEMP%%/*}; SMASK=${STEMP##*/}
[ "$SPORT" = "$STEMP" ] && SMASK="0xffff"
### Convert asterisks to empty strings
SADDR=${SADDR#\*}; DADDR=${DADDR#\*}
### Compose u32 filter rules
u32_s="${SPORT:+match ip sport $SPORT $SMASK}"
u32_s="${SADDR:+match ip src $SADDR} $u32_s"
u32_d="${DPORT:+match ip dport $DPORT $DMASK}"
u32_d="${DADDR:+match ip dst $DADDR} $u32_d"
rules
### Uncomment the following if you want to see parsed 396
#echo "$rule: $u32_s $u32_d"
397
398
### Attach u32 filter to the appropriate class
399
tc filter add dev $DEVICE parent 1:0 protocol ip \
400
prio $PRIO_RULE u32 $u32_s $u32_d classid 1:$CLASS
401
done ### rule
402
403
[ "$1" = "compile" ] && echo
404 done ### classfile
405 ;;
406
407
408 ########################################################################
#####
409 ################################# TIME CHECK ################################
410 ########################################################################
#####
411
412 timecheck)
413
414 ### Get time + weekday
415 TIME_TMP=`date +%w/%k:%M`
416 TIME_DOW=${TIME_TMP%%/*}
417 TIME_NOW=${TIME_TMP##*/}
418
419 ### Load DEVICES, DEVFIELDS and CLASSLIST
420 cbq_init $CBQ_PATH
421
422 ### Run through all classes
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
135
423 for classfile in $CLASSLIST; do
424
### Gather all TIME rules from class config
425
TIMESET=`sed ­n 's/#.*//; s/[[:space:]]//g; /^TIME/ { s/.*=//; p; }' \
426
$CBQ_PATH/$classfile`
427
[ ­z "$TIMESET" ] && continue
428
429
MATCH=0; CHANGE=0
430
for timerule in $TIMESET; do
431
TIME_ABS=`cbq_time2abs $TIME_NOW`
432
433
### Split TIME rule to pieces
434
TIMESPEC=${timerule%%;*}; PARAMS=${timerule##*;}
435
WEEKDAYS=${TIMESPEC%%/*}; INTERVAL=${TIMESPEC##*/}
436
BEG_TIME=${INTERVAL%%­*}; END_TIME=${INTERVAL##*­}
437
438
### Check the day­of­week (if present)
439
[ "$WEEKDAYS" != "$INTERVAL" ­a \
440
­n "${WEEKDAYS##*$TIME_DOW*}" ] && continue
441
442
### Compute interval boundaries
443
BEG_ABS=`cbq_time2abs $BEG_TIME`
444
END_ABS=`cbq_time2abs $END_TIME`
445
446
### Midnight wrap fixup
447
if [ $BEG_ABS ­gt $END_ABS ]; then
448
[ $TIME_ABS ­le $END_ABS ] &&
449
TIME_ABS=$[TIME_ABS + 24*60]
450
451
END_ABS=$[END_ABS + 24*60]
452
fi
453
454
### If the time matches, remember params and set MATCH flag
455
if [ $TIME_ABS ­ge $BEG_ABS ­a $TIME_ABS ­lt $END_ABS ]; then
456
TMP_RATE=${PARAMS%%/*}; PARAMS=${PARAMS#*/}
457
TMP_WGHT=${PARAMS%%/*}; TMP_PEAK=${PARAMS##*/}
458
459
[ "$TMP_PEAK" = "$TMP_WGHT" ] && TMP_PEAK=""
460
TMP_PEAK=${TMP_PEAK:+peakrate $TMP_PEAK}
461
462
MATCH=1
463
fi
464
done ### timerule
465
466
467
cbq_load_class $CBQ_PATH $classfile
468
469
### Get current RATE of CBQ class
470
RATE_NOW=`tc class show dev $DEVICE| sed ­n \
471
"/cbq 1:$CLASS / { s/.*rate //; s/ .*//; p; q; }"`
472
[ ­z "$RATE_NOW" ] && continue
473
474
### Time interval matched
475
if [ $MATCH ­ne 0 ]; then
476
477
### Check if there is any change in class RATE
478
if [ "$RATE_NOW" != "$TMP_RATE" ]; then
479
NEW_RATE="$TMP_RATE"
480
NEW_WGHT="$TMP_WGHT"
481
NEW_PEAK="$TMP_PEAK"
482
CHANGE=1
483
fi
484
485
### Match not found, reset to default RATE if necessary
486
elif [ "$RATE_NOW" != "$RATE" ]; then
487
NEW_WGHT="$WEIGHT"
488
NEW_RATE="$RATE"
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
136
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
fi
NEW_PEAK="$PEAK"
CHANGE=1
### If there are no changes, go for next class
[ $CHANGE ­eq 0 ] && continue
### Replace CBQ class
tc class replace dev $DEVICE classid 1:$CLASS cbq \
bandwidth $BANDWIDTH rate $NEW_RATE weight $NEW_WGHT prio $PRIO \
allot 1514 cell 8 maxburst 20 avpkt 1000 $BOUNDED $ISOLATED
### Replace leaf qdisc (if any)
if [ "$LEAF" = "tbf" ]; then
tc qdisc replace dev $DEVICE handle $CLASS tbf \
rate $NEW_RATE buffer $BUFFER limit $LIMIT mtu $MTU $NEW_PEAK
505
fi
506
507
cbq_message "$TIME_NOW: class $CLASS on $DEVICE changed rate ($RATE_NOW ­> $NEW_RATE)"
508 done ### class file
509 ;;
510
511
512 ########################################################################
#####
513 ################################## THE REST #################################
514 ########################################################################
#####
515
516 stop)
517
cbq_off
518
;;
519
520 list)
521
cbq_show
522
;;
523
524 stats)
525
cbq_show ­s
526
;;
527
528 restart)
529
shift
530
$0 stop
531
$0 start "$@"
532
;;
533
534 *)
535
echo "Usage: `basename $0` {start|compile|stop|restart|timecheck|
list|stats}"
536 esac
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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. Deve­se configurar o arquivo de /etc/hosts com os endereços em cada um dos três servidores.
10.3.17.12 servidor1
10.3.17.13 servidor2
10.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/pgcluster­1.7.0rc12/data/cluster.conf.
Na seqüência segue o conteúdo do arquivo cluster.conf do servidor 1:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<Replicate_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
<Host_Name> servior3 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Recovery_Port> 7001 </Recovery_Port>
<Rsync_Path> /usr/bin/rsync </Rsync_Path>
<Rsync_Option> ssh ­1 </Rsync_Option>
<Rsync_Compress> yes </Rsync_Compress>
<Rsync_Timeout> 10min </Rsync_Timeout>
<Rsync_Bwlimit> 0KB </Rsync_Bwlimit>
<Pg_Dump_Path> /usr/local/pgcluster­1.7.0rc12/bin/pg_dump </Pg_Dump_Path>
<Ping_Path> /bin/ping </Ping_Path>
<When_Stand_Alone> read_only </When_Stand_Alone>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 11s </LifeCheck_Interval>
138
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
Na seqüência segue o conteúdo do arquivo cluster.conf do servidor 2:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<Replicate_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
<Host_Name> servior3 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Recovery_Port> 7001 </Recovery_Port>
<Rsync_Path> /usr/bin/rsync </Rsync_Path>
<Rsync_Option> ssh ­1 </Rsync_Option>
<Rsync_Compress> yes </Rsync_Compress>
<Rsync_Timeout> 10min </Rsync_Timeout>
<Rsync_Bwlimit> 0KB </Rsync_Bwlimit>
<Pg_Dump_Path> /usr/local/pgcluster­1.7.0rc12/bin/pg_dump </Pg_Dump_Path>
<Ping_Path> /bin/ping </Ping_Path>
<When_Stand_Alone> read_only </When_Stand_Alone>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 11s </LifeCheck_Interval>
Na seqüência segue o conteúdo do arquivo cluster.conf do servidor 3:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<Replicate_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Replicate_Server_Info>
<Host_Name> servior3 </Host_Name>
<Port> 8001 </Port>
<Recovery_Port> 8101 </Recovery_Port>
</Replicate_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Recovery_Port> 7001 </Recovery_Port>
<Rsync_Path> /usr/bin/rsync </Rsync_Path>
<Rsync_Option> ssh ­1 </Rsync_Option>
<Rsync_Compress> yes </Rsync_Compress>
<Rsync_Timeout> 10min </Rsync_Timeout>
<Rsync_Bwlimit> 0KB </Rsync_Bwlimit>
<Pg_Dump_Path> /usr/local/pgcluster­1.7.0rc12/bin/pg_dump </Pg_Dump_Path>
<Ping_Path> /bin/ping </Ping_Path>
<When_Stand_Alone> read_only </When_Stand_Alone>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 11s </LifeCheck_Interval>
139
Após configurar esse arquivo nos três servidores anteriores, deve­se BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
configurar o arquivo /usr/local/pgcluster­1.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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<Cluster_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Replication_Port> 8001 </Replication_Port>
<Recovery_Port> 8101 </Recovery_Port>
<RLOG_Port> 8301 </RLOG_Port>
<Response_Mode> normal </Response_Mode>
<Use_Replication_Log> no </Use_Replication_Log>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>
<Log_File_Info>
<File_Name> /var/log/postgresql/pgreplicate.log </File_Name>
<File_Size> 1M </File_Size>
<Rotate> 3 </Rotate>
</Log_File_Info>
Na seqüência segue o conteúdo deste arquivo no servidor 2:
1
2
3
4
5
6
7
8
<Cluster_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 5432 </Port>
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
140
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Replication_Port> 8001 </Replication_Port>
<Recovery_Port> 8101 </Recovery_Port>
<RLOG_Port> 8301 </RLOG_Port>
<Response_Mode> normal </Response_Mode>
<Use_Replication_Log> no </Use_Replication_Log>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>
<Log_File_Info>
<File_Name> /var/log/postgresql/pgreplicate.log </File_Name>
<File_Size> 1M </File_Size>
<Rotate> 3 </Rotate>
</Log_File_Info>
Na seqüência segue o conteúdo deste arquivo no servidor 3:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<Cluster_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info> <Host_Name> servidor3 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7001 </Recovery_Port>
</Cluster_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Recovery_Port> 6101 </Recovery_Port>
</LoadBalance_Server_Info>
<Host_Name> servidor3 </Host_Name>
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
141
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<Replication_Port> 8001 </Replication_Port>
<Recovery_Port> 8101 </Recovery_Port>
<RLOG_Port> 8301 </RLOG_Port>
<Response_Mode> normal </Response_Mode>
<Use_Replication_Log> no </Use_Replication_Log>
<Replication_Timeout> 1min </Replication_Timeout>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>
<Log_File_Info>
<File_Name> /var/log/postgresql/pgreplicate.log </File_Name>
<File_Size> 1M </File_Size>
<Rotate> 3 </Rotate>
</Log_File_Info>
Em seguida deve­se configurar também nos três servidores o arquivo /usr/local/pgcluster­1.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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<Cluster_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info> <Cluster_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info> <Host_Name> servidor1 </Host_Name>
<Backend_Socket_Dir> /tmp </Backend_Socket_Dir>
<Receive_Port> 5433 </Receive_Port>
<Recovery_Port> 6101 </Recovery_Port>
<Max_Cluster_Num> 128 </Max_Cluster_Num>
<Use_Connection_Pooling> no </Use_Connection_Pooling>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>
<Log_File_Info>
<File_Name> /var/log/postgresql/pglb.log </File_Name>
<File_Size> 1M </File_Size>
<Rotate> 3 </Rotate>
</Log_File_Info>
No servidor 2 o conteúdo do arquivo é:
1
2
3
4
5
6
7
8
9
10
<Cluster_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info> BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
142
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<Cluster_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info> <Host_Name> servidor2 </Host_Name>
<Backend_Socket_Dir> /tmp </Backend_Socket_Dir>
<Receive_Port> 5433 </Receive_Port>
<Recovery_Port> 6101 </Recovery_Port>
<Max_Cluster_Num> 128 </Max_Cluster_Num>
<Use_Connection_Pooling> no </Use_Connection_Pooling>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>
<Log_File_Info>
<File_Name> /var/log/postgresql/pglb.log </File_Name>
<File_Size> 1M </File_Size>
<Rotate> 3 </Rotate>
</Log_File_Info>
No servidor 3 o conteúdo do arquivo é:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<Cluster_Server_Info>
<Host_Name> servidor1 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> servidor2 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info> <Cluster_Server_Info>
<Host_Name> servidor3 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 30 </Max_Connect> </Cluster_Server_Info> <Host_Name> servidor3 </Host_Name>
<Backend_Socket_Dir> /tmp </Backend_Socket_Dir>
<Receive_Port> 5433 </Receive_Port>
<Recovery_Port> 6101 </Recovery_Port>
<Max_Cluster_Num> 128 </Max_Cluster_Num>
<Use_Connection_Pooling> no </Use_Connection_Pooling>
<LifeCheck_Timeout> 3s </LifeCheck_Timeout>
<LifeCheck_Interval> 15s </LifeCheck_Interval>
<Log_File_Info>
<File_Name> /var/log/postgresql/pglb.log </File_Name>
<File_Size> 1M </File_Size>
<Rotate> 3 </Rotate>
</Log_File_Info>
Além disso, é necessário configurar o arquivo /usr/local/pgcluster­1.7.0rc12/
data/pg_hba.conf de cada servidor habilitando o acesso dos demais servidores e clientes aos mesmos.
BDU – Biblioteca Digital da UNIVATES (http://www.univates.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
2
3
4
5
6
7
8
9
10
11
12
#!/usr/local/php­5.2.5/bin/php
<?php
//definições para o banco de dados
define(DB, 'dbteste');
define(USER, 'postgres');
define(PASS, 'postgres');
define(PORT, '5432');
define(HOST, '10.3.17.12');
/*
* Classe para conexão, consulta e execução de comandos no banco de dados
13 */
14 class Sql
15 {
16
17 //atributo para guardar a conexão
18 var $conn;
19
20 /*
21 * Método construtor
22 */
23 function Sql()
24 {
25 }
26
27 /*
28 * Método para abrir uma conexão
29 */
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 else
42 {
43 return false;
44 }
45 }
46
47 /*
48 * Método para fazer consultas
49 */
50 function Query($sql)
51 {
52 $result = pg_query($this­>conn, $sql);
53 if ( $result )
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
144
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
{
$x = 0;
while ( $l = pg_fetch_array($result) )
{
$y = 0;
for ( $z=0; $z<count($l); $z+=2 )
{
$data[$x][$y] = $l[$y];
$y++;
}
$x++;
}
}
return $data;
}
/*
* Método para executar comandos
*/
function Execute($sql)
{
if ( pg_exec($this­>conn, $sql) )
{
return true;
}
else
{
return false;
}
}
/*
* Método para fechar a conexão
*/
function Close()
{
if ( pg_close($this­>conn) )
{
return true;
}
else
{
return false;
}
}
}
/*
* Classe para gerar as operações de leitura e escrita na base de dados
103 */
104 class Operation
105 {
106
107 //atributo com os nomes a serem inseridos, atualizados ou excluídos
108 var $nomes;
109
110 /*
111 * Método construtor
112 */
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',
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
145
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
7 => 'Samuel',
8 => 'Angela',
9 => 'Tatiane' );
}
/*
* Método para gerar um índice aleatório entre 0 e 9
*/
function getRanIndex()
{
return rand(0, 9);
}
/*
* Método para gerar um comando de inserção na base de dados
*/
function getInsert()
{
$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 }
144
145 /*
146 * Método para gerar um comando de atualização na base de dados
147 */
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 }
154
155 /*
156 * Método para gerar um comando de exclusão na base de dados
157 */
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 }
164
165 /*
166 * Método para gerar um comando de seleção de dados na base de dados
167 */
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 }
175
176 /*
177 * Início do programa
178 */
179
180 //sem tempo máximo de execução
181 set_time_limit(0);
182
183 while ( true )
184 {
BDU – Biblioteca Digital da UNIVATES (http://www.univates.br/bdu)
146
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
//Instancia a classe do banco
$DB = new Sql();
//Abre uma conexão com o banco
if ( $res = $DB­>Open() )
{
//Instancia a classe para gerar os comandos SQL
$OP = new Operation();
//Sortei qual será o comando a ser executado. //Os comandos de inserção tem 30% deSumário chance
//Os comandos de atualização tem 20% de chance
//Os comandos de exclusão tem 10% de chance
//Os comandos de consulta tem 40% de chance
$i = rand(0, 9);
switch ( $i )
{
//Insere dados no banco
case 0:
case 1:
case 2:
$res = $DB­>Execute($OP­>getInsert());
break;
//Atualiza dados no banco
case 3:
case 4:
$res = $DB­>Execute($OP­>getUpdate());
break;
//Exclui dados no banco
case 5:
$res = $DB­>Execute($OP­>getDelete());
break;
//Consulta dados do banco
case 6:
case 7:
case 8:
case 9:
$res = $DB­>Query($OP­>getSelect());
break;
}
//Fecha a conexão com o banco
$res = $DB­>Close();
}
//Aqui o comando de espera de 0 a 5 segundos com cálculos em microsegundos
// 5000000 microsegundos = 5 segundos (usleep = microsegundos e sleep = segundos)
$tempo = rand(0, 50);
if ( $tempo != 0 )
{
echo sprintf("Esperando %.2f segundos...\n", $tempo/10);
usleep($tempo * 100000);
}
}
233
234
235
236
237
238
239
240
241 ?>