Você está na página 1de 19

Configurando o Slony-I

João Cosme de Oliveira Júnior


14 de agosto de 2007

Resumo
Esse artigo serve como passo-a-passo para configuração de um Cluster
de banco de dados Postresql utilizando o Slony-I, sistema de replicação
assı́ncrono,master to multiple slaves com cascateamento e failover.

1
Sumário
1 O que é Slony-I? 1
1.1 Caracterı́sticas do Slony-I . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Limitaçõ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 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

6 Plano de Configuração 1

7 Configurando as conexões dos nós 2

8 Configurando o Nó Master e os nós escravos 3

9 Configurando as comunicações entre os nós 3

10 Configurando quais tabelas e sequê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 nó de origem 1


14.1 Nó de origem está rodando . . . . . . . . . . . . . . . . . . . . . 1
14.2 Nó de origem caiu ou esta fora do ar . . . . . . . . . . . . . . . . 2

2
1 O que é Slony-I?
Slony-I é um projeto open-source que tem como objetivo prover replicação entre
banco de dados Postgresql. É isso que o slony se propõe a fazer, replicação de
dados nada mais além disso. Slony-I não é um software para gerenciamento de
redes, alta disponibilidade ou qualquer outra necessidade diferente de replicação
entre banco de dados Postgresql.
Existem Outras opções de replicaçã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 está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 vários elefantes!

1.1 Caracterı́sticas do Slony-I


Segue abaixo algumas das caracterı́sticas que eu julgo interessante dependendo
do tipo de solução que se deseja alcançar, entre várias outras.

• Replicação Assı́ncrona:
A replicação entre os banco de dados não ocorrem em tempo real entre
os nós do cluster. Sendo mais claro, isso significa que, se uma alteração é
realizada em um nó, existe um atraso para atualização se propagar entre
os outros nós que fazem parte do nosso cluster.

• Master to Multiple Slaves (Um master para vários escravos).


No sistema de replicação existe sempre um nó origem e vários nós escravos.
Toda a origem de replicação ocorre no nó de origem, depois se propagando
aos outros nós

• Cascateamento entre os nós.


A topologia do slony permite que um nós escravo seja nó de origem a outro
nós escravo, e sempre cascateando as alterações sofridas.
Isso significa dizer que: O nó de origem só e responsável diretamente pelos
nós escravos ligados a ele diretamente.

• Replicação baseado em Triggers.


Todo o esquema de Replicação é baseado em Triggers. Esse é um dos
motivos que os Slony não permite que se propaguem mudanças relativas
ao schema do banco de dados, ex: Depois de configurado o seu ambiente,
se você quizer adicionar uma tabela no nó de origem isso não irá se pro-
pagar para os outros nós, simplesmente porque o esquema de replicação é
baseado em Triggers.

• Permite Fail-over.
Se o seu nó de origem cair, você pode fazer um nó escravo assumir a
posição do nó de origem. Cabe salientar que: O slony não é um programa
de gerenciamento de rede ou alta disponibilidade, isso é feito manualmente!

• Solução escalável
Pode-se ter dezenas de nós.
1.2 Limitações do Slony
• Não replica DDL.
Já foi explicado acima

• Não Replica Large Objects

2
2 Instalando o Postgresql
Um dos pré-requisitos para se ter o Slony-I rodando é ter instalado o Postgresql
em cada máquina do cluster. A instalação do Postgresql é extremamente simples
como iremos observar nos passos abaixo:

1. Realizar o download da versão mais nova do postgresql, no momento a


versão 8.2.4.
www.postgresql.org
Aproximadamente 14.9 mb

2. Descompactar o código fonte.


tar -jxvf postgresql-8.2.4.tar.bz

3. ./configure
Se por acaso a instalaçã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 usuário postgresql será o owner do diretório de dados do postgresql.

8. su postgresql
Muda para o usuário postgresql.

9. /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Cria o diretó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 conexão liberada para o usuário postgresql pro-
veninete de qualquer host, essa entrada será a tı́tulo para nossos testes
ok?
12. /usr/local/pgsql/bin/pg ctl -D /usr/local/pgsql/data start
Servidor no ar! Parabéns!

Se você notou e for um cara esperto e souber um pouquinho de linux/unix,


é cansativo ficar digitando /usr/local/pgsql/bin/... então coloque o diretó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 você colocou o diretó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 instalação e uso do
slony-I.

1. Cluster
Agrupamento de todos os nós que fazem parte do sistema de replicação.

2. Node
Cada host que compõe o sistema de replicação e consequentemente formam
o cluster.

3. Origem
Nó origem de todo o esquema de replicação.

4. Provider
Um nó provider é um nó que vai prover replicação ao próximo nó.

5. Subscribe
Um nó que receberá a replicaçao a partir de outro nó.

6. Slonik
Interface de configuração para o Slony-I. Através do Slonik que vamos
configurar o Slony! Ele possue uma sintaxe própria no qual vamos especi-
ficando as caracterı́sticas do nosso Cluster.

