[SERVER-38165] Test that prepared transactions work with an in-memory secondary Created: 15/Nov/18  Updated: 29/Oct/23  Resolved: 22/Apr/19

Status: Closed
Project: Core Server
Component/s: Replication, Testing Infrastructure
Affects Version/s: None
Fix Version/s: 4.1.11

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Dianna Hohensee (Inactive)
Resolution: Fixed Votes: 0
Labels: prepare_basic, txn_storage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-12657 Docs for SERVER-38165: Test that prep... Closed
Duplicate
is duplicated by SERVER-37943 Enable replica set transactions for t... Closed
Problem/Incident
Related
related to SERVER-41699 Make sure we are running transactions... Closed
related to SERVER-40462 Disallow transactions on shard serve... Closed
is related to SERVER-36494 Prevent oplog truncation of oplog ent... Closed
is related to SERVER-37943 Enable replica set transactions for t... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-03-25, Storage NYC 2019-04-22
Participants:
Linked BF Score: 0

 Description   

SERVER-37943 makes transactions work with the in-memory storage engine. In 4.0 an in-memory secondary can apply transactions, an in-memory primary just won't accept them. Even if we do not make transactions work on in-memory primaries, they must work for in-memory secondaries.



 Comments   
Comment by Githook User [ 22/Apr/19 ]

Author:

{'email': 'dianna.hohensee@10gen.com', 'name': 'Dianna', 'username': 'DiannaHohensee'}

Message: SERVER-38165 add the 'requires_persistence' tag to recover_prepared_transactions_startup_secondary_application.js so it does not run on the inMemory storage engine
Branch: master
https://github.com/mongodb/mongo/commit/8fea1553c0ddc6bf632d6d9e951a510892d6f1c5

Comment by Dianna Hohensee (Inactive) [ 22/Apr/19 ]

Cool. I just closed SERVER-37943 as a dupe.

Comment by Judah Schvimer [ 22/Apr/19 ]

Can we close SERVER-37943 as a duplicate?

There are none that I know of. The above commit enables all testing, including sharded clusters. SERVER-40462 will need documentation changes around the behavior involving writeConcernMajorityJournalDefault.

Comment by Dianna Hohensee (Inactive) [ 22/Apr/19 ]

judah.schvimer, I marked this as needing documentation, saying that transactions work on inMemory. I don't believe there are any qualifications on that, but wanted to check.

Comment by Githook User [ 22/Apr/19 ]

Author:

{'email': 'dianna.hohensee@10gen.com', 'name': 'Dianna', 'username': 'DiannaHohensee'}

Message: SERVER-38165 Enable transactions testing with the inMemory storage engine
Branch: master
https://github.com/mongodb/mongo/commit/96bf04156c9a78446f6b5dea988888427e032a2f

Comment by Alyson Cabral (Inactive) [ 01/Apr/19 ]

Is it possible to ban transactions that come through the mongos for in-memory nodes? If so, that's my ideal.

Comment by Judah Schvimer [ 27/Mar/19 ]

alyson.cabral, I think the first question here is, how much do we have to support transactions on in-memory nodes? For both transactions that go through prepare and transactions that do not go through prepare, do we have to support them on in-memory primaries? Do we have to support them for in-memory secondaries that have a non-in-memory primary or are the in-memory secondaries allowed to fassert on seeing an oplog entry relevant to prepare or relevant to transactions in general?

  • If we are allowed to ban them on primaries, we should add the ban back in.
  • If we are only allowed to crash in-memory secondaries that see prepare, then we need to make that graceful and make SERVER-36494 work for in-memory secondaries with Larger Transactions.
  • If we are allowed to crash in-memory secondaries that see any transaction oplog entry, then we only need to make that graceful.
Comment by Judah Schvimer [ 27/Mar/19 ]

This ticket will include (or should file other tickets for) any work to make sure in-memory nodes are both 1) able to truncate their oplog and 2) do not truncate their oplog prematurely for both Larger Transactions and Prepare post SERVER-36494.

