<div dir="ltr">Another issue to consider with regards to backup tables is the length of time that can occur between upgrade and downgrade functionally. What if you upgrade, then see an issue and downgrade in an hour. Is the backup table data still relevant? Would you end up putting stale/broken data back in place because other things changed? At a certain point restore from backup is really the only sane option. That threshold isn't exactly a long period of time.<div>
<br></div><div>Cheers,</div><div>Morgan Fainberg</div><div><br></div><div>IRC: morganfainberg</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 11, 2013 at 10:30 PM, 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></div>