Less-Painful MongoDB Migration

StrangeWill

Administrator
Staff member
So I'm looking to replace some old MongoDB servers, these are VMs that are manually managed, and they need a fresh ground-up rebuild. They're in multi-node clusters (3 nodes) -- I've never tried to do a per-node replacement/replication on them before. Is there an easy way to basically just like... bring a node into the cluster, then take a node offline and do that one at a time for all 3? It this a huge pain and it'll be easier to just stand up a whole new cluster and replicate? I can deploy same-version then upgrade the new cluster so that's not necessarily a problem.

Thoughts?
 
I've done rolling upgrades (node-by-node) replacement before and while nothing is wrong with that, I think since you mention these VMs being manually managed, that your setup-new-and-replicate would be smoother (imho).

Possibly helpful (If not for you, then maybe others reading) stuff from my past mistakes/experiences:

1. oplog sizing. Making sure its large enough to cover expected migration time.
Code:
use local
db.oplog.rs.stats().maxSize
db.adminCommand({replSetResizeOplog: 1, size: <new_size_in_mb>})

2. Change streams (speeds up sync)
Code:
const changeStream = db.collection('mycollection').watch();
changeStream.on('change', (change) => {
  // Apply this change to the new cluster
});

3. Mongodb Compass
Kinda neat for visually inspecting the data before and after migration, and for ad-hoc queries or updates

4. config servers
If using a sharded cluster, migrating config servers as well.

5. mongo tools
Probably already know about but helpful: mongodump, mongorestore, mongoexport, mongoimport.
 
Back
Top