Olá,
No MongoDB a partir da versão 3.6 em um ambiente de replicasets, temos a opção de redimensionar o tamanho do oplog de forma online através da função replSetResizeOplog. No exemplo abaixo poderemos executar o comando para aumentar o oplog para 32 GB nos membros SECONDARY primeiro e por último no membro PRIMARY.
PrdSet:SECONDARY> db.adminCommand({replSetResizeOplog: 1, size: 32768})
Nas versões do MongoDB anteriores a versão 3.6 precisamos fazer de forma offline, ou seja, os membros da replicaset precisam sofrer shutdown e subir de forma standalone para poder redimensionar o oplog. O ideal é verificar se existe retenção suficiente no oplog do membro primário quando o membro subir e voltar novamente como membro da replicaset de forma que a sincronização tenha tempo suficiente para ser realizada. No mais, segue abaixo os procedimentos necessários realizados para redimensionar o tamanho do oplog em um ambiente de replicaset que utilizam o MongoDB 3.2. O propósito será aumentar o tamanho do oplog de 1GB para 32GB de forma que a sincronização entre os membros tenham uma margem de tempo razoável.
Abaixo, irei checar o status da replicaset de todos os membros envolvidos.
[mongodb@linux2 ~]$ mongo --port 27017
MongoDB shell version: 3.2.17
connecting to: 127.0.0.1:27017/test
PrdSet:SECONDARY> rs.status()
{
"set" : "PrdSet",
"myState" : 1,
"term" : NumberLong(37),
"heartbeatIntervalMillis" : NumberLong(2000),
"members" : [
{
"_id" : 0,
"name" : "linux.local.net:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 201,
"configVersion" : 4,
"self" : true
},
{
"_id" : 1,
"name" : "linux2.local.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 194,
"pingMs" : NumberLong(0),
"syncingTo" : "linux.local.net:27017",
"configVersion" : 4
},
{
"_id" : 2,
"name" : "linux3.local.net:27017",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 194,
"pingMs" : NumberLong(0),
"configVersion" : 4
}
],
"ok" : 1
}
A estratégia é realizar o procedimento primeiro nos membros SECONDARY e por último no membro PRIMARY. irei realizar o shutdown do MongoDB no nó linux2.local.net:27017 e subi-lo standalone utilizando a porta 37018 conforme a seguir.
[mongodb@linux2 ~]$ mongod --dbpath /mongodb/data --shutdown
killing process with pid: 1786
[mongodb@linux ~]$ mongod --fork --port 37018 --dbpath /mongodb/data/ --logpath /mongodb/log/mongo_PRD.log
about to fork child process, waiting until server is ready for connections.
forked process: 1954
child process started successfully, parent exiting
Após subir a instância do MongoDB como standalone na porta 37018, irei conectar nele e realizar os procedimentos para redimensionamento do oplogsize de 1GB para 32GB. Observe abaixo que ao executar o comando db.printReplicationInfo(), temos a informação do tamanho atual do oplog além da informação de que a retenção do oplog atual do membro PRIMARY está em 4.5 horas, ou seja, um membro SECONDARY conseguiria ficar em média até 4.5 horas fora da replicaset e mesmo assim conseguir se sincronizar com o PRIMARY até esse tempo.
[mongodb@linux2 ~]$ mongo --port 37018
MongoDB shell version: 3.2.17
> //Recreate the Oplog with a New Size and a Seed entry
> use local
switched to db local
> db = db.getSiblingDB('local')
local
> //get size of the oplog
> db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 16200secs (4.5hrs)
> //Ensure that the temp temporary collection is empty by dropping the collection
> db.temp.drop()
false
> //Use the db.collection.save() method and a sort on reverse natural order to find the last entry and save it to a temporary collection
> db.temp.save(db.oplog.rs.find( { }, { ts: 1, h: 1 } ).sort( {$natural : -1} ).limit(1).next())
WriteResult({ "nInserted" : 1 })
> //Remove the Existing Oplog Collection
> db.oplog.rs.drop()
true
> //Create a New Oplog
> db.runCommand({ create: "oplog.rs", capped: true, size: (32 * 1024 * 1024 * 1024) })
{ "ok" : 1 }
> //Insert the Last Entry of the Old Oplog into the New Oplog
> db.oplog.rs.save(db.temp.findOne())
WriteResult({
"nMatched" : 0,
"nUpserted" : 1,
"nModified" : 0,
"_id" : ObjectId("5d1fb2f43037c7e5b94410cf")
})
> exit
bye
Pronto. Agora podemos subir o MongoDB novamente como membro da replicaset na sua porta usual.
[mongodb@linux2 ~]$ mongod --dbpath /mongodb/data --shutdown
killing process with pid: 1954
[mongodb@linux2 ~]$ mongod --fork --journal --replSet PrdSet --port 27017 --dbpath /mongodb/data/ --logpath /mongodb/log/mongo_PRD.log
about to fork child process, waiting until server is ready for connections.
forked process: 3348
child process started successfully, parent exiting
Podemos ver abaixo que o oplog agora está com tamanho de 32GB.
[mongodb@linux2 ~]$ mongo --port 27017
MongoDB shell version: 3.2.17
connecting to: 127.0.0.1:27017/test
PrdSet:SECONDARY> db.printReplicationInfo()
configured oplog size: 32768MB
log length start to end: 16200secs (4.5hrs)
Feito esse procedimento em todos os membros SECONDARY, o último passo será realizá-lo no membro PRIMARY. será necessário apenas repetir o mesmo procedimento. Para tanto, de forma a não gerar indisponibilidade no cluster do MongoDB, será necessário eleger um novo membro PRIMARY antes de realizar essa operação. Basta executar o comando rs.stepDown() no membro PRIMARY de forma que algum membro SECONDARY assuma como PRIMARY. Após a realização do stepDown, o antigo PRIMARY se tornará SECONDARY e o procedimento poderá ser realizado normalmente.
Nenhum comentário:
Postar um comentário