<div dir="ltr">I can't agree more with Robert.<div><br></div><div>Even if it was possible to downgrade all migrations without data loss, it would be required to make backups before DB schema upgrade/downgrade. </div><div>
<br></div><div>E.g. MySQL doesn't support transactional DDL. So if a migration script can't be executed successfully for whatever reason (let's say we haven't tested it well enough on real data and it's turned out it has a few bugs), you will end up in a situation when the migration is partially applied... And migrations can possibly fail before backup tables are created, during this process or after it.</div>
<div><div><br></div><div>Thanks,</div><div>Roman</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 12, 2013 at 8:30 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think having backup tables adds substantial systematic complexity,<br>
for a small use case.<br>
<br>
Perhaps a better answer is to document in 'take a backup here' as part<br>
of the upgrade documentation and let sysadmins make a risk assessment.<br>
We can note that downgrades are not possible.<br>
<br>
Even in a public cloud doing trunk deploys, taking a backup shouldn't<br>
be a big deal: *those* situations are where you expect backups to be<br>
well understood; and small clouds don't have data scale issues to<br>
worry about.<br>
<br>
-Rob<br>
<br>
-Rob<br>
<div class="HOEnZb"><div class="h5"><br>
On 12 September 2013 17:09, Joshua Hesketh <<a href="mailto:joshua.hesketh@rackspace.com">joshua.hesketh@rackspace.com</a>> wrote:<br>
> On 9/4/13 6:47 AM, Michael Still wrote:<br>
>><br>
>> On Wed, Sep 4, 2013 at 1:54 AM, Vishvananda Ishaya<br>
>> <<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>> wrote:<br>
>>><br>
>>> +1 I think we should be reconstructing data where we can, but keeping<br>
>>> track of<br>
>>> deleted data in a backup table so that we can restore it on a downgrade<br>
>>> seems<br>
>>> like overkill.<br>
>><br>
>> I guess it comes down to use case... Do we honestly expect admins to<br>
>> regret and upgrade and downgrade instead of just restoring from<br>
>> backup? If so, then we need to have backup tables for the cases where<br>
>> we can't reconstruct the data (i.e. it was provided by users and<br>
>> therefore not something we can calculate).<br>
><br>
><br>
> So assuming we don't keep the data in some kind of backup state is there a<br>
> way we should be documenting which migrations are backwards incompatible?<br>
> Perhaps there should be different classifications for data-backwards<br>
> incompatible and schema incompatibilities.<br>
><br>
> Having given it some more thought, I think I would like to see migrations<br>
> keep backups of obsolete data. I don't think it is unforeseeable that an<br>
> administrator would upgrade a test instance (or less likely, a production)<br>
> by accident or not realising their backups are corrupted, outdated or<br>
> invalid. Being able to roll back from this point could be quite useful. I<br>
> think potentially more useful than that though is that if somebody ever<br>
> needs to go back and look at some data that would otherwise be lost it is<br>
> still in the backup table.<br>
><br>
> As such I think it might be good to see all migrations be downgradable<br>
> through the use of backup tables where necessary. To couple this I think it<br>
> would be good to have a standard for backup table naming and maybe schema<br>
> (similar to shadow tables) as well as an official list of backup tables in<br>
> the documentation stating which migration they were introduced and how to<br>
> expire them.<br>
><br>
> In regards to the backup schema, it could be exactly the same as the table<br>
> being backed up (my preference) or the backup schema could contain just the<br>
> lost columns/changes.<br>
><br>
> In regards to the name, I quite like "backup_table-name_migration_214". The<br>
> backup table name could also contain a description of what is backed up (for<br>
> example, 'uuid_column').<br>
><br>
> In terms of expiry they could be dropped after a certain release/version or<br>
> left to the administrator to clear out similar to shadow tables.<br>
><br>
> Thoughts?<br>
><br>
> Cheers,<br>
> Josh<br>
><br>
> --<br>
> Rackspace Australia<br>
><br>
>><br>
>> Michael<br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>