On Fri, Sep 13, 2013 at 7:51 AM, Dolph Mathews dolph.math...@gmail.com wrote:
++ Data backups are a solved problem, and no DB admin should trust an
application to perform its own backups.
I'm not completely sure I agree. Consider the case where a cloud with
active users undertakes an upgrade.
On Mon, Sep 16, 2013 at 5:31 AM, Michael Still mi...@stillhq.com wrote:
On Fri, Sep 13, 2013 at 7:51 AM, Dolph Mathews dolph.math...@gmail.com
wrote:
++ Data backups are a solved problem, and no DB admin should trust an
application to perform its own backups.
I'm not completely sure I
On 9/16/13 10:37 PM, Dolph Mathews wrote:
On Mon, Sep 16, 2013 at 5:31 AM, Michael Still mi...@stillhq.com
mailto:mi...@stillhq.com wrote:
On Fri, Sep 13, 2013 at 7:51 AM, Dolph Mathews
dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote:
++ Data backups are a solved
I can't agree more with Robert.
Even if it was possible to downgrade all migrations without data loss, it
would be required to make backups before DB schema upgrade/downgrade.
E.g. MySQL doesn't support transactional DDL. So if a migration script
can't be executed successfully for whatever
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
On Thu, Sep 12, 2013 at 2:34 AM, Roman Podolyaka rpodoly...@mirantis.comwrote:
I can't agree more with Robert.
Even if it was possible to downgrade all migrations without data loss, it
would be required to make backups before DB schema upgrade/downgrade.
E.g. MySQL doesn't support
On 9/4/13 6:47 AM, Michael Still wrote:
On Wed, Sep 4, 2013 at 1:54 AM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
+1 I think we should be reconstructing data where we can, but keeping track of
deleted data in a backup table so that we can restore it on a downgrade seems
like overkill.
I
I think having backup tables adds substantial systematic complexity,
for a small use case.
Perhaps a better answer is to document in 'take a backup here' as part
of the upgrade documentation and let sysadmins make a risk assessment.
We can note that downgrades are not possible.
Even in a public
