I'm not sure what documentation you've read so apologies if I'm repeating anything here.
To distribute reads to secondary nodes, most drivers allow you to set a readPreference value for the current session. Clients set read preference on a per-connection basis. With slaveOk, the driver should will always send queries to the secondaries, if they're available.
Distributing reads to secondaries requires the use of
ReplicaSetConnection with ReadPreference.SECONDARY.
See “rs.slaveOk()” for more information and this link.
In the mongo shell, to enable secondary reads, issue the following command :
rs.slaveOk()
The PHP documentation for it is here but I'm guessing that may be the documentation you're referring to.
As a FYI, here's an old discussion about it on the MongoDB Google Group.
If you're still having issues, I'd recommend using the MongoDB Google Group and providing some further information such as the version of MongoDB you're using, the version of the PHP driver, your log files, rs.conf() and rs.status().
As a FYI, you have to be careful with read scaling as sending too many reads to the secondaries can often result in the secondaries lagging the primary and becoming stale, thus requiring a full resync.
There are a couple of separate questions/issues here:
do you have to create that same user on nodes 2/3?
If they are members of the same replica set, then no. The users will be written to the primary and then replicated to the secondaries - remember any secondary can become primary in a normal set, so you would have to have all the data necessary to do that, including users. If the nodes are in the set when they are added, the users will replicate normally. If you add them later, they will replicate the users as part of the initial sync process.
Note that for nodes that are members of different replica sets (say multiple shards) that is not the case.
I'm having some trouble doing that if I bring up the other nodes with
auth/keyfile turned on
Remember that the keyfile must be identical for all nodes in a set. The keyfile is what the nodes will use to authenticate with each other (for the purposes of initial sync and replication for a start, so it is an absolute must). If you are having issues when you add the nodes, there will be errors in the logs that will tell you why. The common reasons would be:
- Incorrect config (new nodes not configured with the replica set name)
- Different key files (this must be identical on all nodes in the replica set)
- Connectivity or hostname lookup issues
If you expand on the difficulties you have when you try to add (how you are adding, what error you get, and preferably the output of rs.status() and a sample config file) I can elaborate further.
Best Answer
Secondaries in replica sets sync from another member of the replica set with a newer oplog, but that does not necessarily have to be the current primary.
MongoDB supports chained replication, where a secondary member can replicate from another secondary member instead of the primary. This feature is enabled by default, and is particularly useful to minimise network traffic for deployments spanning multiple data centres. Unless chained replication is specifically disallowed, secondaries will periodically evaluate the member they are syncing from and may choose a lower latency secondary (with a more current oplog) to sync from.
You can check which member a secondary is syncing from via
rs.status(). There should be asyncSourceHostfield (MongoDB 4.0+) or asyncingTofield (deprecated name for the same field in older versions of MongoDB).If you aren't seeing any performance issues with your current deployment and workload, there should be no need to proactively downgrade unless you feel the extra replica set members are no longer needed for your use case.