MySQL Forums
Forum List  »  Perl

Re: DBD::mysql::st execute failed: Lost connection to MySQL server during query
Posted by: Philip Johnson
Date: July 05, 2011 10:53AM

>> innodb_data_file_path = ibdata01:50G;ibdata02:50G;ibdata03:50G;ibdata04:50G;ibdata05:50G
> You realize that the system will crash if you ever get 250GB of data?
I do, we're prepared to add more ibdata files once we start reaching that point. Currently the database has less then 50G of data in it, and that data in increasing linearly with time.

connect_timeout = 10
delayed_insert_timeout = 300
innodb_lock_wait_timeout = 50
innodb_rollback_on_timeout = OFF
interactive_timeout = 25500
lock_wait_timeout = 31536000
net_read_timeout = 30
net_write_timeout = 60
slave_net_timeout = 3600
wait_timeout = 28800

> Anything useful in mysqld.err ?
Nothing at all in the mysqld.log or mysql-error.log files since when we brought the server online, before we started these processes.

> Does it match
> ?
Doesn't look to match to me, these connections are both from localhost (no potential for network problems) and persistent (the error will come up after the connection has already been established and used for anywhere from minutes to hours).

> Is anything going on in the background, like a backup?
No server backup or anything like that, and it can happen at any time of day or night, though busier times to tend to correlate to it happening more often, but the connection has been lost mid-query during very slow times as well.

Something else to note, as you asked about autocommit before. This has occured with statements run outside of any transaction (autocommit will be creating a transaction around the single statement) as well as on transactions executed between a 'START TRANSACTION' and 'COMMIT', so there was already a transaction session in place.

Options: ReplyQuote

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.