Introduce wsrep_consistency_policy variable to configure reaction to inconsistency

Bug #1271375 reported by Alex Yurchenko on 2014-01-22
This bug affects 6 people
Affects Status Importance Assigned to Milestone
MySQL patches by Codership
Percona XtraDB Cluster moved to
Status tracked in 5.6

Bug Description

Aborting on inconsistency potentially means downtime. If some inconsistencies may be tolerated (like delete event for a missing row), that may save users some downtime. However even if DELETE of a non-existing row may seem safe to ignore, this is most likely not the only inconsistency in the database and an operation that can't be ignored will soon follow. And that may result in a wrong data sent to client. Generally, the sooner you deal with inconsistency - the better. So this ticket here is to discuss the feasibility and usefulness of ignoring inconsistencies.

Proposed variable name: wsrep_consistency_policy

Possible values:
0 - return error on any inconsistency
1 - warn on DELETE, warn on INSERTing exactly the same row, error on any other inconsistency
2 - warn on DELETE, warn and overwrite on INSERT if there is only one unique key or 1-to-1 row match, error on any other inconsistency
3 - warn and ignore all inconsistencies

Default value: 1

description: updated
Changed in codership-mysql:
status: New → Opinion
Jay Janssen (jay-janssen) wrote :


By "error" in this context, do you mean "WSREP abort"?

Can I suggest that you perhaps add a global status counter to count warnings generated by this setting so they are easy to monitor?

DDL errors (like creating a table already there) are already technically "warning" now, right?

Alex Yurchenko (ayurchen) wrote :

Jay, yes, like that. And yes, I guess error counter status variable should go with that.

tags: added: i39505

Percona now uses JIRA for bug reports so this bug report is migrated to:

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

Other bug subscribers