Discussion:
ReplicaSet primary election success but C# driver fails to find the new primary
(too old to reply)
Jesse Pasichnyk
2018-08-18 16:32:39 UTC
Permalink
We've been having an issue with our setup for some time, and are finally
taking some time to dig into it.

Our setup is that we have a replica set, and are using the C# (now 2.7, but
legacy interface) driver to connect to it. Everything fires up and works as
expected normally, however during a stepdown/re-election, often some of the
applications will fail to identify the new primary/writable server until
the application is restarted. We do create some
MongoClient/MongoServer/MongoDatabase/MongoCollection references at startup
time in the app, and continue to use those (which I understand is safe) and
recreating them may fix the issue, but regardless this seems like it should
resolve itself in the client.

The exact behavior here after a stepDown or forced election due to a server
unexpectedly rebooting, is that whenever a write is tried (or maybe on some
schedule) the driver tries to find the current primary, and all servers
come back as ReplicaSetSecondary status, even the one that is now primary.

System.TimeoutException: A timeout occured after 30000ms selecting a server
using CompositeServerSelector{ Selectors = WritableServerSelector,
LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 } }.
Client view of cluster state is { ClusterId : "1", ConnectionMode :
"ReplicaSet", Type : "ReplicaSet", State : "Connected", Servers : [{
ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/mongo1.:27017" }",
EndPoint: "Unspecified/mongo1:27017", State: "Connected", Type:
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
ClusterId : 1, EndPoint : "Unspecified/mongo2:27017" }", EndPoint:
"Unspecified/mongo2:27017", State: "Connected", Type:
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
ClusterId : 1, EndPoint : "Unspecified/mongo3:27017" }", EndPoint:
"Unspecified/mongo3:27017", State: "Connected", Type:
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }]}.

Just to confirm, when the error is being thrown, we do have a primary
elected, in this case its "mongo3". My assumption in this example is that
the mongo3 sever should come back with something like "ReplicaSetPrimary"
instead of ReplicaSetSecondary, since it is indeed the primary now.

An example connection string for this setup is
mongodb://USERREDACTED:***@mongo1:27020,mongo2:27020,mongo3:27020/admin?replicaset=MongoDBReplSet_clicks&ssl=true&sslverifycertificate=false

All servers involved here including the application servers and mongodb
servers are on the same private network, plugged into the same private
switch, and are within a fraction of a millisecond from each other.

If the application is restarted it will connect instantly, identify mongo3
as the primary, and work properly until the next election occurs (at which
time it may or may not run into this issue again).

Thoughts?

Thanks,
Jesse
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/5db62cf1-8283-45b5-8961-0e4542f71488%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jesse Pasichnyk
2018-08-20 17:48:37 UTC
Permalink
I just noticed the example there i pasted a connection string for a
different replicaset we're running on a different port. The connection
Post by Jesse Pasichnyk
We've been having an issue with our setup for some time, and are finally
taking some time to dig into it.
Our setup is that we have a replica set, and are using the C# (now 2.7,
but legacy interface) driver to connect to it. Everything fires up and
works as expected normally, however during a stepdown/re-election, often
some of the applications will fail to identify the new primary/writable
server until the application is restarted. We do create some
MongoClient/MongoServer/MongoDatabase/MongoCollection references at startup
time in the app, and continue to use those (which I understand is safe) and
recreating them may fix the issue, but regardless this seems like it should
resolve itself in the client.
The exact behavior here after a stepDown or forced election due to a
server unexpectedly rebooting, is that whenever a write is tried (or maybe
on some schedule) the driver tries to find the current primary, and all
servers come back as ReplicaSetSecondary status, even the one that is now
primary.
System.TimeoutException: A timeout occured after 30000ms selecting a
server using CompositeServerSelector{ Selectors = WritableServerSelector,
LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 } }.
"ReplicaSet", Type : "ReplicaSet", State : "Connected", Servers : [{
ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/mongo1.:27017" }",
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }]}.
Just to confirm, when the error is being thrown, we do have a primary
elected, in this case its "mongo3". My assumption in this example is that
the mongo3 sever should come back with something like "ReplicaSetPrimary"
instead of ReplicaSetSecondary, since it is indeed the primary now.
An example connection string for this setup is
All servers involved here including the application servers and mongodb
servers are on the same private network, plugged into the same private
switch, and are within a fraction of a millisecond from each other.
If the application is restarted it will connect instantly, identify mongo3
as the primary, and work properly until the next election occurs (at which
time it may or may not run into this issue again).
Thoughts?
Thanks,
Jesse
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/c99bfda5-3b52-440a-a235-a8e4feac1ac5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
vincent.kam via mongodb-user
2018-08-22 20:30:40 UTC
Permalink
Hi Jesse,

