Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-9131

MariaDB 10.0.22 to 10.1.8 fails (signal 11)

    XMLWordPrintable

    Details

      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

        Attachments

          Activity

            People

            Assignee:
            jplindst Jan Lindström
            Reporter:
            vancanneyt Sander Vancanneyt
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Git Integration