Re: Handling death of mysqld
From: Jerry Stuckle <jstucklex_at_attglobal.net>
Date: Tue, 23 Jan 2018 21:33:15 -0500
Message-ID: <p48r83$4lj$1_at_jstuckle.eternal-september.org>
>
> Normally it is. "Once" means that it tries to reconnect and if that fails
> too (the server is not reachable) then it stops trying.
>
>
> OMG. That was so forever. Actually that API method is there only for that
> reason. Do you ever read API documentation?
>
>
> You'll have quite some fun when the server is indeed gone. Maybe due to
> table space corruption or for some other severe reason. IMNSHO it's not very
> clever to try infinitely. You should have some safe way out. If nothing
> else, you have at least provided an example why logging into a database is a
> bad idea. Log files do the job nice and safe and with fewer opportunities
> for failure.
>
> BTW, there was a reason why auto-reconnect was disabled. It can be quite
> harmful. A database connection has internal state that is lost by the
> reconnect. That includes (not meant to be complete) user variables,
> temporary tables, prepared statement handles. Losing that context without
> being noticed (aka auto-reconnect) can be quite as disastrous as the lost
> connection itself.
>
Date: Tue, 23 Jan 2018 21:33:15 -0500
Message-ID: <p48r83$4lj$1_at_jstuckle.eternal-september.org>
On 1/23/2018 6:29 PM, Axel Schwenke wrote:
> On 23.01.2018 22:39, The Natural Philosopher wrote:
>> On 23/01/18 21:27, Axel Schwenke wrote: >>> On 23.01.2018 22:01, The Natural Philosopher wrote: >>>> I would have assumed that the >>>> underlying C libraries would reconnect to the server >>> >>> https://dev.mysql.com/doc/refman/5.7/en/c-api-auto-reconnect.html >>> >> "If auto-reconnect is enabled, the library tries once to reconnect to the >> server and send the statement again" >> >> Once isn't going to be enough though, is it?
>
> Normally it is. "Once" means that it tries to reconnect and if that fails
> too (the server is not reachable) then it stops trying.
>
>> But you did make me aware of mysql_ping() which looks like a way to test if >> the server is in fact there
>
> OMG. That was so forever. Actually that API method is there only for that
> reason. Do you ever read API documentation?
>
>> I am thinking that
>>
>> while mysql_ping(&mysql)
>> {
>> sleep (1);
>> mysql_real_connect(&mysql,"127.0.0.1",
>> DBUSER,DBPASS,DBNAME,0,"",0);
>> }
>> mysql_query(............
>>
>> should in fact simply stall the program until a valid connection is
>> restablished?
>
> You'll have quite some fun when the server is indeed gone. Maybe due to
> table space corruption or for some other severe reason. IMNSHO it's not very
> clever to try infinitely. You should have some safe way out. If nothing
> else, you have at least provided an example why logging into a database is a
> bad idea. Log files do the job nice and safe and with fewer opportunities
> for failure.
>
> BTW, there was a reason why auto-reconnect was disabled. It can be quite
> harmful. A database connection has internal state that is lost by the
> reconnect. That includes (not meant to be complete) user variables,
> temporary tables, prepared statement handles. Losing that context without
> being noticed (aka auto-reconnect) can be quite as disastrous as the lost
> connection itself.
>
Axel, by now you should know you're arguing with - I would say an idiot, but that would be an insult to idiots. TNP has absolutely no idea how to build an normal application - much less one capable of error recovery.
-- ================== Remove the "x" from my email address Jerry Stuckle jstucklex_at_attglobal.net ==================Received on Wed Jan 24 2018 - 03:33:15 CET