Hm, that's quite interesting! The latest version of the driver has SDAM
(Server Discovery and Monitoring) logging which could help us diagnose this
issue. In this version, logging can be enabled like so:

var connectionString = "mongodb://localhost";
var settings =
MongoClientSettings.FromConnectionString(connectionString);
settings.SdamLogFilename = "stdout"; // or a log file name
var client = new MongoClient(settings);

Would you be able to build the latest version of the driver from
https://github.com/mongodb/mongo-csharp-driver/, enable SDAM logging in
your application, and share the log output when the driver fails to find
the primary?

Kind regards,
Vincent
Post by Jesse Pasichnyk
I just noticed the example there i pasted a connection string for a
different replicaset we're running on a different port. The connection
Post by Jesse Pasichnyk
We've been having an issue with our setup for some time, and are finally
taking some time to dig into it.
Our setup is that we have a replica set, and are using the C# (now 2.7,
but legacy interface) driver to connect to it. Everything fires up and
works as expected normally, however during a stepdown/re-election, often
some of the applications will fail to identify the new primary/writable
server until the application is restarted. We do create some
MongoClient/MongoServer/MongoDatabase/MongoCollection references at startup
time in the app, and continue to use those (which I understand is safe) and
recreating them may fix the issue, but regardless this seems like it should
resolve itself in the client.
The exact behavior here after a stepDown or forced election due to a
server unexpectedly rebooting, is that whenever a write is tried (or maybe
on some schedule) the driver tries to find the current primary, and all
servers come back as ReplicaSetSecondary status, even the one that is now
primary.
System.TimeoutException: A timeout occured after 30000ms selecting a
server using CompositeServerSelector{ Selectors = WritableServerSelector,
LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 } }.
"ReplicaSet", Type : "ReplicaSet", State : "Connected", Servers : [{
ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/mongo1.:27017" }",
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }]}.
Just to confirm, when the error is being thrown, we do have a primary
elected, in this case its "mongo3". My assumption in this example is that
the mongo3 sever should come back with something like "ReplicaSetPrimary"
instead of ReplicaSetSecondary, since it is indeed the primary now.
An example connection string for this setup is
All servers involved here including the application servers and mongodb
servers are on the same private network, plugged into the same private
switch, and are within a fraction of a millisecond from each other.
If the application is restarted it will connect instantly, identify
mongo3 as the primary, and work properly until the next election occurs (at
which time it may or may not run into this issue again).
Thoughts?
Thanks,
Jesse
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/8d7d9e7b-5691-4620-8d35-fa5dfc681eb6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jesse Pasichnyk
2018-08-22 21:53:21 UTC
Permalink
Hi Vincent,

For sure, we’ll do this ASAP and share the log with you. Should we send it
to you directly?



Thanks,
Jesse



*From:* vincent.kam via mongodb-user <mongodb-***@googlegroups.com>
*Sent:* Wednesday, August 22, 2018 1:31 PM
*To:* mongodb-user <mongodb-***@googlegroups.com>
*Subject:* [mongodb-user] Re: ReplicaSet primary election success but C#
driver fails to find the new primary



Hi Jesse,



Hm, that's quite interesting! The latest version of the driver has SDAM
(Server Discovery and Monitoring) logging which could help us diagnose this
issue. In this version, logging can be enabled like so:



var connectionString = "mongodb://localhost";

var settings =
MongoClientSettings.FromConnectionString(connectionString);

settings.SdamLogFilename = "stdout"; // or a log file name

var client = new MongoClient(settings);



Would you be able to build the latest version of the driver from
https://github.com/mongodb/mongo-csharp-driver/, enable SDAM logging in
your application, and share the log output when the driver fails to find
the primary?



Kind regards,

Vincent

On Monday, August 20, 2018 at 1:48:38 PM UTC-4, Jesse Pasichnyk wrote:

I just noticed the example there i pasted a connection string for a
different replicaset we're running on a different port. The connection
string that matches this error message is actually as follows:

mongodb://USERREDACTED:***@mongo1
:27017,mongo2:27017,mongo3:27017/admin?replicaset=MongoDBReplSet&ssl=true&sslverifycertificate=false




On Saturday, August 18, 2018 at 6:51:03 PM UTC-7, Jesse Pasichnyk wrote:

