[SERVER-3715] re-adding member to replica set without keyFile results in secondary node Created: 29/Aug/11  Updated: 11/Jul/16  Resolved: 05/Oct/11

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.0.0-rc0
Fix Version/s: 2.0.2, 2.1.0

Type: Bug Priority: Major - P3
Reporter: Greg Studer Assignee: Kristina Chodorow (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File reproduce_test_and_servers_js.patch    
Issue Links:
Depends
Related
related to SERVER-15077 remove authissue/blockSync logic Closed
is related to SERVER-9110 checkAuth can cause step down on Auth... Closed
Operating System: ALL
Participants:

 Description   

If a replica set is started with authentication via a key file, and a member is shut down and restarted without a key file, the member will eventually rejoin the replica set and become a SECONDARY member, even though (it appears) that the oplog and database are empty. Queries could get routed to these nodes with weird effects.

Invalid key files result in a RECOVERING state, which is probably correct.



 Comments   
Comment by auto [ 24/Oct/11 ]

Author:

{u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}

Message: Make secondaries go into recovering state when auth is wrong SERVER-3715
Branch: v2.0
https://github.com/mongodb/mongo/commit/e65e110553c725939f0706ca42a952855fea388b

Comment by auto [ 05/Oct/11 ]

Author:

{u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}

Message: Make secondaries go into recovering state when auth is wrong SERVER-3715
Branch: master
https://github.com/mongodb/mongo/commit/d21c163de24219fa238cd92e492d8d27cdc2a55f

Comment by Eliot Horowitz (Inactive) [ 02/Oct/11 ]

A node that can't talk to any other node because of password issues, should go into recovering.

Comment by Kristina Chodorow (Inactive) [ 29/Sep/11 ]

Actually, invalid key file results in a secondary, too.

I'm not sure if this can even be handled because there is no "definitive truth" about what key file is correct. If A can't log into B and B can't log into A, who is to say which one has the right keyFile?

One possibility is that we could have a member go into RECOVERING if it can't log into the primary, but there's no guarantee it can even reach the primary (or that a primary exists at all) and, in general, isolated secondaries should still be readable.

Generated at Thu Feb 08 03:03:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.