Summary
Drivers will automatically retry any read operation that has not yet received any results exactly once.
Motivation
Alleviate application developer pain
- Application developers want to design fault tolerant or highly available applications without having to implement retry logic in their application
- Application developers currently have to write boilerplate retry logic for reads (but not for writes).
- Much like for retryable writes, developers should not need to think about this type of retry logic.
- Furthermore, application developers transitioning from traditional, non-distributed architectures and topologies sometimes have a hard time reasoning about transitional MongoDB states due to single node faults or sharding/replication state.
- Automatically retrying reads will allow these developers to focus more on the business logic and less on the implementation details of MongoDB.
Alleviate Atlas team pain.
- The Atlas team should be able to perform unplanned maintenance without impacting end users or requiring developers to add logic to prevent these failures from being exposed to the user.
Cast of Characters
Lead: behackett
Author:
POCs: Python, C#
Product Owner: Scott L; Rachelle Palmer
Documentation
- depends on
-
RUBY-1562 Retryable Reads
- Released
-
NODE-1744 Retryable Reads
- Development Complete
-
CDRIVER-2873 Retryable Reads
- Closed
-
CSHARP-2429 POC for Retryable Reads
- Closed
-
CSHARP-2482 Full implementation of retryable reads
- Closed
-
CXX-1685 Retryable Reads
- Closed
-
GODRIVER-624 Retryable Reads
- Closed
-
JAVA-3070 Retryable Reads
- Closed
-
MOTOR-283 Retryable Reads
- Closed
-
PHPC-1291 Retryable Reads
- Closed
-
PYTHON-1674 Retryable Reads
- Closed
-
RUST-128 Retryable Reads
- Closed
-
DRIVERS-615 countDocuments should use group with _id: 1
- Closed
-
SERVER-34943 failCommand failpoint should ignore commands from replica set members
- Closed
- is related to
-
SERVER-39478 Backport failCommand failPoint to 3.6
- Closed