This is patch for the https://jira.mariadb.org/browse/MDEV-9519 issue:

If we have a 2+ node cluster which is replicating from an async master
and the binlog_format is set to STATEMENT and multi-row inserts are executed
on a table with an auto_increment column such that values are automatically
generated by MySQL, then the server node generates wrong auto_increment
values, which are different from what was generated on the async master.

The causes and fixes:

1. We need to improve processing of changing the auto-increment values
after changing the cluster size.

2. If wsrep auto_increment_control switched on during operation of
the node, then we should immediately update the auto_increment_increment
and auto_increment_offset global variables, without waiting of the next
invocation of the wsrep_view_handler_cb() callback. In the current version
these variables retain its initial values if wsrep_auto_increment_control
is switched on during operation of the node, which leads to inconsistent
results on the different nodes in some scenarios.

3. If wsrep auto_increment_control switched off during operation of the node,
then we must return the original values of the auto_increment_increment and
auto_increment_offset global variables, as the user has set. To make this
possible, we need to add a "shadow copies" of these variables (which stores
the latest values set by the user).

1 files changed, 28 insertions, 3 deletions

diff --git a/sql/handler.cc b/sql/handler.cc
index 9c319b995da..e2690023807 100644
--- a/sql/handler.cc
+++ b/sql/handler.cc
@@ -2853,9 +2853,15 @@ compute_next_insert_id(ulonglong nr,struct system_variables *variables)
     nr= nr + 1; // optimization of the formula below
   else
   {
+    /*
+       Calculating the number of complete auto_increment_increment extents:
+    */
     nr= (((nr+ variables->auto_increment_increment -
            variables->auto_increment_offset)) /
          (ulonglong) variables->auto_increment_increment);
+    /*
+       Adding an offset to the auto_increment_increment extent boundary:
+    */
     nr= (nr* (ulonglong) variables->auto_increment_increment +
          variables->auto_increment_offset);
   }
@@ -2911,8 +2917,14 @@ prev_insert_id(ulonglong nr, struct system_variables *variables)
   }
   if (variables->auto_increment_increment == 1)
     return nr; // optimization of the formula below
+  /*
+    Calculating the number of complete auto_increment_increment extents:
+  */
   nr= (((nr - variables->auto_increment_offset)) /
        (ulonglong) variables->auto_increment_increment);
+  /*
+    Adding an offset to the auto_increment_increment extent boundary:
+  */
   return (nr * (ulonglong) variables->auto_increment_increment +
           variables->auto_increment_offset);
 }
@@ -3134,10 +3146,23 @@ int handler::update_auto_increment()
   if (unlikely(tmp))                            // Out of range value in store
   {
     /*
-      It's better to return an error here than getting a confusing
-      'duplicate key error' later.
+      first test if the query was aborted due to strict mode constraints
+    */
+    if (thd->killed == KILL_BAD_DATA ||
+        nr > table->next_number_field->get_max_int_value())
+      DBUG_RETURN(HA_ERR_AUTOINC_ERANGE);
+
+    /*
+      field refused this value (overflow) and truncated it, use the result of
+      the truncation (which is going to be inserted); however we try to
+      decrease it to honour auto_increment_* variables.
+      That will shift the left bound of the reserved interval, we don't
+      bother shifting the right bound (anyway any other value from this
+      interval will cause a duplicate key).
     */
-    result= HA_ERR_AUTOINC_ERANGE;
+    nr= prev_insert_id(table->next_number_field->val_int(), variables);
+    if (unlikely(table->next_number_field->store((longlong) nr, TRUE)))
+      nr= table->next_number_field->val_int();
   }
   if (append)
   {