[DOCS-10803] Highlight renameCollection caveats Created: 18/Sep/17  Updated: 30/Oct/23  Resolved: 25/Oct/17

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

Type: Improvement Priority: Major - P3
Reporter: Stennie Steneker (Inactive) Assignee: Stennie Steneker (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by DOCS-10528 Docs for SERVER-15723: Avoid G_X lock... Closed
Participants:
Days since reply: 6 years, 21 weeks, 2 days ago

 Description   

The renameCollection command says it is "suitable for production environments:
https://docs.mongodb.com/manual/reference/command/renameCollection/#behavior

.. and then highlights two caveats that contradict this:

  • renameCollection blocks all database activity for the duration of the operation.
  • renameCollection is not compatible with sharded collections.

The most important warning is lurking below the example:

This command obtains a global write lock and will block other operations until it has completed.

I think this should not be recommended for production environments and the warning on global lock should be prominently featured. An initial skim of the "blocks all database activity" point might suggest that this only blocks activity for the current database rather than globally.

Note: SERVER-15723 will improve the lock granularity for renames within the same database, but renaming a collection between databases will still involve a global write lock while the data is copied to the target database.


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