Hi Bill, The stack trace isn't useful. Did you build the server too? Could you try repeating this on a debug build? I would also advise you to file a bug at jira.mariadb.org.
Best, Nirbhay On Wed, May 25, 2016 at 6:29 PM, Bill Mair <william.m...@t-online.de> wrote: > A new install and instance crashes when I try to start it with galera, I > don't know what I'm doing wrong. > > I built galera from source according to the instructions here: > https://mariadb.com/kb/en/mariadb/installating-galera-from-source/ > > I had to use "scons strict_build_flags=0" (warnings were being flagged up > as errors). > > # uname -a > Linux alarm 4.6.0-3-ARCH #1 Fri May 20 20:21:01 MDT 2016 armv7l GNU/Linux > > # 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 <i...@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. > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-discuss > Post to : maria-discuss@lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-discuss > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
