<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 05:11:40 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[SERVER-46499] revisit minOpTime logic in serverSelector</title>
                <link>https://jira.mongodb.org/browse/SERVER-46499</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;&lt;a href=&quot;https://github.com/mongodb/mongo/blob/144ec4a088a2c9d78403dc978443e7aa63cdcf98/src/mongo/client/scanning_replica_set_monitor.cpp#L1201&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;This logic&lt;/a&gt; was found to be required for test conformance.&lt;/p&gt;

&lt;p&gt;Currently, the server selector code does the equivalent of the old RSM implementation, which is:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;if tags are specified and minOpTime is in the readPreference, then try to only select servers that fit this requirement. Call this set S. If |S| == 0 then, ignore minOpTime in the readPref.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I suspect that, from the client&apos;s perspective, this has similar runtime characteristics as just ignoring the minOpTime altogether. We should validate whether this is true, and if so remove this logic.&lt;/p&gt;</description>
                <environment></environment>
        <key id="1203967">SERVER-46499</key>
            <summary>revisit minOpTime logic in serverSelector</summary>
                <type id="3" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14718&amp;avatarType=issuetype">Task</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="1" iconUrl="https://jira.mongodb.org/images/icons/statuses/open.png" description="">Open</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="backlog-server-cluster-scalability">Backlog - Cluster Scalability</assignee>
                                    <reporter username="lamont.nelson@mongodb.com">Lamont Nelson</reporter>
                        <labels>
                    </labels>
                <created>Fri, 28 Feb 2020 18:31:00 +0000</created>
                <updated>Tue, 12 Dec 2023 15:58:45 +0000</updated>
                                                            <fixVersion>4.3 Desired</fixVersion>
                                                        <votes>0</votes>
                                    <watches>1</watches>
                                                                                                                <comments>
                            <comment id="4262740" author="JIRAUSER1262719" created="Tue, 21 Dec 2021 21:33:44 +0000"  >&lt;p&gt;We haven&#8217;t heard back from you in at least 1 year, so I&apos;m going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.&lt;/p&gt;</comment>
                            <comment id="3347811" author="lamont.nelson" created="Wed, 19 Aug 2020 19:12:18 +0000"  >&lt;p&gt;Thanks for the analysis, at the time this was written there wasn&apos;t enough time to investigate further. I was operating under the assumption that this property was optional and not required for correctness, since that is the current implementation, which makes me question whether it is actually an effective one. I&apos;m not sure either way without measurement, but I suspect that for the types of commands that are being run on the config server performance probably about the same.&lt;/p&gt;

&lt;p&gt;However, with your analysis it seems minOpTime (now renamed) is also required for safety in some cases. Since the behavior is optional this cannot be a safety property unless it&apos;s also enforced on the other end like with _exhaustiveFindOnConfig. So while most of the time the commands will run on an up to date server, when the system is under duress any server may be a target (all other things remaining equal). Intuitively, I think when things aren&apos;t operating in the normal manner is when users often want stronger guarantees, not weaker. I find this hard to reason about, and suspect there is some subset of commands where this is undesired behavior. &lt;/p&gt;

&lt;p&gt;Even if there are no undesired effects currently, I do find it confusing from an api perspective to have this option named minOpTime on read preference because, without knowing these details, one might reasonably think that this is a safety property and act accordingly. Maybe in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-49970&quot; title=&quot;Prefer the VectorClock&amp;#39;s ConfigTime to configOpTime when querying config servers&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-49970&quot;&gt;&lt;del&gt;SERVER-49970&lt;/del&gt;&lt;/a&gt; we could indicate that this is in fact just a hint when renaming the variable.&lt;/p&gt;</comment>
                            <comment id="3334634" author="kevin.pulo@10gen.com" created="Wed, 12 Aug 2020 14:54:07 +0000"  >&lt;p&gt;I&apos;ve been looking into this on &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-49970&quot; title=&quot;Prefer the VectorClock&amp;#39;s ConfigTime to configOpTime when querying config servers&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-49970&quot;&gt;&lt;del&gt;SERVER-49970&lt;/del&gt;&lt;/a&gt;.  I believe the answer is that minOpTime is still necessary, not an optimisation that can be removed.&lt;/p&gt;

&lt;p&gt;The only users of minOpTime (AFAICT) are ShardRemote::_exhaustiveFindOnConfig() and ShardRemote::_scheduleCommand().  In both cases they are used to target a config server that is &quot;current&quot; according to configOpTime, rather than one which has an optime that is less than configOpTime.&lt;/p&gt;

&lt;p&gt;In the case of _scheduleCommand(), there is no other mechanism for ensuring that the command is run on a non-stale configsvr (if one is known).  The command will just execute on the nearest configsvr, regardless of how stale it might be.  This might not be good, and is an actual change in behaviour (I don&apos;t know which commands actually use this, or if any of them actually rely on this behaviour).&lt;/p&gt;

&lt;p&gt;In the case of _exhaustiveFindOnConfig(), configOpTime is also used for the afterOpTime field of the readConcern.  In this sense, the minOpTime is an &quot;optional optimisation&quot;, because it is the read concern&apos;s afterOpTime which ensures that the correct data is read and returned, ie. if the query targets a stale configsvr, that node will wait for its optime to advance to afterOpTime (configOpTime) before processing the read.&lt;/p&gt;

&lt;p&gt;However, this assumes that the stale configsvr will soon reach configOpTime, which may not be true.  Consider the case of three configsvrs, where one is unhealthy and severely lagged or completely stuck (ie. its optime is not advancing), and this unhealthy node has the lowest ping time.  The cluster as a whole is healthy, because the other 2 configsvrs are maintaining majority and majority writes.  With minOpTime, queries (and commands) will be corrected targeted to one of the two healthy configsvrs.  However, without minOpTime, the queries (and commands) will end up going to the unhealthy node, which may never return a result (or it might be very delayed).  Considering that users/admins reasonably expect the cluster to be resilient to a minority of stale configsvrs (while whatever the underlying root cause is fixed, eg. bad hardware, or whatever) &amp;#8212; in part because that&apos;s how it behaves today &amp;#8212; removing the minOpTime targeting would add fragility to the cluster.&lt;/p&gt;

&lt;p&gt;So I think that the minOpTime targeting is still required (including the quirk where it gets ignored if it can&apos;t be satisfied).&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="1423729">SERVER-49970</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>3.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                <customfield id="customfield_12751" key="com.atlassian.jira.plugin.system.customfieldtypes:multiselect">
                        <customfieldname>Assigned Teams</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="26583"><![CDATA[Cluster Scalability]]></customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 12 Aug 2020 14:54:07 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        2 years, 7 weeks, 1 day ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[]]></customfieldvalue>


                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>dbeng-pm-bot</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            2 years, 7 weeks, 1 day ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>backlog-server-cluster-scalability</customfieldvalue>
            <customfieldvalue>kevin.pulo@mongodb.com</customfieldvalue>
            <customfieldvalue>lamont.nelson@mongodb.com</customfieldvalue>
            <customfieldvalue>lauren.lewis@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hwxcxj:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hwl94f:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hwwz6v:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>