Read concern level of majority error while upgrading Sharded Cluster from 3.2 to 3.4

0
votes

I have upgraded MongodDB sharded cluster having two replica sets from 3.2 to 3.4. Current storage engine is MMAPv1. After successfully upgrading all the secondary, primary, config server and mongos to 3.4, when I run config server using following command.

sudo mongod --configsvr

I keep getting following Error.

SHARDING [shard registry reload] Periodic reload of shard registry failed :: caused by :: 115 could not get updated shard list from config server due to Current storage engine does not support majority readConcerns; will retry after 30s

And also I am unable to connect mongos with config server. When I try to connect it using following command

sudo mongos --configdb [ip-of-my-config-server]:27019

It gives me following error.

BadValue: configdb supports only replica set connection string

I suppose mongos is unable to connect to config server due to the majority readConcerns error on config server.

MongoDB manual says "When reading from the replica set config servers, MongoDB 3.4 uses a Read Concern level of "majority"."

And to use a read concern level of "majority", WiredTiger must be used as storage engine.

So it seems I have to switch to WiredTiger storage engine to make it work. But when I was going to switch to WiredTiger storage engine of a secondary replica set member, according to manual

"This procedure completely removes a secondary replica set member’s data"

So I am stuck halfway. Situation is

  1. Config server is giving error regarding majority readConcerns.
  2. I have to switch to WiredTiger to get rid of it.
  3. Switching to WiredTiger will remove data from secondary members.
  4. Data will not be replicated back to secondary members during this switching to WiredTiger procedure because of config server error and eventually I will be ended up losing all the data (Please correct if I am wrong).

Questions are:

  1. Can I make MongoDB 3.4 to use a Read Concern level of "local" when reading from the replica set config servers?
  2. How can I switch to WiredTiger engine without losing data in my scenario?
1
mongodbupgradeshardingreplicasetwiredtiger
Is it an option to downgrade to v3.2, do the migration to WiredTiger, and then upgrade? – Vince Bowdren
Yes it can be done if no other solution is found. – umarxe

1 Answers

0
votes

You could migrate each node in the replica set as if it was a standalone, by using mongodump to back up the data, restarting with WiredTiger and a blank data directory, then using mongorestore to populate the new database.

This isn't normally recommended for replica set nodes, but only because it's just easier to wipe the data on a secondary and let it resync from the other nodes. Doing it this way will work just fine, but involves a little more fiddly work for you with the dump and restore tools.