[MDEV-15483] MariaDB Cluster Crash Created: 2018-03-06  Updated: 2018-09-02  Resolved: 2018-09-02

Status: Closed
Project: MariaDB Server
Component/s: Galera
Affects Version/s: 10.1
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Tolga Cengiz Assignee: Jan Lindström (Inactive)
Resolution: Incomplete Votes: 0
Labels: crash, galera, innodb


 Description   

Cluster is constantly crashing. Sometimes it works stable for 2 days. Sometimes five minutes after 2 servers stand.

server.cnf was tested with different parameters. The result did not change

When the setup is not installed, the single server is running without problems.

Clean installation several times.

iptables stop selinux disable

yum repo

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.1/centos6-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

Centos 6.9 64bit

yum install MariaDB-server MariaDB-client
Erorr Log

/var/lib/mysql/maria1.err

180305 16:17:03 [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.31-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=5
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 = 467163 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x0
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 = 0x0 thread_stack 0x48400

/etc/my.cnf.d/server.cnf

#
# These groups are read by MariaDB server.
# Use it for options that only the server (but not clients) should see
#
# See the examples of server my.cnf files in /usr/share/mysql/
#
 
# this is read by the standalone daemon and embedded servers
[server]
 
# this is only for the mysqld standalone daemon
[mysqld]
bind-address=0.0.0.0
skip-name-resolve
#
# * Galera-related settings
#
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.1.1.11,10.1.1.12"
wsrep_cluster_name='galera_cluster'
wsrep_node_address='10.1.1.11'
wsrep_node_name='maria1'
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:!!PassWordSs!!
 
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
#
# Allow server to accept connections on all interfaces.
#
#bind-address=0.0.0.0
#
# Optional setting
#wsrep_slave_threads=1
#innodb_flush_log_at_trx_commit=0
# this is only for embedded server
[embedded]
 
# This group is only read by MariaDB servers, not by MySQL.
# If you use the same .cnf file for MySQL and MariaDB,
# you can put MariaDB-only options here
[mariadb]
 
# This group is only read by MariaDB-10.1 servers.
# If you use the same .cnf file for MariaDB of different versions,
# use this group for options that older servers don't understand
[mariadb-10.1]

I want a stable cluster system.
Which source can I set up?



 Comments   
Comment by Sachin Setiya (Inactive) [ 2018-04-02 ]

Hi tolgacengiz!

Can you provide query on which this server crashes,
Since stack is also smashed it is very difficult to trace this bug.

Comment by Jan Lindström (Inactive) [ 2018-08-24 ]

Can you add wsrep_debug=ON to your configuration and send full unedited error log from server that has problems?

Comment by Jan Lindström (Inactive) [ 2018-09-02 ]

No feedback provided. I suggest upgrading to the newer version and if issue is repeatable again please provide requested information to analyze.

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