Introduce wsrep_consistency_policy variable to configure reaction to inconsistency

[Alex Yurchenko]

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

[Jay Janssen (jay-janssen)]

Neat!

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)]

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

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1171