[SERVER-31454] rs.initiate() does not load default configuration as expected Created: 06/Oct/17  Updated: 27/Oct/23  Resolved: 09/Oct/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.5.12
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Bartosz Solowiej Assignee: Unassigned
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-31464 replSetInitiate with no explicit conf... Closed
Operating System: ALL
Steps To Reproduce:

Here are the steps:

$ > mongod --port 27017 --dbpath /Users/sjcbsolo/.mongodb/data/test --logpath /Users/sjcbsolo/.mongodb/logs/test.log --logappend --logRotate rename --replSet test0 --journal --smallfiles --bind_ip 127.0.0.1 --fork
.mongodb $ > mongo localhost:27017
MongoDB shell version v3.5.12-93-g2d7aef7
connecting to: localhost:27017
MongoDB server version: 3.5.12-93-g2d7aef7
Server has startup warnings:
2017-10-06T15:38:11.864-0700 I CONTROL  [initandlisten]
2017-10-06T15:38:11.864-0700 I CONTROL  [initandlisten] ** NOTE: This is a development version (3.5.12-93-g2d7aef7) of MongoDB.
2017-10-06T15:38:11.864-0700 I CONTROL  [initandlisten] **       Not recommended for production.
2017-10-06T15:38:11.864-0700 I CONTROL  [initandlisten]
2017-10-06T15:38:11.864-0700 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2017-10-06T15:38:11.864-0700 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2017-10-06T15:38:11.864-0700 I CONTROL  [initandlisten]
MongoDB Enterprise > rs.initiate({})
{
	"info2" : "no configuration specified. Using a default configuration for the set",
	"me" : "sjca0bsolopro:27017",
	"ok" : 0,
	"errmsg" : "No host described in new configuration 1 for replica set test0 maps to this node",
	"code" : 93,
	"codeName" : "InvalidReplicaSetConfig"
}
MongoDB Enterprise > rs.initiate({
... _id: "test0",
... configsvr: false,
... members: [
...   { _id: 0, host: "localhost:27017", priority: 2 }
... ]})
{ "ok" : 1, "operationTime" : Timestamp(1507329694, 1) }
MongoDB Enterprise test0:SECONDARY>
MongoDB Enterprise test0:PRIMARY>

Participants:

 Description   

When launching a replicated local 1x1 cluster (a 1 member replicaSet), the default configuration is not applied as expected and the replicaSet remains uninitiated.

However, by passing an explicit configuration, it initializes just fine.



 Comments   
Comment by Bartosz Solowiej [ 09/Oct/17 ]

@Spencer T Brody - That makes the most sense to me especially because localhost is the default binding now. Although, I understand what @Andy Schwerin mentioned, it doesn't make sense to attempt CNAME (or any other hostname for that matter) when localhost is default. Thank you both for the feedback.

Comment by Spencer Brody (Inactive) [ 09/Oct/17 ]

This problem is exacerbated by the behavior change from SERVER-28229 to always bind to localhost by default. I have filed SERVER-31464 to change replSetInitiate to generate its default config based on localhost instead of hostnames.

Comment by Andy Schwerin [ 09/Oct/17 ]

When you do not pass an explicit replica set configuration to rs.initiate, the server against which you run the initiate command attempts to guess what host name to put into the configuration. It does this simply by calling the libc function gethostname and accepting the resulting value. This naive approach is rarely what you want for a production system, but can be good for testing.

Since you have restricted mongod to only bind to 127.0.0.1, and gethostname returns a name that resolves to another IP address, mongod is unable to find itself in the replica set configuration that it produced.

In general, mongod cannot guess the right host name to use use, because you might wish to resolve through a CNAME, your host might have multiple resolving names, or even a more complicated scenario. Because mongod cannot be right all the time, we chose a simple-to-explain mechanism with the expectation that most deployments would instead need to pass a name into rs.initiate.

Comment by Bartosz Solowiej [ 09/Oct/17 ]

Similar error but without the "info" or "me".

MongoDB Enterprise > rs.initiate({
... _id:"test0",
... configsvr: false,
... members: [
...   { _id: 0, host: "sjca0bsolopro:27018", priority: 2 }
... ]})
{
	"ok" : 0,
	"errmsg" : "No host described in new configuration 1 for replica set test0 maps to this node",
	"code" : 93,
	"codeName" : "InvalidReplicaSetConfig"
}
MongoDB Enterprise >

Comment by Andy Schwerin [ 08/Oct/17 ]

What happens if you attempt to initiate the set explicitly using the value returned in the "me" field of the failed initiate? In your example, sjca0bsolopro:27017?

Generated at Thu Feb 08 04:27:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.