NoSQl – parte 2 (MongoDB)

Continuando (antes tarde do que nunca) com a segunda parte do tutorial, vamos ver como construir agora uma arquitetura distribuida com MongoDB, fazendo uso da feature ReplicaSet. Para isso, vou supor que você tenha o MongoDB instalado, e/ou adicionado no seu PATH.

Arquitetura

Teoricamente, teremos 3 máquinas: server1, server2 e arbiter. Ok, server1 e server2 eu sei pra que serve, mas pra que eu preciso de um arbiter? Um arbiter (arbitro) é um servidor que monitora os membros da nossa infraestrutura (arquitetura, replicaset, chame do que quiser) e quando o nosso master cai por algum motivo, ele escolhe (por meio de votes) um outro nó da nossa infraestrutura para ser o novo master, garantindo assim, alta disponibilidade da aplicação.

Montando a infraestrutura

Vamos manter a seguinte convenção: server1 é o master e server2 é o slave.

Com isso em mente, vamos até o server1 e inicializamos o processo mongod nele, da seguinte forma:

mongod –rest –replSet geek

Atente para o parâmetro replSet. É o nome lógico do nosso ReplicaSet. Se formos verificar o status do ReplicaSet agora (rs.status()) teremos o seguinte retorno:

rs.status()

{

“startupStatus” : 3,

“errmsg” : “can’t get local.system.replset (EMPTYCONFIG)”,

“ok” : 0

}

Isso acontece por que nós ainda não inicializamos o nosso ReplicaSet. Vamos iniciar ele agora fazendo isso:

rs.initiate()

{

“info2″ : “no configuration explicitly specified — making one”,

“info” : “Config now saved locally. Should come online in about a minute.”,

“ok” : 1

}

Agora, o comando rs.status() vai ficar um pouco mais legal

rs.status()

{

“set” : “geek”,

“myState” : 1,

“members” : [

{

"name" : "mb17:27017",

"self" : true

}

],

“ok” : 1

}

Mas de acordo com a tag members, nós só temos um membro no nosso ReplicaSet ainda. Vamos deixar as coisas mais excitates ainda, adicionado outro membro à nossa infraestrutura. Para isso, vamos ao nosso server2 e iniciamos o processo mongod da mesma forma que fizemos no nosso master:

mongod –rest –replSet geek

Aqui, seu outro servidor deve ter iniciado corretamente, mas o nosso master (server1) ainda não sabe que existe outro membro na nossa infraestrutura. Vamos mudar essa história, e fazer com que eles sejam amiguinhos

No server1, apenas adicionamos o server2 ao ReplicaSet da seguinte forma:

rs.add(“server2”);

(Lembrando, esse comando rs.add está disponivel dentro do console do MongoDB, com o comando mongo).

Agora, um rs.conf() nos mostrará a configuração, e retornará algo muito mais legal do que antes:

rs.conf()

{

“_id” : “geek”,

“version” : 2,

“members” : [

{

"_id" : 0,

"host" : “sf1"

},

{

"_id" : 1,

"host" : “sf2"

}

]

}

Se você acessar a pagina “http://server1:28017/_replSet” veremos os dois membros la, mas ambos tem 1 voto. Caso o master caia, ninguem será o master (pensando em uma arquitetura maior) visto que teremos um empate. Vamos adicionar o nosso arbitro nesse ReplicaSet:

mongod –rest –replSet geek –oplogSize 8

Um arbitro, praticamente não consoem recursos da maquina, e pode rodar em uma maquina 32bits.

Agora, temos um arbitro rodando, mas ainda a nossa arquitetura não sabe da existencia dele. Vamos adicionar ele:

rs.add( { _id:2, host:”arbiter”, arbiterOnly:true } )

Derrube o master, e acesse a pagina “http://server2:28017/_replSet” e você verá que o nosso server2 se tornou o master da nossa arquitetura.