Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.4-1
Description
The current auto_increment behavior in the InnoDB engine is sub-optimal. As it currently functions, the auto_increment value is stored until the server shuts down or resets, and then is rebuilt based on values in the table when it starts up again. Furthermore, in 5.6 this ought to become even worse, because tables can be evicted from the InnoDB data dictionary cache. We may get a too low auto-increment value even without shutdown/restart. When a table is evicted, InnoDB will forget the current auto-increment value, and it will do SELECT MAX(auto_inc_column) next time when the table is accessed.
Attachments
Issue Links
- blocks
-
MDEV-11578 Remove the requirement to have an INDEX on AUTO_INCREMENT column
- Open
- causes
-
MDEV-20775 InnoDB: Failing assertion: !page_zip || page_zip_validate(page_zip, page, index)
- Closed
- is duplicated by
-
MDEV-13074 AliSQL: [Feature] Issue #42 Persistent AUTO_INCREMENT value for InnoDB table
- Closed
- relates to
-
MDEV-12123 Page contains nonzero PAGE_MAX_TRX_ID
- Closed
-
MDEV-18288 Transportable Tablespaces leave AUTO_INCREMENT in mismatched state, causing INSERT errors in newly imported tables when .cfg is not used.
- Closed
-
MDEV-20892 AUTO_INCREMENT is set lower than the max value of the primary_key
- Closed
-
MDEV-22357 Clearing InnoDB autoincrement counter when upgrading from MariaDB < 10.2.4
- Open
-
MDEV-26224 InnoDB fails to remove AUTO_INCREMENT attribute
- Closed
-
MDEV-12848 InnoDB: Assertion failure in file mariadb-10.2.5/storage/innobase/handler/ha_innodb.cc line 2780
- Closed
-
MDEV-13094 SHOW CREATE TABLE can report non-persistent AUTO_INCREMENT value before server restart
- Confirmed
-
MDEV-20357 Strange auto_increment counter setting changes on direct upgrade from 10.1 to 10.3
- Closed
-
MDEV-33277 In-place migration from MySQL 5.7 causes invalid AUTO_INCREMENT values
- Closed