[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:
Depends
Duplicate
duplicates SERVER-36483 Transaction reaper should not reap 'c... Closed
Related
related to SERVER-37235 invalidateSessions calls inside the O... Closed
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 ]

SERVER-36483 only prevents writes for transactions with state "prepared". If the state is "committed" or "aborted" but formerly was "prepared", is it a problem that a user could effectively change the decision of the transaction for that shard?

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 SERVER-36483 we will solve that problem, so I am closing this ticket as duplicate.

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.

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