[MDEV-14915] Attempted to upgrade from 5.5.52 to 10.2.12 Created: 2018-01-10  Updated: 2018-12-29

Status: Open
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Michael Hudacko Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux 2.6.32-696.13.2.el6.x86_64 #1 SMP Fri Sep 22 12:32:14 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux


Attachments: File ibsqldeva02.err     File ibsqldeva02.err     File ibsqldeva02.err.5.5.x     File my.cnf.5.5.x    
Issue Links:
Relates
relates to MDEV-15488 Crashes after upgrade from 5.5.52 to ... Closed
relates to MDEV-16923 10.3.8 crashes Open

 Description   

Instance restart - after running mysql_upgrade script - produced following crash error.
Subsequent rstarts show a clean error log.

2018-01-10 12:19:24 0x7f35c80c8700 InnoDB: Assertion failure in file /home/buildbot/buildbot/build/storage/innobase/que/que0que.cc line 567
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
180110 12:19:24 [ERROR] mysqld got signal 6 ;
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 https://mariadb.com/kb/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.2.12-MariaDB-log
key_buffer_size=268435456
read_buffer_size=131072
max_used_connections=5
max_threads=502
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1365189 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
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 0x49000
/home/fds/ferdb/mysql/bin/mysqld(my_print_stacktrace+0x2e)[0xde610e]
/home/fds/ferdb/mysql/bin/mysqld(handle_fatal_signal+0x471)[0x7de601]
/lib64/libpthread.so.0[0x3d31e0f7e0]
/lib64/libc.so.6(gsignal+0x35)[0x3d31632495]
/lib64/libc.so.6(abort+0x175)[0x3d31633c75]
/home/fds/ferdb/mysql/bin/mysqld[0xbafc13]
/home/fds/ferdb/mysql/bin/mysqld[0xad7f63]
/home/fds/ferdb/mysql/bin/mysqld[0xb0e9e3]
/home/fds/ferdb/mysql/bin/mysqld[0xa2b73a]
/home/fds/ferdb/mysql/bin/mysqld(_Z8closefrmP5TABLE+0x11e)[0x6a811e]
/home/fds/ferdb/mysql/bin/mysqld(_Z8tc_purgeb+0x61)[0x769981]
/home/fds/ferdb/mysql/bin/mysqld(_Z19close_cached_tablesP3THDP10TABLE_LISTbm+0x87)[0x59fd17]
/home/fds/ferdb/mysql/bin/mysqld[0x547895]
/home/fds/ferdb/mysql/bin/mysqld(kill_server_thread+0xa3)[0x54e8c3]
/home/fds/ferdb/mysql/bin/mysqld[0xa054a9]
/lib64/libpthread.so.0[0x3d31e07aa1]
/lib64/libc.so.6(clone+0x6d)[0x3d316e8bcd]
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.



 Comments   
Comment by Elena Stepanova [ 2018-01-10 ]

Could you please paste a bigger portion of the error log, last session of 5.5 and up to and including the first occurrence of the failure on 10.2?
Please also attach your cnf files.

Thanks.

Comment by Michael Hudacko [ 2018-01-10 ]

NOTE: after the restart that produced the crash, I removed the configuration parameter [innodb_file_format = 'Barracuda']. And restarted instance.

Comment by Elena Stepanova [ 2018-01-10 ]

MichaelTHudacko, thanks. However, the attached log still starts from a crash on 10.2. Can we see the last shutdown on 5.5 and the first startup on 10.2, and everything else until the crash has happened? Thanks.

Comment by Michael Hudacko [ 2018-01-10 ]

Attached as much "err" log as I have avail (ibsqldeva02.err.5.5.x) from previous runing instance. (this server is very inactive from a usage standpoint). It is also one node of a master-master replication set-up. This is inactive node #2 (10.2.12) with its master active node #1 (5.5.52). Since starting this thread it crashed another time and will provide another full error log.

Comment by Michael Hudacko [ 2018-01-10 ]

Hi Elena, Don't wish to waste your time on this.I'm beginning to think that this issue may be related to master-master replication set-up and initiating a mysql_upgrade with the target server slave started. I reviewed my notes from a previous upgrade and now see that before starting the instance (for upgrade) at that time put skip-slave-start in the my.cnf file.

Since your last update, I upgraded a totally different server without replication configured and experienced none of what I initially reported. I'm performing some tests on this server now,

Comment by Michael Hudacko [ 2018-04-05 ]

What type of feed back is desired here? Thanks!

Generated at Thu Feb 08 08:17:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.