# grep wsrep /etc/mysql/my.cnf

wsrep_on=ON

wsrep_provider=/usr/lib/galera/libgalera_smm.so

wsrep_cluster_address=gcomm://192.168.1.91,192.168.1.92,192.168.1.93

wsrep_node_address='192.168.1.91'

wsrep_node_name='node1'

wsrep_cluster_name='mariadb_cluster'

wsrep_sst_method=rsync

wsrep_provider_options=pc.bootstrap=true

# sudo -u mysql mysqld --wsrep-new-cluster

2016-05-25 22:10:31 3061874688 [Note] mysqld (mysqld 10.1.14-MariaDB) starting as process 8527 ...

2016-05-25 22:10:31 3061874688 [Note] WSREP: Read nil XID from storage engines, skipping position init

2016-05-25 22:10:31 3061874688 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib/galera/libgalera_smm.so'

2016-05-25 22:10:31 3061874688 [Note] WSREP: wsrep_load(): Galera 3.16(rXXXX) by Codership Oy <info@codership.com> loaded successfully.

2016-05-25 22:10:31 3061874688 [Note] WSREP: CRC-32C: using "slicing-by-8" algorithm.

2016-05-25 22:10:31 3061874688 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1

2016-05-25 22:10:31 3061874688 [Note] WSREP: Passing config to GCS: base_dir = /var/lib/mysql/; base_host = 192.168.1.91; 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; gcomm.thread_prio = ; 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 = 2147483647; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.segment = 0; gmcast.version = 0; pc.announce_timeout = PT3S; pc.bootstrap = true; pc.checksum = false; pc.ignore_quo

2016-05-25 22:10:31 2908746768 [Note] WSREP: Service thread queue flushed.

2016-05-25 22:10:31 3061874688 [Note] WSREP: Assign initial position for certification: -1, protocol version: -1

2016-05-25 22:10:31 3061874688 [Note] WSREP: wsrep_sst_grab()

2016-05-25 22:10:31 3061874688 [Note] WSREP: Start replication

2016-05-25 22:10:31 3061874688 [Note] WSREP: 'wsrep-new-cluster' option used, bootstrapping the cluster

2016-05-25 22:10:31 3061874688 [Note] WSREP: Setting initial position to 00000000-0000-0000-0000-000000000000:-1

2016-05-25 22:10:31 3061874688 [Note] WSREP: protonet asio version 0

2016-05-25 22:10:31 3061874688 [Note] WSREP: Using CRC-32C for message checksums.

2016-05-25 22:10:31 3061874688 [Note] WSREP: backend: asio

2016-05-25 22:10:31 3061874688 [Note] WSREP: gcomm thread scheduling priority set to other:0 

2016-05-25 22:10:31 3061874688 [Note] WSREP: restore pc from disk successfully

2016-05-25 22:10:31 3061874688 [Note] WSREP: GMCast version 0

2016-05-25 22:10:31 3061874688 [Note] WSREP: (8708eb25, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567

2016-05-25 22:10:31 3061874688 [Note] WSREP: (8708eb25, 'tcp://0.0.0.0:4567') multicast: , ttl: 1

2016-05-25 22:10:31 3061874688 [Note] WSREP: EVS version 0

2016-05-25 22:10:31 3061874688 [Note] WSREP: gcomm: bootstrapping new group 'mariadb_cluster'

2016-05-25 22:10:31 3061874688 [Note] WSREP: start_prim is enabled, turn off pc_recovery

2016-05-25 22:10:31 3061874688 [Note] WSREP: Node 8708eb25 state prim

2016-05-25 22:10:31 3061874688 [Note] WSREP: view(view_id(PRIM,8708eb25,17) memb {

8708eb25,0

} joined {

} left {

} partitioned {

})

2016-05-25 22:10:31 3061874688 [Note] WSREP: save pc into disk

2016-05-25 22:10:31 3061874688 [Note] WSREP: discarding pending addr without UUID: tcp://192.168.1.91:4567

2016-05-25 22:10:31 3061874688 [Note] WSREP: discarding pending addr proto entry 0xb652e2a0

2016-05-25 22:10:31 3061874688 [Note] WSREP: discarding pending addr without UUID: tcp://192.168.1.92:4567

2016-05-25 22:10:31 3061874688 [Note] WSREP: discarding pending addr proto entry 0xb652e380

2016-05-25 22:10:31 3061874688 [Note] WSREP: discarding pending addr without UUID: tcp://192.168.1.93:4567

2016-05-25 22:10:31 3061874688 [Note] WSREP: discarding pending addr proto entry 0xb652e460

2016-05-25 22:10:31 3061874688 [Note] WSREP: clear restored view

2016-05-25 22:10:31 3061874688 [Note] WSREP: gcomm: connected

2016-05-25 22:10:31 3061874688 [Note] WSREP: Changing maximum packet size to 64500, resulting msg size: 32636

2016-05-25 22:10:31 3061874688 [Note] WSREP: Shifting CLOSED -> OPEN (TO: 0)

2016-05-25 22:10:31 3061874688 [Note] WSREP: Opened channel 'mariadb_cluster'

2016-05-25 22:10:31 3061874688 [Note] WSREP: Waiting for SST to complete.

2016-05-25 22:10:31 2860512272 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 1

2016-05-25 22:10:31 2860512272 [Note] WSREP: Starting new group from scratch: 1d570213-22bd-11e6-a70b-6aae917d4541

2016-05-25 22:10:31 2860512272 [Note] WSREP: STATE_EXCHANGE: sent state UUID: 1d574d2d-22bd-11e6-8936-86e5eb8c6c4c

2016-05-25 22:10:31 2860512272 [Note] WSREP: STATE EXCHANGE: sent state msg: 1d574d2d-22bd-11e6-8936-86e5eb8c6c4c

2016-05-25 22:10:31 2860512272 [Note] WSREP: STATE EXCHANGE: got state msg: 1d574d2d-22bd-11e6-8936-86e5eb8c6c4c from 0 (node1)

2016-05-25 22:10:31 2860512272 [Note] WSREP: Quorum results:

version = 4,

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 = 1d570213-22bd-11e6-a70b-6aae917d4541

2016-05-25 22:10:31 2860512272 [Note] WSREP: Flow-control interval: [16, 16]

2016-05-25 22:10:31 2860512272 [Note] WSREP: Restored state OPEN -> JOINED (0)

160525 22:10:31 [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.14-MariaDB

key_buffer_size=0

read_buffer_size=262144

max_used_connections=0

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 = 119520 K  bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0xb65d7008

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 = 0xad90edc4 thread_stack 0x48400

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort.

2016-05-25 22:10:31 2860512272 [Note] WSREP: Member 0.0 (node1) synced with group.

2016-05-25 22:10:31 2860512272 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 0)

Query (0x0):

Connection ID (thread ID): 1

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

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.