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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Bartłomiej Piotrowski (Barthalion)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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

Loading...