[MDEV-9827] can not start new galera cluster: mysqld got signal 11 Created: 2016-03-29  Updated: 2017-06-26  Resolved: 2017-06-26

Status: Closed
Project: MariaDB Server
Component/s: Galera
Affects Version/s: 10.1.12, 10.1.13
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Jakub Dorňák Assignee: Sachin Setiya (Inactive)
Resolution: Incomplete Votes: 0
Labels: galera, need_feedback
Environment:

Fedora 24
the same result with both galera-25.3.12 and galera-25.3.15


 Description    

2016-03-29  8:45:43 140006784002240 [Note] WSREP: Read nil XID from storage engines, skipping position init
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so'
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: wsrep_load(): Galera 3.12(r9921e73) by Codership Oy <info@codership.com> loaded successfully.
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: CRC-32C: using "slicing-by-8" algorithm.
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Passing config to GCS: base_dir = /var/lib/mysql/; base_host = 10.16.46.34; base_port = 4567; cert.log_conflicts = no; debug = no; evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.user_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 128M; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.segment = 0; gmcast.version = 0; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; 
2016-03-29  8:45:43 140006694938368 [Note] WSREP: Service thread queue flushed.
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: wsrep_sst_grab()
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Start replication
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: 'wsrep-new-cluster' option used, bootstrapping the cluster
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: protonet asio version 0
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Using CRC-32C for message checksums.
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: backend: asio
 
2016-03-29  8:45:43 140006784002240 [Warning] WSREP: access file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory)
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: restore pc from disk failed
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: GMCast version 0
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: (2672f829, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: (2672f829, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: EVS version 0
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: gcomm: bootstrapping new group 'my_wsrep_cluster'
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: start_prim is enabled, turn off pc_recovery
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Node 2672f829 state prim
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: view(view_id(PRIM,2672f829,1) memb {
 
	2672f829,0
 
} joined {
 
} left {
 
} partitioned {
 
})
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: save pc into disk
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: discarding pending addr without UUID: tcp://10.16.144.72:4567
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: discarding pending addr proto entry 0x55c4a740ed20
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: gcomm: connected
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Changing maximum packet size to 64500, resulting msg size: 32636
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Shifting CLOSED -> OPEN (TO: 0)
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Opened channel 'my_wsrep_cluster'
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 1
 
2016-03-29  8:45:43 140006784002240 [Note] WSREP: Waiting for SST to complete.
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: Starting new group from scratch: 267f0d15-f5ac-11e5-be3e-9745b69f0a6c
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: STATE_EXCHANGE: sent state UUID: 267f15ce-f5ac-11e5-bf4c-ab995ec17939
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: STATE EXCHANGE: sent state msg: 267f15ce-f5ac-11e5-bf4c-ab995ec17939
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: STATE EXCHANGE: got state msg: 267f15ce-f5ac-11e5-bf4c-ab995ec17939 from 0 ()
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: Quorum results:
 
	version    = 3,
 
	component  = PRIMARY,
 
	conf_id    = 0,
 
	members    = 1/1 (joined/total),
 
	act_id     = 0,
 
	last_appl. = -1,
 
	protocols  = 0/7/3 (gcs/repl/appl),
 
	group UUID = 267f0d15-f5ac-11e5-be3e-9745b69f0a6c
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: Flow-control interval: [16, 16]
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: Restored state OPEN -> JOINED (0)
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: Member 0.0 () synced with group.
 
2016-03-29  8:45:43 140006446315264 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 0)
 
160329  8:45:43 [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



 Comments   
Comment by Elena Stepanova [ 2016-03-30 ]

Fedora 24 is a new-born alpha (less than 1 day old), we cannot guarantee any stability on a non-stable OS.
Still, if you can acquire a proper stack trace, it could be useful to look at it. If it's really a problem in MariaDB/Galera code, it needs to be fixed.

Have you seen the same issue on Fedora 23?

Comment by Elena Stepanova [ 2016-04-28 ]

Assigning to nirbhay_c in case he wants to check it out – time flies, Fedora 24 will be Beta soon.

Comment by Nirbhay Choubey (Inactive) [ 2016-04-28 ]

jdornak: Could you also add the full stack trace?

Comment by Sergei Golubchik [ 2017-06-26 ]

No feedback for more than a year, so closing.

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