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 Developer
http://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 <solar...@one-n.co.uk <mailto:solar...@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 <raz...@opensips.org
    <mailto:raz...@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@lists.opensips.org <mailto:Users@lists.opensips.org>
        > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
        >

        _______________________________________________
        Users mailing list
        Users@lists.opensips.org <mailto:Users@lists.opensips.org>
        http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to