Slony - Manual

Configurando o Slony-I
João Cosme de Oliveira Júnior

14 de agosto de 2007
Resumo
Esse artigo serve como passo-a-passo para configuração de um Cluster
de banco de dados Postresql utilizando o Slony-I, sistema de replicação
assı́ncrono,master to multiple slaves com cascateamento e failover.
1
Sumário
1 O que é Slony-I? 1
1.1 Caracterı́sticas do Slony-I . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Limitações do Slony . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Instalando o Postgresql 1
2.1 Testando o servidor Postgresql . . . . . . . . . . . . . . . . . . . 2
3 Entendendo um pouco mais sobre o Slony-I 1
4 Instalando o Slony-I 1
5 Configurando o Slony-I !!! 1

5.1 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
6 Plano de Configuração 1
7 Configurando as conexões dos nós 2
8 Configurando o Nó Master e os nós escravos 3
9 Configurando as comunicações entre os nós 3
10 Configurando quais tabelas e sequências devem ser replicadas 4
11 Colocando o slony pra rodar 6
12 Definindo a Topologia 9
13 Alterando a topologia! 1
14 Mudando o nó de origem 1

14.1 Nó de origem está rodando . . . . . . . . . . . . . . . . . . . . . 1
14.2 Nó de origem caiu ou esta fora do ar . . . . . . . . . . . . . . . . 2
2
1 O que é Slony-I?
Slony-I é um projeto open-source que tem como objetivo prover replicação entre
banco de dados Postgresql. É isso que o slony se propõe a fazer, replicação de
dados nada mais além disso. Slony-I não é um software para gerenciamento de
redes, alta disponibilidade ou qualquer outra necessidade diferente de replicação
entre banco de dados Postgresql.
Existem Outras opções de replicação entre banco de dados Postgresql, pg-
pool,pgcluster, cada qual com sua caracterı́stica especı́fica. O Slony vem se
destacando por ser um projeto considerado estável e maduro.
A tı́tulo de curiosidade Slony significa manada de elefantes em russo, um nome
bastante interessante, visto que em um cluster da banco de dados Postgresql
teremos vários elefantes!
1.1 Caracterı́sticas do Slony-I

Segue abaixo algumas das caracterı́sticas que eu julgo interessante dependendo
do tipo de solução que se deseja alcançar, entre várias outras.
• Replicação Assı́ncrona:
A replicação entre os banco de dados não ocorrem em tempo real entre
os nós do cluster. Sendo mais claro, isso significa que, se uma alteração é
realizada em um nó, existe um atraso para atualização se propagar entre
os outros nós que fazem parte do nosso cluster.
• Master to Multiple Slaves (Um master para vários escravos).

No sistema de replicação existe sempre um nó origem e vários nós escravos.
Toda a origem de replicação ocorre no nó de origem, depois se propagando
aos outros nós
• Cascateamento entre os nós.

A topologia do slony permite que um nós escravo seja nó de origem a outro
nós escravo, e sempre cascateando as alterações sofridas.
Isso significa dizer que: O nó de origem só e responsável diretamente pelos
nós escravos ligados a ele diretamente.
• Replicação baseado em Triggers.

Todo o esquema de Replicação é baseado em Triggers. Esse é um dos
motivos que os Slony não permite que se propaguem mudanças relativas
ao schema do banco de dados, ex: Depois de configurado o seu ambiente,
se você quizer adicionar uma tabela no nó de origem isso não irá se pro-
pagar para os outros nós, simplesmente porque o esquema de replicação é
baseado em Triggers.
• Permite Fail-over.
Se o seu nó de origem cair, você pode fazer um nó escravo assumir a
posição do nó de origem. Cabe salientar que: O slony não é um programa
de gerenciamento de rede ou alta disponibilidade, isso é feito manualmente!
• Solução escalável
Pode-se ter dezenas de nós.
1.2 Limitações do Slony
• Não replica DDL.
Já foi explicado acima
• Não Replica Large Objects
2
2 Instalando o Postgresql
Um dos pré-requisitos para se ter o Slony-I rodando é ter instalado o Postgresql
em cada máquina do cluster. A instalação do Postgresql é extremamente simples
como iremos observar nos passos abaixo:
1. Realizar o download da versão mais nova do postgresql, no momento a

