mysqld crashes on simple SELECT w/ large table

[Kian Mohageri]

MySQL is crashing with a simple "SELECT * FROM large_table" query. It happens every time. This does not affect stock MySQL (I tried).

This happens with a single-node cluster, or multi-node cluster.

Here are the version numbers:

# uname -a
Linux db02 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
<email address hidden>:/var/lib/mysql
# dpkg -l|grep mysql
ii libdbd-mysql-perl 4.016-1 Perl5 database interface to the MySQL database
ii libmysqlclient16 5.1.63-0+squeeze1 MySQL database client library
ii mysql-client-5.1 5.1.63-0+squeeze1 MySQL database client binaries
ii mysql-common 5.1.63-0+squeeze1 MySQL database common files, e.g. /etc/mysql/my.cnf
ii mysql-server-wsrep 5.5.23-23.6 wsrep-enabled MySQL server
<email address hidden>:/var/lib/mysql
# dpkg -l|grep galera
ii galera 23.2.1 Galera Replication Framework

Attached is a file with MySQL configuration and the relevant logs.

---

# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.5.23-log Source distribution, wsrep_23.6.r3755

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SET GLOBAL wsrep_debug=1;
Query OK, 0 rows affected (0.00 sec)

mysql> USE placelocal;
Database changed
mysql> SELECT * FROM trackings_referrers;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>

---

mysql> SHOW CREATE TABLE placelocal.trackings_referrers\G
*************************** 1. row ***************************
       Table: trackings_referrers
Create Table: CREATE TABLE `trackings_referrers` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `trackings_id` int(11) NOT NULL,
  `page` varchar(260) NOT NULL DEFAULT '',
  `event_count` int(11) NOT NULL DEFAULT '1',
  PRIMARY KEY (`id`),
  UNIQUE KEY `consolidated_key` (`trackings_id`,`page`),
  KEY `tracking_id` (`trackings_id`),
  CONSTRAINT `trackings_referrers_ibfk_1` FOREIGN KEY (`trackings_id`) REFERENCES `trackings` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=217890980 DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

[Seppo Jaakola (seppo-jaakola)]

I could not reproduce this with 1M rows. How many rows are in your table?

Looking at the log, it seems that mysqld_safe does server restart, without reason, MySQL server has not logged any issues on the log. Could you reproduce the problem with debugging enabled? To enable debugging, set:

mysql> set global wsrep_debug=1;

[Kian Mohageri (kian-mohageri)]

There are about 40 million rows in this table for us.

As shown in the initial bug report, I had tried to turn on wsrep_debug=1. I will try to figure out if it got logged somewhere else.

[Kian Mohageri (kian-mohageri)]

I just discovered that the crash is actually oom-killer kicking in. Don't know how I missed that before.

That said, I remember trying this with stock MySQL and oom-killer (apparently) never kicked in. Would it be helpful to try again, or would you like to simply close this?

Sorry for the noise...

[Kian Mohageri (kian-mohageri)]

This does in fact reproduce on regular MySQL, so it isn't like the wsrep patches are causing high memory usage.

Very relieved this isn't a bug in wsrep code and I apologize for the false report :)

Please close this.

[Seppo Jaakola (seppo-jaakola)]

ok, thanks for reporting anyways