From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id drhTFKRNZ18mIwAA0tVLHw (envelope-from ) for ; Sun, 20 Sep 2020 12:40:04 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id UP+WD6RNZ19dVwAAB5/wlQ (envelope-from ) for ; Sun, 20 Sep 2020 12:40:04 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C05F09403C9 for ; Sun, 20 Sep 2020 12:40:03 +0000 (UTC) Received: from localhost ([::1]:48360 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJydN-0000HT-7y for larch@yhetil.org; Sun, 20 Sep 2020 08:40:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJydE-0000HC-UZ for guix-devel@gnu.org; Sun, 20 Sep 2020 08:39:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34219) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJydA-0006NQ-Pc for guix-devel@gnu.org; Sun, 20 Sep 2020 08:39:52 -0400 Received: from ti0006q161-3115.bb.online.no ([88.95.106.80]:36292 helo=localhost) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJydA-0006IV-9u for guix-devel@gnu.org; Sun, 20 Sep 2020 08:39:48 -0400 From: Marius Bakke To: guix-devel@gnu.org Subject: Running service migrations during upgrades Date: Sun, 20 Sep 2020 14:39:45 +0200 Message-ID: <87o8m062r2.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -3.11 X-TUID: YhzqRgQAMqY9 --=-=-= Content-Type: text/plain Hello Guix, Some services require administrator interaction when they are updated. The most prominent examples here are MySQL/MariaDB and PostgresQL. For the former, running 'mysql_upgrade' in-place is generally sufficient and fairly safe. For the latter, the procedure is more involved, and requires making a full backup, as well as access to the old _and_ new PostgreSQL packages. 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. 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. How do other distros deal with this? On a related note, a 'herd backup' action might be a prerequisite for doing such potentially dangerous operations... I will try to add a 'mysql_upgrade' pass to 'mysql-service-type' in time for the MariaDB upgrade, but tips regarding backups, potential pitfalls, and especially Postgres welcome. PS: I'm mostly busy for some time still, but can be reached on #guix or by private email if you want my feedback on something. :-) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl9nTZEACgkQoqBt8qM6 VPpZZwgAvdCisFXp0EgFfIlIkQCG6t/TeO3Ud+MTSY4VVGdqMNUz5MDdtrICSznC oQ23YiTUGHXmq13tCCPl57gOeAnRnw7M19ssg4Sn3nyWtt+/4xgrkcvC/BTgJA/K vmM1qNiwHuqxWAJzqjus4frrF6qlw2j7LehRiE4QV9LA0azi/a1KxG3ptX9+ULHn GxxIQypzCXey3WHLowMDkqGQjZxYCMXDDm6qqy4a/gPRWGOAcC7cctTl9b+oSQn1 WVFIgMr7jXh3NlWrGJyul/WcUEZCahCVy7APLlswq9+V28AVdHj2hrFvseTfyqYf NlJal67US57DxBSorl1KGBS5QAuTSg== =kMer -----END PGP SIGNATURE----- --=-=-=--