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 is a guide for how to do this (reconfigure a replica set with unavailable members) here:
http://docs.mongodb.org/manual/tutorial/reconfigure-replica-set-with-unavailable-members/
You essentially have to do a forced reconfig of the set because there is no primary available. If you want to keep a set operational while doing this type of move, you can:
- Use your hosts file to temporarily point the old names to the new (or similar) and "fool" the primary into thinking they are up (then make the permanent changes one at a time)
- Temporarily add arbiters to prevent the primary from stepping down (2 more for example, so the primary is kept with 3/5 votes)
- Reconfigure the set to a single node before doing the moves
- Do the moves one server at a time, ensuring there are 2/3 nodes up to form a majority at all times (and hence keep a primary up)
Best Answer
You can influence the outcome of elections by adjusting the priority for specific members. The default priority of 1 can be changed to any floating point value between 0 and 1000 (where 0 indicates a non-electable member).
For your use case, you might want to set your preferred primary to have a priority of 10. The priority value doesn't have any special significance aside from numerical ordering for all member priorities. For example: priority values of 1.01, 10, or 1000 are all higher than the default priority of 1.
Note: using priorities may result in extra elections to ensure a preferred member becomes primary when eligible. Typically it is best to think about replica set members as peers with similar resources so that any member can take on the role of primary. Unless there is a strong reason to have a specific member as primary (for example, a replica set distributed across multiple data centres), I would avoid using priorities or consider having a few preferred members with equal priorities in order to minimise elections.
An example sequence with
replica-1having a higher priority (10) than all other members with default priority (1):replica-1is current primary.replica-1is shutdown in order to be upgraded.replica-2is elected as the new primary.replica-1is restarted and resumes syncing in order to catch up with the current primary.replica-1catches up with the current primary and triggers an election so it can become primary.replica-2will drop all current connections when it steps down to a secondary.Setting
replica-1andreplica-2to the same priority would avoid the extra election.