Crash of MySQL databas after import of data

Background: We are using Solaris 10 on Sun Zones, and I stood up a MySQL 5.6.12 Advanced server edition database. Now currently we are using MySQL 5.0.51a Community edition, also on Solaris 10 Sun Zones. So the only thing that is new is the MySQL 5.6.12 database.

So I brought the new database up on a new configured Zone and it worked just fine. I even used Mysqldump to imported the DDL for (12) different company based parts (I would refer to them as Schemas in the Oracle DB world, but MySQL refers to them as Databases). Now I should say that my company is not doing or using anything complicated at all in MySQL (pretty simple in structures). Tables, Indexes, Views...we are NOT using Partitioning, MYSQL DB replication, or they using any of the other less popular storage engines types. Actually most of our tables are using INNODB with a few still using MyISAM (we use no other storage engine type).

So I had all of these "schemas" within the database and all was fine, we even stopped the database a number of times and even bounced the Zone a couple of times too. The database always came up with no issues. We also installed and configured MySQL Monitor 2,13 and started testing and watching all using it.

Now I had heard that there were issues with Migrating from a 5.0 to a 5,1 and the from a 5.1 to 5.5 MySQL Database, but since we are using a new 5.6.12 MySQL database, and recreated all the objects for the different schemas, we were just importing the data back into the database.

So using Mysqldump and trying to import the data caused the MySQL database to crash with the following error:

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=4
max_threads=151
thread_count=3
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68182 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x101a9c990
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...
/opt/mysql/mysql/bin/mysqld:my_print_stacktrace+0x2c
/opt/mysql/mysql/bin/mysqld:handle_fatal_signal+0x32c
/lib/sparcv9/libc.so.1:0xd8684
/lib/sparcv9/libc.so.1:0xcc1f8
/lib/sparcv9/libc.so.1:0xcc404
/opt/mysql/mysql/bin/mysqld:0x42d7cc [ Signal 69819032 (?)]
/opt/mysql/mysql/bin/mysqld:__1cLmysql_grant6FpnDTHD_pkcrnEList4nLst_lex_user___Lbb_b_+0x694
/opt/mysql/mysql/bin/mysqld:__1cVmysql_execute_command6FpnDTHD__i_+0x408c
/opt/mysql/mysql/bin/mysqld:__1cLmysql_parse6FpnDTHD_pcIpnMParser_state__v_+0x384
/opt/mysql/mysql/bin/mysqld:__1cQdispatch_command6FnTenum_server_command_pnDTHD_pcI_b_+0xa40
/opt/mysql/mysql/bin/mysqld:__1cKdo_command6FpnDTHD__b_+0x18c
/opt/mysql/mysql/bin/mysqld:__1cYdo_handle_one_connection6FpnDTHD__v_+0x1c8
/opt/mysql/mysql/bin/mysqld:handle_one_connection+0x54
/opt/mysql/mysql/bin/mysqldfs_spawn_thread+0xc0
/lib/sparcv9/libc.so.1:0xd8558
Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.html
and follow instructions on how to resolve the stack trace.
Resolved stack trace is much more helpful in diagnosing the
problem, so please do resolve it

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (122ce1c18): grant all on *.* to qedadm_db@'aruba' identified by "Op123xR5" with Grant option
Connection ID (thread ID): 31
Status: NOT_KILLED

******So after it finished we found that via MySQL Monitor 2.13 the server was green and not up, we tried to start it and it failed to start. the system at the OS level still showed that the process was up but you could not log into it. So we bounced the whole server and brought up everything, and still the MySQL database would crash and not let one log in.

Any advice here? I have tried to look up this via the net and it would seem to point to either of these two bugs #48726 and 61351 or a permissions issue with /tmp being able to write to /tmp/MySQL.sock which is blown open to the wold so that shouldn't be a problem, and as I have said this all worked before I attempted to import data into these schemas.

Ok so what if I were to roll back a snapshot I have of the Zone just prior to the change of adding the data,, and were to use mysqldump and export just the RAW data and then import the data...would that work then.

I am thinking that since there is a know bug from going to 5.0 to 5.1 and 5.1 to 5.5 and continues in 5.6 maybe taking the RAW data might work.

Ok I figured it out, when we did the mysqldump we did all the schemas which means the MYSQL schema which is like the SYSTEM schema in Oracle was over written and in the MySQL 5.6.12 database was confused...the my.cnf thought it was a 5.6 and the structures and internals from the import were from a 5.0.51a MySQL database....thus it was in a confused state.

I rolled back to a snapshot taken prior to the import and the database is backup and working correctly. I then did a mysqldump of just one schema and imported the raw data (the schema objects are already in the database) and it works.

So it would appear the work around might be that we stand up a new 5.6.12 MySQL database and then recreate the individual schema and import the Raw data each one individually.