Comment by Judah Schvimer [ 08/Mar/19 ]

siyuan.zhou and I discovered last night that we think dianna.hohensee removed the code to ban transactions on in-memory nodes in SERVER-36072. SERVER-37943 was just about re-enabling tests. It seems we may need to reintroduce the ban on transactions on in-memory nodes as part of this ticket if we choose to continue prohibiting them.

Comment by Tess Avitabile (Inactive) [ 08/Mar/19 ]

I don't believe we need to handle the case where in-memory secondaries with prepared transactions become primary. We would document that transactions are only supported on in-memory nodes with priority:0 or votes:0. Applications using transactions would not be built against replica sets with an in-memory node that could become primary, since transactions would stop succeeding when that node became primary. There is no issue with upgrading applications using transactions against replica sets to sharded clusters because applications using transactions cannot be built against replica sets with an in-memory node that could become primary.

However, if there is any work involved in supporting rollback for Prepare or Larger Transactions on in-memory secondaries, then I am in favor of stopping support for this use case.

Comment by Judah Schvimer [ 07/Mar/19 ]

siyuan.zhou, we do not currently support transactions on in-memory nodes (SERVER-37943), but we also do not do anything to prevent them from replicating to in-memory secondaries. In-memory nodes don't have any extra problems with resources, just we'd run into problems if they could prepare transactions as a secondary but not commit or abort them as a primary, which is the direction we're heading in.

Comment by Siyuan Zhou [ 07/Mar/19 ]

I see Judah's point why the storage change to support SERVER-36494 excludes the in-memory storage engine, but it's unclear to me how different that is from the current way in storage to truncate oplog on in-memory nodes. If I understand correctly, the concern about large transaction is that we used to allow transactions on in-memory nodes, but due to the new forma of large transactions, we'd have to change the way of truncating oplog on in-memory nodes. That's a good point. Is it possible to call the callback to replication used by SERVER-36494 without checkpointing?

If an in-memory secondary prepares a transaction and steps up as primary, but it cannot commit the transaction, does it just leave the transaction prepared indefinitely pinning resources?

I agree that prepared and large transactions require more space to store the oplog, but I don't see why it's fundamentally different from the existing resource assumption of in-memory storage - the memory should be large enough for everything that used to be on disk.

Comment by Judah Schvimer [ 07/Mar/19 ]

Since SERVER-36494 is also used to ensure we keep enough oplog for larger transactions, does this mean that larger transactions will not work on in-memory secondaries?

I think that without more work, with larger transactions there is a chance that rollback would fail due to not having the oplog entries needed to recover. CC siyuan.zhou

Comment by Tess Avitabile (Inactive) [ 07/Mar/19 ]

I believe this is for priority:0 in-memory secondaries, so we don't need to worry about the node becoming primary.

SinceĀ SERVER-36494 is also used to ensure we keep enough oplog for larger transactions, does this mean that larger transactions will not work on in-memory secondaries?

I am in favor of cutting work to support transactions on in-memory secondaries.

Comment by Judah Schvimer [ 07/Mar/19 ]

I'm not actually sure that this ticket makes sense. If an in-memory secondary prepares a transaction and steps up as primary, but it cannot commit the transaction, does it just leave the transaction prepared indefinitely pinning resources? Additionally, having enough oplog for rollback was going to be a byproduct of SERVER-36494, but that would no longer be the case for an in-memory storage engine since it doesn't take checkpoints. It would have to do something different to truncate the oplog but not truncate oplog entries required for RTT.

I doubt SERVER-37943 will land since it's not marked "4.1 Required", but then I'm not sure now to prevent an in-memory secondary from getting into a bad state. We could make SERVER-37943 required, and add work to keep enough oplog for rollback with the in-memory storage engine (potentially with some periodic background job to query the "oldest active transaction timestamp at the time of the stable timestamp"). Alternatively we could just document that this is not allowed and fassert in-memory secondaries that receive prepareTransaction commands.

alyson.cabral and tess.avitabile, what do you think?

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