Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 127.0.0.1 --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 127.0.0.1 mydb > /dev/null

Here's some of the settings in my.cnf

max_allowed_packet = 1G
interactive_timeout = 600
wait_timeout = 600
net_read_timeout=600
net_write_timeout=600
connect_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

WILL

share|improve this question
    
Try: restoring interactive_timeout and wait_timeout to their default values, or using a named pipe. –  Michael Hampton Jan 18 '13 at 1:05
    
Are there any errors in the server log? Did you try a dump via phpmyadmin? –  Jure1873 Jan 19 '13 at 20:56
    
This is a linux server. What is a pipe? (isn't that Windows only). –  Will Glass Jan 21 '13 at 16:00
    
no errors in the log. –  Will Glass Jan 21 '13 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 '13 at 22:41

2 Answers 2

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.

share|improve this answer

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
share|improve this answer
    
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 '13 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 '13 at 5:30
    
What bug report? –  Will Glass Jan 29 '13 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 '13 at 2:53
    
Didn't notice. They should ban hyperlinks without underlines. –  Will Glass Apr 1 '13 at 8:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.