MongoDB with Replication connection issue on GCP

Keywords: MongoDB - Google Cloud Platform - Technical issue - Connectivity (SSH/FTP)
Description:
Hi, there

I am encountering the exact same issue as in this post (status and setup)

I have one primary + 2 secondary nodes. And I couldn’t connect using the replica uri. The link in the previous post seems expired.

Did anybody see this?

Thanks

Hi @zwei,

We made some changes in our documentation system and some links are not redirected properly and we are working on fixing them. I just updated the link in the other thread, this is the good one:

https://docs.bitnami.com/google-templates/infrastructure/mongodb/administration/connect-app-cluster/

Let us know if you have any questions.

Thanks @jota for the quick response. I did read this page.

Follows is the uri I used to connect through Compass or Robo 3T (neither works)
mongodb://{user}:{pswd}@{PRIMARY_IP}:27017,${SECONDARY1_IP}:27017,${SECONDARY2_IP}:27017/${DB}?replicaSet=rs0

I managed the instance through:

mongo admin --username root -p --host rs0/{PRIMARY_IP}:27017,{SECONDARY1_IP}:27017,{SECONDARY2_IP}:27017

and
rs.status() shows

{
    "set" : "rs0",
    "date" : ISODate("2019-01-24T17:47:39.409Z"),
    "myState" : 1,
    "term" : NumberLong(6),
    "syncingTo" : "",
    "syncSourceHost" : "",
    "syncSourceId" : -1,
    "heartbeatIntervalMillis" : NumberLong(2000),
    "optimes" : {
            "lastCommittedOpTime" : {
                    "ts" : Timestamp(1548352055, 1),
                    "t" : NumberLong(6)
            },
            "readConcernMajorityOpTime" : {
                    "ts" : Timestamp(1548352055, 1),
                    "t" : NumberLong(6)
            },
            "appliedOpTime" : {
                    "ts" : Timestamp(1548352055, 1),
                    "t" : NumberLong(6)
            },
            "durableOpTime" : {
                    "ts" : Timestamp(1548352055, 1),
                    "t" : NumberLong(6)
            }
    },
    "lastStableCheckpointTimestamp" : Timestamp(1548352035, 1),
    "members" : [
            {
                    "_id" : 0,
                    "name" : PRIMARY_IP,
                    "health" : 1,
                    "state" : 1,
                    "stateStr" : "PRIMARY",
                    "uptime" : 49650,
                    "optime" : {
                            "ts" : Timestamp(1548352055, 1),
                            "t" : NumberLong(6)
                    },
                   "optimeDate" : ISODate("2019-01-24T17:47:35Z"),
                    "syncingTo" : "",
                    "syncSourceHost" : "",
                    "syncSourceId" : -1,
                    "infoMessage" : "",
                    "electionTime" : Timestamp(1548302432, 1),
                    "electionDate" : ISODate("2019-01-24T04:00:32Z"),
                    "configVersion" : 3,
                    "self" : true,
                    "lastHeartbeatMessage" : ""
            },
            {
                    "_id" : 1,
                    "name" : SECONDARY1_IP,
                    "health" : 1,
                    "state" : 2,
                    "stateStr" : "SECONDARY",
                    "uptime" : 49645,
                    "optime" : {
                            "ts" : Timestamp(1548352055, 1),
                            "t" : NumberLong(6)
                    },
                    "optimeDurable" : {
                            "ts" : Timestamp(1548352055, 1),
                            "t" : NumberLong(6)
                    },
                    "optimeDate" : ISODate("2019-01-24T17:47:35Z"),
                    "optimeDurableDate" : ISODate("2019-01-24T17:47:35Z"),
                    "lastHeartbeat" : ISODate("2019-01-24T17:47:37.756Z"),
                    "lastHeartbeatRecv" : ISODate("2019-01-24T17:47:37.757Z"),
                    "pingMs" : NumberLong(0),
                    "lastHeartbeatMessage" : "",
                    "syncingTo" : SECONDARY2_IP,
                    "syncSourceHost" : SECONDARY2_IP,
                    "syncSourceId" : 2,
                    "infoMessage" : "",
                    "configVersion" : 3
            },
            {
                    "_id" : 2,
                    "name" : SECONDARY2_IP,
                    "health" : 1,
                    "state" : 2,
                    "stateStr" : "SECONDARY",
                    "uptime" : 49648,
                    "optime" : {
                            "ts" : Timestamp(1548352055, 1),
                            "t" : NumberLong(6)
                    },
                    "optimeDurable" : {
                            "ts" : Timestamp(1548352055, 1),
                            "t" : NumberLong(6)
                    },
                    "optimeDate" : ISODate("2019-01-24T17:47:35Z"),
                    "optimeDurableDate" : ISODate("2019-01-24T17:47:35Z"),
                    "lastHeartbeat" : ISODate("2019-01-24T17:47:37.756Z"),
                    "lastHeartbeatRecv" : ISODate("2019-01-24T17:47:37.755Z"),
                    "pingMs" : NumberLong(0),
                    "lastHeartbeatMessage" : "",
                    "syncingTo" : PRIMARY_IP,
                    "syncSourceHost" : PRIMARY_IP,
                    "syncSourceId" : 0,
                    "infoMessage" : "",
                    "configVersion" : 3
            }
    ],
    "ok" : 1,
    "operationTime" : Timestamp(1548352055, 1),
    "$clusterTime" : {
            "clusterTime" : Timestamp(1548352055, 1),
            "signature" : {
                    "hash" : xx,
                    "keyId" : xx
			} 
       }
}

The strange thing is that: If I only used the primary node to connect, I can do that.

Thanks

Hi @zwei,

If you are trying to access the MongoDB instances remotely without using a SSH tunnel, have you ensure that all those instances have a public IP and the port 27017 is open in the firewall rules?

Let us know if you have any questions

Yes, I did open the port and set the external ip as in the instruction.

telnet {PRIMARY_ID} 27017
Trying {PRIMARY_ID}...
Connected to xxxxxx.bc.googleusercontent.com.
Escape character is '^]'.
Connection closed by foreign host.

telnet {SECONDARY1_IP} 27017

Trying  {SECONDARY1_IP}...
Connected to  xxxxxx.bc.googleusercontent.com.
Escape character is '^]'.
Connection closed by foreign host.

telnet  {SECONDARY2_IP} 27017
Trying  {SECONDARY2_IP}...
Connected to xxxxxxx.bc.googleusercontent.com.
Escape character is '^]'.

Hi @zwei,

We’re able to connect properly with the MongoDB CLI (“mongo”), e.g.:

mongo mongodb://root:PASSWORD@IP_1:27017,IP_2:27017,IP_3:27017/admin
MongoDB shell version v3.6.2
...

However, please note it is possible not all drivers support specifying multiple instances in a replica set at once.

Also, we were able to reproduce your issue with Robo 3T, but it seems to be a bug specific to the tool itself, not MongoDB. Even specifying manually the replica set name “rs0” did not fix the issue, so it is likely there is a bug with the tool.

Thanks @marcos

I am able to connect through

mongo mongodb://root:PASSWORD@IP_1:27017,IP_2:27017,IP_3:27017/admin

However, I got error if i do

mongo mongodb://root:PASSWORD@IP_1:27017,IP_2:27017,IP_3:27017/admin?replicaSet=rs0

which is recommended in the instruction at https://docs.bitnami.com/google-templates/infrastructure/mongodb/administration/connect-app-cluster/

@zwei What error do you get when connecting with that command? You mentioned in post #3 that it worked for you.

Follow is what I got:

MongoDB shell version v4.0.5
connecting to: mongodb://{PRIMARY_EXTERNAL_IP}:27017,{SECONDARY1_EXTERNAL_IP}:27017,{SECONDARY2_EXTERNAL_IP}:27017/? 
gssapiServiceName=mongodb&replicaSet=rs0
2019-01-28T11:29:29.384-0800 I NETWORK  [js] Starting new replica set monitor for 
rs0/{PRIMARY_EXTERNAL_IP}:27017,{SECONDARY1_EXTERNAL_IP}:27017,{SECONDARY2_EXTERNAL_IP}:27017
2019-01-28T11:29:29.497-0800 I NETWORK  [ReplicaSetMonitor-TaskExecutor] Successfully connected to             
{SECONDARY1_EXTERNAL_IP}:27017 (1 connections now open to {PRIMARY_EXTERNAL_IP}:27017 with a 5 second timeout)
2019-01-28T11:29:29.498-0800 I NETWORK  [js] Successfully connected to {SECONDARY1_EXTERNAL_IP}:27017 (1 connections 
now open to {SECONDARY2_EXTERNAL_IP}:27017 with a 5 second timeout)
2019-01-28T11:29:29.646-0800 I NETWORK  [js] Successfully connected to  {SECONDARY2_EXTERNAL_IP}:27017 (1 connections now 
open to {PRIMARY_EXTERNAL_IP}:27017 with a 5 second timeout)
2019-01-28T11:29:29.685-0800 I NETWORK  [js] changing hosts to 
rs0/{PRIMARY_INTERNAL_IP}:27017,{SECONDARY1_EXTERNAL_IP}:27017,{SECONDARY2_EXTERNAL_IP} from 
rs0/{PRIMARY_EXTERNAL_IP}:27017,{SECONDARY1_EXTERNAL_IP}:27017,{SECONDARY2_EXTERNAL_IP}
^C2019-01-28T11:29:35.587-0800 E -        [main] Error saving history file: FileOpenFailed: Unable to open() file : 
Unknown error
2019-01-28T11:29:35.587-0800 I CONTROL  [main] shutting down with code:0

Is it something related to host name as mentioned in:

https://github.com/bitnami/bitnami-docker-mongodb/issues/84

Hi @zwei, it turns out that is the issue. In our documentation we mention this:

Option 3: Make the server publicly accessible and restrict access to a trusted list of source IP addresses using firewall rules. Refer to the FAQ for information on opening ports in the server firewall.

But that is wrong, unless you change the IP of each MongoDB node to be the public IP. And changing the IP of all nodes in a MongoDB cluster can be a bit complex, as you must do it in all nodes and make sure the IP for each one is static (if it is dynamic it may break after restarting a node).

Instead, if you want to use the MongoDB cluster with an app, would it be possible for you to peer virtual networks for your application and MongoDB? See: https://docs.bitnami.com/google-templates/how-to/connect-instances-network-peering/

If you only need to connect to MongoDB via the CLI, you can run the “mongo” command above inside one of the MongoDB nodes (e.g. PRIMARY_EXTERNAL_IP).

In the meantime, we will look into documenting how to change the IP of all MongoDB nodes, and correct option 3 in our docs.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.