Samir MamudeSimplicidade é a maior forma de sofisticação

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.