does primary,secondary order matter in connection string?

[Adam Monsen]

Do these two connection strings behave the same?

1. mongodb://primary:27017,secondary:27017
2. mongodb://secondary:27017,primary:27017

I was seeing a bunch of "MongoCursorTimeoutException: cursor timed out"
errors using #2, when I switched to #1 they went away.

I'm running a 3-node replica set on EC2 instances. Each node runs in a
different availability zone.

Each node is MongoDB 2.2.1 on the latest Amazon Linux (2012.09).

I connect to MongoDB using Doctrine MongoDB, so here are a few other
moving parts:

* Symfony v2.0.18
* doctrine-common b886898821288d305862ee9c567cc5b5cbb4c0dc
* doctrine-mongodb 727a12d25ba12d18aa293bc6eb61f203a9545912
* doctrine-mongodb-odm bd65a47c32f9ad9ac888914ab88d89976a5bcfe8
* 'mongo' from pecl.php.net, version 1.2.12

[Hannes Magnusson]

We will always use the first entry in the seed list to discover the
topology of the replicaset, and then match the next server in the
seedlist to our discovery.

The only case where it could possibly matter is if the first node is
down, but the end results would be the same as we will verify the the
entire seed list to our discovered topology.

This should have no affect on the cursor whatsoever.. You are passing
in an array as the second argument to the constructor with
array("replicaSet" => "replicaset-name") right?

-Hannes

[Adam Monsen]

Replies inline, below.

On 11/06/2012 06:17 PM, Hannes Magnusson wrote:
> We will always use the first entry in the seed list to discover the
> topology of the replicaset, and then match the next server in the
> seedlist to our discovery.
>
> The only case where it could possibly matter is if the first node is
> down, but the end results would be the same as we will verify the the
> entire seed list to our discovered topology.

Thanks. This is helpful to know the expected behavior, and good to know
that the expected behavior makes sense!

> This should have no affect on the cursor whatsoever.. You are passing
> in an array as the second argument to the constructor with
> array("replicaSet" => "replicaset-name") right?

Yes.

Well, I'm using Symfony2 + Doctrine MongoDB, so I just configure that
option and the framework passes it in when connecting to MongoDB. I
stepped through the code with a debugger and it did indeed appear to
pass in array("replicaSet" => "replicaset-name").

> -Hannes

[Hannes Magnusson]

I assume you managed to connect to the replicaset just fine, it was
just after some queries that you started getting that exception?
Are you doing slaveOkay reads?
Do you have a log from mongodb from that time period?

-Hannes

[Adam Monsen]

On 11/10/2012 01:58 PM, Hannes Magnusson wrote:
> I assume you managed to connect to the replicaset just fine,

Yes.

> it was just after some queries that you started getting that exception?

I'd been using the same replica set for *months* without ever seeing
these cursor timeouts. A couple things happened lately that may be related.

I recently upgraded all my MongoDB servers from 2.0.6 to 2.2.0, and
then, shortly after, to 2.2.1.

When I do these upgrades, I typically tear down the Amazon EC2 instance
the MongoDB server is running on and create a new one from scratch. It's
possible there was some network connectivity issues between the client
(Symfony2 app / PHP driver) and the MongoDB replica set.

I also upgraded Doctrine/MongoDB libs (see previous post for versions).

I think what I finally did to fix things was just restart every MongoDB
server, then restart every Symfony2 Apache server.

Related:
http://stackoverflow.com/questions/13318321/symfony2-app-mongodb-replica-set-failover-requires-apache-restart
(although I can't recall if these errors were near a failover event).

My wondering about the primary,secondary order in the connection string
was a long shot.

> Are you doing slaveOkay reads?

No.

> Do you have a log from mongodb from that time period?

The MongoDB server logs were empty around the time I was seeing the
errors (I use --quiet).

Sorry I didn't specify earlier, but these errors were showing up in the
Symfony2 application log, not the MongoDB server log. I assume these
errors were coming from the PHP driver.

Also see http://stackoverflow.com/a/13259538/156060 , another possibly
related issue.

[Hannes Magnusson]

These were coming from the application yes - but there are some many
reason for that exception to occur that we really need to know what
was going on on the server and the network during that time to be able
to offer any logical explanation other then obvious "the cursor simply
timedout" (the script could have been running for long time, the read
timeout was lowered, the network broken, the server under serious
load, ...)..

Sorry

-Hannes

[Adam Monsen]

On 11/13/2012 01:37 PM, Hannes Magnusson wrote:
> we really need to know what was going on on the server and the
> network during that time to be able to offer any logical explanation
> other then obvious "the cursor simply timedout" (the script could
> have been running for long time, the read timeout was lowered, the
> network broken, the server under serious load, ...)

Yes, I understand. There's really no way to nail this one down without
more information. I'll work on improving my networking diagnosis toolkit
and hopefully will understand more of what's going on the next time this
happens.

I was really just seeking to rule out the primary,secondary ordering in
the connection string, and I'm satisfied that was definitely not an issue.

I'm thinking the issue is most likely related to Doctrine MongoDB, so
folks can follow that thread here:
https://groups.google.com/d/msg/doctrine-user/_Zt8cVxnEuk/m_LOSdvAACsJ
(mirror: http://thread.gmane.org/gmane.comp.php.doctrine.user/29 )