[debian-mysql] Redesigning the /var/lib/mysql/*.flag thing

[Robie Basak]

On Mon, Oct 05, 2015 at 02:40:53PM +0300, Otto Kekäläinen wrote:
> 2015-10-05 12:06 GMT+03:00 Robie Basak <robie.basak at canonical.com>:
> > Separate from this I think that a user should always explicitly choose
> > before migrating data that cannot automatically be reverted when moving
> > between variants, but that would be easy enough to do with debconf if we
> > had separate variant and disk version directories.
> 
> I had in mariadb-server for a while a "are you sure?" dialog, but it
> sucked because if people choose No, then dpkg would abort and be in an
> unclean state, just like the downgrade warning does. We should not
> have any upgrade/downgrade warning at least build at debconf/dpkg
> level.

If were to implement my proposal, then the debconf option wouldn't a
simple yes/no any more. As an example, if the user had MySQL 5.6 and
were switching to MariaDB 10.0, we could prompt with multiple choices
(we can work out the exact text and UX flow later):

1) Move the existing MySQL 5.6 database to MariaDB 10.0 and crossgrade
it (irreversible).

2) Copy the existing MySQL 5.6 database to MariaDB 10.0 and crossgrade
it (reversible in that the user could go back to MySQL 5.6 and the
database would just go back in time).

3) Start a fresh MariaDB 10.0 database without impacting the MySQL 5.6
database at all.

>From a disk space perspective, only option 2 really requires much space,
and it should be relatively easy to warn the user or not present the
option at all if it looks like it is unlikely to succeed.

I think this eliminates potential for a dpkg abort and broken state,
since not proceeding no longer needs to be an option. The user can
always just choose option 3 instead, which will always be safe.

> Also I don't think that copying original data would work, as in many
> cases there isn't enough diskspace for such an action, and if it is a
> production database, then you don't want to use an old database with
> old data in any case either.

It doesn't have to be mandatory. What I don't want is users
inadvertently crossgrading automatically when the reverse must be
manual, since this is asymmetric. What happens if the user tries to then
switch back to MySQL after a crossgrade? Now the mysql-server postinst
must fail and leave dpkg in a broken state, or try to start the database
and potentially leave that in a broken state, and I get bug reports.

So I want users to at least have the option of doing 1 or 3 if they are
experimenting. Using a single /var/lib/mysql is what makes this
impossible.

Further, if the user then switches back to MySQL 5.6 having picked
option 1 previously, then we can just display a debconf note with
information on crossgrading back manually if desired and provide an
empty database. Nothing will break.

> I think that it would be fair to assume that users know enough about
> their database files and have backups / database dumps made in case
> they are working with production databases and they care about their
> database contents.

I don't think this is a safe assumption. I see many bug reports from
users who aren't doing this. I think many might be desktop users who are
experimenting with web apps (LAMP stack, etc) who aren't running a
production system but are experimenting with variants. My proposal
covers this class of users, too.

In short my proposal makes all of the options available to us. Without
it, we're stuck with hacks.

Robie