versão 8.2.4.
www.postgresql.org
Aproximadamente 14.9 mb
2. Descompactar o código fonte.

tar -jxvf postgresql-8.2.4.tar.bz
3. ./configure
Se por acaso a instalação reclamar das libs readline ou zlib, execute ./confi-
gure –without-readline –without-zlib ou instale os pacotes libreadline5-dev
e zlib1g-dev
4. make
5. make install
6. useradd postgresql
Cria o usuario postgresql no sistema.
7. chown postgres -R /usr/local/pgsql/

O usuário postgresql será o owner do diretório de dados do postgresql.
8. su postgresql
Muda para o usuário postgresql.
9. /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Cria o diretório de dados do postgresql.
10. edite o arquivo /usr/local/pgsql/data/postgresql.conf
11. edite o arquivo /usr/local/pgsql/pg hba.conf coloque a seguinte entrada:

host all postgresql 0.0.0.0/0 trust
Essa entrada permite a conexão liberada para o usuário postgresql pro-
veninete de qualquer host, essa entrada será a tı́tulo para nossos testes
ok?
12. /usr/local/pgsql/bin/pg ctl -D /usr/local/pgsql/data start
Servidor no ar! Parabéns!
Se você notou e for um cara esperto e souber um pouquinho de linux/unix,

é cansativo ficar digitando /usr/local/pgsql/bin/... então coloque o diretório
/usr/local/pg... cansei! no PATH!
PATH=$PATH:/usr/local/pgsql/bin
2.1 Testando o servidor Postgresql
Digite simplesmente:
/usr/local/pgsql/bin/psql -U postgres -h localhost template1
Se você colocou o diretório no PATH digite somente:
psql -U postgres -h localhost template1
2
3 Entendendo um pouco mais sobre o Slony-I
Existem alguns conceitos que devem ser entendidos antes da instalação e uso do
slony-I.
1. Cluster
Agrupamento de todos os nós que fazem parte do sistema de replicação.
2. Node
Cada host que compõe o sistema de replicação e consequentemente formam
o cluster.
3. Origem
Nó origem de todo o esquema de replicação.
4. Provider
Um nó provider é um nó que vai prover replicação ao próximo nó.
5. Subscribe
Um nó que receberá a replicaçao a partir de outro nó.
6. Slonik
Interface de configuração para o Slony-I. Através do Slonik que vamos
configurar o Slony! Ele possue uma sintaxe própria no qual vamos especi-
ficando as caracterı́sticas do nosso Cluster.
Observações:
Um nó que seja Provider ele é orbigatoriamente subscribe também, pois ele é
subscribe de um nó e provider de outro.
Como veremos asseguir, é através do slonik que configuramos o nosso cluster.
Posso configurar sem utlizar o slonik? Pode mas dá um trabalho enorme e
você tem que ter amplo conhecimento dos objetos de banco de dados que são
necessários para o Slony-I rodar(Tabelas,Funcões,Views).
4 Instalando o Slony-I
O slony-I está atualmente na versão 1.2.0 (26/06/2007), e é essa versão que
iremos utilizar.
Baixe o arquivo slony1-1.2.0.tar.bz2 do site www.slony.info/downloads/1.2/source/
tar -jxvf slony1-1.2.0.tar.bz2

cd ./slony1-1.2.0
./configure
make
make install
.....
make[2]: Entering directory ‘/usr/src/slony1-1.2.10/tools/altperl’ /bin/sh

