Unexpected mysql crash after env cold restart
Bug #1606536 reported by
Mikhail Samoylov
This bug report is a duplicate of:
Bug #1572521: ntpdate run before p_ntp pacemaker resource is up.
Edit
Remove
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Fuel for OpenStack |
Confirmed
|
High
|
Fuel Sustaining | ||
Mitaka |
Confirmed
|
High
|
Fuel Sustaining |
Bug Description
Scenario:
1. Revert from ceph_ha
2. Waiting up galera and cinder
3. Check ceph status
4. Run OSTF
5. Destroy and remove osd-node
6. Check ceph status
7. Run OSTF
8. Destroy and remove one compute node
9. Check ceph status
10. Run OSTF
11. Cold restart
12. Waiting up galera and cinder
13. Run single OSTF - Create volume and attach it to instance
14. Run OSTF
Actual result:
Failed on step 12
Expected result:
Test passed
summary: |
- Failed ceph_ha_restart test + Unexpected mysql crash after env cold restart |
To post a comment you must log in.
After short inspection it seems to be either bug in mysql itself:
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.
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.
key_buffer_ size=16777216 size=131072 connections= 0 size)*max_ threads = 76505 K bytes of memory
read_buffer_
max_used_
max_threads=151
thread_count=1
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f4def5a0800 mysqld( my_print_ stacktrace+ 0x2c)[0x7f4ded1 60b7c] mysqld( handle_ fatal_signal+ 0x3c2)[ 0x7f4deceb15c2] 64-linux- gnu/libpthread. so.0(+0x10340) [0x7f4debba6340 ] mysqld( thd_get_ ha_data+ 0xc)[0x7f4decef e54c] mysqld( _Z20thd_ binlog_ trx_resetP3THD+ 0x2e)[0x7f4ded1 0b79e] mysqld( _Z17wsrep_ post_commitP3TH Db+0xcc) [0x7f4decfeb32c ] mysqld( _Z12trans_ commitP3THD+ 0x6f)[0x7f4decf d1dcf] mysqld( _Z21mysql_ execute_ commandP3THD+ 0x38d1) [0x7f4decf3f851 ] mysqld( _Z11mysql_ parseP3THDPcjP1 2Parser_ state+0x3c8) [0x7f4decf439d8 ] mysqld( +0x508c24) [0x7f4decf43c24 ] mysqld( _Z19do_ handle_ bootstrapP3THD+ 0x111)[ 0x7f4decf43ff1] mysqld( +0x509060) [0x7f4decf44060 ] 64-linux- gnu/libpthread. so.0(+0x8182) [0x7f4debb9e182 ] 64-linux- gnu/libc. so.6(clone+ 0x6d)[0x7f4deb2 c147d]
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 = 7f4dec926e88 thread_stack 0x30000
/usr/sbin/
/usr/sbin/
/lib/x86_
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/lib/x86_
/lib/x86_
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f4dc40009f0): is an invalid pointer
Connection ID (thread ID): 1
Status: NOT_KILLED
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.
or problem in user table sync (just a year ago galera wasn't sync these tables):
2016-07- 26T01:29: 50.406124+ 00:00 err: 2016-07-26 01:29:50 15678 [ERROR] /usr/sbin/mysqld: Table './mysql/user' is marked as crashed and should be repaired 26T01:29: 50.407359+ 00:00 err: 2016-07-26 01:29:50 15678 [Warning] Checking table: './mysql/user' 26T01:29: 50.407904+ 00:00 err: 2016-07-26 01:29:50 15678 [ERROR] 1 client is using or hasn't closed the table properly 26T01:29: 50.417927+ 00:00 err: 2016-07-26 01:29:50 15678 [ERROR] /usr/sbin/mysqld: Table './mysql/db' is marked as crashed and should be repaired 26T01:29: 50.417927+ 00:00 err: 2016-07-26 01:29:50 15678 [Warning] Checking table: './mysql/db' 26T01:29: 50.417927+ 00:00 err: 2016-07-26 01:29:50 15678 [ERROR] 1 client is using or hasn't closed the table properly
2016-07-
2016-07-
2016-07-
2016-07-
2016-07-