Bug #72519 mysqldump: Error 2013: Lost connection to MySQL server during query when dumping
Submitted: 3 May 2014 3:09 Modified: 17 Aug 2014 20:41
Reporter: Hisayori Noda Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:5.5.37 OS:Linux (Ubuntu 14.04)
Assigned to: CPU Architecture:Any

[3 May 2014 3:09] Hisayori Noda
Description:
I tried to backup my database with the mysqldump command.  But it failed with an error message, "mysqldump: Error 2013: Lost connection to MySQL server during query when dumping
 table `creation_log` at row: 59655".

The log of mysqldump was:
========================================
nodchip@nighthawk ~ % mysqldump -uroot -p[password] -A -v --flush-privileges --rou
tines --result-file mysql_backup_2014-05-03.sql
(skipped)
-- Retrieving table structure for table creation_log...
-- Sending SELECT query...
-- Retrieving rows...
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping
 table `creation_log` at row: 59655
========================================

I added "innodb_force_recovery = 6" to [mysqld] section in my.cnf, restart the mysqld and tried mysqldump again.  But the result was not changed.

The definition of "creation_log" table is:
========================================
mysql> desc creation_log;
+------------+------------------+------+-----+-------------------+-----------------------------+
| Field      | Type             | Null | Key | Default           | Extra                       |
+------------+------------------+------+-----+-------------------+-----------------------------+
| PROBLEM_ID | int(10) unsigned | NO   | MUL | NULL              |                             |
| USER_CODE  | int(10) unsigned | NO   |     | NULL              |                             |
| DATE       | timestamp        | NO   | MUL | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| MACHINE_IP | text             | NO   | MUL | NULL              |                             |
| SUMMARY    | text             | YES  |     | NULL              |                             |
+------------+------------------+------+-----+-------------------+-----------------------------+
========================================

I tried "ALTER TABLE <tablename> ENGINE=INNODB" described in http://bugs.mysql.com/bug.php?id=37364.  But it also failed.
========================================
mysql> ALTER TABLE creation_log ENGINE=INNODB;
ERROR 2013 (HY000): Lost connection to MySQL server during query
========================================

When I started mysqld from command line with "--log-warnings=2", it showed an error message.
========================================
140503 11:34:00 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
140503 11:34:00 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
140503 11:34:00 [Note] Plugin 'FEDERATED' is disabled.
140503 11:34:00 InnoDB: The InnoDB memory heap is disabled
140503 11:34:00 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140503 11:34:00 InnoDB: Compressed tables use zlib 1.2.8
140503 11:34:00 InnoDB: Using Linux native AIO
140503 11:34:00 InnoDB: Initializing buffer pool, size = 1.0G
140503 11:34:00 InnoDB: Completed initialization of buffer pool
140503 11:34:00 InnoDB: highest supported file format is Barracuda.
140503 11:34:00  InnoDB: Waiting for the background threads to start
140503 11:34:01 InnoDB: 5.5.37 started; log sequence number 4595691880
140503 11:34:01 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
140503 11:34:01 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
140503 11:34:01 [Note] Server socket created on IP: '0.0.0.0'.
140503 11:34:01 [Note] Event Scheduler: Loaded 0 events
140503 11:34:01 [Note] mysqld: ready for connections.
Version: '5.5.37-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 24933.
InnoDB: You may have to recover from a backup.
140503 11:34:08  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 50ad50d600006165000061640000616600000000219aea1245bf000000000000000000000000004a3b4a8127000000003b1c00020124012500000000000000000000000000000000001a000000000000000000000000000000000000(skipped)
InnoDB: End of page dump
140503 11:34:08  InnoDB: Page checksum 1579207142, prior-to-4.0.14-form checksum 2128306746
InnoDB: stored checksum 1353535702, prior-to-4.0.14-form stored checksum 2128306746
InnoDB: Page lsn 0 563800594, low 4 bytes of lsn at page end 563800594
InnoDB: Page number (if stored to page already) 24933,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 26
InnoDB: (index "GEN_CLUST_INDEX" of table "qmaclone"."creation_log")
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 24933.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
140503 11:34:08  InnoDB: Assertion failure in thread 139851338319616 in file buf0buf.c line 3619
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
02:34:08 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346700 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
mysqld(my_print_stacktrace+0x20)[0x7f320a45fc70]
mysqld(handle_fatal_signal+0x3d5)[0x7f320a34a6d5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f32090dc340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7f3208732f79]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f3208736388]
mysqld(+0x5c436b)[0x7f320a53536b]
mysqld(+0x5f0cb9)[0x7f320a561cb9]
mysqld(+0x581a48)[0x7f320a4f2a48]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f32090d4182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f32087f730d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
========================================

Each version of mysql commands was 5.5.37.  The OS version was Ubuntu 14.04.

Please let me know if information are missing.

How to repeat:
I could not reproduce this bug intentionally.
[17 Jul 2014 20:41] Sveta Smirnova
Thank you for the report.

Your table seems to be corrupted. Please follow instructions from http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html and try to dump it properly (with innodb_force_recovery=6 you can use only  SELECT ... INTO OUTFILE)
[18 Aug 2014 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".