unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: Marius Bakke <marius@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Running service migrations during upgrades
Date: Fri, 02 Oct 2020 19:56:59 +0100	[thread overview]
Message-ID: <87ft6w1mo4.fsf@cbaines.net> (raw)
In-Reply-To: <87o8m062r2.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3033 bytes --]


Marius Bakke <marius@gnu.org> writes:

> Some services require administrator interaction when they are updated.
> The most prominent examples here are MySQL/MariaDB and PostgresQL.

...

> Another approach is adding a 'herd upgrade' Shepherd action along with a
> news entry describing what to do.  Of course it is possible to do both,
> having 'auto-upgrade?' _and_ a Shepherd action for manual upgrades.
>
> Thoughts?
>
> While that works for MariaDB, I'm not sure what to do about Postgres.
> For those unfamiliar, the procedure for upgrading from PostgreSQL 10
> (current default) to 11 (available in Guix) is roughly:
>
>   sudo cp -a /var/lib/postgresql/data /var/lib/postgresql/data10
>   sudo -u postgres $(guix build postgresql)/bin/pg_upgrade \
>     --old-bindir=$(guix build postgresql@10)/bin \
>     --new-bindir=$(guix build postgresql)/bin \
>     --old-datadir=/var/lib/postgresql/data10 \
>     --new-datadir=/var/lib/postgresql/data
>
> In order to automate it, we need to somehow preserve the "previous"
> version of PostgreSQL so that we can reach it when the major version
> changes.  Or add an 'upgrade-from' parameter to
> postgresql-service-type.

Hi!

I'm really glad you're thinking about this Marius, I've got a few
PostgreSQL clusters running with postgresql@10 that I'd like to upgrade,
so this is very interesting.

Reading through the documentation on pg_upgrade, it suggests the new
cluster should be initialised as part of the process [1]. Maybe leaving
the old files in place is sometimes/always sufficient, I'm unsure?

1: https://www.postgresql.org/docs/11/pgupgrade.html#id-1.9.5.11.7

One approach I have in mind:

 - Make the postgresql package explicit in the configuration

   - This avoids the current situation where changing the major version
     of the postgresql package would cause PostgreSQL not to start when
     reconfigured.

 - Somehow include the major version in the data directory name

   - So rather than /var/lib/postgresql/data it should be
     /var/lib/postgresql/10, /var/lib/postgresql/data/10 or something
     like that.

 - Add a upgrade-from field to the postgresql service configuration,
   this takes a postgresql package, which is used for the old-bindir
   when doing the upgrade

 - Add a shepherd action to call pg_upgrade

I think if all the above things are done, you could end up with a
process like:

(service postgresql-service-type
         (postgresql-configuration
          (postgresql postgresql-10)))

 ->

(service postgresql-service-type
         (postgresql-configuration
          (postgresql postgresql-11)
          (upgrade-from postgresql-10)))

Assuming the data directory default includes the major version, when
reconfiguring you'd go from running version 10, to an empty version 11.

Then running herd upgrade postgres would stop the service, and run
pg_upgrade.

I started sketching out some patches to at least make the postgresql
package explicit in the configuration [2.

2: https://issues.guix.info/43771


Thanks again,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

      parent reply	other threads:[~2020-10-02 18:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-20 12:39 Running service migrations during upgrades Marius Bakke
2020-09-20 20:53 ` Efraim Flashner
2020-09-21 13:08 ` Alex Sassmannshausen
2020-09-30 17:33 ` Ludovic Courtès
2020-10-02 18:56 ` Christopher Baines [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ft6w1mo4.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=guix-devel@gnu.org \
    --cc=marius@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).