db crash during sql dump import
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC |
New
|
Undecided
|
Unassigned |
Bug Description
full db cluster crash while restoring sql dump. Something to do with galera replication/memory allocation?
error log(inconsistent sometimes get signal 6, 11. Also have to note that was able to restore dump than using single node - initial cluster startup. After that stt to second node was successfull):
2014-03-18 12:17:09 55053 [Note] WSREP: rollbacker thread exiting
2014-03-18 12:17:09 55053 [Note] Giving 0 client threads a chance to die gracefully
2014-03-18 12:17:09 55053 [Note] Event Scheduler: Purging the queue. 0 events
2014-03-18 12:17:09 55053 [Note] Shutting down slave threads
2014-03-18 12:17:09 55053 [Note] Forcefully disconnecting 0 remaining clients
2014-03-18 12:17:09 55053 [Note] WSREP: dtor state: SYNCED
2014-03-18 12:17:09 55053 [Note] WSREP: Closing send monitor...
2014-03-18 12:17:09 55053 [Note] WSREP: Closed send monitor.
2014-03-18 12:17:09 55053 [Note] WSREP: mon: entered 1925 oooe fraction 0 oool fraction 0
2014-03-18 12:17:09 55053 [Note] WSREP: mon: entered 1925 oooe fraction 0 oool fraction 0
2014-03-18 12:17:09 55053 [Note] WSREP: mon: entered 1979 oooe fraction 0 oool fraction 0
2014-03-18 12:17:09 55053 [Note] WSREP: cert index usage at exit 0
2014-03-18 12:17:09 55053 [Note] WSREP: cert trx map usage at exit 129
2014-03-18 12:17:09 55053 [Note] WSREP: deps set usage at exit 0
2014-03-18 12:17:09 55053 [Note] WSREP: avg deps dist 66.0078
terminate called after throwing an instance of 'gu::Exception'
what(): Buffer too short: expected 17778, got 5888: 22 (Invalid argument)
at galera/
10:17:09 UTC - mysqld got signal 6 ;
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 https:/
key_buffer_
read_buffer_
max_used_
max_threads=153
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_
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 = 0 thread_stack 0x40000
/usr/sbin/
/usr/sbin/
/lib64/
/lib64/
/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/lib64/
/lib64/
You may download the Percona XtraDB Cluster operations manual by visiting
http://
in the manual which will help you identify the cause of the crash.
-------
16:11:04 UTC - mysqld got signal 6 ;
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 https:/
key_buffer_
read_buffer_
max_used_
max_threads=153
thread_count=3
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f8bd4000990
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 = 7f8bd8d20d98 thread_stack 0x40000
/usr/sbin/
/usr/sbin/
/lib64/
/lib64/
/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/lib64/
/usr/sbin/
/usr/sbin/
/lib64/
/lib64/
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): 1
Status: NOT_KILLED
You may download the Percona XtraDB Cluster operations manual by visiting
http://
in the manual which will help you identify the cause of the crash.
140318 18:11:05 mysqld_safe Number of processes running now: 0
140318 18:11:05 mysqld_safe WSREP: not restarting wsrep node automatically
140318 18:11:05 mysqld_safe mysqld from pid file /var/run/
-------
2 node cluster with arbitrator. configs, just basic install for the proof of concept:
node1:
[mysqld]
innodb_
max_allowed_
datadir=
user=mysql
pid-file=
# Path to Galera library
wsrep_provider=
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
# MyISAM storage engine has only experimental support
default_
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_
# Node #1 address
wsrep_node_
# SST method
wsrep_sst_
# Cluster name
wsrep_cluster_
# Authentication for SST method
wsrep_sst_
node 2:
[mysqld]
innodb_
max_allowed_
datadir=
user=mysql
pid-file=
# Path to Galera library
wsrep_provider=
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
# MyISAM storage engine has only experimental support
default_
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_
# Node #1 address
wsrep_node_
# SST method
wsrep_sst_
# Cluster name
wsrep_cluster_
# Authentication for SST method
wsrep_sst_
arbitrator:
/usr/bin/garbd -d -a gcomm:/
packages:
Percona-
Percona-
Percona-
Percona-
Percona-
Percona-
percona-
libstdc+
glibc-common-
glibc-2.
OS:
CentOS release 6.5 (Final)
Linux db2.tn.telecom.lt 2.6.32-
testing on virtual hosts 1vcpu 12GB ram. db ~6GB
duplicate of https:/ /bugs.launchpad .net/galera/ +bug/1267507 ?