[SERVER-8527] $external database is created as a database and prevented sharding Created: 12/Feb/13 Updated: 11/Jul/16 Resolved: 14/Feb/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security, Sharding |
| Affects Version/s: | 2.4.0-rc0 |
| Fix Version/s: | 2.4.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Mark porter | Assignee: | Andy Schwerin |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
MongoDB2.4.0-rc0 |
||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Steps To Reproduce: | See above |
||||
| Participants: | |||||
| Description |
|
The $external useSource was somehow created as a database, which doesn't seem to be quite logical. It should be an external artifact I'd have thought. I discovered this during testing of adding a sharded cluster infrastructure consisting of two already-Kerborised replica sets. 1. Step : added realm4 replica set as a shard
2. Step : added realm5 set as a shard, however, this is rejected due to the existence of the $external database on both realms. This is logical but it means some reconfiguration if making two Kerberos-enabled replica sets part of a sharded cluster.
So as expected, I can drop the $external database below -
After removing the $external database, I can now add realm5 as the second shard -
Out of curiousity what is the $SERVER database? I never created it. |
| Comments |
| Comment by auto [ 14/Feb/13 ] |
|
Author: {u'date': u'2013-02-14T17:14:09Z', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}Message: It is the attempt to acquire privileges stored in "$external.system.users" that is causing the |
| Comment by Andy Schwerin [ 13/Feb/13 ] |
|
It seems that what is happening is that a transient, in-memory Database object is created and added to the DatabaseHolder singleton via DatabaseHolder::getOrCreateDatabase() whenever a context object is created. Unfortunately, DH::gOCDB doesn't check to see if a database name is valid. That is only done, AFAICT, on the write path when deciding whether or not to create actual database files. This means that any read operation on a non-existent database, including authentication, will create one of these objects, which shows up in "listDatabases" and interferes with replicaset establishment. Restarting the affected node removes the bad entry, but I'm not certain yet what the right fix is to prevent this from manifesting. |
| Comment by Andy Schwerin [ 12/Feb/13 ] |
|
Marking 2.4.0-rc1 for triage. Note that there is a workaround, albeit painful, of manually removing the "$external" database (which has no associated files, AFAICT). It's not even a real database – it's just getting into some system catalog somehow. |