[SERVER-38576] Ban direct writes to transaction table in replset Created: 12/Dec/18 Updated: 04/Apr/19 Resolved: 03/Apr/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Siyuan Zhou | Assignee: | Kaloian Manassiev |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | prepare_errors | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Sprint: | Sharding 2018-12-31, Sharding 2019-01-14, Sharding 2019-01-28, Sharding 2019-02-11, Sharding 2019-02-25, Sharding 2019-03-11, Sharding 2019-03-25, Sharding 2019-04-08 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
We support the direct writes to transaction table, "config.transactions", to provide the maintenance ability to Support team. However, transactions use the transaction table for persistency as well. Changing its content arbitrarily may corrupt the data on the node and across the cluster. Thus we should ban direct writes to the transaction table in a replset. There's no restriction for writes to "config.transactions" in standalone mode. Support team can still restart the node in standalone mode, fix its content and restart as a replica, whenever that's necessary. This work should also remove the session invalidation in OpObserver for direct writes on transaction table. |
| Comments |
| Comment by Judah Schvimer [ 04/Apr/19 ] |
|
That's reasonable to me. |
| Comment by Kaloian Manassiev [ 04/Apr/19 ] |
|
That would be a problem, yes, but it is not different that customers being able to write to the config.chunks collection for example. The only reason why we want to fix this ticket is so the server doesn't crash when the fuzzer tests do it. Our stance on this has been that this not something that we support, but there is merit in allowing for emergency support situations. And because it requires administrative privileges, regular users are not able to do it. |
| Comment by Judah Schvimer [ 04/Apr/19 ] |
|
|
| Comment by Kaloian Manassiev [ 03/Apr/19 ] |
|
The fundamental reason to disable direct writes to the transactions collection is because it may make the on disk state out of sync with the in-memory cache. However, through |
| Comment by Siyuan Zhou [ 16/Jan/19 ] |
|
Session reaper is internal and has a simpler concurrency requirement. For example, it will not run on a prepared transaction. We are able to distinguish internal operation and user operation. Does it make sense to only ban user direct writes to the transaction table? CC judah.schvimer. |
| Comment by Kaloian Manassiev [ 15/Jan/19 ] |
|
I don't think we can actually ban direct writes to the transactions collection, because this is what the sessions reaper does when expiring sessions. Because of this I am going to repurpose this ticket to mean "fix the concurrency control around direct writes to the transactions collection". |
| Comment by Siyuan Zhou [ 12/Dec/18 ] |
|
alyson.cabral and bruce.lucas@mongodb.com, this ticket is from a meeting with kaloian.manassiev and judah.schvimer to simplify the state management in transaction participant. We are not aware of any real case where this support feature is used. Does this proposed change make sense to you? kaloian.manassiev, assigning to Sharding team, since it's about retryable writes, but Replicaiton team is also equipped to handle this if the OpObserver is the only thing that needs to be removed. |