[SERVER-34557] Allow running transactions against primaries with readPreferences other than 'primary' Created: 18/Apr/18  Updated: 29/Oct/23  Resolved: 02/May/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: William Schultz (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
related to SERVER-43708 Wait for nodes to become secondary in... Closed
is related to SERVER-37189 transactions.currentActive has a valu... Closed
is related to SERVER-40473 Using readPreference: secondary in mu... Closed
is related to SERVER-33580 Restrict multi-statement transactions... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.6
Sprint: Repl 2018-05-07
Participants:
Linked BF Score: 0

 Description   

We want to restrict transactions to only run on primaries. The way SERVER-33580 accomplished that was by restricting them to only work if the readPreference provided was 'primary'. Drivers, however, may send 'primaryPreferred' when connected to a primary via a direct connection.

We should undo the server changes from SERVER-33580, and instead change the checkCanServeReadsFor method in ReplicationCoordinator to return false if the node is not currently primary and we're in a transaction.



 Comments   
Comment by Githook User [ 09/Oct/19 ]

Author:

{'username': 'jasonjhchan', 'email': 'jason.chan@mongodb.com', 'name': 'Jason Chan'}

Message: SERVER-34557 last_vote.js needs to wait for stable node before reading oplog

(cherry picked from commit 381acc4baa6d5f730fb77be5acc39f8473a16b88)

SERVER-34557 Make sure slave_delay_clean_shutdown.js awaits secondary nodes before
reading from oplog after restarting node

(cherry picked from commit 978ee4b254f75351006648577f1e0fd3673ee412)
Branch: v3.6
https://github.com/mongodb/mongo/commit/2b9354fd6fddc70aecfcaf3dc53593df203248b8

Comment by Jason Chan [ 27/Sep/19 ]

The bug fixes in this ticket should be backported to v3.6:
https://github.com/mongodb/mongo/commit/381acc4baa6d5f730fb77be5acc39f8473a16b88
and
https://github.com/mongodb/mongo/commit/978ee4b254f75351006648577f1e0fd3673ee412

Filed SERVER-43708 to make it not look like we are backporting the entirety of SERVER-34557.

Comment by Githook User [ 04/May/18 ]

Author:

{'email': 'william.schultz@mongodb.com', 'name': 'William Schultz', 'username': 'will62794'}

Message: SERVER-34557 last_vote.js needs to wait for stable node before reading oplog
Branch: master
https://github.com/mongodb/mongo/commit/381acc4baa6d5f730fb77be5acc39f8473a16b88

Comment by Githook User [ 02/May/18 ]

Author:

{'email': 'william.schultz@mongodb.com', 'name': 'William Schultz', 'username': 'will62794'}

Message: SERVER-34557 Make sure slave_delay_clean_shutdown.js awaits secondary nodes before
reading from oplog after restarting node
Branch: master
https://github.com/mongodb/mongo/commit/978ee4b254f75351006648577f1e0fd3673ee412

Comment by William Schultz (Inactive) [ 02/May/18 ]

With this change, transactions should now only be allowed to run against a replica set primary, but with any read preference that is supported on primary. We no longer explicitly take the read preference into account when determining whether a transaction is allowed to execute. We instead directly check the replication member state for that node i.e. PRIMARY, SECONDARY, etc.

Comment by Githook User [ 02/May/18 ]

Author:

{'email': 'william.schultz@mongodb.com', 'name': 'William Schultz', 'username': 'will62794'}

Message: SERVER-34557 Restrict transactions to only run against replica set primaries
Branch: master
https://github.com/mongodb/mongo/commit/e8fe32029aded4d0e909f531196edff43c96cfff

Comment by Bernie Hackett [ 26/Apr/18 ]

Not just 'primaryPreferred', that's the case with OP_MSG. With OP_QUERY we set the slaveOk wire protocol bit, which the server translates to 'secondaryPreferred.'

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