We've been having an issue with our setup for some time, and are finally
taking some time to dig into it.



Our setup is that we have a replica set, and are using the C# (now 2.7, but
legacy interface) driver to connect to it. Everything fires up and works as
expected normally, however during a stepdown/re-election, often some of the
applications will fail to identify the new primary/writable server until
the application is restarted. We do create some
MongoClient/MongoServer/MongoDatabase/MongoCollection references at startup
time in the app, and continue to use those (which I understand is safe) and
recreating them may fix the issue, but regardless this seems like it should
resolve itself in the client.



The exact behavior here after a stepDown or forced election due to a server
unexpectedly rebooting, is that whenever a write is tried (or maybe on some
schedule) the driver tries to find the current primary, and all servers
come back as ReplicaSetSecondary status, even the one that is now primary.



System.TimeoutException: A timeout occured after 30000ms selecting a server
using CompositeServerSelector{ Selectors = WritableServerSelector,
LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 } }.
Client view of cluster state is { ClusterId : "1", ConnectionMode :
"ReplicaSet", Type : "ReplicaSet", State : "Connected", Servers : [{
ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/mongo1.:27017" }",
EndPoint: "Unspecified/mongo1:27017", State: "Connected", Type:
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
ClusterId : 1, EndPoint : "Unspecified/mongo2:27017" }", EndPoint:
"Unspecified/mongo2:27017", State: "Connected", Type:
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
ClusterId : 1, EndPoint : "Unspecified/mongo3:27017" }", EndPoint:
"Unspecified/mongo3:27017", State: "Connected", Type:
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }]}.



Just to confirm, when the error is being thrown, we do have a primary
elected, in this case its "mongo3". My assumption in this example is that
the mongo3 sever should come back with something like "ReplicaSetPrimary"
instead of ReplicaSetSecondary, since it is indeed the primary now.



An example connection string for this setup is

mongodb://USERREDACTED:***@mongo1
:27020,mongo2:27020,mongo3:27020/admin?replicaset=MongoDBReplSet_clicks&ssl=true&sslverifycertificate=false



All servers involved here including the application servers and mongodb
servers are on the same private network, plugged into the same private
switch, and are within a fraction of a millisecond from each other.



If the application is restarted it will connect instantly, identify mongo3
as the primary, and work properly until the next election occurs (at which
time it may or may not run into this issue again).



Thoughts?



Thanks,

Jesse
--
You received this message because you are subscribed to the Google Groups
"mongodb-user"
group.

For other MongoDB technical support options, see:
https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups
"mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/8d7d9e7b-5691-4620-8d35-fa5dfc681eb6%40googlegroups.com
<https://groups.google.com/d/msgid/mongodb-user/8d7d9e7b-5691-4620-8d35-fa5dfc681eb6%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/9003aa9e0c66de1a415bab74c8eabc03%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
vincent.kam via mongodb-user
2018-08-23 14:37:52 UTC
Permalink
Hi Jesse,

That works!

