[SERVER-32572] Run causally consistent resmoke suites with non-voting secondaries Created: 05/Jan/18  Updated: 27/Oct/23  Resolved: 17/Apr/20

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

Type: Task Priority: Major - P3
Reporter: Kevin Albertson Assignee: Max Hirschhorn
Resolution: Gone away Votes: 0
Labels: open_todo_in_code, sharding-wfbf-day, stm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-34597 shardedcluster.py does not wait corre... Closed
Related
is related to SERVER-31670 Change replica set fixture used by re... Closed
is related to SERVER-32775 Investigate afterClusterTime error in... Closed
Sprint: Sharding 2020-04-20
Participants:
Linked BF Score: 0

 Description   

In testing changes for SERVER-31670, setting secondaries to have zero votes causes some tests in the causally consistent passthrough suites to fail complaining that the afterClusterTime sent to a secondary is after the clusterTime on the secondary.

As a temporary fix, we are not giving secondaries zero votes in those suites. These failures should be investigated, and the voting_secondaries: true options should be removed from the causally_consistent*.yml configs.



 Comments   
Comment by Max Hirschhorn [ 17/Apr/20 ]

The changes from c57a899 as part of SERVER-44214 made it so rather than not giving secondaries a vote to ensure a stable primary in the presence of slow logging, we instead set the election timeout to 24 hours. The causal consistency test suites are therefore no longer more special than any of our other test suites in giving secondaries a vote.

Investigations into the issue Kevin Albertson had originally reported have proven unsuccessful (e.g. SERVER-32775, SERVER-34597) that I don't think it is worth spending more time there. Closing this ticket as "Gone away".

Comment by Kevin Duong [ 16/Jan/18 ]

misha.tyulenev Is there already a ticket related to this?

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