MongoDB replica sets: members, authentication, and discovery

The earlier MongoDB 4.4 notebook moved from three local processes to separately named replica-set members. Its useful thread is the relationship between membership, authentication, and the addresses clients discover.

Start with a topology

The local experiment called its members N1, N2, and N3, using ports 2717, 2727, and 2737 and separate data directories. Three processes on one machine can demonstrate replication and elections, but they do not provide three independent failure domains. An election chooses a primary; N2 is not guaranteed to become primary whenever N1 disappears.

These are the original membership and read observations:

mongo --port 2717
> rs.status()
> rs.initiate()
rs0:SECONDARY> <enter>
rs0:PRIMARY> rs.status()
# check member info, current has only primary node
rs0:PRIMARY> rs.add("localhost:2727")
rs0:PRIMARY> rs.add("localhost:2737")

mongo --port 2727
> rs.secondaryOk()

mongo --port 2737
> rs.secondaryOk()

Primary node:
rs0:PRIMARY> show dbs
rs0:PRIMARY> use test
rs0:PRIMARY> db.users.insert({"name":"nhancv"})
WriteResult({ "nInserted" : 1 })
rs0:PRIMARY> db.users.find()
{ "_id" : ObjectId("60d7035e05a5bc7636da0dbf"), "name" : "nhancv" }

Secondary node:
rs0:SECONDARY> show dbs
rs0:SECONDARY> db.users.find()
{ "_id" : ObjectId("60d7035e05a5bc7636da0dbf"), "name" : "nhancv" }

rs0:PRIMARY> rs.add("<ip_1>:2727")
rs0:PRIMARY> rs.add("<ip_2>:2737")

Secondary reads can lag the primary. Replication also does not replace a backup: an unwanted write can replicate too. The old shell syntax is preserved as MongoDB 4.4 context.

Keep client and member authentication distinct

A client authenticates as a database user. Replica-set members also need an agreed authentication mechanism; the original keyfile approach used shared key material between members.

mongo -u root -p --authenticationDatabase admin

rs0:PRIMARY > rs.status()

mkdir -p /etc/mongodb/keys
openssl rand -base64 756 > /etc/mongodb/keys/mongo-key
chmod 400 /etc/mongodb/keys/mongo-key
chown -R mongodb:mongodb /etc/mongodb

sudo nano /etc/mongod.conf

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1,<current_node_ip>

#security:
security:
  authorization: 'enabled'
  keyFile: /etc/mongodb/keys/mongo-key

#replication:
replication:
  replSetName: 'rs0'

The keyfile command is a historical fragment, not a full ownership, permissions, distribution, TLS, or bootstrap procedure. The source’s unauthenticated public listeners, broad firewall opening, password-reset shortcut, and excessive database roles are omitted.

Advertised names must be reachable

A client can contact a seed and then learn the replica set’s advertised member addresses. Each advertised host and port must resolve and be reachable from that client; a successful first connection is insufficient.

The source assigned one A record per member, one _mongodb._tcp SRV record per member and port, and TXT options for replicaSet and authSource. An SRV URI shortens the seed configuration, but does not remove DNS, TLS, authentication, or network requirements. Its old ssl=false note describes that experiment, not a general requirement.

One recorded explicit URI accidentally repeated NODE2 instead of listing NODE3; it is not reproduced as a working template. Host-specific commands and DNS screenshots are replaced with these relationships. No replica set, account, firewall, or DNS record was changed.

Reference: MongoDB connection strings.

← Back to the garden