You are right again - the metadata is written before tables are locked (in
Backup_restore_ctx::do_backup() the write_preamble() call, while table
locking happens in write_table_data() call).
What about CS driver and online operations. If there are concurrent
transactions inserting data into a table changing its AUTO_INCREMENT, we
should be careful to save/restore its value from the validity point time.
Since creating a VP is the responsibility of a backup driver, this indicates
that handling AUTO_INCREMENT should be left to the drivers I think.
Ingo Strüwing wrote:
> Hi Rafal,
> Rafal Somla, 22.09.2009 11:23:
>> No, I did not understand your suggestion completely. Indeed, for each
>> table there is extra_data field in the metadata record for that table
>> and it could be used for storing AUTO_INCREMENT value. Then the general
>> handling of AUTO_INCREMENT could be implemented without changing current
>> image format. In that case I think it is a better alternative than my
> I was so happy that I could make a point. However, I stumbled over a
> problem, which might invalidate it.
> Since backup shall work "online", the auto_increment value can change
> while the backup is going on. The only safe moment to grab the value
> would be the lock phase. The meta data section is written before table
> data backup does even start.
> I just wonder if the default and cs drivers lock the tables from changes
> before or after the meta data section is written. If they do it before,
> my idea could be modified to require auto_increment value backup from
> the native drivers and do it in meta data only for the default and cs
> drivers. If not, we need to go with your suggestion.