Bug #2884 IO-Thread stops working, simple slave start won
Submitted: 19 Feb 2004 1:02 Modified: 19 Feb 2004 2:43
Reporter: Anders Henke Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:4.0.17 OS:Linux (GNU/Linux)
Assigned to: CPU Architecture:Any

[19 Feb 2004 1:02] Anders Henke
Description:
In a replication setup with all databases (except mysql) on innodb tables, a cronjobs runs once a night on all hosts:

/usr/bin/mysqlcheck --repair --all-databases --medium-check --silent
and
/usr/bin/mysqlcheck --optimize --all-databases --silent

As only a read slave is involved, user connections still can take place, but beside the running 'CHECK TABLE' only the replication user waits for updates;
however, connection attempts do fail

During the run of this cronjob, sometimes on one or more random replication slaves MySQL breaks down, starts replication again, but breaks down a minute later.

040219  3:40:15  Error: Can't create thread to kill server
040219  3:40:19  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 11 3008127633
InnoDB: Doing recovery: scanned up to log sequence number 11 3008516235
040219  3:40:19  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 5
6 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 617772, file name binlog.2473
InnoDB: Last MySQL binlog file position 0 2967730, file name /db/logs/binlog.067
040219  3:40:43  InnoDB: Flushing modified pages from the buffer pool...
040219  3:40:58  InnoDB: Started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.17-standard-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306
040219  3:40:58  Slave SQL thread initialized, starting replication in log 'binlog.2473' at position 617772, relay log './rdb88-relay-bin.065' position: 617772
040219  3:40:58  Slave I/O thread: connected to master 'repl@rdb84.schlund.de:3306',  replication started in log 'binlog.2473' at position 710852
040219  3:41:22  Error in Log_event::read_log_event(): 'read error', data_len: 158, event_type: 2
040219  3:41:22  Error reading relay log event: slave SQL thread aborted because of I/O error
040219  3:41:22  Slave: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log)
, the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check 
the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 0
040219  3:41:22  Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'binlog.2473' position 705697

The master's binlog position 617772 is in the middle of a transaction.

Maybe related to Bug 1858, but show up in another way and 1858 was already supposed to be fixed in 4.0.17 - so a new bug report.

How to repeat:
[19 Feb 2004 1:27] Anders Henke
close/remove this bug report, it's yet unfinished due to a <return> at the wrong button :)

I'm investigating the full scope and surroundings and will create a new bug
when I'm sure on those matters ..
[19 Feb 2004 1:28] Anders Henke
remove bug, yet unfinished report.
[19 Feb 2004 2:43] Guilhem Bichot
replaced by BUG#2886.