Observações:
Um nó que seja Provider ele é orbigatoriamente subscribe também, pois ele é
subscribe de um nó e provider de outro.
Como veremos asseguir, é através do slonik que configuramos o nosso cluster.
Posso configurar sem utlizar o slonik? Pode mas dá um trabalho enorme e
você tem que ter amplo conhecimento dos objetos de banco de dados que são
necessários para o Slony-I rodar(Tabelas,Funcões,Views).
4 Instalando o Slony-I
O slony-I está atualmente na versão 1.2.0 (26/06/2007), e é essa versã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 instalação é extremamente simples e não causa muitos danos


emocionais!
5 Configurando o Slony-I !!!
5.1 Cenário
Para configurarmos o nosso cluster de Banco de dados postgresql, elaboraremos
o seguinte cenário que vai ser utilizado como estudo de caso.

1. Nosso Cluster de Banco de dados vai ser formado por 4 má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 nó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 será o nó origem de toda replicação.


5. Inicialmente todos os outros 3 nós vão ser replicados a partir do hot ja-
tiuca.
6. Trocaremos a topologia do Cluster.
7. Faremos um nó escravo assumir o lugar de um master.
Em todos os nó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 Configuração
Deveremos seguir alguns passos para configuração sem erros,e que nos propor-
ciona fácil manutenção.
1. Configurar as conexões dos nós e o nome do nosso Cluster.
2. Configurar quem é o nó Master e sãos os nós Escravos.
3. Configurar a comunicação entre os nós.
4. Configurar quais tabelas e sequências devem ser replicadas.
5. Colocar o slon pra rodar!
6. Configurar quem é Provider de quem( Topologia )
Essas tarefas são realizadas através do slonik.
7 Configurando as conexões dos nós
Devemos criar um arquivo chamado pg service.conf e deve ser copiado para a
pasta $PGDATA/etc
( Deve-se criar o diretó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. É esse arquivo que vai
possibilitar o slonik (que já foi comentado acima! ) se conectar nos hosts e
construir toda a estrutura de replicação necessária. Devemos observar que as
entradas do arquivo pg service.conf serã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
————————————————————————————

Observaçõ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 fácil fazer a ma-

nutenção no arquivo porque colocamos ao invés da string


... admin conninfo=’dbname=db praias host=10.1.0.2 user=postgres’
utlizamos o nome da conexão que ja esta mapeada no arquivo!!!
... admin conninfo=’service=barra’;

Outra vantagem que temos para garantir a facilidade de manutenção


sao os defines, que funcionam como variáveis!

8 Configurando o Nó Master e os nós escravos


Devemos criar um arquivo chamado initcluster.sk, nesse arquivo iremos deter-
minar quem é o nó primário e quais são os nós escravos.
Arquivo initcluster.sk

————————————————————————————

#!/usr/local/pgsql/bin/slonik
include preamble.sk
### Adivinha o motivo desse include? fica de lição de casa!
### init cluster(id=id-origem,comment=’comentario’);
### Indica quem é o nó de origem da replicação

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

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


### Indica quem são os nó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 comunicações entre os nós


Devemos configurar como cada nó do Cluster deve se comunicar com os outros
participantes, para isso criaremos outro arquivo chamado path.sk

3
Arquivo path.sk

————————————————————————————

#!/usr/local/pgsql/bin/slonik
include preamble.sk
### Já 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’);

————————————————————————————

Observações:
O caminho entre 2 nós tem sempre a ida e a volta. Se eu estabeleço um caminho
entre um nó X ao nó Z então faço o contrário, do nó Z ao nó X.
Viu como é mais fácil o uso do preamble.sk? nao??? Então olha como é legal
fazer a manutenção nisso!
Imagina um Cluster com dezenas de nó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 sequências de-


vem ser replicadas
Os objetos de banco de dados que podemos replicar através do Slony-I são:
tabelas e sequências.
Vamos entender como as coisas funcionam:

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


objetos que vão ser replicados. Set em inglês significa conjunto.

4
2. Dentro do set informamos quais tabelas e sequências devem ser replicadas.

Então mais uma vez criaremos outro arquivo: sets.sk

Arquivo sets.sk

————————————————————————————

#!/usr/local/pgsql/bin/slonik
include preamble.sk
### Já sabe o motivo do include?Ainda não? Sé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 sequê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 sequê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’);
set add table(id = 1, origin= @jatiuca, id = 2, @fqn =’public.tabela2’);
set add table(id = 1, origin= @jatiuca, id = 3, @fqn =’public.tabela3’);
set add table(id = 1, origin= @jatiuca, id = 4, @fqn =’public.tabela4’);
set add table(id = 1, origin= @jatiuca, id = 5, @fqn =’public.tabela5’);
set add table(id = 1, origin= @jatiuca, id = 6, @fqn =’public.tabela6’);
set add table(id = 1, origin= @jatiuca, id = 7, @fqn =’public.tabela7’);
set add table(id = 1, origin= @jatiuca, id = 8, @fqn =’public.tabela8’);
set add table(id = 1, origin= @jatiuca, id = 9, @fqn =’public.tabela9’);
set add table(id = 1, origin= @jatiuca, id = 1, @fqn =’public.tabela10’);

————————————————————————————
Observações:
Recapitulando... Primeiro criamos o SET, depois definimos quais
objetos vão ser replicados.
Necessariamente as tabelas devem ter chaves primárias..
Se as tabelas não tiverem chave primária (Bem segundo o modelo
relacional .... mas isso e outra tema)devem ter indices únicos e você
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 você leitor, (acho isso comédia demais!) já deve estar ancioso pra
replicar uma única tabela! calma vamos lá!
No momento temos os seguintes arquivos:

pg service.conf
preamble.sk
initcluster.sk
path.sk
sets.sk

Todos os nós do Cluster obviamente devem ter instalados o Slony-I, post-


gresql (Isso já foi dito e não me canso de dizer.)
O arquivo pg service.conf deve estar em todos os hosts no diretório $PGDATA/etc,
então trate de copiá-lo agora mesmo.
No meu cenário existe um diretório /usr/loca/pgsql/etc/pg service.conf nos
hosts jatiuca,barra,frances,maragogi.
vamos tornar os arquivos executá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”

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit


index ”sl nodelock-pkey”for table ”sl nodelock”
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl set-pkey”for table ”sl set”
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl setsync-pkey”for table ”sl setsync”
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl table-pkey”for table ”sl table”
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl trigger-pkey”for table ”sl trigger”
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
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
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl path-pkey”for table ”sl path”
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl listen-pkey”for table ”sl listen”
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl subscribe-pkey”for table ”sl subscribe”
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl event-pkey”for table ”sl event”
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index ”sl registry pkey”for table ”sl registry”

Algumas mensagens vão surgir na sua tela! O que o slonik esta fazendo é o
seguinte:
Ele se conecta nos bancos de dados que participarão na replicação, cria um es-
quema novo com o nome do Cluster que nós definimos láaaaa no começ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 replicação necessária para o funcionamento, totalizando 25 objetos
dentro desse esquema entre tabelas,sequê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 nó do Cluster crie os seguintes arquivos:


jatiuca.slon
barra.slon
frances.slon
maragogi.slon
Cada arquivo correspondente em cada máquina!
jatiuca.slon em uma maquina,barra.slon em outra máquina, frances.slon em ou-
tra má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
————————————————————————————

cluster name = ’teste’


conn info=’service=barra’

————————————————————————————

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

frances.slon
————————————————————————————

cluster name = ’teste’


conn info=’service=frances’

————————————————————————————

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

maragogi.slon
————————————————————————————

cluster name = ’teste’


conn info=’service=maragogi’

————————————————————————————

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


Nesse momento startamos os daemon em todas as maquinas, e elas começaram a

trocar SYNCS. O nó de origem começa a puxar um histórico de cada modificacao


da tabela TESTE.sl log l e mandad SYNCS para todos os nós subscribers. Mas
como não definimos ainda a topologia a replicação ainda não acontece.

8
12 Definindo a Topologia
Para definirmos a topologia, criamos um arquivo chamado subscribe.sk.

subscribe.sk
————————————————————————————

#!/usr/local/pgsql/bin/slonik
include preamble.sk;
#Sem querer ser chato, ainda nã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 replicação
# e todos os nós irã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 explicações!

id = indica que replication set queremos replicar.

provider = indica qual nó que proverá a replicação.

receiver = indica qual nó irá receber a replicação.

forward = TRUE ou FALSE, se TRUE o nó subscribe retém uma cópia dos
dados para poder prover para outros nós subscribers, caso contrário false.

Devemos dar permissão de execução ao arquivo. chmod 700 subscribk.sk


Devemos executá-lo
./subscribe.sk

A partir desse momento todos os dados irão ser replicados!!!

9
13 Alterando a topologia!
Agora vamos alterar a topologia do Cluster!
Vamos obter o seguinte cenário!

1. jatiuca é o nó origem de toda a replicação.


2. frances é subscribe de jatiuca e provider para barra.
3. barra é subscribe de frances e provider de maragogi.

Então temos o seguinte: jatiuca - frances - barra - maragogi Se lembra do arquivo


subscribe.sk?? Vamos editá-lo da seguinte maneira!

subscribe.sk
————————————————————————————

#!/usr/local/pgsql/bin/slonik
include preamble.sk;
#Sem querer ser chato, ainda nã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 replicação
# e todos os nós irã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 é só executar o script ./subscribe.sk, e observar as mensagens


de alteração dos subscribers!!!

14 Mudando o nó de origem


Temos duas situações para mudar o nó de origem:
1. O nó de origem está rodando.
2. O nó de origem caiu, ou esta fora do ar!

14.1 Nó de origem está rodando


Vamos mudar o nó de origem de toda replicação para o nó 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 é executado, Slony troca os papéis entre
a antiga origem e a nova origem. A antiga origem ainda faz parte da
replicação mas agora é um simples subscribe!

14.2 Nó de origem caiu ou esta fora do ar


Vamos mudar o nó de origem de toda a replicação para o nó frances!;

include preamble.sk
failover(id=@jatiuca, backup node = @frances);