MongoDB – Vamos entender a alta disponibilidade
Agora que passamos pela construção do nosso ReplicaSet e troca de papéis entre Primary e Secondary, vamos avançar e ver como tudo isso é feito de forma automática em um ambiente de produção. Vimos também que em um ReplicaSet com dois membros não temos alta disponibilidade, visto que com qualquer um dos membros down provoca a queda de todos (pelo menos para escrita).
Nosso próximo passo será adicionar o último membro na configuração e verificar que podemos perder um membro sem impactar a disponibilidade.
Adicionando o terceiro membro
Atualmente nosso ambiente está assim:
rsYadax0 [direct: primary] test> rs.status().members
[
{
_id: 0,
name: 'mymongo1:27017',
health: 1,
state: 2,
stateStr: 'SECONDARY',
...
},
{
_id: 1,
name: 'mymongo2:27017',
health: 1,
state: 1,
stateStr: 'PRIMARY',
...
}
]
Vamos adicionar o mymongo3. Lembre-se que aqui<https://yadax.com.br/mongodb/mongodb-adicionando-membros-no-replicaset/> deixamos todos os arquivos de conf idênticos e o mongod rodando.
Em seguida, conferir se o mongod ainda está em execução no mymongo3 e adicionamos o membro no cluster.
[root@mymongo3 /]# ps -ef | grep mongo | grep -v grep
root 157 1 2 Jan16 ? 03:18:53 mongod -f /etc/mongod.conf
[root@mymongo3 /]#
No Primary:
rsYadax0 [direct: primary] test> rs.add('mymongo3:27017')
{
ok: 1,
'$clusterTime': {
clusterTime: Timestamp({ t: 1642851881, i: 1 }),
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: Long("0")
}
},
operationTime: Timestamp({ t: 1642851881, i: 1 })
} Agora nosso membros são:
rsYadax0 [direct: primary] test> rs.status().members
[
{
_id: 0,
name: 'mymongo1:27017',
health: 1,
state: 2,
stateStr: 'SECONDARY',
...
},
{
_id: 1,
name: 'mymongo2:27017',
health: 1,
state: 1,
stateStr: 'PRIMARY',
...
},
{
_id: 2,
name: 'mymongo3:27017',
health: 1,
state: 2,
stateStr: 'SECONDARY',
...
}
]
Alta disponibilidade
Temos 3 membros, a quantidade mínima recomendada para qualquer ambiente de produção. E vamos entender o porquê. Com número de membros par, a maioria é a metade mais um. Com dois membros a maioria é dois, com quatro membros a maioria é três, com seis membros é quatro, e assim por diante.
O que é importante notar é que com três ou quatro membros só podemos perder um. Com cinco ou seis, só podemos perder 2. Por isso acaba sendo mais interessante manter um número ímpar de nodes.
Vamos testar nossa configuração. Temos três membros e vamos derrubar o Primary. Mantenha a sessão do mongosh aberta no mymongo1 e no mymongo3, algum deles vai virar Primary.
rsYadax0 [direct: primary] test> db.shutdownServer()
MongoNetworkError: connection 1 to 127.0.0.1:27017 closed
test>
No meu caso quem assumiu o papel de Primary foi o mymongo1.
rsYadax0 [direct: primary] test> rs.status().members
[
{
_id: 0,
name: 'mymongo1:27017',
health: 1,
state: 1,
stateStr: 'PRIMARY',
...
},
{
_id: 1,
name: 'mymongo2:27017',
health: 0,
state: 8,
stateStr: '(not reachable/healthy)',
...
lastHeartbeatMessage: 'Error connecting to mymongo2:27017 (172.100.0.12:27017) :: caused by :: Connection refused',
...
},
{
_id: 2,
name: 'mymongo3:27017',
health: 1,
state: 2,
stateStr: 'SECONDARY',
...
}
]
O lado bom de tudo isso é que perdemos o membro e tudo está funcionando normalmente. A troca ocorre de forma automática, sem precisarmos da atuação de um DBA. Subindo novamente o mongod no mymongo2, ele volta à configuração e a syncar também sem precisar de atuação.
Caso queira ler mais sobre o assunto, aqui fica a documentação.
Temos mais alguns pontos para tratar sobre ReplicaSet nos próximos artigos, como usar o método rs.reconfig(), como fica a configuração do ReplicaSet com autenticação e mais. Vamos nos vendo por lá. Até mais.
Tag:mongodb
Você também pode gostar
MongoDB – Queries com operadores
Login com: Google