-
Type:
Bug
-
Resolution: Won't Do
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
ALL
See SERVER-83421
From George
today, when we run getClusterParameter on any mongod, the value can be stale or 'ahead' of an update (i.e. roll-backable). When we run it on mongos, the value can only be stale of what is majority-commmitted on every shard + the CSRS, and any change it observes can't be rolled-back
i'm wondering if the second semantic is important to preserve from the automation persepctive. I think the answer might be no because if we consider setting a cluster parameter from A to B and back to A, it's possible for the router to not see B entirely, and when get returns A, there's no way of knowing if it's the first or second