Começando com o Londiste…

Mais uma vez resolvi dedicar um tempinho e mexer com as ferramentas do SkyTools, o Londiste. Esse post já tem quase um ano , estava nos seus 80% mas por motivos maiores de falta de tempo, trampo …. e vcs sabem a “caixa é uma vidinha de surpresas”…

Aproveitando a proximidade do PGDAY ,um dia dedicado ao nosso querido Postgresql  (Estou realmente pensando em bolar alguma palestra com  PL/PROXY e Londiste aqui no PGDAY de Porto Alegre) , resolvi terminar de escrever sobre o londiste, e como promessa é dívida….

Primeiro foi o plproxy agora é a vez do londiste. Não esqueci não, vou postar algumas coisinhas que eu fiquei de postar do plproxy, inclusive testes de estress em cima dele, mas como a curiosidade falou mais alto,resolvi passar para o Londiste. A intenção é a seguinte:

Pegar o básico do PLPROXY, Londiste e PGBouncer (próximo post). Depois de um how to em cima de cada um deles montar um ambiente com os 3 e meter BALA!

As primeira impressões que eu tive do do londiste foram as seguintes:

Documentação:

Se a documentação do PLPROXY não era das melhores a do Londiste xiiiiiiiiiiii, lascou tudo, sinceramente uma negação, e vi os mesmos comentários dos gringos também Muito mal documentado mesmo!!!

Instalação:

A instalação foi um tanto penosa, perdi algumas horinhas mesmo batendo cabeça e pra não cometer novamente os erros eu documentei, ou pelo menos acho que documentei hehehe. Para quem não é perseverante, é desistência na certa!!!! E mais uma vez vi gringo reclamar!

Implementação:

Colocar o londiste pra rodar e ver suas bases de dados replicando é muito, mas muito simples mesmo. Chega a ser ridículo ( depois de passar pela instalação….), é estremamente simples e chega ser recompensador!!!!

Então que comece a temporada do Londiste!!!!

O que é replicação???

Bem, como esse post não é sobre replicação em si, e mais precisamente sobre o Londiste não vamos entrar em todo o mérito!!!

O objetivo de um mecanismo de replicação de dados é permitir a manutenção de de várias cópias idênticas de um mesmo dado em vários servidores de banco de dados (SGBD).

Para que serve a replicação???

Principais benefícios da replicação de dados são:

Redundância.
Possibilidade de um balanceamento de carga.
Tornar o sistema menos sensível as falhas.

Sugiro que você jovem de uma lidinha sobre replicação ok?? hehhe eu quero é postar sobre o londiste!!!!

É Pra que serve o Londiste??

O Londiste é uma ferramenta para replicação assíncrona, master-to-slaves. Assíncrona significa que: Quando o nó master receber uma transação, existe um tempo para essa transação ser replicada nos nós slaves. O contrário disso , a replicação síncrona, ocorre quando as transações ocorrem em todos os nós on-line.

E como eu poderia usar o Londiste??

Hum deixa eu ver…. Onde não fosse necessário o espelhamento dos dados em todos os nós ao mesmo tempo?? Isso depende muito do projeto em questão. As vezes tenho somente 2 servidores de banco de dados, um servidor MASTER que recebe todas as transações e um servidorzinho na senzala, SLAVE que fica lá jogado esperando por receber os dados, depois que o Master fez uso …. As vezes tenho um servidor master e vários servidores slaves….. Então necessitou de dados repetidos em vários servidores, REPLICAÇÂO. Se não possui como pré-requisito que os dados sejam replicados instataneamente ,ASSÍNCRONO.
Nunca se esquecer que eu tenho somente um MASTER e vários SLAVES. Tudo que acontece, o Master é quem manda… já viu escravo mandar no mestre??

AAAAA mas o Slony faz isso não????

Faz sim , slony faz até mais por permitir cascateamento entre os nós e slave promotion. Ou seja no slony você tem um nó MASTER e outros nós slaves, mas esses nós slaves podem ser Providers para outros nós, cascateando assim os servidores.

Mas se o Slony tem mais recursos por que eu utilizaria o Londiste??

