I have a 4 node cluster, where 3 of the nodes are VPSes in the same data centre, and the fourth node is in the office, which is connected to the internet by fibre, and to the rest of the cluster via OpenVPN.
The VPSes are quad E5620 CPU, 32GB mem, 2TB disk. The dedicated office server is 8 thread i7-4820K CPU, 48GB mem, and runs 3 KVM VPSes as well. All have of the order of 10GB memory unused.
All are running Ubuntu 14.04 LTS, and Percona 5.6.21 ( the latest GHOST vulnerability has been patched on all servers ).
MySQL on the dedicated node has crashed twice over the weekend with the message below.
Could anyone provide any pointers on where to look while I’m working through the manual, or in the meantime indicate how to reverse the message
‘150201 06:11:25 mysqld_safe WSREP: not restarting wsrep node automatically’ so that it does restart?
Cheers,
Steve
7:11:24 UTC - 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.
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.
Please help us make Percona XtraDB Cluster better by reporting any
bugs at [url]https://bugs.launchpad.net/percona-xtradb-cluster[/url]
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=2
max_threads=153
thread_count=3
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 603396 K bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.
Thread pointer: 0x49f4130
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 = 7fe1d403ee20 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x923b1c]
/usr/sbin/mysqld(handle_fatal_signal+0x352)[0x67cac2]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7fe209627340]
/usr/sbin/mysqld[0xb42ab0]
/usr/sbin/mysqld(_ZN11MDL_context12release_lockEP10MDL_ticket+0x4e)[0x66e29e]
/usr/sbin/mysqld(_ZN18Global_backup_lock7releaseEP3THD+0x1c)[0x66127c]
/usr/sbin/mysqld(_ZN3THD7cleanupEv+0xee)[0x6ccb5e]
/usr/sbin/mysqld(_ZN3THD17release_resourcesEv+0x298)[0x6cf988]
/usr/sbin/mysqld(_Z29one_thread_per_connection_endP3THDb+0x2a)[0x5920fa]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0xf0)[0x6d7840]
/usr/sbin/mysqld(handle_one_connection+0x39)[0x6d7ad9]
/usr/sbin/mysqld(pfs_spawn_thread+0x140)[0xb41570]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7fe20961f182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe208b2c00d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 196
Status: KILL_CONNECTION
You may download the Percona XtraDB Cluster operations manual by visiting
[url]http://www.percona.com/software/percona-xtradb-cluster/[/url]. You may find information
in the manual which will help you identify the cause of the crash.