[MDEV-7373] Error while running mysql_upgrade Created: 2014-12-25  Updated: 2014-12-29  Due: 2014-12-31  Resolved: 2014-12-29

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.1.2
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Koustubh Sinkar Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: mysql_upgrade
Environment:

OS: Fedora 19
Architecture: x86_64
Downloaded from http://yum.mariadb.org/10.1/fedora20-amd64


Attachments: Zip Archive mdev_7373.zip    
Issue Links:
Relates
relates to MDEV-7374 Losing connection to MySQL while runn... Closed

 Description   

Faced an error while running

#mysql_upgrade -uroot -p

STDOUT:

Phase 1/5: Checking mysql database
Processing databases
mysql
mysql.column_stats                                 OK
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
mysql.func                                         OK
mysql.gtid_slave_pos                               OK
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.host                                         OK
mysql.index_stats                                  OK
mysql.innodb_index_stats                           OK
mysql.innodb_table_stats                           OK
mysql.ndb_binlog_index                             OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.roles_mapping                                OK
mysql.servers                                      OK
mysql.table_stats                                  OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.user                                         OK
Phase 2/5: Running 'mysql_fix_privilege_tables'...
ERROR 2013 (HY000) at line 584: Lost connection to MySQL server during query
ERROR 2006 (HY000) at line 585: MySQL server has gone away

ERROR_LOG_FILE:

Version: '10.1.2-MariaDB-wsrep'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server, wsrep_25.10.r4123
141225 19:56:07 [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.2-MariaDB-wsrep
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=2
max_threads=153
thread_count=2
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467237 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x0x7f4218fef008
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 = 0x7f422fefbcf0 thread_stack 0x48000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x7f42309f687e]
/usr/sbin/mysqld(handle_fatal_signal+0x37d)[0x7f423055bf2d]
/lib64/libpthread.so.0(+0x308960f6d0)[0x7f422fbb36d0]
/usr/sbin/mysqld(thd_get_ha_data+0xa)[0x7f42303bb32a]
/usr/sbin/mysqld(_Z13get_trans_logP3THD+0x31)[0x7f423061ce71]
/usr/sbin/mysqld(wsrep_run_wsrep_commit+0x62c)[0x7f42304fafec]
/usr/sbin/mysqld(+0x71790a)[0x7f42306fa90a]
/usr/sbin/mysqld(_ZN7handler12ha_write_rowEPh+0x3bf)[0x7f4230565caf]
/usr/sbin/mysqld(+0x3555bb)[0x7f42303385bb]
/usr/sbin/mysqld(_Z17mysql_alter_tableP3THDPcS1_P14HA_CREATE_INFOP10TABLE_LISTP10Alter_infojP8st_orderb+0x3501)[0x7f4230472f91]
/usr/sbin/mysqld(_ZN19Sql_cmd_alter_table7executeEP3THD+0x65a)[0x7f42304b632a]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x182b)[0x7f42303ebbfb]
/usr/sbin/mysqld(_ZN18Prepared_statement7executeEP6Stringb+0x496)[0x7f4230405b96]
/usr/sbin/mysqld(+0x422d03)[0x7f4230405d03]
/usr/sbin/mysqld(_Z22mysql_sql_stmt_executeP3THD+0xb3)[0x7f42304062e3]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x1afe)[0x7f42303ebece]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x20b)[0x7f42303f2d5b]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x21a5)[0x7f42303f5cc5]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x134)[0x7f42303f63f4]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x18a)[0x7f42304b351a]
/usr/sbin/mysqld(handle_one_connection+0x40)[0x7f42304b36e0]
/lib64/libpthread.so.0(+0x3089607ee5)[0x7f422fbabee5]
/lib64/libc.so.6(clone+0x6d)[0x7f422dfcbb8d]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f42029a54a0): is an invalid pointer
Connection ID (thread ID): 13
Status: NOT_KILLED
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pus
hdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cach
e=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=of
f,table_elimination=on,extended_keys=on,exists_to_in=on
 
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.
141225 19:56:08 mysqld_safe Number of processes running now: 0
141225 19:56:08 mysqld_safe mysqld restarted
141225 19:56:08 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.OABotj' --pid-file='/var/lib/mysql/c4.pune.mangopulse.com-recover.pid'



 Comments   
Comment by Elena Stepanova [ 2014-12-25 ]

Please attach your cnf file(s) and/or the output of SHOW GLOBAL VARIABLES.

If you have wsrep_on=1, please set it to 0 and try agian.

Comment by Elena Stepanova [ 2014-12-26 ]

The crash itself is a duplicate of MDEV-7374 (I'm keeping MDEV-7374 as a primary one because it's more obvious via a simple ALTER than via mysql_upgrade).

The bug affects tables with > 10K rows.
I assume you hit the problem on mysql_upgrade because your mysql.innodb_index_stats or mysql.innodb_table_stats tables contained many rows. It can happen if you have many tables and indexes.
If that's really the reason, it should have been enough to truncate the tables. But since you've already dropped one, you can proceed this way – drop another one, then run mysql_upgrade --force – if it doesn't choke on something else, it should regenerate the tables, empty ones with the right structure.
Then you can re-enable InnoDB persistent stats which I asked you to disable earlier.

Comment by Koustubh Sinkar [ 2014-12-29 ]

elenst

You are right about the bug affecting tables with > 10K rows. The table in question had ~ 63000 rows.

mysql_upgrade --force works file after dropping mysql.innodb_index_stats and mysql.innodb_table_stats.

The solution that you gave has worked for me to get around the problem I faced. Thank you.

Comment by Elena Stepanova [ 2014-12-29 ]

Then I'll close it as a duplicate of MDEV-7374 which, I hope, will be fixed soon.

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