#At file:///home2/mydev/bzrroot/mysql-5.6-backup-backport-ms09-2/ based on revid:thavamuni.alagu@stripped
3050 Ingo Struewing 2010-01-11
WL#5101 - MySQL Backup back port
Merged revid:ingo.struewing@stripped
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.
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.
@ storage/heap/ha_heap.cc
WL#5101 - MySQL Backup back port
Bug#47484 - Online Backup: Restore does not
set the auto_increment value correctly
Fixed the value assignment to HP_SHARE::auto_increment
in ha_heap::reset_auto_increment().
@ storage/heap/hp_open.c
WL#5101 - MySQL Backup back port
Bug#47484 - Online Backup: Restore does not
set the auto_increment value correctly
Added DBUG.
modified:
storage/heap/ha_heap.cc
storage/heap/hp_open.c
=== modified file 'storage/heap/ha_heap.cc'
--- a/storage/heap/ha_heap.cc 2009-12-05 01:26:15 +0000
+++ b/storage/heap/ha_heap.cc 2010-01-11 15:31:28 +0000
@@ -406,7 +406,10 @@ int ha_heap::info(uint flag)
stats.max_data_file_length= hp_info.max_records * hp_info.reclength;
stats.delete_length= hp_info.deleted * hp_info.reclength;
if (flag & HA_STATUS_AUTO)
+ {
stats.auto_increment_value= hp_info.auto_increment;
+ DBUG_PRINT("heap", ("autoinc: %lu", (ulong) stats.auto_increment_value));
+ }
/*
If info() is called for the first time after open(), we will still
have to update the key statistics. Hoping that a table lock is now
@@ -447,7 +450,12 @@ int ha_heap::delete_all_rows()
int ha_heap::reset_auto_increment(ulonglong value)
{
- file->s->auto_increment= value;
+ /*
+ The heap share holds the last used auto_increment value.
+ See heap_info() and ha_heap::create().
+ */
+ file->s->auto_increment= value ? value - 1 : 0;
+ DBUG_PRINT("heap", ("autoinc: %lu", (ulong) file->s->auto_increment));
return 0;
}
=== modified file 'storage/heap/hp_open.c'
--- a/storage/heap/hp_open.c 2009-12-05 01:26:15 +0000
+++ b/storage/heap/hp_open.c 2010-01-11 15:31:28 +0000
@@ -53,9 +53,11 @@ HP_INFO *heap_open_from_share(HP_SHARE *
#ifndef DBUG_OFF
info->opt_flag= READ_CHECK_USED; /* Check when changing */
#endif
- DBUG_PRINT("exit",("heap: 0x%lx reclength: %d records_in_block: %d",
- (long) info, share->reclength,
- share->block.records_in_block));
+ DBUG_PRINT("exit",("heap: %p reclength: %d records_in_block: %d "
+ "autoinc: %lu",
+ info, share->reclength,
+ share->block.records_in_block,
+ (ulong) share->auto_increment));
DBUG_RETURN(info);
}
Attachment: [text/bzr-bundle] bzr/ingo.struewing@sun.com-20100111153128-01fs7t6tmv4d64ci.bundle
Thread |
---|
• bzr commit into mysql-backup-backport branch (ingo.struewing:3050)Bug#47484 WL#5101 | Ingo Struewing | 11 Jan |