[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: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2019-03-25, Storage NYC 2019-04-22 | ||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
|
| Comments |
| Comment by Githook User [ 22/Apr/19 ] |
|
Author: {'email': 'dianna.hohensee@10gen.com', 'name': 'Dianna', 'username': 'DiannaHohensee'}Message: |
| Comment by Dianna Hohensee (Inactive) [ 22/Apr/19 ] |
|
Cool. I just closed |
| Comment by Judah Schvimer [ 22/Apr/19 ] |
|
Can we close There are none that I know of. The above commit enables all testing, including sharded clusters. |
| 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: |
| 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?
|
| 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 |
| 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 |
| 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 ( |
| Comment by Siyuan Zhou [ 07/Mar/19 ] |
|
I see Judah's point why the storage change to support
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 ] |
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Ā 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 I doubt alyson.cabral and tess.avitabile, what do you think? |