MySQL Bugs: #30971: Mysqld crashed on simple insert when log-bin is activated

Bug #30971	Mysqld crashed on simple insert when log-bin is activated
Submitted:	12 Sep 2007 12:52	Modified:	26 Oct 2007 11:14
Reporter:	Nicolas Legrand	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Cluster: Replication	Severity:	S1 (Critical)
Version:	5.1.20	OS:	Linux (x86_64 )
Assigned to:		CPU Architecture:	Any

Description:
When a ndb cluster is activated, if I launch mysql with log_bin binlog-format and binlog-ignore-db in my.cnf, the mysql server crashed on each insert. The same behaviour does not happened when this parameters are not used.
if table type not NDB, no error occured.

How to repeat:
# mysql -uroot spp
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.1.20-beta-log MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> create table test (id int) engine=NDB;
Query OK, 0 rows affected (0.63 sec)

mysql> insert into test values('1');
Query OK, 1 row affected (0.06 sec)

mysql> insert into test values('2');
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
ERROR:
Can't connect to the server

in /var/log/syslog:
Sep 12 14:49:40 replication02 mysqld: InnoDB: Started; log sequence number 0 46409
Sep 12 14:49:40 replication02 mysqld: Version: '5.1.20-beta-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
Sep 12 14:49:40 replication02 mysqld: Starting MySQL Cluster Binlog Thread
Sep 12 14:49:40 replication02 mysqld: Recovering after a crash using /SPP/data/replication02-bin
Sep 12 14:49:40 replication02 mysqld: Starting crash recovery...
Sep 12 14:49:40 replication02 mysqld_safe[13819]: Number of processes running now: 0
Sep 12 14:49:40 replication02 mysqld: This could be because you hit a bug. It is also possible that this binary
Sep 12 14:49:40 replication02 mysqld_safe[13821]: mysqld restarted
Sep 12 14:49:40 replication02 mysqld: or one of the libraries it was linked against is corrupt, improperly built,
Sep 12 14:49:40 replication02 mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
Sep 12 14:49:40 replication02 mysqld: We will try our best to scrape up some info that will hopefully help diagnose
Sep 12 14:49:40 replication02 mysqld: Crash recovery finished.
Sep 12 14:49:40 replication02 mysqld: the problem, but since we have already crashed, something is definitely wrong
Sep 12 14:49:40 replication02 mysqld: and this may fail.
Sep 12 14:49:40 replication02 mysqld: Event Scheduler: Loaded 0 events
Sep 12 14:49:40 replication02 mysqld: /usr/local/mysql.old/bin/mysqld: ready for connections.
Sep 12 14:49:40 replication02 mysqld: key_buffer_size=8388600
Sep 12 14:49:40 replication02 mysqld: read_buffer_size=131072
Sep 12 14:49:40 replication02 mysqld: max_used_connections=2
Sep 12 14:49:40 replication02 mysqld: max_threads=50
Sep 12 14:49:40 replication02 mysqld: threads_connected=1
Sep 12 14:49:40 replication02 mysqld: It is possible that mysqld could use up to
Sep 12 14:49:40 replication02 mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 117443 K
Sep 12 14:49:40 replication02 mysqld: bytes of memory
Sep 12 14:49:40 replication02 mysqld: Hope that's ok; if not, decrease some variables in the equation.
Sep 12 14:49:40 replication02 mysqld: thd: 0x14ed770
Sep 12 14:49:40 replication02 mysqld: Attempting backtrace. You can use the following information to find out
Sep 12 14:49:40 replication02 mysqld: where mysqld died. If you see no messages after this, something went
Sep 12 14:49:40 replication02 mysqld: terribly wrong...
Sep 12 14:49:40 replication02 mysqld: Cannot determine thread, fp=0x4409d0a8, backtrace may not be correct.
Sep 12 14:49:40 replication02 mysqld: Stack range sanity check OK, backtrace follows:
Sep 12 14:49:40 replication02 mysqld: 0x1
Sep 12 14:49:40 replication02 mysqld: New value of fp=0x14ed770 failed sanity check, terminating stack trace!
Sep 12 14:49:40 replication02 mysqld: Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.html
Sep 12 14:49:40 replication02 mysqld: and follow instructions on how to resolve the stack trace.
Sep 12 14:49:40 replication02 mysqld: Resolved stack trace is much more helpful in diagnosing the
Sep 12 14:49:40 replication02 mysqld: problem, so please do resolve it
Sep 12 14:49:40 replication02 mysqld: Trying to get some variables.
Sep 12 14:49:40 replication02 mysqld: Some pointers may be invalid and cause the dump to abort...
Sep 12 14:49:40 replication02 mysqld: thd->query at (nil)  is invalid pointer
Sep 12 14:49:40 replication02 mysqld: thd->thread_id=1
Sep 12 14:49:40 replication02 mysqld: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Sep 12 14:49:40 replication02 mysqld: information that should help you find out what is causing the crash.

Suggested fix:
none

my.cnf values that are crashing mysql if set:
server-id               = 53
log_bin                 = /SPP/data/replication01-bin.log
binlog-format           = row
binlog-ignore-db        = mysql

possible fix: data restoration works 1 out of 2 cluster

on slave, relay is also a problem:

mysqlbinlog relay-bin.00001
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
mysqlbinlog: File 'relay-bin.00001' not found (Errcode: 2)
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

on slave, one way to recover was to restart node with start-initial

Thank you for the report.

I can not repeat described behaviour in myself environment. Please provide your cluster configuration files, full mysqld configuration and all error logs.

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".