[DOCS-14626] [SERVER] Creating a collection on standalone node that was part of a replica set may lead to fassert Created: 06/Jul/21  Updated: 29/Oct/23  Resolved: 24/Jan/23

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Dave Cuthbert (Inactive)
Resolution: Fixed Votes: 0
Labels: manual, server
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-58018 Creating a collection on standalone n... Closed
Participants:
Days since reply: 1 year, 2 weeks, 1 day ago
Epic Link: DOCSP-11701

 Description   

ORIGINAL TITLE: Investigate changes in SERVER-58018: Creating a collection on standalone node that was part of a replica set may lead to fassert

Downstream Change Summary

If the following sequence of events occurs:

1. Node n in replica set is restarted as standalone
2. User creates a replicated collection on n
3. n rejoins the replica set

In this case, the collection created on n in standalone mode would have a different UUID compared to the rest of the replica set. As a result, any subsequent operations on that collection would lead to an fassert.

Should we update the docs around creating a replicated collection in standalone mode to inform users of this potential issue? This may help inform users about having collections with mismatched UUIDs. Thank you!

Description of Linked Ticket

If the following sequence of events occurs:

  1. Node n in replica set is restarted as standalone
  2. User creates a replicated collection on n
  3. n rejoins the replica set

In this case, the collection created on n in standalone mode would have a different UUID compared to the rest of the replica set. As a result, any subsequent operations on that collection would lead to an fassert.

To help alleviate this, one idea is require an explicit UUID when creating this new collection, if the node is currently in standalone mode but was previously part of a replica set.

Alternatively, we can add warning logs when the node attempts to create replicated collections in standalone mode.



 Comments   
Comment by Githook User [ 24/Jan/23 ]

Author:

{'name': 'Dave Cuthbert', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}

Message: DOCS-14626 restore node (#2382) (#2437)

Comment by Githook User [ 24/Jan/23 ]

Author:

{'name': 'Dave Cuthbert', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}

Message: DOCS-14626 restore node (#2382) (#2436)

Comment by Githook User [ 24/Jan/23 ]

Author:

{'name': 'Dave Cuthbert', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}

Message: DOCS-14626 restore node (#2382) (#2434)

Comment by Githook User [ 24/Jan/23 ]

Author:

{'name': 'Dave Cuthbert', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}

Message: DOCS-14626 restore node (#2382) (#2435)

Comment by Githook User [ 23/Jan/23 ]

Author:

{'name': 'Dave Cuthbert', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}

Message: DOCS-14626 restore node (#2382)

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