> simply restore pre-upgrade copy of the DB What about the data manually changed in-between? What if you've been running for a week before discovering a critical issue requiring rollback? All those changes would be lost?
On Fri, Oct 19, 2018 at 8:07 AM Dave Neuman <neu...@apache.org> wrote: > I think this sounds reasonable assuming we work out the details later. > +1 > > On Fri, Oct 19, 2018 at 07:59 Dave Cardosi (dcardosi) > <dcard...@cisco.com.invalid> wrote: > > > +1 > > > > On 10/18/18, 7:49 PM, "Rawlin Peters" <rawlin.pet...@gmail.com> wrote: > > > > >I'd like to propose we drop support for `goose down` in terms of doing > > >a Traffic Ops downgrade. > > > > > >Right now whenever you upgrade Traffic Ops you also need to run > > >`db/admin.pl upgrade` to migrate the DB to the latest version. This > > >step runs all unapplied migrations since the last DB migration was > > >applied. However, if something goes wrong with the deploy and TO needs > > >to be rolled back, you have to run `db/admin.pl down` X times if your > > >TO upgrade ran X migrations in order to get back to the pre-upgrade > > >state of the DB. There are also certain steps in `db/admin.pl upgrade` > > >that cannot be reversed with a `goose down`, because they are done in > > >patches.sql or seeds.sql. So even if you `db/admin.pl down` the > > >correct number of times to get back to the _original_ schema version, > > >it's likely that your data has actually changed irreversibly (but > > >maybe not in a very bad way). > > > > > >A much safer alternative to `db/admin.pl down` is to simply restore a > > >pre-upgrade copy of the DB. I think we should make that the > > >"supported" DB rollback process rather than the `goose down`. For dev > > >purposes I think it's fine to still include `goose down` steps in your > > >migrations, but I think we should build pre-upgrade DB copying into > > >the official upgrade process as well as restoration of the pre-upgrade > > >DB on rollback. > > > > > >Manually saving off a copy of the pre-upgrade DB should already be a > > >step in everyone's TO upgrade process, but I'm proposing we actually > > >build this functionality into the upgrade process itself, drop support > > >for `goose down`, and add support for DB restoration upon rollback. > > > > > >Initially I'd like to just get +1/-1 on this proposal, then we can > > >follow up and figure out the best way to implement it. > > > > > >- Rawlin > > > > >
