Upgrading Storage Engine from MMAP to WiredTiger in MongoDB 3.2 version

Ops and Admin Installation & Upgrades
1

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:

  1. Upgrade to mongo 3.6 via 3.4
  2. 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?

2

Hi @Anshuman_Biswal,

Yes this is expected, you cant take a node from replica B and plug it to replica A. Once it had a different replica ID it will force initial sync.

I think the best approach is to make sure you are running 3.2.18+ on all replica set nodes and use a server parameter to allow initial sync to finish regardless of renames allowUnsafeRenamesDuringInitialSync.

It was introduced in 3.2.18 as part of https://jira.mongodb.org/browse/SERVER-29772

Best
Pavel

1 Like
3

Hi @Pavel_Duchovny ,
Thanks a lot of your answer. Will definitely try using the allowUnsafeRenamesDuringInitialSync parameter.
Just one question, i thought the replicaset information resided in the local database.
So when we do the following in mongo shell:
use local
db.dropDatabase()
I guess the node looses the information to which replica set it was belonging.
Is it not correct?

4

Hi @Anshuman_Biswal,

No replication information means not belonging to replica A or B. Attaching it to both will result in initial sync.

Thanks
Pavel

5

Hi @Pavel_Duchovny,

Thanks for your reply.

I assume the flag allowUnsafeRenamesDuringInitialSync will be set true in all the replica set nodes right?

Thanks
Anshuman

6

Hi @Anshuman_Biswal,

Yes its a parameter.

It should be :

--setParameter allowUnsafeRenamesDuringInitialSync=true

Best regards,
Pavel

1 Like
7

Thanks @Pavel_Duchovny for the help. Really appreciate it !!

1 Like