From: Charles Bell
Date: July 28 2009 2:30pm
Subject: Re: Please advise [Re: Restore locking: TRUNCATE resets AUTO_INCREMENT
 on InnoDB]
List-Archive: http://lists.mysql.com/backup/14
Message-Id: <4A6F0B99.4050607@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
Content-Transfer-Encoding: 7BIT

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