Re: Handling death of mysqld

[Quoted] 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
>>

[Quoted] 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

[Quoted] 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?

[Quoted] [Quoted] 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. Received on Wed Jan 24 2018 - 00:29:18 CET