14
Configurando Replica Sets no MongoDB
Filed Under (Desenvolvimento) by Samir on 14-08-2010
Tagged Under : mongodb
Atualmente de tudo o que venho utilizando no trabalho, o MongoDB sem sobra de dúvidas é uma das coisas mais empolgantes que ja vi nesses 3 últimos anos. A sensação é a mesma nos tempos antigos quando em 2003 migrei de ASP 3.0 para .NET (C#), depois em 2007 de .NET para Ruby on Rails e hoje 2010 trabalhando MongoDB e Python.
Bom, nesse post vamos falar um pouco do Replica Sets, um recurso novo que foi introduzido na versão 1.6 lançada recentemente.
O Replica Sets é um novo método de replicação com o mesmo conceito de Master/Slave Replication, porém, vai mais longe, também oferece o recurso de alta disponibilidade e recuperação automática entre os membros de um cluster.
Para trabalhar com Replica Sets você precisa ter em mente uma coisa, ter pelo menos um banco PRIMARY (Master) e N bancos SECONDARY (Slave), nesse caso vamos usar 3 bancos para replicação.
Configurando o Cluster
Crie 3 diretórios para cada banco de dados:
mkdir -p /data/db/rep0 mkdir -p /data/db/rep1 mkdir -p /data/db/rep2
Agora iremos iniciar 3 processos do MongoDB com o parâmetro –replSet.
./mongod --replSet teste --dbpath=/data/db/rep0 --port=10000 ./mongod --replSet teste --dbpath=/data/db/rep1 --port=10001 ./mongod --replSet teste --dbpath=/data/db/rep2 --port=10002
Se você reparar em cada processo, irá exibir a seguinte mensagem:
Sat Aug 14 16:30:19 [startReplSets] replSet can't get local.system.replset config from self or any seed (EMPTYCONFIG)
Isso indica que o sistema de replicação ainda não está funcionando pois ainda não foi inicializado.
Inicializando o Cluster
Para configurar o replica set, podemos conectar em qualquer um dos membros e passar um objeto de configuração pelo comando replSetInitiate.
./mongo localhost:10000
[samirmamude ~$]$ mongo localhost:10000
MongoDB shell version: 1.6.0
connecting to: localhost:10000/test
> config = {_id: 'teste', members: [
{_id: 0, host: 'localhost:10000'},
{_id: 1, host: 'localhost:10001'},
{_id: 2, host: 'localhost:10002'}]
}
> rs.initiate(config);
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}
Uma coisa muito legal é que em momento algum estamos informando explicitamente qual banco deve ser Master ou Slave, se você obvservar os logs o próprio Cluster decide por votação quem deve ser o Master e os demais como Slaves.
Para saber informações do cluster, digite o seguinte comando no shell.
rs.status()
Replication
Ainda conectado no shell, vamos inserir um registro qualquer.
db.post.save({titulo:"MongoDB e Replica Sets"});
Veja o log de cada banco Slave e observe como a informação é replicada entre os bancos.
Failover
Agora sem dúvida o recurso mais interessante do Replica Sets é a capacidade de alta disponibilidade. Imagine que por alguma falha ou acidente o banco Master para de funcionar. No caso vamos de propósito parar o processamento do banco Master.
^CSat Aug 14 16:50:16 got kill or ctrl c or hup signal 2 (Interrupt), will terminate after current cmd ends Sat Aug 14 16:50:16 [interruptThread] now exiting Sat Aug 14 16:50:16 dbexit:
Observando o log do primeiro banco Slave, você verá uma série de mensagens indicando um failover.
Sat Aug 14 16:50:16 [ReplSetHealthPollTask] replSet info localhost:10000 is now down (or slow to respond) Sat Aug 14 16:50:17 [conn1] replSet info voting yea for 2 Sat Aug 14 16:50:17 [rs Manager] replSet not trying to elect self as responded yea to someone else recently Sat Aug 14 16:50:27 [rs_sync] replSet SECONDARY
No segundo Slave:
Sat Aug 14 16:50:17 [ReplSetHealthPollTask] replSet info localhost:10000 is now down (or slow to respond) Sat Aug 14 16:50:17 [rs Manager] replSet info electSelf 2 Sat Aug 14 16:50:17 [rs Manager] replSet PRIMARY Sat Aug 14 16:50:27 [initandlisten] connection accepted from 127.0.0.1:61263 #5
Note que ambos notificaram que algo de errado aconteceu com o Master sendo assim, uma nova votação é realizada para decidir um novo Master, no caso nosso segundo Slave (10002), se você voltar o processamento do membro 10000, ele voltará como Slave, muito interessante não?
Isso acaba sendo muito útil caso você tenha uma aplicação com um grande volume de dados onde o principal requisito é a alta disponibilidade. Pois mesmo que um banco de dados pare de funcionar, sua aplicação dificilmente vai apresentar algum problema porque uma nova conexão é realizada com o novo Master eleito pelo cluster.
Para saber mais informações de Replica Sets, veja a prórpria documentação.
)
