Bug #5580 Master crashes if slave is up during import
Submitted: 14 Sep 2004 21:00 Modified: 4 Feb 2005 12:54
Reporter: Keith Dreibelbis Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:4.1.3-beta OS:Linux (linux)
Assigned to: CPU Architecture:Any

[14 Sep 2004 21:00] Keith Dreibelbis
Description:
When loading a master database (with active slave) from mysqldump output, I repeately got this error:

Error 2013 at line 19: Lost connection to MySQL server during query

The error log indicated that mysqld got a signal 11.  I tried bouncing the slave and master, but it consistently failed.  After a few tries, I stopped the slave, then did the import on the master (successful) and restarted the slave after the import finished.  The slave caught up normally as expected.

How to repeat:
- The database used (on master and slave) is utf8
- The tables already exist on the master, but not on the slave.  (But "DROP TABLE IF EXISTS" should work on both...?)
- slave is read-only

Import file is approximately like this: (with expected stuff at the end to reset original values)

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE="NO_AUTO_VALUE_ON_ZERO" */;

--
-- Table structure for table `mytable`
--

DROP TABLE IF EXISTS `mytable`;
CREATE TABLE `mytable` (
  [... etc etc ... ]
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

/*!40000 ALTER TABLE `mytable` DISABLE KEYS */;
LOCK TABLES `mytable` WRITE;
INSERT INTO `mytable` [... etc ...]
UNLOCK TABLES;
/*!40000 ALTER TABLE `mytable` ENABLE KEYS */;

Suggested fix:
Some more info from the logs:

This was what the binary log said:

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
# at 4
#040914 12:40:51 server id 1  log_pos 4         Start: binlog v 3, server v 4.1.3-beta-standard-log created 040914 12:40:51 at startup
# at 79
#040914 12:44:37 server id 1  log_pos 79        Query   thread_id=3     exec_time=0     error_code=0
use mydb;
SET TIMESTAMP=1095191077;
SET ONE_SHOT CHARACTER_SET_CLIENT=33,COLLATION_CONNECTION=33,COLLATION_DATABASE=33,COLLATION_SERVER=8;
# at 216
#040914 12:44:37 server id 1  log_pos 216       Query   thread_id=3     exec_time=0     error_code=0
SET TIMESTAMP=1095191077;
SET FOREIGN_KEY_CHECKS=0;
# at 276
#040914 12:44:37 server id 1  log_pos 276       Query   thread_id=3     exec_time=0     error_code=0
SET TIMESTAMP=1095191077;
DROP TABLE IF EXISTS `mytable`;
# at 343
#040914 12:44:37 server id 1  log_pos 343       Query   thread_id=3     exec_time=0     error_code=0
SET TIMESTAMP=1095191077;
SET FOREIGN_KEY_CHECKS=1;

The error log included this message:

040914 12:26:43  mysqld started
040914 12:26:43  InnoDB: Started; log sequence number 0 43634
/usr/sbin/mysqld: ready for connections.
Version: '4.1.3-beta-standard-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306
mysqld got signal 11;
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=258048
max_used_connections=3
max_connections=100
threads_connected=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 92783 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Number of processes running now: 0
040914 12:33:43  mysqld restarted
040914 12:33:43  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040914 12:33:43  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 43678.
InnoDB: Doing recovery: scanned up to log sequence number 0 43678
InnoDB: Last MySQL binlog file position 0 79, file name ./myhost-bin.000001
040914 12:33:43  InnoDB: Flushing modified pages from the buffer pool...
040914 12:33:43  InnoDB: Started; log sequence number 0 43678
/usr/sbin/mysqld: ready for connections.
Version: '4.1.3-beta-standard-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306
mysqld got signal 11;

Apologies if this has already been fixed in 4.1.4
[15 Sep 2004 18:57] Keith Dreibelbis
I have since seen the master crash when doing other tasks, so it seems to be a more general problem, rather than being specific to importing.  Two other notes about my setup, which might be unusual:

- the slave is on a network/host which cannot be seen by the master.  the slave can see the master's host.
- the slave has log-bin enabled.
[16 Sep 2004 19:59] Keith Dreibelbis
Also, the master is a 64 bit machine, while the slave is a 32 bit machine.
[4 Jan 2005 12:54] MySQL Verification Team
Hi,

Thank you for the report.
I tested you report, but wasn't able reproduce server crash.
Does master crash every time when you load  table `mytable`?
How big the table is?
We need to reproduce the problem to fix it.
[14 Feb 2005 22:54] 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".