MySQLMaxValueIncrementer is not multi-master replication-safe [SPR-14418] #18989
Labels
in: data
Issues in data modules (jdbc, orm, oxm, tx)
status: superseded
An issue that has been superseded by another
type: enhancement
A general enhancement
Tim Gokcen opened SPR-14418 and commented
The Spring
org.springframework.jdbc.support.incrementer
subsystem is used by Spring Batch, among others, to generate increasing "unique" IDs.However,
org.springframework.jdbc.support.incrementer.MySQLMaxValueIncrementer
is not safe to use in multi-master MySQL or MariaDB environments, e.g. master-master replication or MySQL/Galera cluster. This is because of the way in which it always kicks forward last_insert_id() by getCacheSize(), which will result in duplicate IDs across hosts and result in collisions if those IDs are used to, for example, insert rows into a table that has a unique key on the ID.The global MySQL variable
auto_increment_increment
is available and used by clustering systems to ensure that AUTO_INCREMENT columns do not collide across the cluster (see the Galera documentation). The same value could also be used by MySQLMaxValueIncrementer to avoid collisions.In multi-master environments, the cacheSize would also have to always be equal to 1; there is no way to pre-allocate IDs without guaranteeing that they were not already selected by another host.
Alternatively, the whole idea of using the backing RDBMS to generate increasing IDs could be abandoned in favour of generating non-linearly increasing "probably-unique" IDs, as for example in in Twitter Snowflake, which uses a combination of "timestamp + host-ID + thread-ID + counter" to produce a very-likely-to-be-unique 64-bit integer.
Affects: 4.2.6
The text was updated successfully, but these errors were encountered: