Guia passo a passo para configurar um ReplicatSet no MongoDB
O MongoDB é um banco com foco em escalabilidade horizontal, sendo assim ele possui um recurso chamado ReplicatSet que serve para replicar os dados em um cluster de servidores para garantir redundância em caso de indisponibilidade e integridade dos dados.
Preparação do mongodb
Para criar um ReplicatSet no MongoDB eu criei 3 instâncias t2.micro na AWS com o RedHat Enterprise Linux 7.
As 3 máquinas ficaram o seguinte:
192.168.0.2 mongoprimary
192.168.0.3 mongoreplica1
192.168.0.5 mongoreplica2
Essas entradas foram adicionadas dentro do /etc/hosts de todas as máquinas.
Agora o repositório do MongoDB também deve ser configurado em todas as máquinas.
vim /etc/yum.repos.d/mongodb-org-3.4.repo # conteudo abaixo foi adicionado no arquivo acima [mongodb-org-3.4] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.4/x86_64/ gpgcheck=1 enabled=1 gpgkey=https://www.mongodb.org/static/pgp/server-3.4.asc
Agora a instalação do MongoDB precisa ser realizada em todos os servidores:
yum -y install mongodb-org
Configuração da replicação
Dentro do servidor mongoprimary vou iniciar o mongodb dizendo que ele faz parte de uma replica chamada “rs0”, que significa replica set 0.
mongod --port 27017 --replSet "rs0" &
Com o serviço do Mongo DB em execução, pode-se acessar o console.
[root@mongoservice data]# mongo MongoDB shell version v3.4.3 connecting to: mongodb://127.0.0.1:27017 >
Dentro do console do Mongo DB será necessário digitar o comando abaixo:
> rs.initiate()
Esse comando irá iniciar o modo replica e indicará que esse é o servidor primário do cluster.
Agora nas outras duas instâncias eu rodei o mesmo comando:
mongod --port 27017 --replSet "rs0" &
Sendo assim todas as instancias fazem parte do mesmo replicaset, mesmo ainda não tendo conectividade entre sí.
Agora dentro do console do servidor primario ainda é necessário executar os seguintes comandos:
> rs.add("192.168.0.3")
> rs.add("192.168.0.4")
E automaticamente os servidores já foram adicionados como replica.
Resultado final
Para verificar como ficou a configuração final do seu cluster é só digitar o comando abaixo:
rs0:PRIMARY> rs.config()
{
"_id" : "rs0",
"version" : 4,
"protocolVersion" : NumberLong(1),
"members" : [
{
"_id" : 0,
"host" : "mongoservice:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 10,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "192.168.0.2:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 2,
"host" : "192.168.0.3:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : 2000,
"getLastErrorModes" : {
},
"getLastErrorDefaults" : {
"w" : 1,
"wtimeout" : 0
},
"replicaSetId" : ObjectId("58dbf0fc8becc34a89e7f3fa")
}
}
Ou para ver o status do cluster pode ser executado o comando abaixo:
rs0:PRIMARY> rs.status()
{
"set" : "rs0",
"date" : ISODate("2017-03-29T19:09:59.077Z"),
"myState" : 1,
"term" : NumberLong(9),
"heartbeatIntervalMillis" : NumberLong(2000),
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1490814595, 1),
"t" : NumberLong(9)
},
"appliedOpTime" : {
"ts" : Timestamp(1490814595, 1),
"t" : NumberLong(9)
},
"durableOpTime" : {
"ts" : Timestamp(1490814595, 1),
"t" : NumberLong(9)
}
},
"members" : [
{
"_id" : 0,
"name" : "mongoservice:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1265,
"optime" : {
"ts" : Timestamp(1490814595, 1),
"t" : NumberLong(9)
},
"optimeDate" : ISODate("2017-03-29T19:09:55Z"),
"electionTime" : Timestamp(1490813345, 1),
"electionDate" : ISODate("2017-03-29T18:49:05Z"),
"configVersion" : 4,
"self" : true
},
{
"_id" : 1,
"name" : "107.23.94.24:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1263,
"optime" : {
"ts" : Timestamp(1490814595, 1),
"t" : NumberLong(9)
},
"optimeDurable" : {
"ts" : Timestamp(1490814595, 1),
"t" : NumberLong(9)
},
"optimeDate" : ISODate("2017-03-29T19:09:55Z"),
"optimeDurableDate" : ISODate("2017-03-29T19:09:55Z"),
"lastHeartbeat" : ISODate("2017-03-29T19:09:57.916Z"),
"lastHeartbeatRecv" : ISODate("2017-03-29T19:09:57.230Z"),
"pingMs" : NumberLong(0),
"syncingTo" : "mongoservice:27017",
"configVersion" : 4
},
{
"_id" : 2,
"name" : "54.197.121.234:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1263,
"optime" : {
"ts" : Timestamp(1490814595, 1),
"t" : NumberLong(9)
},
"optimeDurable" : {
"ts" : Timestamp(1490814595, 1),
"t" : NumberLong(9)
},
"optimeDate" : ISODate("2017-03-29T19:09:55Z"),
"optimeDurableDate" : ISODate("2017-03-29T19:09:55Z"),
"lastHeartbeat" : ISODate("2017-03-29T19:09:57.916Z"),
"lastHeartbeatRecv" : ISODate("2017-03-29T19:09:57.462Z"),
"pingMs" : NumberLong(0),
"syncingTo" : "107.23.94.24:27017",
"configVersion" : 4
}
],
"ok" : 1
}
About author
Você pode gostar também
Conexão com Cluster Kafka Hospedado em Kubernetes: Guia Completo
Nesse artigo vamos discutir questões relacionadas a como disponibilizar um cluster kafka hospedado em um k8s para aplicações que estejam hospedadas fora do cluster kubernetes. Não vamos tratar da instalação
Conhecendo o kernel Linux pelo /proc (parte 5) – Recursos da memória virtual
No post anterior vimos comportamentos relacionados ao uso de memória de virtual, como a “sobre-alocação” de memória, uso de SWAP, estouro de memória RAM e o que pode ocorrer em
Workshop Infraestrutura Ágil: Conheça as ferramentas DevOps da 4Linux
No dia 10/11/2016, aconteceu na sede da 4linux em São Paulo o workshop “Infraestrutura Ágil”. A procura foi grande pois o público estava muito interessado em ouvir sobre DOCKER, GIT,






