Do I need to perform db.fsyncLock() when running a replica set without journal enabled

Question

I'm running MongoDB 3.2.9 with WiredTiger on 3 EC2 instances. When backing up the database volumes using elastic block store snapshots, do I need to perform db.fsyncLock() when running a 3 node replica set where all nodes are running without journal enabled? Additionally, for reference, my storage.dbPath maps to a dedicated EBS volume for /data on each mongod instance on each EC2 server. There are also separate dedicated volumes for logs.

I'm working off of the below documentation for reference, but it's not clear how these steps map from single instance deployments to replica set deployments: https://docs.mongodb.com/ecosystem/tutorial/backup-and-restore-mongodb-on-amazon-ec2

If I do need to run db.fsyncLock(), does the lock apply to all instances on all EC2 servers? The documentation says that it locks the 'entire' mongod instance, but it's not clear to me whether the instance in this case refers to an instance on a single EC2 server, or if this applies to all instances in the replica set spread over all EC2 servers (3 EC2 servers in my case).

Answer 1

Yes, to get a consistent backup (when journaling is not enabled) you need to db.synclock your mongod. You use synclock only at that node from where you take the backup (and you only need to make the backup from one node; you can restore whole replica set from one backup). db.synclock locks only that node where you give this command, other nodes work as they were, so lock (and make the backup) one of the SECONDARY nodes.

Addition, you DON'T need to make the backup of arbiter, because there is no data to be backuped. Arbiter is just "voter" or "observer" at replica set.