[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Running service migrations during upgrades
From: |
Ludovic Courtès |
Subject: |
Re: Running service migrations during upgrades |
Date: |
Wed, 30 Sep 2020 19:33:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi!
Marius Bakke <marius@gnu.org> skribis:
> There is a patch to update MariaDB here:
>
> https://issues.guix.gnu.org/43355
>
> Users of mysql-service-type will need to run 'mysql_upgrade' afterwards.
>
> I have been considering adding an AUTO-UPGRADE? parameter of
> mysql-service-type that runs 'mysql_upgrade' as part of the activation
> script.
>
> 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.
Running upgrades in the activation snippet sounds reasonable. If
‘mysql_upgrade’ detects what version it is upgrading from, that’s
perfect. However, the activation snippet runs upon reconfigure even if
the service is not restarted; so you could find yourself running version
N but you’ve just upgraded the database to N+1. The safest way would be
to do that in the ‘start’ method.
But you can also add an ‘upgrade’ action to the service, just like
‘mcron’ has a ‘schedule’ action.
> 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.
One way would be to determine the previous generation number of
/run/current-system and use, say, /var/guix/profiles/system-42-link/bin
as the bindir. Not pretty.
A nicer way would be to add a ‘bindir’ and a ‘datadir’ action to the
postgresql service; the activation snippet could use it to find the
right values.
Thoughts?
Thanks,
Ludo’.