[SERVER-40991] 4.4 binary in FCV 4.4 should not be able to read oplog entries generated by 4.2 binaries Created: 03/May/19 Updated: 06/Dec/22 Resolved: 26/Sep/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Upgrade/Downgrade |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Backlog - Replication Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Replication
|
| Participants: |
| Description |
|
Two-phase upgrade/downgrade is supposed to ensure that once a node is in a "fully upgraded" FCV, then it never reads an oplog entry from the previous binary version. Committing a prepared transaction must be able to read an oplog entry behind the commit point. The Global S lock taken during upgrade/downgrade should ensure that no transactions are prepared in one FCV and committed in the other, which should prevent any problem here. In testing upgrade/downgrade for 4.4, we should test that in committing a prepared transaction nodes do not read oplog entries generated by 4.2 binaries. Otherwise we will be unable to change the oplog format, or will need to make oplog parsing less strict, at least in this case. |
| Comments |
| Comment by Judah Schvimer [ 26/Sep/19 ] |
|
We don't really know how we would test this without actually changing the oplog format, which we don't currently need to do in 4.4. If we change the oplog format in 4.4, we can revisit this. |
| Comment by Judah Schvimer [ 03/May/19 ] |
|
Done! |
| Comment by Siyuan Zhou [ 03/May/19 ] |
judah.schvimer, would you mind changing the title to be "should not be able"? It's not clear whether the title describes a desired behavior or a problematic issue. |