Re: Please advise [Re: Restore locking: TRUNCATE resets AUTO_INCREMENT on InnoDB]

[Charles Bell]

Ingo,

>>> A) Explicitly transport the auto_increment value.
>>>    A.1) Since the value is part of the meta data of a table in the
>>>         backup image, we could modify si_objects to save the value
>>>         in a context object so that the value used to create the last
>>>         table can be queried from si_objects. However, this means that
>>>     si_objects will have to parse the serialization string.
>> I want to note that A.1) might be possible without parsing the
>> serialisation string (I mean, parsing the CREATE TABLE statement). Since
>> serialization string produced by si_objects can consist of several
>> sub-strings, it is possible that the value of auto_increment is appended
>> to it in a form which is easy to retrieve at restore time.
> 
> Ok, but current backup images don't have that. What do you suggest
> regarding treatment of old images?

Ok, So I'm reading through this thread and I start to wonder ... since 
we're using InnoDB which uses the row-level insert mechanism of the 
default drivers, what do the rows in the backup image file contain for 
the auto increment column? I think it would be helpful to see a dump of 
a row to see if the auto increment value is in there.

Chuck