I'm -1 on this. In the event you're doing some massaging of commits and migrations are missed due to the dependence on timestamps in filenames, "goose down" allows you to fix the data.
Jonathan G On 10/19/18, 8:34 AM, "Gelinas, Derek" <[email protected]> wrote: I'm plus one on this if we add an automatic DB backup during install and a restore utility. Derek On Oct 19, 2018, at 10:31 AM, Robert Butts <[email protected]> wrote: >> 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 <[email protected]> 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) >> <[email protected]> wrote: >> >>> +1 >>> >>>> On 10/18/18, 7:49 PM, "Rawlin Peters" <[email protected]> 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 >>> >>> >>