/usr/src/slony1-1.2.10/config/mkinstalldirs /usr/local/etc /bin/sh /usr/src/slony1-
1.2.10/config/mkinstalldirs /usr/local/pgsql/lib/ /bin/sh /usr/src/slony1-
1.2.10/config/mkinstalldirs The altperl tools won’t be installed un-
less –with-perltools is specified in configure make[2]: Leaving di-
rectory ‘/usr/src/slony1-1.2.10/tools/altperl’ make[1]: Leaving di-
rectory ‘/usr/src/slony1-1.2.10/tools’ All of Slony-I is successfully
installed
A instalação é extremamente simples e não causa muitos danos

emocionais!
5 Configurando o Slony-I !!!
5.1 Cenário
Para configurarmos o nosso cluster de Banco de dados postgresql, elaboraremos
o seguinte cenário que vai ser utilizado como estudo de caso.
1. Nosso Cluster de Banco de dados vai ser formado por 4 máquinas, com os
seguintes ips.
jatiuca(10.1.0.1)
barra(10.1.0.2)
frances(10.1.0.3)
maragogi(10.1.0.4)
2. Em cada host temos um banco de dados chamado bd praias
create database bd praias;
3. Replicaremos as seguintes 9 tabelas entres os nós.
create table tabela1(id integer primary key,nome text);
create table tabela2(id integer primary key, nome text);
create table tabela3(id integer primary key, nome text);
.....
create table tabela10(id integer primary key,nome text);
4. Nosso host jatiuca será o nó origem de toda replicação.

5. Inicialmente todos os outros 3 nós vão ser replicados a partir do hot ja-
tiuca.
6. Trocaremos a topologia do Cluster.
7. Faremos um nó escravo assumir o lugar de um master.
Em todos os nós do Cluster deve-se ter instalado o Slony-I e o postgresql.
O banco bd praias deve ter suporte a linguagem pl/pgsql!
6 Plano de Configuração
Deveremos seguir alguns passos para configuração sem erros,e que nos propor-
ciona fácil manutenção.
1. Configurar as conexões dos nós e o nome do nosso Cluster.
2. Configurar quem é o nó Master e sãos os nós Escravos.
3. Configurar a comunicação entre os nós.
4. Configurar quais tabelas e sequências devem ser replicadas.
5. Colocar o slon pra rodar!
6. Configurar quem é Provider de quem( Topologia )
Essas tarefas são realizadas através do slonik.
7 Configurando as conexões dos nós
Devemos criar um arquivo chamado pg service.conf e deve ser copiado para a
pasta $PGDATA/etc
( Deve-se criar o diretório $PGDATA/etc ).
Arquivo pg service.conf
—————————————————————————–
[jatiuca]
dbname=db praias
host=10.1.0.1
user=postgres
[barra]
dbname=db praias
hots=10.1.0.2
user=postgres
[frances]
dbname=db praias
host=10.1.0.3
user=postgres
[maragogi]
dbname=db praias
host=10.1.0.4
user=postgres
—————————————————————————–
Devemos criar um arquivo chamado preamble.sk. É esse arquivo que vai
possibilitar o slonik (que já foi comentado acima! ) se conectar nos hosts e
construir toda a estrutura de replicação necessária. Devemos observar que as
entradas do arquivo pg service.conf serão utilizadas nesse arquivo.
Arquivo preamble.sk
————————————————————————————
define CLUSTER teste;
define jatiuca 1;
define barra 2;
define frances 3;
define maragogi 4;
define fqn fully qualified name;
cluster name= @CLUSTER;

node @jatiuca admin conninfo=’service=jatiuca’;
node @barra admin conninfo=’service=barra’;
node @frances admin conninfo=’service=frances’;
node @maragogi admin conninfo=’service=maragogi’;
2
————————————————————————————
Observações:
A sintaxe poderia ser:
cluster name = teste

node 1 admin conninfo = ’dbname=db praias host=10.1.0.1 user=postgres’
node 2 admin conninfo = ’dbname=db praias host=10.1.0.2 user=postgres’
Utilizando o arquivo pg service.conf torna-se mais fácil fazer a ma-
nutenção no arquivo porque colocamos ao invés da string

