Introdução
Muitas pessoas se perguntariam para quê migrar a sua aplicação de uma solução proprietária para uma solução livre, somente pelo custo da licença? E a formação de pessoal especializado e o suporte técnico, como fica, e as ferramentas de administração, replicação, backup, performance e outros.
É fato que as ferramentas proprietárias são melhores como um todo, mas cresce no mundo todo pessoas que desenvolvem soluções e as publicam, tornando cada vez mais robusta, esta por definição é SOFTWARE LIVRE. Você é livre para escolher, o suporte vêm pela internet até mesmo em poucas horas, e não leva dias como em soluções proprietárias. Você é livre para desenvolver a sua própria solução para o seu negócio, você é livre para distribuí-la, mantendo os direitos que recebeu. Não podemos dizer que a ferramenta é instável, por que não existe ainda no mundo auditoria tão severa como a de estar com o código fonte aberto para o mundo.
A medida que se estuda mais este sistema, encontramos novos horizontes que existem na sua maioria das ferramentas proprietárias já são realidade. Neste documento procurei despejar a melhor didática para o estudo de caso com Slony.
1. PostgreSQL
PostgreSQL
é um Sistema Gerenciador de Banco de Dados, Objeto-Relacional,
com licença BSD, ou seja, gratuito e aberto, multiplataforma,
que vem crescendo muito o número de adeptos ao seu uso pela
suas vantagens, principalmente a sua robustez.
2- Replicação
2.1 – Conceitos de replicação
Replicação
de banco de dados é a cópia dos dados de uma base de
dados original para outra base. Isto permite que possa disponibilizar
os dados em um ou mais sites. Isto melhora a disponibilidade dos
dados. A cópia destes dados podem ser parcial ou total.
Areplicação poderá ser usada para Sistemas distribuídos, Sistema de alta disponibilidade, ou talvez em processo de ETL em Data Warehouse.
Nos conceitos atuais de replicação a primeira classificação
das ferramentas é relativo a sua arquitetura é síncrona
ou assíncrona.
Replicação síncrona é uma cópias fiel em qualquer momento
dos dados e transações. No mecanismo assíncrono, o servidor Master assume toda carga de escrita, atualização, deleção e leitura, com a diferença que o Slave apenas disponibiliza leitura da base conforme a figura 2.
Nos servidores Master podem ocorrer transações de leitura, escrita, atualização e deleção, já no servidor Slave, poderá ocorrer apenas operações de leitura, conforme figura 1.
Entre servidores Multimaster você poderá ter síncrono ou assíncrono, já em servidores Master e Slave, assíncrono. Isto é determinado pela ferramenta
utilizada, e o que determina qual arquitetura será utilizada é o objetivo de implementação. Segue abaixo um comparativo de ferramentas para replicação no PostgreSQL:
|
|
Slony-I
|
Mamooth
|
Postgres-R
|
PG-Replicator
|
|
Tipo:
|
Assíncrono
|
Assíncrono
|
Síncrono
|
Assíncrono
|
|
Uso:
|
Master
- multislave
|
Master
- multislave
|
MultiMaster
|
Multimaster
|
|
Propaga
DDL
|
Não
|
Não
|
Não
|
?
|
|
Sist.
Operacional
|
Todos
|
Todos
|
Todos
|
Linux
|
|
BLOB
|
Não
|
?
|
?
|
Sim
|
Nestas
três arquiteturas propostas acima, cada uma tem uma
aplicabilidade específica preferencial.
- Síncrono
Multimaster: Balanceamento de carga ou alta disponibilidade;
- Assíncrono
Multimaster: Alta disponibilidade;
- Assíncrono
Master-Slave: Relatórios diversos níveis.
Fig1
– Servidores Master estão ambos sincronizados transmitindo
escrita, atualizações e deleções em tempo
real.
Fig2
- Servidores Master e Slave estão ambos sincronizados
transmitindo escrita, atualizações e deleções
em tempo real do Master para o Slave.
Para
quem ainda não está familiarizado com as
particularidades do mecanismo síncrono ou assíncrono
talvez se pergunte o que aconteceria se um “Servidor A”
replicasse assincronamente ao “Servidor B” e vice versa, isto não
seria parecido com o mecanismo síncrono? A resposta disso é
imediata, o servidor Slave é atualizado apenas e
exclusivamente pelo mecanismo de sincronização. Isto
provocaria um “lock”, travamento, de entrada de dados em ambos os
servidores, ficando ambos apenas disponível para leitura, o
que é logicamente um erro.
A
maior aplicabilidade dos mecanismos síncronos são para
proporcionar alta disponibilidade, enquanto o mecanismo assíncrono
pode ser usado para melhoria de performance e disponibilidade de
relatórios complexos, e por que não dizer parte
constituinte de um Data Warehouse,
no processo de Extração, Transformação e
Carga(ETL).
A
alta disponibilidade é desejável em sistemas críticos
que não podem parar. Em caso de crash de um servidor, outro
servidor assume de forma transparente para o usuário final do
sistema.
Para
nosso primeiro exemplo de replicação imaginem uma
empresa matriz no Distrito Federal e com filiais nos estados do Rio
de Janeiro e São Paulo. A estrutura de rede necessariamente
uma máquina deve “enxergar” a outra, seja por IP fixo, VPN
ou outra. A matriz possui a gerência de material e recursos
humanos da empresa toda e as filiais estão on-line podendo
acompanhar atualizações na gestão de material e
dos recursos humanos. Se houver uma queda temporária da rede
a(s) filial(ais) estarão com o último estado
consistente da base de dados, podendo manter seus serviços com
menor risco, como por exemplo de vender algo que já foi
vendido pela matriz ou outra filial, ou de não vender por não
saber que o estoque já foi renovado e está disponível.
Fig3
– Distribuições entre filiais, em residências
ou em escritórios pelos gestores.
Dentre
os mecanismos de replicação iremos no capítulo
seguinte mostrar o Slony, atualmente é o mais conhecido pela
internet e aparentemente é o projeto que ganha mais adeptos.
2.2- Slony no Windows.
Algumas
características do Slony são:
- Replicação
Master Multislave;
- Assíncrono;
- Multiplataforma;
- A
definição da tabela a ser replicada na base “Master”
deve ser idêntica a “Slave”;
- Replicação
de tabelas e seqüências. Os demais objetos devem ser
importados na base Slave de acordo com a necessidade do usuário;
- Em
caso de falha o servidor slave não para, e quando retomada a
comunicação, o banco slave retorna automaticamente a
forma do master em “pouco tempo”;
- Slony
deve ser instalado em cada servidor que desejar ser master ou slave;
- Baixo
tráfego pela rede;
- As
tabelas e seqüências slave ficam permanentemente com lock
para escreta, atualização ou deleção.
Qualquer tratamento deve ser feito pelo banco através de
functions ou triggers;
- Inadequado
para clusters multimaster;
2.2.1- Conceitos no Slony
O
Slony é um um replicador Master multi-Slave, assíncrono,
e é multi-plataforma, ou seja, podemos instalá-lo no
Windows, Linux, UNIX, Free BSD, e outros. Para nosso estudo de caso,
adotamos a instalação no Windows pela familiaridade da
maioria dos usuários, usando ferramenta de administração
PgAdmin3 e neste caso o PostgreSQL 8.2, ou seja, apenas ferramentas
livres em um sistema operacional proprietário. A seguir será
mostrado screenshots de passo a passo da instalação
e configuração do servidor de banco de dados e
replicação.
2.2.2– Preparação do Sistema
Operacional
Para
aquisição do PostgreSQL na internet o usuário
poderá buscar o site oficial: www.postgresql.org
Com
o download do instalador do PostgreSQL para Windows é
relativamente pequeno, aproximadamente 25MB, você estará
com com todas as ferramentas necessárias para continuar nosso
estudo. Lembro que no entanto que para instalar o PostgreSQL no
Windows, é necessário usar Sistema de Arquivo NTFS.
Para maiores detalhes a documentação está
disponível para consulta no site.
A
instalação do PostgreSQL é relativamente
simples. Deve-se tomar o cuidado de instalar o módulo do Slony
neste momento. Caso o usuário esteja aprendendo, recomento um
nome fácil para senha do usuário postgres. No caso a
senha que usarei no exemplo é 'postgres', mas isto é
uma sugestão apenas didática, mas nada segura!
Fig4
– Seleção do Slony no momento de instalação
do PostgreSQL.
Após
a instalação do PostgreSQL, falta a instalação
do serviço Slony. É uma boa prática a utilização
de ferramentas gráficas para administração, mas
a instalação do serviço Slony é
inevitavelmente na linha de comando. No entanto não se
assuste, pois é bem fácil. O Slony é o serviço
que rodará paralelo ao serviço de Servidor, que fará
a ligação e replicação entre as bases de
dados “Master” e “Slave”. Sem o serviço não há
comunicação entre as bases de dados.
Uma
vez instalado e configurado o serviço, “nunca mais” será
necessário ficar mexendo neste serviço, mesmo que a
rede sofra interferência e volte a funcionar, mesmo que o
computador servidor reinicie os serviços.
Próximo
passo é começar a configurar engines, do Slony.
Para isto recomento a criação de uma pasta(folder) na
raiz: C:\slony\
Os
engines precisam construídos e dessa forma fica melhor
de administrar caso precise aumentar a criação de bases
replicadas. Estes engines são arquivos de texto, que
sugiro o nome: [base de dados].conf. Exemplo: Master.conf.
O conteúdo do engine é bem simples, pois é somente
para o Slony saber qual base ele deverá gerenciar. O conteúdo
do engine é simplesmente a indicação do:
cluster_name, e do conn_info. Veja o exemplo abaixo:
Fig5
– Engine Master.conf dentro de C:\slony\
Agora
repita este procedimento para o Slave.conf.
Ao
final deste passo você deverá ter os dois arquivos
engines do serviço Slony. Master.conf e Slave.conf.
Próximo
passo é instalar o serviço Slony no Sistema Operacional
Windows
neste caso, mas que poderia ser outro sistema operacional.
Para isto, vamos abrir o Prompt, e abrir o diretório:
“C:\Program Files\Postgresql\8.2\bin”
Fig6
– Tela inicial para instalação do serviço
Slony no Windows.
Esta
é a única parte que é nescessário mexer
nas linhas de código, muitas pessoas não gostam,
respeito, mas garanto que é bem fácil esta parte.
O
comando SLON é chefe disso tudo e seus parâmetros são
bem simples:
- regservice
[nome do serviço]: Registra serviço Slony;
- unregservice
[nome do serviço]; Destrói serviço Slony;
- addengine
[nome do serviço] [path para engine]; Acrescenta engine
ao serviço Slony;
- delengine
[nome do serviço] [path para engine]; Exclui logicamente
engine ao serviço;
- listengines
[nome do serviço]; Lista todos engines do serviço
Slony.
Sabendo
disso siga os passos para continuar a instalação do
serviço:
- slon
-regservce Slony-I
- slon
-addengine Slony-I C:\slony\Master.conf
- slon
-addengine Slony-I C:\slony\Slave.conf
- slon
-listengines Slony-I (opcinal)
Seu
serviço está instalado e disponível conferir em
Painel de Controle> Ferramentas Administrativas> Serviços.
Fig7
– Lista de serviços do Sistema Operacional no caso do
Windows.
É
uma boa prática trocar a inicialização de
Automático para Manual, em caso de desktop pessoal, mas em
servidor de teste ou produção sim, este deverá
ser automático. No momento o serviço não precisa
ser iniciado, mas quando precisar iniciar, parar ou reinicializar,
poderá ser feito nesta tela.
Este
passo terminou, como resultado final do sucesso é o serviço
Slony-I.
2.2.2- Implementando Slony
Chega
de brincar com linhas de comando, a partir de agora toda as ações
de administração do Slony será com PgAdmin3,
para alívio de alguns e desespero de outros mais
conservadores. Acontece que quando a quantidade de replicação
começam a crecer, começa ficar complicado a
administração por linha de código.
Para
começar a interação entre PgAdmin3 e o Slony, é
nescessário a indicação de um caminho nas opções
do PgAdmin3.
Fig8
– Configuração PgAdmin3 com Slony.
Escrevendo
o caminho: C:\Program Files\PostgreSQL\8.2\share
de acorco com a figura 8, o PgAdmin3 está preparado para
começar o cluster.
O
próximo passo, iremos criar uma base de dados Master e uma
Slave, para fins didático.
Fig9
– Base de dados criadas.
Crie
um cluster “cl_teste” conforme os moldes passados na figura 10.
Fig10
– Cluster na base Master.
Fig11
– Cluster na base Slave.
Crie
uma tabela de teste em ambas as bases:
create
table t (name text not null primary key);
Próximo
passo é mostrar para cada um dos nós, Master node e
Slave node no nosso exemplo, os caminhos entre si, estes caminhos são
chamados de path. Abrindo a árvore das bases de dados,
Master, replicação, cl_teste, encontraremos os nodes.
Na
base Master, o caminho do Master node deverá ser mostrado para
enxergar o Slave node com a string “host=localhost
dbname=Slave user=postgres password=postgres”.
A demonstração de como se faz isto está na
figura 12.
 Fig12
