[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: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| 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 |
| 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 |
| 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. |