O londiste é muito mais simples de configurar e gerenciar, muito mesmo!!!! Antes o projeto Skype utilizava o próprio Slony, depois começaram a utilizar o Londiste, que foi desenvolvido por eles mesmos.
Motivos!!!! Como já disse, facilidade de configurar e principalmente gerenciar.

Não tá acreditando né? Então toma!!!
Trecho de uma discursão sobre Slony X londiste
….
“I have not been running slony for quite a long time. I last used it at
Skype a few years ago before we moved to our own implementation –
Londiste/pgQ from SkyTools. The main reason was that our cluster got too
big to manage with slony. ”
….

Beleza então vamos começar a instalação!!!!

Como eu disse no início do post, o grande problema do Londiste, como todos to Skytools é a documentação. Eu estou utilizando o debian 4.0.

Depois de bater muito a cabeça acabei instalando alguns pacotes a mais:

apt-get install build-essential python-psycopg libevent-dev python-all-dev python-all python-support

Uma vez instalados esses pacotes, vamos baixar o código fonte:
http://pgfoundry.org/frs/download.php/1813/skytools-2.1.7.tar.gz

baixado o código fonte no meu diretório /usr/src:
tar -xzvf skytools-2.1.7.tar.gz

./configure –with-pgconfigdir=/usr/local/pgsql/bin (No meu caso ok?? deve-se setar o diretório do seu pg_config)

make && make install

Se o bicho não reclamou de nada beleza!!! Se reclamou aí vamos ter que sambar um pouco….
Pelo o que eu me lembre esses foram os pacotes que eu instalei, eu instalarei do zero novamente pra fazer a prova dos 9 🙂

PS: O jovenzinho, ele sabe quem é…. vai falar, já tem o pacote no debian http://packages.debian.org/sid/skytools
Olha o garotinho aí né ??? mas não ta na versão stable ainda …. Detalhe: ele mantém o pacote 🙂

Criando o Ambiente!!!

Vamos fazer o seguinte: Iremos criar inicialmente 2 databases, um master e outro slave

create database mestre;
create database escravo;

Em cada database iremos criar 2 tabelas:
create table tabela1(id serial primary key,nome text);
create table tabela2(id serial primary key,nome text);

Um detalhe muito importante!!!!! Todas as tabelas devem ter chaves primárias ok??? Não se esqueça disso. Atenção nisso jovem!

O que vai acontecer: Nós iremos realizar algumas operações no banco de dados mestre e elas vão ser replicadas ao banco de dados escravo.

Criando o primeiro CLUSTER

Como eu disse a configuração do londiste é muito simples mesmo. Vamos lá:

Crie um arquivo chamado replicacao.conf com o seguinte conteudo:

[londiste]
job_name = replic

provider_db = dbname=mestre host=localhost user=postgres
subscriber_db = dbname=escravo host=localhost user=postgres

pgq_queue_name = londiste_replic

pidfile = /tmp/pid.%(job_name)s
logfile = /tmp/log.%(job_name)s

loop_delay = 1

connection_lifetime = 30

Crie um arquivo chamado ticker.ini com o seguinte conteúdo:

[pgqadm]

job_name = ticker

db = dbname=mestre user=postgres host=localhost

maint_delay_min = 1

loop_delay = 0.5

logfile = /tmp/log.%(job_name)s
pidfile = /tmp/pid.%(job_name)s

use_skylog = 0

connection_lifetime = 21

queue_refresh_period = 10

Instalando o Londiste no sevidor mestre

Devemos instalar toda a estrutura para o londiste rodar: A instalação deve ser feita tanto no servidor mestre como no servidor escravo. Essa estrutura consiste em instalar a linguagem plpgsql,plpython…

londiste.py replicacao.conf provider install

Detalhe: provider o nó que é origem da replicação!

Instalando o Londiste no servidor escravo

<Em cada um dos nós escravos devemos também instalar toda a estrutura necessária como descrito acima.

londiste.py replicacao.conf subscriber install

Detalhe: subscriber é o nó escravo!

Colocando o PGQ pra rodar…

O Daemon pgqadm deve rodar no servidor master , ele vai ser o cara responsável pelo mecanismo de transporte para implementar a replicação!

pgqadm.py -d ticker.ini ticker
para verificar se realmente esta rodando o processo vamos dar um ps aux | grep pgq

