FS#48724 - [mariadb] 10.1.13 crashes on tying to start wsrep replication
Attached to Project:
Arch Linux
Opened by c chandel (cchandel) - Monday, 28 March 2016, 10:49 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 23 August 2016, 08:23 GMT
Opened by c chandel (cchandel) - Monday, 28 March 2016, 10:49 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 23 August 2016, 08:23 GMT
|
Details
Description: After Installing 10.1.13-MariaDB, I compiled
galera provider on my Arch machine and copied to
/usr/lib64/libgalera_smm.so.
Copied wsrep.cnf from /usr/share/mysql to /etc/mysql and setup variables as given in /usr/share/mysql/README-wsrep. On giving command SET GLOBAL wsrep_cluster_address="gcomm://192.168.1.9,192.168.1.2"; mariadb crashes. Additional info: * package version(s) 10.1.13-MariaDB * config and/or log files etc. wsrep.cnf [mysqld] binlog_format=ROW default-storage-engine=innodb innodb_autoinc_lock_mode=2 bind-address=0.0.0.0 wsrep_provider=/lib64/libgalera_smm.so #wsrep_provider_options= wsrep_cluster_name="my_wsrep_cluster" wsrep_cluster_address="gcomm://192.168.1.9,192.168.1.2" wsrep_node_name="cc-laptop" wsrep_node_address="192.168.1.9" wsrep_slave_threads=1 wsrep_certify_nonPK=1 wsrep_max_ws_rows=131072 wsrep_max_ws_size=1073741824 wsrep_debug=0 wsrep_convert_LOCK_to_trx=0 wsrep_retry_autocommit=1 wsrep_auto_increment_control=1 wsrep_drupal_282555_workaround=0 wsrep_causal_reads=0 wsrep_sst_method=rsync #wsrep_sst_receive_address= wsrep_sst_auth=root:password #wsrep_sst_donor= #wsrep_sst_donor_rejects_queries=0 # wsrep_protocol_version= [Note] WSREP: Stop replication [Note] WSREP: Provider was not loaded, in stop replication [Note] WSREP: Start replication [Note] WSREP: 'wsrep-new-cluster' option used, bootstrapping the cluster [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.13-MariaDB key_buffer_size=16777216 read_buffer_size=262144 max_used_connections=1 max_threads=27 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 37652 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f763671e088 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 = 0x7f764c931238 thread_stack 0x48400 /usr/bin/mysqld(my_print_stacktrace+0x2e)[0x564f71c12f3e] /usr/bin/mysqld(handle_fatal_signal+0x34d)[0x564f7175e98d] /usr/lib/libpthread.so.0(+0x10e80)[0x7f764a996e80] /usr/bin/mysqld(+0x5292da)[0x564f716f92da] /usr/bin/mysqld(_Z28wsrep_cluster_address_updateP7sys_varP3THD13enum_var_type+0x12a)[0x564f7170914a] /usr/bin/mysqld(_ZN7sys_var6updateEP3THDP7set_var+0xde)[0x564f71550eee] /usr/bin/mysqld(_ZN7set_var6updateEP3THD+0x17)[0x564f715511b7] /usr/bin/mysqld(_Z17sql_set_variablesP3THDP4ListI12set_var_baseEb+0x89)[0x564f715523f9] /usr/bin/mysqld(_Z21mysql_execute_commandP3THD+0x6f6a)[0x564f715d763a] /usr/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x26e)[0x564f715d9b9e] /usr/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x24a7)[0x564f715dcf57] /usr/bin/mysqld(_Z10do_commandP3THD+0x176)[0x564f715dd6c6] /usr/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x182)[0x564f716a5d02] /usr/bin/mysqld(handle_one_connection+0x40)[0x564f716a5ec0] /usr/lib/libpthread.so.0(+0x7424)[0x7f764a98d424] /usr/lib/libc.so.6(clone+0x6d)[0x7f764a045cbd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f762523df60): is an invalid pointer Connection ID (thread ID): 3 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. 160328 15:53:08 mysqld_safe Number of processes running now: 0 160328 15:53:08 mysqld_safe WSREP: not restarting wsrep node automatically Steps to reproduce: 1. install mariadb 2. git clone https://github.com/codership/galera.git galera 3. cd galera 4. scons 5. cp libgalera_smm.so /usr/lib64 6. cp /usr/share/mysql/wsrep/cnf /etc/mysql 7. edit my.cnf and galera.cnf 8. mysqld_safe --wsrep-new-cluster 9. show status like "%wsrep%"; 10. +--------------------------+----------------------+ | Variable_name | Value | +--------------------------+----------------------+ | wsrep_cluster_conf_id | 18446744073709551615 | | wsrep_cluster_size | 0 | | wsrep_cluster_state_uuid | | | wsrep_cluster_status | Disconnected | | wsrep_connected | OFF | | wsrep_local_bf_aborts | 0 | | wsrep_local_index | 18446744073709551615 | | wsrep_provider_name | | | wsrep_provider_vendor | | | wsrep_provider_version | | | wsrep_ready | OFF | | wsrep_thread_count | 0 | +--------------------------+----------------------+ 11. SET GLOBAL wsrep_cluster_address="gcomm://192.168.1.9,192.168.1.2"; ERROR 2013 (HY000): Lost connection to MySQL server during query |
This task depends upon
Closed by Christian Hesse (eworm)
Tuesday, 23 August 2016, 08:23 GMT
Reason for closing: Upstream
Additional comments about closing: Fixed in mariadb 10.1.16-2
Tuesday, 23 August 2016, 08:23 GMT
Reason for closing: Upstream
Additional comments about closing: Fixed in mariadb 10.1.16-2