Mario advised me that he tested the latest upstream Percona XtraDB Cluster 5.6 release (5.6.43-28.32) against his reproducer (using openstack rally) which causes foreign key violations even with wsrep_slave_threads=1 that it does not reproduce on the latest upstream release.
There is no clear changelog entry in the XtraDB Cluster changelog itself detailing this (I had already checked, and now double checked) however unfortunately what is not clear is that when XtraDB Cluster is updated it also updates several other components with their own changelogs
- Percona Server (5.6.43-84.3)
- Codership WSREP API (5.6.42)
- Codership Galera (3.25)
So to find the specific bug fix we would need to analyse all 3 changelogs.
Will look at either if that is feasible or if we can justify a microversion update exception since that has already been done at least once.
Note that some components are in a separate source package, i.e. percona-galera
Mario advised me that he tested the latest upstream Percona XtraDB Cluster 5.6 release (5.6.43-28.32) against his reproducer (using openstack rally) which causes foreign key violations even with wsrep_slave_ threads= 1 that it does not reproduce on the latest upstream release.
There is no clear changelog entry in the XtraDB Cluster changelog itself detailing this (I had already checked, and now double checked) however unfortunately what is not clear is that when XtraDB Cluster is updated it also updates several other components with their own changelogs
- Percona Server (5.6.43-84.3)
- Codership WSREP API (5.6.42)
- Codership Galera (3.25)
So to find the specific bug fix we would need to analyse all 3 changelogs.
Will look at either if that is feasible or if we can justify a microversion update exception since that has already been done at least once.
Note that some components are in a separate source package, i.e. percona-galera