[OpenSIPS-Users] INFO:db_mysql:switch_state_to_disconnected

solarmon solarmon at one-n.co.uk
Tue Jan 7 09:35:00 EST 2020 

Hi Livui,

Thank you for your response.

I've checked wait_timeout and it is the default 28800 (8 hours).

Is this default not suitable?

Note that our SIP load balancers currently have little traffic going
through it, so is this default value not suitable? Should we be reducing
it? Or are these DB log message common/expected in this situation with
little traffic?

I'm still trying to correlate whether these database errors are related to
the dispatcher endpoints that are seemingly and randomly failing (when
using the opensipsctl dispatcher show or dump commands).

Thanks.

On Tue, 7 Jan 2020 at 11:55, Liviu Chircu <liviu at opensips.org> wrote:

> Hi solarmon,
>
> Please find an elaborate discussion on this topic here [1].  In short,
> MySQL's "wait_timeout" setting directly affects the number of such errors
> you are seeing in the logs, unless you are dealing with some other kind of
> a DB problem which causes new connections to be immediately dropped
> (e.g. deadlock, internal error, read-only state, etc.).
>
> Best regards,
>
> [1]: http://lists.opensips.org/pipermail/devel/2019-October/026171.html
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> OpenSIPS Summit, Amsterdam, May 2020
>   https://www.opensips.org/events/Summit-2020Amsterdam/
> OpenSIPS Bootcamp, Miami, March 2020
>   https://opensips.org/training/OpenSIPS_Bootcamp_2020/
>
> On 07.01.2020 13:45, solarmon wrote:
>
> Hi,
>
> I'm am still getting these database related messages on my opensips
> servers.
>
> /usr/local/sbin/opensips[29086]:
> INFO:db_mysql:switch_state_to_disconnected: disconnect event for
> 0x7fb482d108a8
> /usr/local/sbin/opensips[29086]: INFO:db_mysql:reset_all_statements:
> resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8
> /usr/local/sbin/opensips[29086]: INFO:db_mysql:connect_with_retry:
> re-connected successful for 0x7fb482d108a8
>
> As per my last post on this subject, the database it is using is local to
> opensips - i.e. running on the same machine opensips. Thus, there should be
> no networking or routing or firewall that could be causing connectivity
> issues.
>
> Why is opensips generating such logs suggesting that it cannot connect to
> its local database? What could be causing this issue - opensips or the
> (MariaDB) database?
>
> Thank you.
>
> On Mon, 23 Dec 2019 at 14:49, solarmon <solarmon at one-n.co.uk> wrote:
>
>> Hi,
>>
>> Looking at the logs, these "INFO:db_mysql:switch_state_to_disconnected"
>> events do occur quite regularly.
>>
>> Also note that the database is local to the opensips node (part of a two
>> node cluster, with mariadb master/master syncing)).
>>
>> As per another post (that has not has a response) I'm using the
>> "opensipsctl dispatcher show" to monitor the endpoint status. I think this
>> is related as I've notice that the state shown by " "opensipsctl dispatcher
>> show"" and  "opensipsctl dispatcher dump" differ:
>>
>> When using "opensipsctl dispatcher show":
>>
>>
>> +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+
>> | id | setid | destination            | socket                | state |
>> weight | priority | attrs | description  |
>>
>> +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+
>> |  1 |     1 | sip:A.B.C.D:5060   | udp:W.X.Y.Z:5060 |     2 | 1      |
>>      0 |       | |
>>
>> When using "opensipsctl dispatcher dump":
>>
>>         SET:: 1
>>                 URI:: sip:A.B.C.D:5060 state=Active first_hit_counter=0
>>                         socket:: udp:W.X.Y.Z:5060
>>
>> I might change my monitoring script to use  "opensipsctl dispatcher
>> dump", but it was easier for me to process the tabular format as it
>> contains the destination and state in the same line.
>>
>> Thanks.
>>
>> On Mon, 23 Dec 2019 at 14:37, Răzvan Crainea <razvan at opensips.org> wrote:
>>
>>> There are no errors - as the level indicates, there are some INFO
>>> messages indicating that a re-connection is done. Most likely the
>>> database connection was in a stale state, and the driver decided to
>>> reconnect. Nothing wrong about that.
>>>
>>> The reason for switching the endpoint in probing mode comes from the SIP
>>> signaling level - you should add more debugging in your script to
>>> understand this problem, or take a look at the signaling level.
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>>
>>> On 12/23/19 11:38 AM, solarmon wrote:
>>> > Hi,
>>> >
>>> > I'm investigating why there was a blip in the Dispatcher endpoint SIP
>>> > Options pings. The endpoint went in to "State=2 (Probing)" state and
>>> at
>>> > the same time the following was logged in opensips.log:
>>> >
>>> > /usr/local/sbin/opensips[29087]:
>>> > INFO:db_mysql:switch_state_to_disconnected: disconnect event for
>>> > 0x7fb482d108a8
>>> > /usr/local/sbin/opensips[29087]: INFO:db_mysql:reset_all_statements:
>>> > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8
>>> > /usr/local/sbin/opensips[29087]: INFO:db_mysql:connect_with_retry:
>>> > re-connected successful for 0x7fb482d108a8
>>> > /usr/local/sbin/opensips[29077]:
>>> > INFO:db_mysql:switch_state_to_disconnected: disconnect event for
>>> > 0x7fb482d108a8
>>> > /usr/local/sbin/opensips[29077]: INFO:db_mysql:reset_all_statements:
>>> > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8
>>> > /usr/local/sbin/opensips[29077]: INFO:db_mysql:connect_with_retry:
>>> > re-connected successful for 0x7fb482d108a8
>>> >
>>> > Please can somebody advise what these error messages mean and how/what
>>> > to investigate it further and resolve it.
>>> >
>>> > Thank you.
>>> >
>>> > _______________________________________________
>>> > Users mailing list
>>> > Users at lists.opensips.org
>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200107/85fb77b4/attachment-0001.html>

More information about the Users mailing list