Sinister has asked for the wisdom of the Perl Monks concerning the following question:

Fellow monks,

I call upon your endless wisdom, for I have a very strange problem at hand.
It so seems that when running mod_perl with all the fancy Apache::DBI stuff in place, and boy (or girl) do I have to call the DBI (A mysql server in this case) a lot.

But now it seems my MySQL server is bored with me, and has gone and wander around a bit, because I keep getting this error message: 
DBD::mysql::st execute failed: MySQL server has gone away at /opt/perl
+-5.6.1/lib/site_perl/5.6.1/i686-linux/Mysql.pm

[download]

I can agree with my SQL server to take a hike - cause it is lovely weather over here. I just don't want it to, because I need it.
Is there a monk in this vast monestary who could inform on how to keep your SQL server indoors...?

Sinister greetings.
"With tying hashes you can do everything God and Larry have forbidden" -- Johan Vromans - YAPC::Europe 2001
perldoc -q $_

Replies are listed 'Best First'.
Re: My MySQL server has wanderlust...
by gmax (Abbot) on Feb 28, 2002 at 13:09 UTC
    Not exactly a Perl question, ;) but since I happen to know the problem ... here you are.
    This page should give you the answer.
    Shortly, if it is not a timeout problem, it could be that your query has exceeded the size limits set by "max_allowed_packet".
    Check the queries that you are feeding the server through the DBI, and see if you have the same result in a command line client.
    I also had this error when I tried to update a BLOB field with a chunk of data bigger than the field size.

    I hope these hints could be helpful.
    If none of the things listed in the manual are solving your problem, you may try at the MySQL mail list

    update Try also this link. It will give you more than 200 comments on this issue.
     _  _ _  _  
(_|| | |(_|><
 _|

    [download]
[reply]
[d/l]
      This could even be the solution to my problem. I insert serialized data (CGI Session info) into my poor MySQL server... - I have now altered the table to have a longglob for dinner... (-;)

      So far it seems to actually work....

      Sinister greetings.
      "With tying hashes you can do everything God and Larry have forbidden" -- Johan Vromans - YAPC::Europe 2001
      perldoc -q $_
[reply]
UPDATE: My MySQL server has wanderlust...
by Sinister (Friar) on Mar 01, 2002 at 14:38 UTC
    Fellow monks, as you can wel see above, I had stated to have fixed the problem. I did not - The server now has less interest in taking a strawl, then before, but still it has not lost it appetite completely.

    Altough I have changed my table definition to meet my requirments (now way overkill, since the data I pass in has not grown beyond 1.7Kb so far). The problem kept occuring.

    After reading a lot of documents, and mailing lists (and google of course) I came to the conclusion that it sometimes serve you better not to do: 
    my $dbq = $dbh->query("UPDATE table WHERE column='value'");

    [download]
    but:
    For some odd reason, loading a result-less query object into a local var, can make the SQL server wander off again...

    I now have adapted my code in such a manner that I will not be asking the server to answer. (iow: $dbq = $dbh->query($SQL) only for SELECT statements).

    Allas : Problem still here in contradiction to the MySQL server.
    Okay - time for some hard debugging rules to be implemented. Before every query i added a warn("Question #1\n"); and after the query I added a warn("Answer #1\n"); (the #1 increments of course).

    After some intensive research I found that playing around with your SQL statements, tend to increase the amount of 'Server has gone away' (eg INSERT INTO instead of INSERT. VALUES('val1','val2') instead of VALUES ('val1', 'val2') (which puzzles me big time...)).

    Further more; the message it self is useless. In most cases it just seems to mean: 'Hey - your query has no results...'. This is not bad (unless you are definitly expecting some).

    It seems to be very satisfying to do $Mysql::QUIET = -1 right before the query that may give you a server is off shopping message. (be nice and set it back to 0 (NULL) when done...)

    Hoping to be off help to all those troubles Mysql(.pm) & mod_perl developers.

    Sinister.
    "Field experience is something you don't get until just after you need it."
[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom