MongoDB – Como trocar papéis Primary/Secondary – rs.stepDown()
No último artigo falamos como identificar os membros que participam de um ReplicaSet e seus papéis. Agora vamos conversar um pouco sobre como podemos trocar de papéis usando o rs.stepDown(). A situação pode ser algo assim: seu cliente deseja fazer uma manutenção programada no site principal e quer deixar o banco rodando no site DR. Nós ainda temos um problema com a quantidade de membros, mas não vou focar nisso agora. O que queremos aqui é saber como inverter Primary x Secondary.
O método rs.stepDown() (veja a doc aqui) faz com que o Primary deixe de fazer esse papel e se torne um Secondary. Se houver outros membros disponíveis, alguém assumirá o papel de Primary. Vamos manter as duas sessões do mongosh abertas, no mymongo1 e no mymongo2. Se você curte acompanhar os logs, terá bastante coisa por lá também.
ReplicaSet Stepdown
No Primary (mymongo1):
rsYadax0 [direct: primary] test> rs.stepDown()
{
ok: 1,
'$clusterTime': {
clusterTime: Timestamp({ t: 1642706894, i: 2 }),
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: Long("0")
}
},
operationTime: Timestamp({ t: 1642706894, i: 2 })
}
rsYadax0 [direct: secondary] test>
Se você apertar o <ENTER> no mymongo2 verá que ele assumiu o papel de Primary.
rsYadax0 [direct: secondary] test>
rsYadax0 [direct: primary] test>
No log do mymongo1, o primeiro evento que vemos:
{"t":{"$date":"2022-01-20T19:28:19.080+00:00"},"s":"I", "c":"COMMAND", "id":21579, "ctx":"conn51","msg":"Attempting to step down in response to replSetStepDown command"} No log do mymongo2, vemos que haverá uma eleição (falaremos sobre isto em outro artigo):
{"t":{"$date":"2022-01-20T19:28:19.102+00:00"},"s":"I", "c":"COMMAND", "id":21581, "ctx":"conn6","msg":"Received replSetStepUp request"}
{"t":{"$date":"2022-01-20T19:28:19.102+00:00"},"s":"I", "c":"ELECTION", "id":4615661, "ctx":"conn6","msg":"Starting an election due to step up request"} Por fim, olhando novamente para os membros no status do ReplicaSet, veremos que o mymongo2 é o novo primary e ele deixa registrado o momento da eleição (electionDate):
rsYadax0 [direct: primary] test> rs.status().members
[
{
_id: 0,
name: 'mymongo1:27017',
health: 1,
state: 2,
stateStr: 'SECONDARY',
uptime: 250365,
optime: { ts: Timestamp({ t: 1642707169, i: 1 }), t: Long("2") },
optimeDurable: { ts: Timestamp({ t: 1642707169, i: 1 }), t: Long("2") },
optimeDate: ISODate("2022-01-20T19:32:49.000Z"),
optimeDurableDate: ISODate("2022-01-20T19:32:49.000Z"),
lastAppliedWallTime: ISODate("2022-01-20T19:32:49.147Z"),
lastDurableWallTime: ISODate("2022-01-20T19:32:49.147Z"),
lastHeartbeat: ISODate("2022-01-20T19:32:49.283Z"),
lastHeartbeatRecv: ISODate("2022-01-20T19:32:50.327Z"),
pingMs: Long("0"),
lastHeartbeatMessage: '',
syncSourceHost: 'mymongo2:27017',
syncSourceId: 1,
infoMessage: '',
configVersion: 3,
configTerm: 2
},
{
_id: 1,
name: 'mymongo2:27017',
health: 1,
state: 1,
stateStr: 'PRIMARY',
uptime: 362979,
optime: { ts: Timestamp({ t: 1642707169, i: 1 }), t: Long("2") },
optimeDate: ISODate("2022-01-20T19:32:49.000Z"),
lastAppliedWallTime: ISODate("2022-01-20T19:32:49.147Z"),
lastDurableWallTime: ISODate("2022-01-20T19:32:49.147Z"),
syncSourceHost: '',
syncSourceId: -1,
infoMessage: '',
electionTime: Timestamp({ t: 1642706899, i: 1 }),
electionDate: ISODate("2022-01-20T19:28:19.000Z"),
configVersion: 3,
configTerm: 2,
self: true,
lastHeartbeatMessage: ''
}
]
No próximo artigo vou simular uma falha em um destes hosts para gente entender qual é o problema com a configuração com apenas dois membros e vamos entender melhor como funciona a votação. Vejo você lá.
Tag:mongodb
Você também pode gostar
MongoDB – Queries com operadores
Login com: Google