MongoDB PHP: Reading from Slaves and setting persistent connections with a heavy read environment

Question

I'm attempting to set all incoming read queries to hit slaves on my mongo servers.

I see in the PHP docs a reference to:

MongoCursor::$slaveOkay = true;

However, this just seems to setup queries to be fired off to slaves; not really to do anything else. My connections to my servers look like this:

$mongo = new Mongo("mongodb://my.server:27017", 
                      array("replicaSet" => 'replicaSet', "persist" => "pool")
                  );

• Will I need to do anything different with my persist connection when wanting to only connect to the slave for reads?

• How can I target queries to hit just the Slave so that the writes I have on the primary won't block incoming read requests.

PHP docs shows me this example:

$db->setSlaveOkay(true);
$c = $db->myCollection;

$cursor = $c->find();

However I'm confused at the difference this has between the above, and if both are needed or not.

Jair

Your logic is not correct - the secondary is handling the same write requests as the primary (via replication) so the writes on the primary won't block the incoming read requests, but the writes on the secondary will! In addition, now you are getting stale data. Replica sets don't help with read scaling, just high availability and failover. If you have more traffic than primary can handle, you need to shard. – Marney

@AsyaKamsky ah, I did not know that. So if I have say 5 slaves, and have reads going off to them it wouldn't scale my read requests up? I have high reads and low writes so was thinking by having a handful of slaves in a replica set it would help create quick queries. – Jair

queries are usually not slow because there are too many simultaneous reads, they are usually slow either because there are no appropriate indexes (same on all secondaries) or because the indexes/working data set cannot fit into RAM (getting more RAM would be solution as secondaries would normally not have more RAM but exact same data size). – Marney

Answer 1

SlaveOkay and Read Preferences

The SlaveOkay preference is effectively "secondary preferred", but still allows reading from the primary.

MongoDB 2.2 and the Mongo PHP 1.3.0 driver introduce several new Read Preference Modes so there is now:

• primary - only read from the primary
• primaryPreferred - read from the primary unless it is unavailable
• secondary - only read from secondaries
• secondaryPreferred - prefer reads from a secondary (equivalent semantics to slaveOK)
• nearest - read from the nearest member of the replica set (by ping time)

Another new feature in MongoDB 2.2 is support for Tag Sets, which allow you to specify custom read preferences by tagging replica set members. This allows you to target specific secondaries. For example, a replica set member could be tagged with: { 'group' : 'reporting' }.

For more information on read preferences in the PHP driver see the Mongo manual on PHP.net: Read Preferences.

Persistent Connections

Connection pooling has been rewritten for the PHP 1.3.0 driver release, and all connections are now persistent.

Per the changelog:

Removed the "persist" option, as all connections are now persistent. It can still be used, but it doesn't affect anything.

Farro

Note that the PHP 1.3.0 driver is currently in the final stages of testing for release (1.3.0RC3 was posted today). – Farro

Thank you Stennie; I saw RC3 post today and was elated. I'm a bit nervous on using it in production, you wouldn't happen to know how close it was to being closed out would you? Excited for that driver! – Jair

The Mongo PHP 1.3.0 release has been in public beta testing since August and this is the third release candidate. Unless any major bugs are found I would expect it is close to final. It would be worth testing in your development/staging environment, but I would be inclined to wait for a final release before using it in production. You can see the list of outstanding issues for this release, which are mostly documentation. – Farro

As I commented above, please note that this will not give you effective read scaling as the secondary has to perform exactly the same writes as the primary. – Marney