... admin conninfo=’dbname=db praias host=10.1.0.2 user=postgres’
utlizamos o nome da conexão que ja esta mapeada no arquivo!!!
... admin conninfo=’service=barra’;
Outra vantagem que temos para garantir a facilidade de manutenção

sao os defines, que funcionam como variáveis!
8 Configurando o Nó Master e os nós escravos

Devemos criar um arquivo chamado initcluster.sk, nesse arquivo iremos deter-
minar quem é o nó primário e quais são os nós escravos.
Arquivo initcluster.sk
————————————————————————————
#!/usr/local/pgsql/bin/slonik
include preamble.sk
### Adivinha o motivo desse include? fica de lição de casa!
### init cluster(id=id-origem,comment=’comentario’);
### Indica quem é o nó de origem da replicação
init cluster(id=@jatiuca, comment=’no de origim’);
### store node(id=id-no-escravo,comment=’comentario’);

### Indica quem são os nós escravos
store node(id=@barra, comment=’no escravo barra’);

store node(id=@frances, comment=’no escravo frances’);
store node(id=@maragogi, comment=’no escravo maragogi’);
————————————————————————————
9 Configurando as comunicações entre os nós

Devemos configurar como cada nó do Cluster deve se comunicar com os outros
participantes, para isso criaremos outro arquivo chamado path.sk
3
Arquivo path.sk
————————————————————————————
include preamble.sk
### Já sabe o motivo do include?
# store path(server=id-no , client=id-no , conninfo=’string-de-conexao’);
store path(server = @jatiuca, client = @barra , conninfo=’service=jatiuca’);

store path(server = @barra, client = @jatiuca , conninfo=’service=barra’);
store path(server = @jatiuca, client = @frances , conninfo=’service=jatiuca’);
store path(server = @frances, client = @jatiuca , conninfo=’service=frances’);
store path(server = @jatiuca, client = @maragi , conninfo=’service=barra’);
store path(server = @maragogi, client = @jatiuca , conninfo=’service=frances’);
store path(server = @barra, client = @frances , conninfo=’service=barra’);

store path(server = @frances, client = @barra , conninfo=’service=frances’);
store path(server = @barra, client = @maragogi , conninfo=’service=barra’);
store path(server = @maragogi, client = @barra , conninfo=’service=frances’);
store path(server = @frances, client = @maragogi , conninfo=’service=frances’);

store path(server = @maragogi, client = @frances , conninfo=’service=maragogi’);
————————————————————————————
Observações:
O caminho entre 2 nós tem sempre a ida e a volta. Se eu estabeleço um caminho
entre um nó X ao nó Z então faço o contrário, do nó Z ao nó X.
Viu como é mais fácil o uso do preamble.sk? nao??? Então olha como é legal
fazer a manutenção nisso!
Imagina um Cluster com dezenas de nós?
store path(server = 1, client = 2 , conninfo=’service=’...’);

store path(server = 2, client = 1 , conninfo=’service=...’);
store path(server = 2, client = 3 , conninfo=’service=...’);
store path(server = 3, client = 2 , conninfo=’service=....’);
10 Configurando quais tabelas e sequências de-

vem ser replicadas
Os objetos de banco de dados que podemos replicar através do Slony-I são:
tabelas e sequências.
Vamos entender como as coisas funcionam:
1. Primeiro cria-se um set. O set é um container, um conjunto de todos os

objetos que vão ser replicados. Set em inglês significa conjunto.
4
2. Dentro do set informamos quais tabelas e sequências devem ser replicadas.
Então mais uma vez criaremos outro arquivo: sets.sk
Arquivo sets.sk
————————————————————————————
include preamble.sk
### Já sabe o motivo do include?Ainda não? Sério?
# create set(id=id-do-set , origin=id-no-origem , comment=’comentario’);
### Criando o nosso SET!

create set(id = 1, origin = @jatiuca , comment=’objetos replicados’);
### Informando quais sequências e tabelas devem ser replicadas.

