<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Wed Feb 07 21:37:07 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>[CSHARP-536] DNS round-robin support</title>
                <link>https://jira.mongodb.org/browse/CSHARP-536</link>
                <project id="10041" key="CSHARP">C# Driver</project>
                    <description>&lt;p&gt;It looks like the driver now has the framework to support multiple connections to shards in-place, so I would like to suggest allowing &quot;seeding&quot; the shard router with one DNS record that references multiple addresses leading to having multiple mongos connections for both load balancing and failover. While I guess (not tested yet), that specifying several different address might do the trick, having it use the ability of DNS to have multiple addresses for one name would be very good for administration purposes.&lt;/p&gt;</description>
                <environment></environment>
        <key id="45159">CSHARP-536</key>
            <summary>DNS round-robin support</summary>
                <type id="2" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14711&amp;avatarType=issuetype">New Feature</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="2">Won&apos;t Fix</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="onyxmaster">Aristarkh Zagorodnikov</reporter>
                        <labels>
                    </labels>
                <created>Mon, 23 Jul 2012 21:25:41 +0000</created>
                <updated>Fri, 17 Feb 2017 15:21:35 +0000</updated>
                            <resolved>Wed, 3 Sep 2014 23:53:55 +0000</resolved>
                                    <version>1.5</version>
                                                                        <votes>2</votes>
                                    <watches>2</watches>
                                                                                                                <comments>
                            <comment id="711773" author="onyxmaster" created="Thu, 4 Sep 2014 18:51:00 +0000"  >&lt;p&gt;Robert, thank you for the link, I&apos;ll check it out.&lt;/p&gt;</comment>
                            <comment id="711772" author="onyxmaster" created="Thu, 4 Sep 2014 18:50:20 +0000"  >&lt;p&gt;Craig, I&apos;m sorry for not paying attention to the original comment, yes, you addressed that case.&lt;/p&gt;</comment>
                            <comment id="711686" author="rstam" created="Thu, 4 Sep 2014 17:53:29 +0000"  >&lt;p&gt;Aristarkh, there is another JIRA ticket specifically about supporting mongos&apos;es behind a load balancer:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/CSHARP-1007&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/CSHARP-1007&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;You can also comment or vote on that ticket.&lt;/p&gt;

&lt;p&gt;Currently supporting mongos&apos;es behind a load balancer is considered very low priority and it is not likely to happen, even though there is no reason it couldn&apos;t be made to work.&lt;/p&gt;</comment>
                            <comment id="711584" author="craiggwilson" created="Thu, 4 Sep 2014 16:26:45 +0000"  >&lt;p&gt;No, I didn&apos;t miss it. I mentioned it in my original comment.&lt;/p&gt;

&lt;p&gt;The driver already handles failover between mongos, so that&apos;s not the concern. But the same problem still applies to mongos.   &lt;/p&gt;

&lt;p&gt;First, we are performing health checks against each one we are monitoring and using that information to occasionally decide how to do a certain operation (For instance, add user uses a command in 2.6, but an insert in 2.4). If we can&apos;t reliably know what version of the server we are talking to, there will be random and finicky errors.&lt;/p&gt;

&lt;p&gt;Second, the query protocol for mongodb is stateful. It requires that we send OP_GETMOREs to the same server as the original request. Having a DNS round-robin or a load balancer in front first requires connection affinity and then requires that the driver checkout the connection for the duration of the query, however long that takes. This certainly makes connection pooling less robust and prevents scale. It is also something we are tentatively allowing a user to decide whether or not to do this as they know their applications needs better than we do.&lt;/p&gt;

&lt;p&gt;In any case, if the need is for fail-over, the driver natively provides that which we believe is sufficient.&lt;/p&gt;</comment>
                            <comment id="711567" author="onyxmaster" created="Thu, 4 Sep 2014 16:11:05 +0000"  >&lt;p&gt;Excuse me, but I think you&apos;re missing an important case - mongos-only deployment. I believe that almost any large-scale MongoDB deployment ends up with sharding everything and doing non-admin jobs entirely through mongos. I still understand that it&apos;s far from being the general case &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="711361" author="craiggwilson" created="Thu, 4 Sep 2014 12:40:49 +0000"  >&lt;p&gt;So, this would only be applicable to fail-over if all the servers were standalone servers and not part of a sharded cluster or a replica set. This is of limited value because we don&apos;t recommend people run standa alones in production.  In addition, replica sets and sharded clusters already have fail-over support in the driver.&lt;/p&gt;</comment>
                            <comment id="711234" author="onyxmaster" created="Thu, 4 Sep 2014 07:12:31 +0000"  >&lt;p&gt;I was actually more interested in the failover scenario, but I still understand the difficulties implementing this related to how much useful it would be to the general public.&lt;/p&gt;</comment>
                            <comment id="711231" author="onyxmaster" created="Thu, 4 Sep 2014 07:11:39 +0000"  >&lt;p&gt;Many thanks for the detailed reply, Craig!&lt;/p&gt;</comment>
                            <comment id="711106" author="craiggwilson" created="Wed, 3 Sep 2014 23:53:55 +0000"  >&lt;p&gt;Hi Aristarkh,&lt;/p&gt;

&lt;p&gt;We&apos;ve thought about this type of thing in the same context as using a load balancer between a pool of mongos&apos;s.  Unfortunately, there simply isn&apos;t a good way to handle this for a couple of reasons. First, our query protocol is stateful, meaning we need to send the same OP_GETMORE request down the exact same connection. This is certainly doable, but presents different problems related to connection pooling. The second reason is that we need to monitor replica set members on an individual basis. Unfortunately, if we can&apos;t guarantee each connection for a server is for the actual server, then working in heterogenous versioned replica sets/sharded clusters presents a monitoring problem. It also presents the same problem with regards to deciding who is primary and should accept writes.&lt;/p&gt;

&lt;p&gt;We&apos;ll be closing this ticket for the above reasons. Feel free to leave a comment if you feel we&apos;ve missed something.&lt;/p&gt;

&lt;p&gt;Thanks,&lt;br/&gt;
Craig&lt;/p&gt;</comment>
                            <comment id="648102" author="onyxmaster" created="Thu, 3 Jul 2014 22:35:38 +0000"  >&lt;p&gt;Not if RR DNS would be done inside the driver itself (it does DNS lookup, caches all available addresses and then RRs between them).&lt;/p&gt;</comment>
                            <comment id="647776" author="rstam" created="Thu, 3 Jul 2014 18:20:40 +0000"  >&lt;p&gt;I don&apos;t think round-robin DNS would work currently for the same reason that mongos&apos;es behind a load balancer doesn&apos;t work (i.e. the OP_GETMORE messages usually end up at the wrong server).&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="144186">CSHARP-1007</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="22116">DRIVERS-201</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                        <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10038"><![CDATA[Fully Compatible]]></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_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hs0t8f:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>129176</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            </customfields>
    </item>
</channel>
</rss>