| 2014-01-22 00:02:44 |
Alex Yurchenko |
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 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 |
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 |
|