### Para as tabelas:
#set add table(set id = ’id-do-set’ ,origin = id-no-origem, id = in-
teiro , fully qualified name = ’nome-do-schema.tabela’ ,comment =
’comentario)
### Para as sequências:
set add sequence(set id = ’id-do-set’,origin= id-no-origim, id=inteiro,
fully qualified name = ’nome-do-schema.sequence’, comment = ’co-
mentario’
set add table(id = 1, origin= @jatiuca, id = 1, @fqn =’public.tabela1’);
————————————————————————————
Observações:
Recapitulando... Primeiro criamos o SET, depois definimos quais
objetos vão ser replicados.
Necessariamente as tabelas devem ter chaves primárias..
Se as tabelas não tiverem chave primária (Bem segundo o modelo
relacional .... mas isso e outra tema)devem ter indices únicos e você
deve informar ao slony qual o campo, adicionando o KEY no set
add table
set add table(set id = ’id-do-set’ ...... key=’nome-do-indice’)
5
11 Colocando o slony pra rodar
Acho que você leitor, (acho isso comédia demais!) já deve estar ancioso pra
replicar uma única tabela! calma vamos lá!
No momento temos os seguintes arquivos:
pg service.conf
preamble.sk
initcluster.sk
path.sk
sets.sk
Todos os nós do Cluster obviamente devem ter instalados o Slony-I, post-

gresql (Isso já foi dito e não me canso de dizer.)
O arquivo pg service.conf deve estar em todos os hosts no diretório $PGDATA/etc,
então trate de copiá-lo agora mesmo.
No meu cenário existe um diretório /usr/loca/pgsql/etc/pg service.conf nos
hosts jatiuca,barra,frances,maragogi.
vamos tornar os arquivos executáveis que criamos:
chmod 744 preamble.sk inicluster.sk path.sk sets.sk
Digite: ./inticluster.sk
NOTICE: type ” praias.xxid”is not yet defined

DETAIL: Creating a shell type definition.
NOTICE: argument type praias.xxid is only a shell
NOTICE: type ” praias.xxid snapshot”is not yet defined
DETAIL: Creating a shell type definition.
NOTICE: argument type praias.xxid snapshot is only a shell
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl node-pkey”for table ”sl node”
NOTICE: CREATE TABLE will create implicit sequence ”sl nodelock nl conncnt seq”for
serial column ”sl nodelock.nl conncnt”

index ”sl nodelock-pkey”for table ”sl nodelock”
index ”sl set-pkey”for table ”sl set”
index ”sl setsync-pkey”for table ”sl setsync”
index ”sl table-pkey”for table ”sl table”
index ”sl trigger-pkey”for table ”sl trigger”
index ”sl sequence-pkey”for table ”sl sequence”
NOTICE: CREATE TABLE / UNIQUE will create implicit index
”sl sequence seq reloid key”for table ”sl sequence”
6
index ”sl path-pkey”for table ”sl path”
index ”sl listen-pkey”for table ”sl listen”
index ”sl subscribe-pkey”for table ”sl subscribe”
index ”sl event-pkey”for table ”sl event”
index ”sl registry pkey”for table ”sl registry”
Algumas mensagens vão surgir na sua tela! O que o slonik esta fazendo é o
seguinte:
Ele se conecta nos bancos de dados que participarão na replicação, cria um es-
quema novo com o nome do Cluster que nós definimos láaaaa no começo, no
arquivo pg service.conf, no parametro cluster name.,precedido por ( no nosso
caso teremos um esquema TESTE) e dentro desse esquema cria toda a es-
trutura de replicação necessária para o funcionamento, totalizando 25 objetos
dentro desse esquema entre tabelas,sequências e views. Conecte nos seus bancos
de dados e observem o schema e os objetos criados!
Digite: ./paths.sk
Digite: ./set.sk
Em cada nó do Cluster crie os seguintes arquivos:

jatiuca.slon
barra.slon
frances.slon
maragogi.slon
Cada arquivo correspondente em cada máquina!
jatiuca.slon em uma maquina,barra.slon em outra máquina, frances.slon em ou-
tra máquina ...
Mais uma vez sendo muito chato mesmo, deve-se ter o arquivo pg service.conf
em $PGDATA/etc.
7
Jatiuca.slon
————————————————————————————
cluster name = ’teste’

conn info=’service=jatiuca’
————————————————————————————
Para startar o deamon execute: slon -f jatiuca.slon
barra.slon
————————————————————————————

conn info=’service=barra’
————————————————————————————
Para startar o deamon execute: slon -f barra.slon
frances.slon
————————————————————————————

conn info=’service=frances’
————————————————————————————
Para startar o deamon execute: slon -f frances.slon
maragogi.slon
————————————————————————————

conn info=’service=maragogi’
————————————————————————————
Para startar o deamon execute: slon -f maragogi.slon

Nesse momento startamos os daemon em todas as maquinas, e elas começaram a
trocar SYNCS. O nó de origem começa a puxar um histórico de cada modificacao

da tabela TESTE.sl log l e mandad SYNCS para todos os nós subscribers. Mas
como não definimos ainda a topologia a replicação ainda não acontece.
8
12 Definindo a Topologia
Para definirmos a topologia, criamos um arquivo chamado subscribe.sk.
subscribe.sk
————————————————————————————
include preamble.sk;
#Sem querer ser chato, ainda não sabe o porque desse include?
# subscribe set(id=id-do-set,provider=id-do-no,receiver=id-do-no,
#forward= TRUE ou FALSE );
# Nosso host jatiuca sera origem de toda a replicação
# e todos os nós irão replicar a partir dele!
subscribe set(id=1,provide=@jatiuca,receiver=@frances,forward=TRUE);
subscribe set(id=1,provider=@jatiuca,receiver=@barra,forward=TRUE);
subscrive set(id=1,provider=@jatiuca,receiver=@maragogi,forward=FALSE);
————————————————————————————
Ok vamos as explicações!
id = indica que replication set queremos replicar.
provider = indica qual nó que proverá a replicação.
receiver = indica qual nó irá receber a replicação.
forward = TRUE ou FALSE, se TRUE o nó subscribe retém uma cópia dos
dados para poder prover para outros nós subscribers, caso contrário false.
Devemos dar permissão de execução ao arquivo. chmod 700 subscribk.sk

Devemos executá-lo
./subscribe.sk
A partir desse momento todos os dados irão ser replicados!!!
9
13 Alterando a topologia!
Agora vamos alterar a topologia do Cluster!
Vamos obter o seguinte cenário!
1. jatiuca é o nó origem de toda a replicação.

2. frances é subscribe de jatiuca e provider para barra.
3. barra é subscribe de frances e provider de maragogi.
Então temos o seguinte: jatiuca - frances - barra - maragogi Se lembra do arquivo

subscribe.sk?? Vamos editá-lo da seguinte maneira!
subscribe.sk
————————————————————————————
include preamble.sk;
#Sem querer ser chato, ainda não sabe o porque desse include?
# subscribe set(id=id-do-set,provider=id-do-no,receiver=id-do-no,
#forward= TRUE ou FALSE );
# Nosso host jatiuca sera origem de toda a replicação
# e todos os nós irão replicar a partir dele!
subscribe set(id=1,provide=@jatiuca,receiver=@frances,forward=TRUE);
subscribe set(id=1,provider=@frances,receiver=@barra,forward=TRUE);
subscrive set(id=1,provider=@barra,receiver=@maragogi,forward=FALSE);
————————————————————————————
Alterado o arquivo é só executar o script ./subscribe.sk, e observar as mensagens

de alteração dos subscribers!!!
14 Mudando o nó de origem

Temos duas situações para mudar o nó de origem:
1. O nó de origem está rodando.
2. O nó de origem caiu, ou esta fora do ar!
14.1 Nó de origem está rodando

Vamos mudar o nó de origem de toda replicação para o nó frances!
include preamble.sk
lock set(id=1,origin=@jatiuca);
move set(id=1,old origim=@jatiuca, new origin=@frances);
Quando o comando move set é executado, Slony troca os papéis entre
a antiga origem e a nova origem. A antiga origem ainda faz parte da
replicação mas agora é um simples subscribe!
14.2 Nó de origem caiu ou esta fora do ar

Vamos mudar o nó de origem de toda a replicação para o nó frances!;
include preamble.sk
failover(id=@jatiuca, backup node = @frances);

Slony - Manual

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Slony - Manual

Загружено:

Авторское право:

Доступные форматы

Configurando o Slony-I

João Cosme de Oliveira Júnior

3 Entendendo um pouco mais sobre o Slony-I 1

5 Configurando o Slony-I !!! 1

7 Configurando as conexões dos nós 2

8 Configurando o Nó Master e os nós escravos 3

9 Configurando as comunicações entre os nós 3

10 Configurando quais tabelas e sequências devem ser replicadas 4

11 Colocando o slony pra rodar 6

14 Mudando o nó de origem 1

1.1 Caracterı́sticas do Slony-I

• Master to Multiple Slaves (Um master para vários escravos).

• Cascateamento entre os nós.

• Replicação baseado em Triggers.

• Não Replica Large Objects

1. Realizar o download da versão mais nova do postgresql, no momento a

2. Descompactar o código fonte.

7. chown postgres -R /usr/local/pgsql/

10. edite o arquivo /usr/local/pgsql/data/postgresql.conf

11. edite o arquivo /usr/local/pgsql/pg hba.conf coloque a seguinte entrada:

Se você notou e for um cara esperto e souber um pouquinho de linux/unix,

tar -jxvf slony1-1.2.0.tar.bz2

make[2]: Entering directory ‘/usr/src/slony1-1.2.10/tools/altperl’ /bin/sh

A instalação é extremamente simples e não causa muitos danos

4. Nosso host jatiuca será o nó origem de toda replicação.

cluster name= @CLUSTER;

cluster name = teste

nutenção no arquivo porque colocamos ao invés da string

Outra vantagem que temos para garantir a facilidade de manutenção

8 Configurando o Nó Master e os nós escravos

init cluster(id=@jatiuca, comment=’no de origim’);

### store node(id=id-no-escravo,comment=’comentario’);

store node(id=@barra, comment=’no escravo barra’);

9 Configurando as comunicações entre os nós

store path(server = @jatiuca, client = @barra , conninfo=’service=jatiuca’);

store path(server = @barra, client = @frances , conninfo=’service=barra’);

store path(server = @frances, client = @maragogi , conninfo=’service=frances’);

store path(server = 1, client = 2 , conninfo=’service=’...’);

10 Configurando quais tabelas e sequências de-

1. Primeiro cria-se um set. O set é um container, um conjunto de todos os

Então mais uma vez criaremos outro arquivo: sets.sk

### Criando o nosso SET!

### Informando quais sequências e tabelas devem ser replicadas.

Todos os nós do Cluster obviamente devem ter instalados o Slony-I, post-

NOTICE: type ” praias.xxid”is not yet defined

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit

Em cada nó do Cluster crie os seguintes arquivos:

cluster name = ’teste’

Para startar o deamon execute: slon -f jatiuca.slon

cluster name = ’teste’

Para startar o deamon execute: slon -f barra.slon

cluster name = ’teste’

Para startar o deamon execute: slon -f frances.slon

cluster name = ’teste’

Para startar o deamon execute: slon -f maragogi.slon

trocar SYNCS. O nó de origem começa a puxar um histórico de cada modificacao

id = indica que replication set queremos replicar.

provider = indica qual nó que proverá a replicação.

receiver = indica qual nó irá receber a replicação.

Devemos dar permissão de execução ao arquivo. chmod 700 subscribk.sk

A partir desse momento todos os dados irão ser replicados!!!

1. jatiuca é o nó origem de toda a replicação.

Então temos o seguinte: jatiuca - frances - barra - maragogi Se lembra do arquivo

Alterado o arquivo é só executar o script ./subscribe.sk, e observar as mensagens