hholzgra, I think that this should affect an upgrade to 10.2 already, due to MDEV-6076.

I think that the plausible explanation is that the PAGE_MAX_AUTOINC field in some clustered index root pages was not 0, but garbage, before the upgrade. MDEV-6076 repurposed the field PAGE_MAX_TRX_ID, which was previously only used on secondary index leaf pages. Before a bug fix in MySQL 5.1.48, InnoDB could write garbage to unused data fields; since then, such fields are always written as 0.

It should be possible to reset the AUTO_INCREMENT value by a statement like this:

ALTER TABLE t AUTO_INCREMENT = 1;

This should reset the counter to a value that is not smaller than the current maximum in the table.

I will try to double-check if the PAGE_MAX_TRX_ID was always zero-initialized. I seem to remember that I concluded during MDEV-6076 development that it is the case.

As a starting point, I checked out the MySQL 5.1.47 source code. Side note: I had forgotten a glaring bug: changes of the PAGE_MAX_TRX_ID were not being redo-logged in the built-in InnoDB of MySQL 5.1. It was only fixed in the InnoDB Plugin, which became the basis of the InnoDB in the 5.5 release.

In MySQL 5.1.47, page_create() (which is invoked for creating B-tree pages) did always initialize the PAGE_MAX_TRX_ID, so we do know that whenever the field was unused on a B-tree page, it must have been 0:

	page_set_max_trx_id(page, ut_dulint_zero);

This call was present in the very beginning of the InnoDB revision history.

hholzgra, I am afraid that I cannot explain the observed anomaly with a software bug. I would need more information at the very least.

hholzgra, any chance you could provide more infore or should we close it?