Assertion failure in thread, when loading from dump file

Bug #1357134 reported by Kenn
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC
New
Undecided
Unassigned

Bug Description

I am evaluating stable releases of MariaDB Galera Cluster 5.5, MariaDB Galera Cluster 10.0 and Percona XtraDB Cluster 5.6 on completely separate installs on minimal CentOS 6.5 servers. The clusters are all made up of 4 nodes and are successfully running and synced. I am then running a restore from mysqldump files.

On the two MariaDB clusters, everything restored as expected. However on the Percona cluster I received a Assertion failure on the server where I was performing the restore, note that this was also the server I bootstrapped from. None of the other cluster nodes failed. The data that was being restored was a very large search index table.

I have attached the my.cnf file which is identical for all nodes with the exception of the wsrep_node_address and wsrep_node_name. I have also an the log file from the server that failed.

Thanks,

Kenn

Revision history for this message
Kenn (ubuntuonl) wrote :
Revision history for this message
Kenn (ubuntuonl) wrote :

I have identified and attached an insert that can consistently kill the server it is issues on.

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

@Ken,

It has been fixed but not released. The package is available in experimental repo for further testing. (details in the linked bug)

Revision history for this message
Kenn (ubuntuonl) wrote :

Thanks for the link to the dupe bug. I would further like to note that after this the node cannot rejoin the cluster and I get this:

WSREP: Protocol violation. JOIN message sender 1.0 (db4) is not in state transfer (SYNCED). Message ignored.

To me this seems like it is another bug, as it would render the server useless which is much more critical than simply a crash.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.