Подумайте, что записывается в двоичный журнал.
Вы не можете гарантировать, что для ордера, созданного на ведущем устройстве, будет сгенерирована та же последовательность для него, когда транзакция воспроизводится на ведомом устройстве или, что гораздо более вероятно, другим ведущим устройством в кластере. например,
0) Node 1 and Node 2 are in sync, NextOrderNumber=100
1) Node 1 receives insert statement wrt order from customer A and assigns
order number 100, changes its NextOrderNumber to 101
2) Node 1 writes the settings update to the log
3) Node 1 writes the insert statement to the log
4) Node 2 processes for customer B, asigns order number 100 and increments
5) Node 2 writes the settings update from to the log
6) Node 2 writes the insert statement to the log
7) Nodes 2 reads settings update from the log @2
- Its NextOrderNumber is now 102
8) Node 2 reads insert from log @3, tries to apply it but it fails
due to duplicate key
9) Node 1 reads the update @5 - Its nextOrderNumber is also now 102
10) Node1 reads insert from log @6 -
but this fails due to duplicate key
Теперь заказы 100 на 2 узлах относятся к разным данным, и порядка 101 нет.
Существует причина, по которой было добавлено множество функций для изменения поведения переменных auto_increment.
Если вы вставляете вставку в процедуру, которая извлекает значение из генератора последовательности, а затем встраивает его в оператор вставки, немедленная проблема будет решена, однако вам нужно подумать о том, как избежать присвоения одного и того же номера дважды, используя разные узлы базы данных.