Some MariaDB users have complained that when upgrading from a MariaDB 10.1 to MariaDB 10.2+
some tables has generated wrong auto_increment values after the upgrade.

The reason is probably that the area that InnoDB uses to store auto_increment in 10.2.4 and above can in some cases contain 'not cleared data', which causes the above problem.

The intent of this task is to ensure that when upgrading from MariaDB < 10.2.4 then this area is cleared, which would mean that next generated auto_increment would be max(auto_increment_column) +1

Here follows the suggested way to do this:

Update innodb::check_for_upgrade() as follows:
if the following is true:
table->s->mysql_version < 100204 &&
table->next_number_field;
return HA_ADMIN_NEEDS_UPGRADE
else
return HA_ADMIN_OK

Returning HA_ADMIN_NEEDS_UPGRADE will cause mysqlcheck (part of mysql_upgrade) to call REPAIR and thus innodb::repair() will be called.

In innodb::repair, if the above test in check_for_upgrade() is true
clear the auto_increment area and return HA_ADMIN_OK
else
return HA_ADMIN_NOT_IMPLEMENTED.

if check_for_upgrade() or repair() returns HA_ADMIN_OK then
the current MYSQL_VERSION_ID in the .frm file will be updated
so that the above repair will never be called again for this case.

Upper level change:

Change in handler::ha_repair()

DBUG_ASSERT(result == HA_ADMIN_NOT_IMPLEMENTED ||
ha_table_flags() & HA_CAN_REPAIR);

->

DBUG_ASSERT(result == HA_ADMIN_NOT_IMPLEMENTED ||
result == HA_ADMIN_OK ||
ha_table_flags() & HA_CAN_REPAIR);

The end effect of this change would be that if one runs mysql_upgrade, then any INNODB tables created before 10.2.4 will have it's auto_increment area cleared and the next generated auto_increment value will be max(auto_increment_column) +1