STATUS
------
Approved.
COMMENTARY
----------
[general audience] We should strive to use 'MySQL Backup' and avoid
using 'Online Backup' for documentation of any kind. I'd also suggest we
correct it whenever it appears. The name of the product was changed to
'MySQL Backup' some time ago.
SUGGESTIONS
-----------
Would the test benefit from being placed in the backup_engines suite?
DETAILS
-------
> Bug#47484 - Online Backup: Restore does not
> set the auto_increment value correctly
>
> When implementing the new locking scheme for RESTORE,
> the table's auto_increment values won't be restored.
> The new scheme contains TRUNCATE, which resets the
> auto_increment values to zero. This will lead to a
> "duplicate key" error on the next attempt to insert
> an auto_increment value, at least for the InnoDB
> storage engine.
>
> This patch arranges for a reset of the values to
> what they were at backup time. The auto_increment
> value of each table is stored at the end of the
> table data stream in its own chunk.
>
> Note that this is done for the default- and
> consistent snapshot drivers only. The MyISAM native
> driver restores the value on its own already.
>
> Note that there is a chance that the restored
> auto_increment value can be higher than at the
> validation point of BACKUP. Concurrent DML on a table
> backed up with the consistent snapshot driver can
> increase the auto_increment value before the driver
> reads it. Since we do not guarantee gap free
> auto_increment values, I consider this as acceptable.
> At least this patch assures that the values cannot be
> lower.
Is there no way to capture it at VP time and save it later?
>
> Note that the patch does also contain a fix to the
> MEMORY storage engine. ha_heap::reset_auto_increment()
> assigned the value incorrectly. This has not been
> noticed yet because the only use case of the method
> was to reset the value to zero.
...
Chuck
