MongoDB – Converter Standalone em ReplicaSet
Vamos voltar para administração de MongoDB? O ponto que iremos falar hoje é sobre redundância e alta disponibilidade. O responsável por isso é o chamado ReplicaSet, que é muito bem definido na documentação. Vamos tentar deixar a linguagem mais simples, com um passo a passo baseado em tudo o que já fizemos até aqui. Portanto, se você é um DBA é agora que os artigos começam ficar mais interessantes e indo para o ponto de vista que gostamos. Nosso ponto de partida foi descrito em dois artigos que anteriores que eram ter um container com o MongoDB instalado e rodando em modo standalone.
Replicaset vs Standalone
A documentação diz sobre ReplicaSet: “É um grupo de processos mongod que mantém o mesmo conjunto de dados. Ele provê redundância e alta disponibilidade e deve ser base para todo deploy em ambiente de produção.”
Note um ponto interessante, em que a doc não diz que precisa ser hosts diferentes. Porém, ninguém em sã consciência vai colocar sua redundância no mesmo host. Desta forma, criaremos mais containers docker para abrigar nossas réplicas.
Explicando um pouco melhor como isso funciona, podemos nos basear em outros bancos de dados. É comum termos em produção um ambiente primário replicando as escritas (insert/update/delete) para um ambiente secundário, que estará disponível caso o primário falhe. É isso que o ReplicaSet faz. Teremos um ambiente primário que recebe todas as escritas replicando dados para ambientes secundários, que opcionalmente podem receber leitura.
Ele orquestra a replicação de forma simples e clusterizada, sem necessidade de muita configuração, como em um Oracle Dataguard, por exemplo. Além disso, a alta disponibilidade vem de brinde: em caso de falha, automaticamente outro host assume o papel de primário.
No MongoDB podemos ter até 50 membros em cada ReplicaSet, porém o mais comum é ter 3 membros, preferencialmente em regiões geográficas ou datacenters diferentes. Vou discutir melhor detalhes sobre votação e eleição de um novo primary, número de membros e afins. Por enquanto, vamos focar em montar nosso primeiro e simples ReplicaSet.
E para fechar o assunto, um MongoDB é classificado como standalone exatamente em uma situação oposta, quando não faz parte de nenhuma estrutura de cluster (ReplicaSet). Esta estrutura standalone não é recomendada para produção, utilize apenas em ambiente de testes em que você pode eventualmente perder dados em caso de crash e pode ter algum downtime para recuperá-lo a partir de um backup antigo.
O MongoDB que temos rodando no container mymongo1 é um standalone e precisamos convertê-lo para ReplicaSet para chegar nosso objetivo que será ter dados replicando do mymongo1 -> mymongo2. Este procedimento de conversão está bem detalhado na documentação.
Converter standalone em ReplicaSet
Voltemos para nosso container mymongo1 para seguir esse procedimento. Quando instalamos e subimos o MongoDB pela primeira vez, ignoramos boa parte do arquivo de configuração. É lá que precisamos começar, dizendo ao MongoDB que agora ele faz parte de um ambiente com replicação. Lá o trecho replication estava comentado e agora vamos descomentá-lo.
Serão duas linhas, a primeira dizendo que agora há replicação e a segunda nomeando nosso ReplicaSet. Um detalhe importante é que aqui ainda estamos com nosso MongoDB rodando sem nenhuma forma de autenticação. Quando falarmos de autenticação, vamos avançar um pouco mais nesta configuração. Por enquanto, as novas linhas serão:
replication:
replSetName: "rsYadax0"
Agora o arquivo deve estar da seguinte forma (as linhas iniciadas com # são ignoradas):
[root@mymongo1 /]# cat /etc/mongod.conf
# mongod.conf
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# Where and how to store data.
storage:
dbPath: /var/lib/mongo
journal:
enabled: true
# engine:
# wiredTiger:
# how the process runs
processManagement:
fork: true # fork and run in background
pidFilePath: /var/run/mongodb/mongod.pid # location of pidfile
timeZoneInfo: /usr/share/zoneinfo
# network interfaces
net:
port: 27017
bindIp: 0.0.0.0 # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses or, alternatively, use the net.bindIpAll setting.
#security:
#operationProfiling:
replication:
replSetName: "rsYadax0"
#sharding:
## Enterprise-Only Options
#auditLog:
#snmp:
Feito isso, precisamos restartar o nosso mongod. Vamos dar um kill -15 (nunca use o kill -9) e subi-lo novamente. Existem algumas formas de achar o PID do processo do mongod. A mais prática é pegar o processo em execução. Veja:
[root@mymongo1 /]# ps -ef | grep mongod | grep -v grep
root 287 1 1 Jan14 ? 00:23:13 mongod -f /etc/mongod.conf
[root@mymongo1 /]# kill -15 287
[root@mymongo1 /]# ps -ef | grep mongod | grep -v grep
[root@mymongo1 /]#
Feito isso, só subir o MongoDB novamente usando o novo arquivo de conf.
[root@mymongo1 /]# mongod -f /etc/mongod.conf
about to fork child process, waiting until server is ready for connections.
forked process: 409
child process started successfully, parent exiting
[root@mymongo1 /]#
Após isso, você vai se conectar no mongosh e tudo vai parecer igual. Em seguida, o comando mágico é o rs.initiate(). Ele vai transformar nosso standalone em um ReplicaSet. Após o primeiro comando, o status ficará other e após um tempo, vira primary. Veja:
test> rs.initiate()
{
info2: 'no configuration specified. Using a default configuration for the set',
me: 'mymongo1:27017',
ok: 1
}
rsYadax0 [direct: other] test>
rsYadax0 [direct: primary] test>
A partir de agora, sempre que você se conectar no MongoDB usando o mongosh o prompt vai te mostrar o nome do ReplicaSet (rsYadax0) e o papel que ele está assumindo (primary). Opcionalmente podemos iniciar o ReplicaSet já informando membros e várias outras configurações. Vamos manter simples e adicionar membros manualmente.
Por último, para aqueles que gostam de mais, o log vai registrar bastante coisa interessante. Vale dar uma olhada em /var/log/mongodb/mongod.log e conferir no detalhe tudo que acontece.
Finalizamos a conversão do nosso standalone em ReplicaSet. No próximo artigo vamos adicionar mais membros a este ReplicaSet. Até lá.
Tag:mongodb
Você também pode gostar
MongoDB – Queries com operadores
Login com: Google