[DOCS-14135] Investigate changes in SERVER-53247: Disable enableMajorityReadConcern:false Created: 19/Jan/21 Updated: 13/Nov/23 Due: 16/Jul/21 Resolved: 13/Jul/21 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Backlog - Core Eng Program Management Team | Assignee: | Joseph Dougherty |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Days since reply: | 2 years, 5 weeks, 1 day ago | ||||||||||||||||||||||||
| Epic Link: | DOCSP-9747 | ||||||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||||||
| Description |
DescriptionDownstream Change Summary The server explicitly disallows enableMajorityReadConcern:false to be specified on the command line when starting mongod. Any team that current sets this server parameter to false will be affected. Since we are removing support for the behaviors gated by that server parameter, teams should also be able to remove testing and code using eMRC=false. Please see PM-1769 for more information about what else the server is planning to remove. Description of Linked TicketWiredTiger recently completed an investigation of the feasibility of removing enableMajorityReadConcern:false now that WT has durable history. After reviewing the findings of that investigation, we are moving forward with Removing Support for enableMajorityReadConcern:false. Durable History addresses cache pressure concerns around majority commit point lag allowing for the removal of eMRC:false (a mode of operation that does not allow distributed transactions and other features). We need to disable support for eMRC:false as a first step. In a future release, we will fully remove support for eMRC:false. Scope of changesReview https://docs.mongodb.com/manual/reference/read-concern-majority/#disable-read-concern-majority and possibly other mentions? One approach might be to replace that section with a blurb like 'Starting in MDB 5.0, you can't do this. If you're an older version, refer to those docs to see how to disable maj RC." Impact to Other Docshttps://docs.mongodb.com/manual/core/transactions/index.html#disabled-read-concern-majority Does this also apply to the replication / sharding settings / parameters?
MVP (Work and Date)Resources (Scope or Design Docs, Invision, etc.) |
| Comments |
| Comment by Huayu Ouyang [ 04/Jan/22 ] |
|
I think we should backport these docs changes to 5.0 |
| Comment by Judah Schvimer [ 02/Jan/22 ] |
|
joseph.dougherty and huayu.ouyang, should we be backporting these documentation changes to the 5.0 docs per this comment? CC eric.reid |
| Comment by Githook User [ 13/Jul/21 ] |
|
Author: {'name': 'Joseph Dougherty', 'email': 'joseph.dougherty@mongodb.com', 'username': 'jmd-mongo'}Message: |
| Comment by Alan Zheng [ 02/Jul/21 ] |
|
joseph.dougherty There are two things we want to address: 1) MongoDB has now become more resilient (via "WT durable history" and "flow control"). Not sure if we have pages for that. 2) An alternative workaround is associated with this ticket: https://jira.mongodb.org/browse/DOCS-14598 |
| Comment by Joseph Dougherty [ 02/Jul/21 ] |
|
alan.zheng What are the alternatives for users? Are there other considerations for three member PSA architectures that help avoid possible cache-pressure build up? |
| Comment by Alan Zheng [ 21/Jun/21 ] |
|
We need to keep the section about #disable-read-concern-majority for 5.0. A startup warning for those running PSA will be added in |
| Comment by Louis Williams [ 26/May/21 ] |
|
Agreed that those can be removed as well. |
| Comment by Joseph Dougherty [ 25/May/21 ] |
|
louis.williams Thanks again for the info! It looks like we should be able to remove 3 pages from the 5.0 version of the docs:
Please let me know if you have any objections. Thank you! |
| Comment by Louis Williams [ 25/May/21 ] |
|
joseph.dougherty, I think it makes sense to remove the page about upgrading to WiredTiger for the 5.0 docs. |
| Comment by Joseph Dougherty [ 24/May/21 ] |
|
Hi louis.williams, Thanks for the details. My original intent was to remove the parts of the procedure that reference setting -enableMajorityReadConcern false since it is not possible to set --enableMajorityConcern to false in v5.0. I'm trying to get a sense of what this page should look like specifically for the v5.0 docs. Does it make sense to keep this page and remove the parts that reference setting --enableMajorityConcern to false? Thanks for your help! |
| Comment by Louis Williams [ 21/May/21 ] |
|
MMAP is still available in 4.0 so we should keep that documentation until 4.0 is EOL next year. If you want to remove the MMAP-specific terminology for the 5.0 docs, that is fine. To answer your other question, it doesn't seem like we document switching from inMemory to WiredTiger. It's not a very widely used storage engine, and in fact, the two storage engines are almost identical. I don't think we need to add any special documentation for that case. |
| Comment by Joseph Dougherty [ 21/May/21 ] |
|
Hello kaloian.manassiev and louis.williams, Could you please help clarify here? I'm curious if there we should retain the Change Replica Set to WiredTiger page since support for MMAPv1 no longer exists in v5.0. Will we need to document specific procedures for users who want to change a replica set from using in-memory storage to using WiredTiger? Thank you! |
| Comment by Pavithra Vetriselvan [ 21/May/21 ] |
|
Hi joseph.dougherty, sorry about the late response! You are correct that we removed support for MMAPv1 in 4.2 so I agree that this page wouldn't need to exist if the purpose was to aid users in switching from MMAPv1. However, I still think we support the inMemory storage engine so would this page still be relevant for switching from inMemory to WiredTiger? Perhaps someone from the Execution Team should also verify? |