[MDEV-9131] MariaDB 10.0.22 to 10.1.8 fails (signal 11) Created: 2015-11-14  Updated: 2015-11-16  Resolved: 2015-11-16

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 10.1.8
Fix Version/s: 10.1.9

Type: Bug Priority: Major
Reporter: Sander Vancanneyt Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS 6.7 64bit



 Description   

When trying to upgrade from Mariadb 10.0.22 tot 10.1.8, it all fails and MariaDB won't upgrade, won't start. Downgrading back to original 10.0.22 makes it all work again.

When upgrading from command line these are the messages:

Found /usr/local/directadmin/custombuild/mysql/MariaDB-10.1.8-centos6-x86_64-client.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-10.1.8-centos6-x86_64-devel.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-10.1.8-centos6-x86_64-server.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-10.1.8-centos6-x86_64-shared.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-10.1.8-centos6-x86_64-common.rpm
Found /usr/local/directadmin/custombuild/mysql/MariaDB-10.1.8-centos6-x86_64-compat.rpm
Installing libjemalloc...
Found /usr/local/directadmin/custombuild/mysql/jemalloc-3.6.0-1.el6.x86_64.rpm
Found /usr/local/directadmin/custombuild/mysql/jemalloc-devel-3.6.0-1.el6.x86_64.rpm
warning: /usr/local/directadmin/custombuild/mysql/jemalloc-3.6.0-1.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 1bb943db: NOKEY
Preparing...                ########################################### [100%]
   1:jemalloc               ########################################### [ 50%]
   2:jemalloc-devel         ########################################### [100%]
Stopping mysqld ...
Shutting down MySQL.......................................................................................................................... SUCCESS! 
Upgrading MariaDB 10.0.22 to 10.1.8
warning: /etc/my.cnf.d/server.cnf saved as /etc/my.cnf.d/server.cnf.rpmsave
warning: MariaDB-10.1.8-centos6-x86_64-client.rpm: Header V4 DSA/SHA1 Signature, key ID 1bb943db: NOKEY
Preparing...                ########################################### [100%]
   1:MariaDB-compat         ########################################### [ 17%]
   2:MariaDB-common         ########################################### [ 33%]
   3:MariaDB-client         ########################################### [ 50%]
   4:MariaDB-server         ########################################### [ 67%]
   5:MariaDB-devel          ########################################### [ 83%]
   6:MariaDB-shared         ########################################### [100%]
Starting MySQL...................................... SUCCESS! 
Giving mysqld a few seconds to start up...
Version check failed. Got the following error when calling the 'mysql' command line client
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111 "Connection refused")
FATAL ERROR: Upgrade failed
/usr/bin/mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111 "Connection refused") when trying to connect
cp: `/usr/lib/libmysqlclient.so' and `/usr/lib/mysql/libmysqlclient.so' are the same file
Restarting MySQL.
 ERROR! MySQL server PID file could not be found!
Starting MySQL..................... SUCCESS! 

With the upgrade my.cnf is taken back to standard config, so there can't be a conflict within my.cnf.

So let's take a look at the error log:

151113 15:39:48 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
/usr/sbin/mysqld: /usr/local/lib/libz.so.1: no version information available (required by /usr/sbin/mysqld)
2015-11-13 15:39:48 140184401442848 [Note] /usr/sbin/mysqld (mysqld 10.1.8-MariaDB) starting as process 28262 ...
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: The InnoDB memory heap is disabled
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: Memory barrier is not used
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: Using Linux native AIO
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: Using CPU crc32 instructions
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: Completed initialization of buffer pool
2015-11-13 15:39:48 140184401442848 [Note] InnoDB: Highest supported file format is Barracuda.
2015-11-13 15:39:49 140184401442848 [Warning] InnoDB: Resizing redo log from 2*16384 to 2*3072 pages, LSN=281214655146
2015-11-13 15:39:49 140184401442848 [Warning] InnoDB: Starting to delete and rewrite log files.
2015-11-13 15:39:49 140184401442848 [Note] InnoDB: Setting log file ./ib_logfile101 size to 48 MB
2015-11-13 15:39:49 140184401442848 [Note] InnoDB: Setting log file ./ib_logfile1 size to 48 MB
 
2015-11-13 15:39:49 140184401442848 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
2015-11-13 15:39:49 140184401442848 [Warning] InnoDB: New log files created, LSN=281214655500
2015-11-13 15:39:49 140184401442848 [Note] InnoDB: 128 rollback segment(s) are active.
2015-11-13 15:39:49 140184401442848 [Note] InnoDB: Waiting for purge to start
151113 15:39:49 [ERROR] 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.
 
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
 
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.
 
Server version: 10.1.8-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467104 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
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 = 0x0 thread_stack 0x48000
2015-11-13 15:39:49 140184401442848 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.26-74.0 started; log sequence numb$
2015-11-13 15:39:50 140183638898432 [Note] InnoDB: Dumping buffer pool(s) not yet started
2015-11-13 15:39:50 140184401442848 [Note] Plugin 'FEEDBACK' is disabled.
2015-11-13 15:39:50 140184401442848 [Note] Recovering after a crash using tc.log
2015-11-13 15:39:50 140184401442848 [Note] Starting crash recovery...
2015-11-13 15:39:50 140184401442848 [Note] Crash recovery finished.
2015-11-13 15:39:50 140184401442848 [Note] Server socket created on IP: '::'.
2015-11-13 15:39:50 140184401442848 [Note] Event Scheduler: Loaded 0 events
2015-11-13 15:39:50 7f7f396e5700 InnoDB: Error: Column last_update in table "mysql"."innodb_table_stats" is INT UNSIGNED NOT NULL $
2015-11-13 15:39:50 7f7f396e5700 InnoDB: Error: Fetch of persistent statistics requested for table "mysql"."gtid_slave_pos" but th$
2015-11-13 15:39:50 140184401442848 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.8-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server
mysys/stacktrace.c:247(my_print_stacktrace)[0x7f7f3a19c6cb]
sql/signal_handler.cc:160(handle_fatal_signal)[0x7f7f39cfe0d5]
/lib64/libpthread.so.0(+0xf790)[0x7f7f39317790]
include/dict0dict.ic:181(dict_col_get_no)[0x7f7f39f4e583]
row/row0purge.cc:850(row_purge_record_func)[0x7f7f39f1d5d5]
que/que0que.cc:1089(que_thr_step)[0x7f7f39ee384f]
trx/trx0purge.cc:1254(trx_purge(unsigned long, unsigned long, bool))[0x7f7f39f4b1e1]
srv/srv0srv.cc:3432(srv_do_purge)[0x7f7f39f38dc5]
/lib64/libpthread.so.0(+0x7a51)[0x7f7f3930fa51]
/lib64/libc.so.6(clone+0x6d)[0x7f7f377f593d]
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.
151113 15:39:50 mysqld_safe Number of processes running now: 0

Seems like it goes somewhere terribly wrong. Hopefully there is a fix or solution to this :s



 Comments   
Comment by Elena Stepanova [ 2015-11-14 ]

It's most likely the same as MDEV-9040, but there is a difference in stack trace, so assigning to jplindst to confirm.

Comment by Jan Lindström (Inactive) [ 2015-11-16 ]

This assertion also seen on when testing fix candidates for MDEV-9040.

Generated at Thu Feb 08 07:32:22 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.