[debian-mysql] Discussion on handling 5.6 related matters

[Robie Basak]

On Wed, Jul 09, 2014 at 02:52:03PM +0300, Otto Kekäläinen wrote:
> I don't think we need co-installability, as admins are likely to pick
> just on variant and then run it..?

There are bugs filed in Launchpad that seem to have been triggered
because users are trying to switch between variants, and /var/lib/mysql
has confused matters. This is what I'd like to fix properly.

I suppose co-installability isn't preciely what I'm looking for, but
co-installability capability will mean that what I'm looking for is met.

Exactly what I think I want is the ability for users to be able to
switch between variants at will without anything screwing up. So, for
example, the ability to switch from MySQL to MariaDB, and then switch
back to MySQL for whatever reason later.

>                                    Only one kind of server can listen
> at port 3306 per server

True, but I think that with separate data and config directories this
would be the only point of contention. I think it can be handled quite
easily with a mediating mysql-defaults package. It could manage which
server should start by default, for example, and the other variants
could have their postinsts dynamically suppress daemon startup if other
variants are installed and its own variant is not marked as the default
(pending user configuration to a different port, etc).

>                         The only case where co-installation is perhaps
> needed, is to be able to run a database dump from one
> binary-incompatible format to import to another server due to
> migration purposes.

This assumes that the user only has one database-using application
installed on the system.

What if the user wants to run two different webapps, and each is
optimised against a different variant?

> I think the primary motivation here is to make installation safer and
> with separation of data dir, admins are less likely to accidentally
> "reformat" their database files binary format into a new version that
> inhibits reverting back to old server version.

Agreed. Another motivation though is that admins can freely switch
between variants without things screwing up.

>                                                But that would indeed
> require that the data files are copied to a new datadir, and not
> renamed.

I proposed renaming for the special case of the one-time move from
the confused /var/lib/mysql to your preferred variant's directory, where
it's binary compatible, as a solution for Akhil's concern about the
migration time for a copy.

I do not propose renaming from anything but /var/lib/mysql, once.

>          And I don't think we can assume that all servers have enough
> disk space to have duplicate db data?

I think that this is an acceptable constraint. Maintainer scripts can
only automatically do so much.

To demonstrate an example, let's say we implement my proposal in full,
and I upgrade to MySQL 5.6 with this new mechanism implemented. At this
time, /var/lib/mysql will change (whether copied or renamed) to
/var/lib/mysql-5.6 (or some other name, I don't care). /var/lib/mysql
will no longer exist.

The data is big, and there isn't enough space for another copy.

The user now wishes to switch to MariaDB.

What I propose is:

1. The user installs the MariaDB package, which does not conflict or break
or replace the MySQL package.

2. The postinst discovers that another variant is present, and that
migration is possible. The user can select (via debconf) between
starting fresh, or migrating (ie. forking the data) automatically.

2a. Migrating automatically would copy /var/lib/mysql-5.6 to
/var/lib/mariadb-10 (or whatever name is used). There isn't enough space
for this. A smart migration script would not present this option via
debconf, or try to migrate and fail, or whatever. So the user cannot do
this in this specific case.

2b. The user selects to start fresh.

Through mysql-defaults, the postinst discovers that another variant is
installed and MariaDB isn't the default for listening on the network
port, so it cannot start the daemon by default. So it does not, and
recommends to the user (to stdout) to run some update-alternatives-like
thing that mysql-defaults provides to change the default. The postinst
succeeds.

3. The user manually does what he wants.

3a. He could, for example, remove (not purge) the mysql-5.6 package,
remove /var/lib/mariadb-10, rename /var/lib/mysql-5.6 to
/var/lib/mariadb-10, start the mariadb daemon and then purge mysql-5.6.

3b. Or he could free up enough space, copy /var/lib/mysql-5.6 to
/var/lib/mariadb-10, change the configuration of MariaDB to listen on a
different port, then start the MariaDB daemon concurrently.

Now consider the state of the system. It's completely clean, and the
user got what the specific behaviour he wanted.

He did have to do something manually, but I don't think the maintainer
scripts can cater for every conceivable case. What's important is that
the maintainer scripts allowed the user to do what he wanted without
erroring, and it was not particularly confusing to follow since the
migration mechanism is so simple (each package owns its own directory,
and other packages are permitted to read only).


Alternatively, if there was enough space, then automatically he'd have
got a migration if he wanted, forking the database data. I think this
makes sense, as it's the simplest, most obvious thing to do that does
not lose user data even if he doesn't quite understand what he's doing.

Additionally, in the automatic case the user does not need to understand
binary compatibility between variants.

> What if we just put a big bold warning in the installer that
> installing package X will do a possibly one-way migration for the data
> files? Or install new servers with empty databases and notify the user
> they need to run either cp X Y or mv X Y to copy or migrate the data?

I still want to require that the data files be cloned in the case of
doing a one-way migration.

Otherwise you really need to require that the variant being superceded
is removed and purged, dynamically and as part of the migration, based
on what the user wanted to do. I think this is impossible to implement
under current packaging policy.

If you do not do this, then the variant that has been superceded appears
to still be installed, and then you end up with the mess that we
currently have.

Data directories must have clear variant ownership, and that means that
one variant doing a one-way migration to another variant's data must be
unacceptable.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20140709/61fe9194/attachment.sig>