Discussion:
Failed to upgrade replica set on two computers to MongoDB 4.0.4 on Windows
(too old to reply)
Itzi Kagan
2018-12-01 18:34:51 UTC
Permalink
There are two servers (ServerOne, ServerTwo) with the following
configuration:
OS: Windows server 2012R2
RAM: 3GB
Installed: latest version of vc_redist.x64.exe (relates to visual studio
2017)
MongoDB version: 3.4.6
FCV: 3.4
Engine: wiredTiger
SSL is used: (mode: requireSSL)
security: (clusterAuthMode: x509)
All replica set members are Windows services
A replica consist of a data member + arbiter on ServerOne and a data member
on ServerTwo.

The ServerOne.pem file serves as the PEMKeyFile of ServerOne as well as
the clusterFile of the replica set.
Step one: We upgraded the replica set to version 3.6.8 and set the FCV to
3.6
That was finished successfully.

Step Two: The binaries of all members in the replica set were replaced to
version 4.0.4 and the services were
restarted successfully.
I entered the mongo shell from ServerOne and connected to the replica set
and
executed the command rs.status(). An error was displayed for the other
member (located on ServerTwo):
"lastHeartbeatMessage" : "Error connecting to ServerTwo:27011
(10.36.151.137:27011) :: caused by :: The Local Security Authority cannot
be contacted"

The full rs.status() result is in the file rs-status-result.txt

The error is a windows error, but it does not occur on MongoDB 3.4.6 and
MongoDB 3.6.8
So I assume that something the 4.0.x binaries is doing something extra that
triggers that error.

Is anyone did encountered something similar?

Thanks,
Itzik
--
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/d4e307a3-2962-44aa-8285-bfbeadfcc9a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
MH
2018-12-01 19:05:39 UTC
Permalink
I'm not familiar enough with setting up 509 auth but I suspect something
with the key files.

Why do you have the arbiter on server one? That could cause some problems,
we placed our arbiter on the server where the application resides. You also
might want to look at this
<https://docs.mongodb.com/manual/reference/read-concern-majority/#disable-read-concern-majority> regarding
read concern in a PSA architecture. I had my secondary down for a few days
and it caused performance problems.
Post by Itzi Kagan
There are two servers (ServerOne, ServerTwo) with the following
OS: Windows server 2012R2
RAM: 3GB
Installed: latest version of vc_redist.x64.exe (relates to visual studio
2017)
MongoDB version: 3.4.6
FCV: 3.4
Engine: wiredTiger
SSL is used: (mode: requireSSL)
security: (clusterAuthMode: x509)
All replica set members are Windows services
A replica consist of a data member + arbiter on ServerOne and a data
member on ServerTwo.
The ServerOne.pem file serves as the PEMKeyFile of ServerOne as well as
the clusterFile of the replica set.
Step one: We upgraded the replica set to version 3.6.8 and set the FCV to
3.6
That was finished successfully.
Step Two: The binaries of all members in the replica set were replaced to
version 4.0.4 and the services were
restarted successfully.
I entered the mongo shell from ServerOne and connected to the replica set
and
executed the command rs.status(). An error was displayed for the other
"lastHeartbeatMessage" : "Error connecting to ServerTwo:27011 (
10.36.151.137:27011) :: caused by :: The Local Security Authority cannot
be contacted"
The full rs.status() result is in the file rs-status-result.txt
The error is a windows error, but it does not occur on MongoDB 3.4.6 and
MongoDB 3.6.8
So I assume that something the 4.0.x binaries is doing something extra
that triggers that error.
Is anyone did encountered something similar?
Thanks,
Itzik
--
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/721fe697-5eaa-4f56-bf9f-f0e54c0d325c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Itzi Kagan
2018-12-01 20:39:00 UTC
Permalink
Thanks,
We put the arbiter on ServerOne because that is the only place left for us.
So far until version 4.0.4 it worked well.
Post by MH
I'm not familiar enough with setting up 509 auth but I suspect something
with the key files.
Why do you have the arbiter on server one? That could cause some problems,
we placed our arbiter on the server where the application resides. You also
might want to look at this
<https://docs.mongodb.com/manual/reference/read-concern-majority/#disable-read-concern-majority> regarding
read concern in a PSA architecture. I had my secondary down for a few days
and it caused performance problems.
Post by Itzi Kagan
There are two servers (ServerOne, ServerTwo) with the following
OS: Windows server 2012R2
RAM: 3GB
Installed: latest version of vc_redist.x64.exe (relates to visual studio
2017)
MongoDB version: 3.4.6
FCV: 3.4
Engine: wiredTiger
SSL is used: (mode: requireSSL)
security: (clusterAuthMode: x509)
All replica set members are Windows services
A replica consist of a data member + arbiter on ServerOne and a data
member on ServerTwo.
The ServerOne.pem file serves as the PEMKeyFile of ServerOne as well as
the clusterFile of the replica set.
Step one: We upgraded the replica set to version 3.6.8 and set the FCV
to 3.6
That was finished successfully.
Step Two: The binaries of all members in the replica set were replaced
to version 4.0.4 and the services were
restarted successfully.
I entered the mongo shell from ServerOne and connected to the replica set
and
executed the command rs.status(). An error was displayed for the other
"lastHeartbeatMessage" : "Error connecting to ServerTwo:27011 (
10.36.151.137:27011) :: caused by :: The Local Security Authority cannot
be contacted"
The full rs.status() result is in the file rs-status-result.txt
The error is a windows error, but it does not occur on MongoDB 3.4.6 and
MongoDB 3.6.8
So I assume that something the 4.0.x binaries is doing something extra
that triggers that error.
Is anyone did encountered something similar?
Thanks,
Itzik
--
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/f46128e4-c5e3-4b81-92e3-c2f5c4fdca1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Itzi Kagan
2018-12-04 05:02:23 UTC
Permalink
OK, I understood my mistake.

I thought that the "clusterFile" on all config files should be the same,
and it happen not to be so!

When I change the name of the "clusterFile" to be the same as the name of
the "PEMKeyFile" it start working.



Thanks,

Itzik
Post by Itzi Kagan
There are two servers (ServerOne, ServerTwo) with the following
OS: Windows server 2012R2
RAM: 3GB
Installed: latest version of vc_redist.x64.exe (relates to visual studio
2017)
MongoDB version: 3.4.6
FCV: 3.4
Engine: wiredTiger
SSL is used: (mode: requireSSL)
security: (clusterAuthMode: x509)
All replica set members are Windows services
A replica consist of a data member + arbiter on ServerOne and a data
member on ServerTwo.
The ServerOne.pem file serves as the PEMKeyFile of ServerOne as well as
the clusterFile of the replica set.
Step one: We upgraded the replica set to version 3.6.8 and set the FCV to
3.6
That was finished successfully.
Step Two: The binaries of all members in the replica set were replaced to
version 4.0.4 and the services were
restarted successfully.
I entered the mongo shell from ServerOne and connected to the replica set
and
executed the command rs.status(). An error was displayed for the other
"lastHeartbeatMessage" : "Error connecting to ServerTwo:27011 (
10.36.151.137:27011) :: caused by :: The Local Security Authority cannot
be contacted"
The full rs.status() result is in the file rs-status-result.txt
The error is a windows error, but it does not occur on MongoDB 3.4.6 and
MongoDB 3.6.8
So I assume that something the 4.0.x binaries is doing something extra
that triggers that error.
Is anyone did encountered something similar?
Thanks,
Itzik
--
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/42fbfa98-7799-41eb-9659-1e16c9211e9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...