I have a 1 TB MySQL database that I'd like to dump and reload. Most of the data is in one table. A lot of data has been deleted, so I'm pretty sure if I dump it with mysql, rebuild the database, then reload it the total size will be smaller.

I'm dumping the data with this command:

mysqldump  -uroot -pXXX  mydb | gzip -c > data.sql.gz

I get this error

 mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `MY_TABLE` at row: 596089342

I've tried many variations, including increasing the packet size, doing single translation and going over TCP/IP instead of local socket.

mysqldump  -uroot -pXXX -h --max-allowed-packet=1024M  --single-transaction mydb | gzip -c > data.sql.gz

Finally, I even ran the command going to /dev/null to make sure it wasn't gzip. All permutations produce the same error.

mysqldump  -uroot -pXXX -h mydb > /dev/null

Here's some of the settings in my.cnf

max_allowed_packet = 1G
interactive_timeout = 600
wait_timeout = 600

One other odd thing is that the dump always stops on the same place. Approximately 6GB of gzipped data and at approximately the same record. When I do ls -l the file size is always identical.

I'm stumped. Any suggestions for next steps?

For the record, this is Mysql 5.1.58 running on Ubuntu 11.10


  • Try: restoring interactive_timeout and wait_timeout to their default values, or using a named pipe. Jan 18, 2013 at 1:05
  • Are there any errors in the server log? Did you try a dump via phpmyadmin?
    – Jure1873
    Jan 19, 2013 at 20:56
  • This is a linux server. What is a pipe? (isn't that Windows only).
    – Will Glass
    Jan 21, 2013 at 16:00
  • no errors in the log.
    – Will Glass
    Jan 21, 2013 at 16:01
  • I tried again after restoring interactive_timeout and wait_timeout to their default values and got the same result.
    – Will Glass
    Jan 21, 2013 at 22:41

3 Answers 3


In the end, it looks like I had a data corruption. I had copied two volumes (EC2 ebs) that were linked with LVM. I may not have frozen the volume properly when making the copy and I suspect they were not properly synchronized. I started from my original volumes, ran the procedure again, carefully freezing the xfs volume before taking the EC2 snapshot, then loading the copies onto my new server and it worked fine.


Have you tried using the socket file, to bypass the TCP/IP layer e.g.

# Find the socket file e.g.
$ grep  "^socket"  /etc/my.cnf
socket      = /var/lib/mysql/mysql.sock
# Plug the filename into the mysqldump
$ mysqldump  --socket=/var/lib/mysql/mysql.sock -uroot mydb | gzip -c > data.sql.gz
  • Same issue. mysqldump --socket=/var/run/mysqld/mysqld.sock mydb produces mysqldump: Got error: 2013: Lost connection to MySQL server during query when retrieving data from server
    – Will Glass
    Jan 21, 2013 at 15:58
  • I's suggest you add your issue to the following bug report, as you've still got the issue.
    – arober11
    Jan 22, 2013 at 5:30
  • What bug report?
    – Will Glass
    Jan 29, 2013 at 23:43
  • "bug" is a hyperlink (techie internet term, invented in the 1980's), if you "click" the word you'll be taken to a different web page :o)
    – arober11
    Jan 31, 2013 at 2:53
  • Didn't notice. They should ban hyperlinks without underlines.
    – Will Glass
    Apr 1, 2013 at 8:25

I got the same error, the server had no more ram available and no swap. Mysqldump was eating all ram, so i decreased memory-related parameters in my.ini as worked

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .