Inconsistency voting is complete in MySQL version, and has been fully integrated in MariaDB 10.4 candidate tree. However, no buildbot testing for this feature has yet been carried out. The related tests are in galera_ee and galera_3_nodes_ee suites.

Yurchenko Yes, we want PR against 10.5

https://github.com/MariaDB/server/pull/1373

High-level decsription.

• For transactions:
  • if applying slave writeset fails (apply callback), error description is passed back to provider and it initiates voting in the group. All nodes report which result they got for a given action, and if there is a simple majority about a given result, then this result wins and the nodes that have a different result gracefully quit the group. If there is no majority then success wins. If there is no node with success result, then some other node wins.
• For TOI operations (DDLs):
  • All the same as for transactions, except that master also may initiate a vote if DDL fails.
• Control:
  • wsrep_ignore_apply_errors bitmask controls whether the error is reported back to provider. E.g. wsrep_ignore_apply_errors=4 will ignore any DDL errors, thus imitating 10.4 behavior. (Otherwise any DDL error will result in a voting round) (a better value would be 1 where only reconciling DDL errors are ignored)
• gcs.vote_policy defines who wins in a voting round:
  • Default value 0 means simple majority as described above. Any value >= 1 means that if success votes count is >= that value, success wins even if in minority. E.g. gcs.vote_policy=1 will imitate current 10.4 behavior, where only the node that successfully committed transaction would remain (the difference would be that in 10.4 it will end up in non-primary configuration, in 10.5 it will remain primary).

jacob.moorman This is feature to 10.5 see above for description. I can give a example if wanted.