-
Type: Bug
-
Resolution: Fixed
-
Priority: Minor - P4
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
Execution NAMR Team 2023-07-24, Execution NAMR Team 2023-08-21, Execution NAMR Team 2023-09-04, Execution Team 2023-12-11, Execution Team 2023-12-25, Execution Team 2024-01-08, Execution Team 2024-01-22
-
135
Per a conversation with Max just now, it seems chunk migration uses `listIndexes` to fetch index stats, which (again, per Max) reports expireAfterSeconds as an int. This value, though, is internally a floating-point, which can trigger rounding problems.
This seems to have caused REP-2567, in which the source cluster’s shards built the `x_before_epoch` index with different expireAfterSeconds values.
That happened because ttl_index_options.js sends a UNIX timestamp. Assumedly that value, these days, is just high enough that rounding errors will happen, where previously they may not have.
- causes
-
SERVER-87705 Fix race in InvalidTTLIndexFixer
- Closed
- is related to
-
SERVER-91498 'expireAfterSeconds' persisted in catalog as multiple types
- Open
-
SERVER-73442 The type of the "bits" field can differ between createIndexes and listIndexes
- Backlog
-
SERVER-92364 checkMetadataConsistency() fails on mixed version shards with 'expireAfterSeconds' as double
- Blocked
-
SERVER-92366 CollMod on 'expireAfterSeconds' is a no-op if new value is old value truncated to int
- Closed
- related to
-
SERVER-89210 Chunk migration can unnecessarily fail due to inconsistency between listIndexes and local catalog
- In Progress
-
SERVER-81192 Introduce background maintenance task queue
- Closed