database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2026-01-06 05:22:24 +03:00
Code Activity

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

Browse Source 
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).
This commit is contained in:
Julius Goryavsky
2018-07-26 15:04:11 +02:00
committed by Jan Lindström
parent 5960815630
commit 75dfd4acb9
11 changed files with 677 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
sql/handler.cc
View File

@@ -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
*/
result= HA_ERR_AUTOINC_ERANGE;
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).
*/
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)
{