bug 11938: don't index usage tables when do upgrade from 2211 to 2212.

status 11938: resolved fixed
reviewed-by: Frank Zhang

This fix would cover following scenario:

* the customer is upgrading from 2.2.11 to 2.2.13.
* the incorrect indexes are being dropped as a part of 2.2.12 to 2.2.13 upgarde, but we still insert them as a part of 2.2.11 to 2.2.12, and it might lead to the db upgrade failure. The only one way to handle this case - remove them from 2.2.11 to 2.2.12 upgrade path
This commit is contained in:
Alena Prokharchyk 2011-11-14 15:54:34 -08:00
parent 96e5abeb89
commit 591ba4f0ae
1 changed files with 1 additions and 4 deletions

View File

@ -42,7 +42,4 @@ ALTER TABLE `cloud_usage`.`usage_network_offering` ADD INDEX `i_usage_network_of
ALTER IGNORE TABLE `cloud_usage`.`usage_vm_instance` ADD UNIQUE (`vm_instance_id`, `usage_type`, `start_date`);
ALTER IGNORE TABLE `cloud_usage`.`usage_ip_address` ADD UNIQUE (`id`, `assigned`);
ALTER IGNORE TABLE `cloud_usage`.`usage_volume` ADD UNIQUE (`id`, `created`);
ALTER IGNORE TABLE `cloud_usage`.`usage_storage` ADD UNIQUE (`id`, `storage_type`, `zone_id`, `created`);
ALTER TABLE `cloud_usage`.`usage_load_balancer_policy` ADD PRIMARY KEY (`id`);
ALTER TABLE `cloud_usage`.`usage_port_forwarding` ADD PRIMARY KEY (`id`);
ALTER IGNORE TABLE `cloud_usage`.`usage_network_offering` ADD UNIQUE (`network_offering_id`, `vm_instance_id`, `created`);
ALTER IGNORE TABLE `cloud_usage`.`usage_storage` ADD UNIQUE (`id`, `storage_type`, `zone_id`, `created`);