We have built-in support for rolling back the TO DB via `goose down`, but no built-in support for backing up the DB at pre-upgrade and pre-rollback steps. We should do those automatically but also improve the db/admin.pl tooling to support restoring backup DBs as a standard process rather than as something that should just be done as a documented best practice.
On Fri, Oct 19, 2018 at 1:49 PM Gray, Jonathan <[email protected]> wrote: > > I don't believe it should be the responsibility of ATC to perform the > functions of a DBA. Postgres should be treated as a 3rd party dependency > with independent skills & professional administrators performing industry > standard practices. You should add to your documentation to ensure safe > state is achieved by whatever means their environment defines. By adding > implementation logic, you also accept maintenance and potential > incompatibility with regard to adopter's existing practices. > > Jonathan G > > On 10/19/18, 10:50 AM, "Rawlin Peters" <[email protected]> wrote: > > On Fri, Oct 19, 2018 at 8:33 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. > > I would like to make the DB backups happen automatically at the > pre-upgrade and pre-rollback steps with a handy utility to restore a > certain backed-up version of the DB. I'm not sure the DB restore > itself should be done automatically on a `yum downgrade`, however, > unless we also automatically do the DB upgrade on a `yum upgrade`. > But, those are implementation details I think we can hash out later > once we've decided if this is a good idea or not. > > - Rawlin > >