Kind regards,
Vincent
Post by Jesse Pasichnyk
Hi Vincent,
For sure, we’ll do this ASAP and share the log with you. Should we send
it to you directly?
Thanks,
Jesse
*Sent:* Wednesday, August 22, 2018 1:31 PM
*Subject:* [mongodb-user] Re: ReplicaSet primary election success but C#
driver fails to find the new primary
Hi Jesse,
Hm, that's quite interesting! The latest version of the driver has SDAM
(Server Discovery and Monitoring) logging which could help us diagnose this
var connectionString = "mongodb://localhost";
var settings =
MongoClientSettings.FromConnectionString(connectionString);
settings.SdamLogFilename = "stdout"; // or a log file name
var client = new MongoClient(settings);
Would you be able to build the latest version of the driver from
https://github.com/mongodb/mongo-csharp-driver/, enable SDAM logging in
your application, and share the log output when the driver fails to find
the primary?
Kind regards,
Vincent
I just noticed the example there i pasted a connection string for a
different replicaset we're running on a different port. The connection
We've been having an issue with our setup for some time, and are finally
taking some time to dig into it.
Our setup is that we have a replica set, and are using the C# (now 2.7,
but legacy interface) driver to connect to it. Everything fires up and
works as expected normally, however during a stepdown/re-election, often
some of the applications will fail to identify the new primary/writable
server until the application is restarted. We do create some
MongoClient/MongoServer/MongoDatabase/MongoCollection references at startup
time in the app, and continue to use those (which I understand is safe) and
recreating them may fix the issue, but regardless this seems like it should
resolve itself in the client.
The exact behavior here after a stepDown or forced election due to a
server unexpectedly rebooting, is that whenever a write is tried (or maybe
on some schedule) the driver tries to find the current primary, and all
servers come back as ReplicaSetSecondary status, even the one that is now
primary.
System.TimeoutException: A timeout occured after 30000ms selecting a
server using CompositeServerSelector{ Selectors = WritableServerSelector,
LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 } }.
"ReplicaSet", Type : "ReplicaSet", State : "Connected", Servers : [{
ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/mongo1.:27017" }",
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }]}.
Just to confirm, when the error is being thrown, we do have a primary
elected, in this case its "mongo3". My assumption in this example is that
the mongo3 sever should come back with something like "ReplicaSetPrimary"
instead of ReplicaSetSecondary, since it is indeed the primary now.
An example connection string for this setup is
All servers involved here including the application servers and mongodb
servers are on the same private network, plugged into the same private
switch, and are within a fraction of a millisecond from each other.
If the application is restarted it will connect instantly, identify mongo3
as the primary, and work properly until the next election occurs (at which
time it may or may not run into this issue again).
Thoughts?
Thanks,
Jesse
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups
"mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/8d7d9e7b-5691-4620-8d35-fa5dfc681eb6%40googlegroups.com
<https://groups.google.com/d/msgid/mongodb-user/8d7d9e7b-5691-4620-8d35-fa5dfc681eb6%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/ddfd7ab3-8c58-4b30-a907-b47c6e68d79c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sujesh Arukil
2018-09-24 14:52:01 UTC
Permalink
Has there been an update on this? We are experiencing the same issue using
the latest MongoDb C# driver. The server is running 3.4.10 version of Mongo.

Thanks,
Sujesh
Post by vincent.kam via mongodb-user
Hi Jesse,
That works!
Kind regards,
Vincent
Post by Jesse Pasichnyk
Hi Vincent,
For sure, we’ll do this ASAP and share the log with you. Should we send
it to you directly?
Thanks,
Jesse
<javascript:>>
*Sent:* Wednesday, August 22, 2018 1:31 PM
*Subject:* [mongodb-user] Re: ReplicaSet primary election success but C#
driver fails to find the new primary
Hi Jesse,
Hm, that's quite interesting! The latest version of the driver has SDAM
(Server Discovery and Monitoring) logging which could help us diagnose this
var connectionString = "mongodb://localhost";
var settings =
MongoClientSettings.FromConnectionString(connectionString);
settings.SdamLogFilename = "stdout"; // or a log file name
var client = new MongoClient(settings);
Would you be able to build the latest version of the driver from
https://github.com/mongodb/mongo-csharp-driver/, enable SDAM logging in
your application, and share the log output when the driver fails to find
the primary?
Kind regards,
Vincent
I just noticed the example there i pasted a connection string for a
different replicaset we're running on a different port. The connection
We've been having an issue with our setup for some time, and are finally
taking some time to dig into it.
Our setup is that we have a replica set, and are using the C# (now 2.7,
but legacy interface) driver to connect to it. Everything fires up and
works as expected normally, however during a stepdown/re-election, often
some of the applications will fail to identify the new primary/writable
server until the application is restarted. We do create some
MongoClient/MongoServer/MongoDatabase/MongoCollection references at startup
time in the app, and continue to use those (which I understand is safe) and
recreating them may fix the issue, but regardless this seems like it should
resolve itself in the client.
The exact behavior here after a stepDown or forced election due to a
server unexpectedly rebooting, is that whenever a write is tried (or maybe
on some schedule) the driver tries to find the current primary, and all
servers come back as ReplicaSetSecondary status, even the one that is now
primary.
System.TimeoutException: A timeout occured after 30000ms selecting a
server using CompositeServerSelector{ Selectors = WritableServerSelector,
LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 } }.
"ReplicaSet", Type : "ReplicaSet", State : "Connected", Servers : [{
ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/mongo1.:27017" }",
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }]}.
Just to confirm, when the error is being thrown, we do have a primary
elected, in this case its "mongo3". My assumption in this example is that
the mongo3 sever should come back with something like "ReplicaSetPrimary"
instead of ReplicaSetSecondary, since it is indeed the primary now.
An example connection string for this setup is
All servers involved here including the application servers and mongodb
servers are on the same private network, plugged into the same private
switch, and are within a fraction of a millisecond from each other.
If the application is restarted it will connect instantly, identify
mongo3 as the primary, and work properly until the next election occurs (at
which time it may or may not run into this issue again).
Thoughts?
Thanks,
Jesse
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups
"mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/8d7d9e7b-5691-4620-8d35-fa5dfc681eb6%40googlegroups.com
<https://groups.google.com/d/msgid/mongodb-user/8d7d9e7b-5691-4620-8d35-fa5dfc681eb6%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/f1d0155b-4f95-4d64-ad4c-68638caf064f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
vincent.kam via mongodb-user
2018-09-25 18:14:23 UTC
Permalink
Hello Sujesh,