…..
root 28190 0.0 0.2 19248 4780 ? Ssl 14:20 0:00 /usr/bin/python /usr/local/bin/pgqadm.py -d ticker.ini ticker
….

Olha que bicho danado hehehehe!!
hummm… posso também dar um pgqadmin.py -d ticker.ini status , tenta aí jovem!

Então pra encher o saco e memorizar!!! rodar o daemon pgqadmin no master utilizando o parametro -d ( o -d e pra rodar como daemon) passando o arquivo de configuracao ticker.ini e a opcao ticker.

Se eu quizer parar o daemon: pgqadmin.py  -s ticker.ini
Curioso? lista o processo novamente!
Memorize os parâmetros e como exercício levante e suba umas 1000 vezes.

Colocando o daemon de replicação no ar!

Você precisa rodar o deamon de replicação em cada host, como no nosso caso o host provider e subscriber estão na mesma máquina vamos la!

londiste.py -d replicao.ini replay

ps aux | egrep “lond|pgq”

root 28568 0.0 0.2 11332 4860 ? Ss 14:59 0:00 /usr/bin/python /usr/local/bin/londiste.py -d replicacao.ini replay
root 28693 0.0 0.2 19244 4772 ? Ssl 15:05 0:00 /usr/bin/python /usr/local/bin/pgqadm.py -d ticker.ini ticker
root 28725 0.0 0.0 3020 816 pts/0 R+ 15:06 0:00 egrep lon|pgq

Exatamente os caras que eu estava esperando o pgqadm ( que é o cara que fica no master e) o londiste.py ( que é o cara que roda em cada escravo)

Escolhendo os objetos as serem replicados

Seguindo o nosso roteiro ja temos os deamons rodando no nó provider e nos nós subscribers. Devemos informar ao Londiste quais tabelas e sequences devemos replicar.

No nosso exemplo iremos replicar 2 tabelas: tabela1 e tabela2.

No nó de origem devemos executar o seguinte comando:

londiste.py   replicacao.conf  provider add  tabela1

londiste.py  replicacao.conf  provider add tabela2

Também temos que replicar as sequences criadas pelo campo serial!!!

londiste.py replicacao.conf provider add-seq tabela1_id_seq;

londiste.py replicacao.conf provider add-seq tabela2_id_seq;

Po mas nao apareceu mensagem nenhuma pra mim? Está tudo tão obscuro!!!

beleza  jovem mancebo…. faz o seguinte

londiste.py replicacao.conf provider tables

public.tabela2
public.tabela1

londiste.py replicacao.conf provider seqs

public.tabela2_id_seq
public.tabela1_id_seq

Detalhe na palavra provider!!!

Agora o mesmo procedimento nos nós de origem!!

londiste.py   replicacao.conf  subscriber add  tabela1

londiste.py  replicacao.conf  subscriber add tabela2

londiste.py replicacao.conf  subscriber add-seq tabela1_id_seq;

londiste.py replicacao.conf  subscriber  add-seq tabela2_id_seq;

Para dar aquela conferida básica….

londiste.py replicacao.conf  subscriber tables

public.tabela2
public.tabela1

londiste.py replicacao.conf subscriber seqs

public.tabela2_id_seq
public.tabela1_id_seq

Detalhe na palavra subscriber!!

Enfim Replicando……UFA!

Vamos testar agora se a replicação vai funfar ou não, o cabra le o artigo se irrita e quer logo ver a parada funcionar, pelo menos eu sou assim 😛

Suponha que seu psql esteja no seu PATH e vc esteja usando linux :). AAAAAAAAAAAAAAA beleza então insere na mão mesmo se preferir!! 🙂

for i in $(seq 1 10000) ; do psql -U postgres -h localhost -c “insert into tabela1 values(default,’joao$i’)” mestre ; done

Com isso inserimos 10000 registros na tabela1. Após  a inserção dos registros!!

Conecte-se no banco mestre e rode um count(*) na tabela1

Conecte-se no banco de dados escravo e rode um count(*) na tabela2

psql  -U postgres -h localhost -c “select count(*) from tabela1” mestre

psql  -U postgres -h localhost -c “select count(*) from tabela1” escravo

Consideração finais…

Fica pra amanhã estou realmente cansado…. Eu prometo que faço e não vai demorar quase um ano!
🙂