[DOCS-12758] 3.6 upgrade documentation should mention risk of failure when user-creates "config" database is present. Created: 29/May/19 Updated: 30/Oct/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Rel Notes |
| Affects Version/s: | 3.6 |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Mark Brinsmead | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 1 year, 14 weeks, 2 days ago | ||||||||
| Epic Link: | DOCSP-1769 | ||||||||
| Story Points: | 0.1 | ||||||||
| Description |
DescriptionUpgrading replica set from 3.4 to 3.6 fails when a user-defined database name conflicts with the "config" database that needs to be created during upgrade. (See This is definitely the case where there is a case mismatch (e.g., pre-existing database is named "Config" or "CONFIG") – when the pre-existing database is named "config" this is still incorrect, but the upgrade will probably succeed. Customers should be advised to check for and resolve naming conflicts with config database or config.sessions and config.transactions collections before attempting to upgrade. Scope of changes
|
| Comments |
| Comment by Education Bot [ 31/Oct/22 ] |
|
Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you! |