Thanks for your report :)

After enabling SDAM logging, I believe Jesse was unable to reproduce the
issue again.
May I ask if you are able to reproduce this issue consistently? If not, how
often does the issue occur?

Kind regards,
Vincent
Post by Sujesh Arukil
Has there been an update on this? We are experiencing the same issue using
the latest MongoDb C# driver. The server is running 3.4.10 version of Mongo.
Thanks,
Sujesh
Post by vincent.kam via mongodb-user
Hi Jesse,
That works!
Kind regards,
Vincent
Post by Jesse Pasichnyk
Hi Vincent,
For sure, we’ll do this ASAP and share the log with you. Should we send
it to you directly?
Thanks,
Jesse
*Sent:* Wednesday, August 22, 2018 1:31 PM
*Subject:* [mongodb-user] Re: ReplicaSet primary election success but
C# driver fails to find the new primary
Hi Jesse,
Hm, that's quite interesting! The latest version of the driver has SDAM
(Server Discovery and Monitoring) logging which could help us diagnose this
var connectionString = "mongodb://localhost";
var settings =
MongoClientSettings.FromConnectionString(connectionString);
settings.SdamLogFilename = "stdout"; // or a log file name
var client = new MongoClient(settings);
Would you be able to build the latest version of the driver from
https://github.com/mongodb/mongo-csharp-driver/, enable SDAM logging in
your application, and share the log output when the driver fails to find
the primary?
Kind regards,
Vincent
I just noticed the example there i pasted a connection string for a
different replicaset we're running on a different port. The connection
We've been having an issue with our setup for some time, and are finally
taking some time to dig into it.
Our setup is that we have a replica set, and are using the C# (now 2.7,
but legacy interface) driver to connect to it. Everything fires up and
works as expected normally, however during a stepdown/re-election, often
some of the applications will fail to identify the new primary/writable
server until the application is restarted. We do create some
MongoClient/MongoServer/MongoDatabase/MongoCollection references at startup
time in the app, and continue to use those (which I understand is safe) and
recreating them may fix the issue, but regardless this seems like it should
resolve itself in the client.
The exact behavior here after a stepDown or forced election due to a
server unexpectedly rebooting, is that whenever a write is tried (or maybe
on some schedule) the driver tries to find the current primary, and all
servers come back as ReplicaSetSecondary status, even the one that is now
primary.
System.TimeoutException: A timeout occured after 30000ms selecting a
server using CompositeServerSelector{ Selectors = WritableServerSelector,
LatencyLimitingServerSelector{ AllowedLatencyRange = 00:00:00.0150000 } }.
"ReplicaSet", Type : "ReplicaSet", State : "Connected", Servers : [{
ServerId: "{ ClusterId : 1, EndPoint : "Unspecified/mongo1.:27017" }",
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }, { ServerId: "{
"ReplicaSetSecondary", WireVersionRange: "[0, 6]" }]}.
Just to confirm, when the error is being thrown, we do have a primary
elected, in this case its "mongo3". My assumption in this example is that
the mongo3 sever should come back with something like "ReplicaSetPrimary"
instead of ReplicaSetSecondary, since it is indeed the primary now.
An example connection string for this setup is
All servers involved here including the application servers and mongodb
servers are on the same private network, plugged into the same private
switch, and are within a fraction of a millisecond from each other.
If the application is restarted it will connect instantly, identify
mongo3 as the primary, and work properly until the next election occurs (at
which time it may or may not run into this issue again).
Thoughts?
Thanks,
Jesse
--
You received this message because you are subscribed to the Google
Groups "mongodb-user"
group.
https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/8d7d9e7b-5691-4620-8d35-fa5dfc681eb6%40googlegroups.com
<https://groups.google.com/d/msgid/mongodb-user/8d7d9e7b-5691-4620-8d35-fa5dfc681eb6%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/2c8bc035-77b7-4b91-9ef8-ccb4a74deb0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...