Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.1.16
-
Debian 8
Description
We are experiencing issue https://jira.mariadb.org/browse/MDEV-10301. After last crash on one of the nodes, when it get back and tried to synchronize, DONOR node crashed. This caused error on JOINER:
2016-08-20 12:59:13 140303755372288 [Warning] WSREP: Donor 73e68aa2-63ad-11e6-afe8-b73c902b7af0 is no longer in the group. State transfer cannot be completed, need to abort. Aborting...
|
2016-08-20 12:59:13 140303755372288 [Note] WSREP: /usr/sbin/mysqld: Terminated.
|
Log from DONOR node:
2016-08-20 12:59:08 140353675978496 [Note] WSREP: Member 2.0 (node2) requested state transfer from '*any*'. Selected 0.0 (node1)(SYNCED) as donor.
|
2016-08-20 12:59:08 140353675978496 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 15176302)
|
2016-08-20 12:59:08 140354040666880 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
|
2016-08-20 12:59:08 140353629845248 [Note] WSREP: Running: 'wsrep_sst_rsync --role 'donor' --address 'XXX.XXX.XXX.XXX:4444/rsync_sst' --socket '/var/run/mysqld/mysqld.sock' --datadir '/var/lib/mysql/' --binlog '/var/log/mysql/mariadb-bin' --gtid '97f799e6-b828-11e4-8c4b-5a16ba3e9c9d:15176302' --gtid-domain-id '0''
|
2016-08-20 12:59:08 140354040666880 [Note] WSREP: sst_donor_thread signaled with 0
|
2016-08-20 12:59:08 140353629845248 [Note] WSREP: Flushing tables for SST...
|
2016-08-20 12:59:08 140353629845248 [Note] WSREP: Provider paused at 97f799e6-b828-11e4-8c4b-5a16ba3e9c9d:15176302 (330638)
|
160820 12:59:08 [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 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.1.16-MariaDB-1~jessie
|
key_buffer_size=134217728
|
read_buffer_size=2097152
|
max_used_connections=2
|
max_threads=102
|
thread_count=17
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 759828 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
Thread pointer: 0x0x7fa69f449008
|
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 = 0x7fa6a03fe938 thread_stack 0x48400
|
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x7fa6b971191e]
|
/usr/sbin/mysqld(handle_fatal_signal+0x2d5)[0x7fa6b924e4a5]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7fa6b887b8d0]
|
/usr/sbin/mysqld(_ZN13MYSQL_BIN_LOG21do_checkpoint_requestEm+0x98)[0x7fa6b9304418]
|
/usr/sbin/mysqld(_ZN13MYSQL_BIN_LOG20checkpoint_and_purgeEm+0x11)[0x7fa6b9304441]
|
/usr/sbin/mysqld(_ZN13MYSQL_BIN_LOG16rotate_and_purgeEb+0x7e)[0x7fa6b930689e]
|
/usr/sbin/mysqld(_Z20reload_acl_and_cacheP3THDyP10TABLE_LISTPi+0x135)[0x7fa6b91b2b15]
|
/usr/sbin/mysqld(+0x547c0e)[0x7fa6b91f3c0e]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7fa6b88740a4]
|
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fa6b6a1e87d]
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7fa6b978a895): FLUSH TABLES WITH READ LOCK
|
Connection ID (thread ID): 0
|
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_pushdown=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_cache=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=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=off
|
|
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.
|
This also happend on our third node later. Then we restored cluster without more errors.
I don't know if it's related to https://jira.mariadb.org/browse/MDEV-9510 and others.
Attachments
Issue Links
- relates to
-
MDEV-9510 Segmentation fault in binlog thread causes crash
- Closed