We are currently on mongo 3.2 and plan to upgrade the storage engine from MMAP to WiredTiger.We currently have 1 primary,1 secondary & 1 arbiter in our replicaset(for reference lets call it RS1).
We take daily snapshots of our secondary node. Our data size is around 500GB.
In mongo3.2, upgrading the storage engine from MMAP to WiredTIger should be done in a rolling manner. This includes an initial sync of the mongo node having WiredTiger with an existing mongo node having MMAP. Initial sync fails due to renameCollection command during aggregate or map-reduce functions (JIRA ticket
Now this issue is fixed in mongo 3.6.
So there are two ways to handle this:
- Upgrade to mongo 3.6 via 3.4
- Complete the initial sync process by stopping the aggregate & map-reduce functions, which will require code changes in the application.
However we tried a different approach:
1.launch a mongo node(MMAP storage engine) with the snapshot data and assigned it to a different replicaset(RS2) which was isolated from the application (ie no read/writes happening).
2.attach a new mongo node without any data and WiredTiger storage engine to this new replicaset.
3.Let it sync,
4.Once sync is complete, remove this WiredTiger node from the replicaset(RS2), flush its local database which has replicaset information .
5.Attach this node to the original replica set (RS1)
6.Hopefully it should sync the data without doing an initial sync
But alas, step 6 didnt work and it went for an initial sync.
This eventually failed whenever there was a renameCollection operation with the following error:
“OplogOperationUnsupported: Applying renameCollection not supported in initial sync”
Is this expected? Are we doing something wrong?