[OpenSIPS-Users] Need some clarification in opensips cachedb_mongo db configutaion .
Sasmita Panda
spanda at 3clogic.com
Fri Aug 26 13:05:19 UTC 2022
Can you please suggest something here .
*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*
On Thu, Aug 25, 2022 at 3:13 PM Sasmita Panda <spanda at 3clogic.com> wrote:
> Hi ,
>
> modparam("db_cachedb", "cachedb_url","mongodb://
> docdb:cccl0g1c at oregon-cluster.xyz.com:27017,*east-cluster.xyz.com
> <http://east-cluster.xyz.com>*
> :27017/opensipsDB.userlocation?readPreference=secondaryPreferred&retryWrites=false&serverSelectionTryOnce=false&connectionTimeoutMS=5000")
>
>
> I had this parameter in my config . from these two connection strings one
> is primary and 1 is secondary replica . When primary goes down and
> secondary becomes primary . I am getting the below error .
>
> ERROR:cachedb_mongodb:mongo_con_update: last error: 15.13053: No suitable
> servers found: `serverSelectionTimeoutMS` expired: [connection timeout
> calling ismaster on '*east-cluster.xyz.com <http://east-cluster.xyz.com>*
> :27017']
>
> At this point east-cluster.xyz.com is down . and oregon-cluster.xyz.com
> is the primary server . What should I configure for this? Will I set the
> parameter serverSelectionTimeoutMS , then what will be the value of this
> parameter ? Please advise .
>
>
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Senior Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
> On Wed, Aug 24, 2022 at 7:06 PM Sasmita Panda <spanda at 3clogic.com> wrote:
>
>> What exactly do I have?
>>
>> I have a global cluster of DocumentDB (AWS service ) which is mongodb
>> compatible .
>>
>> In the global cluster , the primary cluster is in us-east and the
>> secondary cluster is in us-west .
>>
>> I have 2 connection strings for both clusters , primary.xyz.com pointed
>> to primary cluster , secondary.xyz.com pointed to secondary cluster
>> (secondary cluster only has read replicas) .
>>
>> In opensips I have given both the domains like below .
>>
>> modparam("usrloc", "cachedb_url","mongodb//docdb:cccl0g1c@*primary.xyz.com:27017
>> <http://primary.xyz.com:27017>*,*secondary.xyz.com:27017
>> <http://secondary.xyz.com:27017>*
>> /opensipsDB.userlocation?&readPreference=secondaryPreferred&retryWrites=false")
>>
>> whenever my primary cluster goes down and secondary is promoted to
>> primary , opensips throws an error of connection loss . Opensips at that
>> point also trying to connect to the *primary.xyz.com
>> <http://primary.xyz.com> *although that is down* . *
>>
>> *At this point , my expectation was , opensips must have automatically
>> detect the the older primary cluster was down and secondary was became
>> primary and work properly . *
>>
>> *But its not happening . Once I restart the service its works fine . *
>>
>>
>>
>>
>>
>>
>> *Thanks & Regards*
>> *Sasmita Panda*
>> *Senior Network Testing and Software Engineer*
>> *3CLogic , ph:07827611765*
>>
>>
>> On Wed, Aug 24, 2022 at 3:30 PM Liviu Chircu <liviu at opensips.org> wrote:
>>
>>> On 24.08.2022 11:56, Sasmita Panda wrote:
>>>
>>>
>>> Now my primary cluster goes down so my secondary cluster becomes primary
>>> . I have updated the connection string against the domain in route53 . Now
>>> *primary-cluster.xzy.com <http://primary-cluster.xzy.com>* is pointed
>>> to the new primary custer connection string .
>>>
>>> While creating a connection from the console through the mongo shell
>>> it's getting connected . But opensips is not able to switch the connecting
>>> string somehow . still it's trying to connect to the previous primary
>>> connection string .
>>>
>>> It seems like opensips has cached the connection string and is trying to
>>> connect to the same even after I have updated the string from the backend .
>>>
>>> libmongo will try each node in your CSV of nodes, there is no going
>>> around this. Now, while your usage of two completely different clusters in
>>> the same connection string seems to be *non-conventional* (I don't
>>> recall any documentation advising this, all Mongo docs talk about
>>> connecting to either a *replica set*, or to a *list of* *mongos*
>>> servers), I still think it could work. Maybe just configure the
>>> "connectionTimeousMS" parameters (or others??) and see if you can get
>>> libmongoc to time out faster on your 1st cluster, when it goes down.
>>>
>>> Best regards,
>>>
>>> --
>>> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
>>> OpenSIPS Summit 2022 Athens, Sep 27-30 | www.opensips.org/events
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220826/c379e05f/attachment.html>
More information about the Users
mailing list