– Digitação do path na base Master, no Master
node
|
Uma base Master
somente precisa o path no Master node. O Slave node não
precisa ser preenchido por que não trata-se de
cascateamento, ou seja, “Master” replica para “Slave1” que
por sua vez replica para “Slave1a”.
|
Este
processo deve ser repetido na base Slave no Slave node para enxergar
o Master node. O node
de administração serve como um concentrador de todos os
paths daquele cluster.
Você após ter digitado o path no Master node na base
Master e Slave node na base Slave esta etapa está completa e
seguiremos para o próximo passo. O Listens
aparecerão automaticamente, não há nada a ser
mexido nele, ele simplesmente surgirá
com a criação do path nos
padrões corretos.
Neste próximo passo é a
hora de iniciar ou reiniciar o serviço Slony no sistema, então
vamos lá. Vá ao Painél de controle do Windows,
Ferramentas Adminstrativas, Serviços, procure o serviço
Slony-I e inicie ou reinicie neste momento.
Fig13
– Momento de reiniciar o serviço Slony-I.
Para
fins de monitoria do que está acontecendo com o serviço
Slony-I, é uma boa prática abrir o Visualizador de
Eventos do Windows para ver alguma possível falha até o
momento. Este visualizador fica em Painel de Controle, Ferramentas
Administrativas e finalmente, Visualizador de Eventos. Vá em
Aplicações e lá mostrará o serviço
Slony-I e seus logs no sistema.
Fig14
– Visualizador de eventos para saber eventual problema no processo.
Próximo
passo é a criação do Set.
Nele define tabelas e seqüências que serão
replicadas. Isto ocorrerá na base Master, não sendo
necessário na base Slave, isto por que o Slony entende que
seja na igualmente correspondente naquela base.
O
Slony replica apenas tabelas e seqüências, isto por que as
functions, views
, triggers, e outros
fazem neste contexto parte da DDL do banco, mas que a partir da
replicação das dependências de cada um destes
objetos, seus resultados serão iguais às da base
Master.
Fig15
– Criação de um SET.
Agora
falta pouco para vermos a nossa base Master replicada. Próximo
passo é a inclusão das tabelas e seqüências
no set.
A(s)
tabela(s) necessariamente deverão possuir um campo chave
unique que será
“a chave” para replicação. Em outras palavras, se
houver atualização, deleção ou inserção
de registro, o Slony vai busca-lo por esta chave. Por este motivo o
set pedirá estas informações no caso da tabela.
Nas seqüências, o mecanismo é parecido, mas sem
precisar se preocupar com o campo chave. Você poderá
fazer uso de nenhuma ou várias tabelas em um único set,
e isto também vale para as seqüências.
Fig
16 – Demonstração de uma tabela inserida no SET.
Por
fim, a última etapa para vermos o nosso mecanismo funcionar,
falta apenas a criação do Subscription. Isto
ocorrerá na base Master, indicando origem, destino.
Clicando
com o botão direito em cima do Master set, procure a
criação de um novo objeto. A sua opção
desejada estará lá, New Subscription.
Fig17
– Criação do Subscription.
Nosso
produto final é esta fotografia:
Fig18
– Fotografia final do exercício.
Agora
falta o teste. Vamos fazer dois testes para começarmos
entender.
Primeiro
teste: Teste da carga, vá a base Master e de carga com vários
nomes a sua escolha, pode escrever quantos quiser.
Ao
termino, o teste consiste em estes mesmos nomes estarem em seu
correspondente na base Slave. Repita esta operação
atualizando os campos e se quiser, apagando os campos também
na base Master. Lembre-se que as tabelas envolvidas na replicação
na base Slave agora possuem lock de qualquer tipo de operação
de atualização, escrita ou deleção, serve
apenas para leitura, mas as demais não envolvidas permanecem
unlock.
Segundo
teste: Vá aos serviços do Windows e PARE o Slony-I. Com
isto simulamos uma “queda de rede” entre base Master e Slave.
Atualize
os registros na Master e observe o que acontece no Slave. Claro que a
Slave ficará com a última “fotografia” consistente,
mas isto não impede que a base Master saia de produção
ou dependa de qualquer favor da base Slave.
Por
fim, reinicie o serviço Slony-I e observe o que acontecerá
com a base Slave. Se tudo estiver certo, ele tomará
imediatamente o aspecto do Master.
Agora
que você teve um primeiro contato com Slony-I na prática,
está livre para inventar desafios, dificuldades e
transpor-las. Isto é um excelente exercício para
conhecimento principalmente dos conceitos de síncrono e
assíncrono, com o tempo o que pode parecer parecido, pode
apresentar vantagens e desvantagens impactantes para o sua
administração do banco.
Bibliografia
- http://slony.info/ - Site oficial do projeto Slony; Acesso em out/2007.
- http://www.postgresql.org/ - Site oficial do PostgreSQL; Acesso em out/2007.
- http://www.pgadmin.org/ - Site oficial do PgAdmin3; Acesso em out/2007.
- http://pgreplicator.sourceforge.net/ - Site oficial Pg Replicator; Acesso em out/2007.
- http://www.commandprompt.com/products/postgresqlcore – Site do Mamooth PostgreSQL; Acesso em out/2007.
- http://pgpool.projects.postgresql.org/ - Site oficial PGPOOL; Acesso em out/2007;
- http://www.postgresql.org.br/ - Site PostgreSQL no Brasil; Acesso em out/2007;
- Elmasri e Navathe “Sistemas de Banco de Dados – Fundamentos e Aplicações - 3a edição”
|
