[debian-mysql] Discussion on handling 5.6 related matters

[Robie Basak]

On Thu, Jul 10, 2014 at 12:59:24AM +0530, Akhil Mohan wrote:
>  1. Will purging the server package for each fork trigger removal of
>     data dir or purging mysql-defaults will remove data dir ?

Each variant's server package owns it's corresponding directory. Purging
the package should purge the directory, since nothing else will do it
after it's gone.

mysql-defaults exists only for common code and for coordination between
variants' packages where we think that would be useful. Variants'
packages still do all the work.

It would probably be useful for mysql-defaults to be aware of what is
present, in terms of installed variants, their data directory names and
their capabilities (in terms of migration fork capability and binary
compatibility). I don't know if this should be dynamic (registering with
mysql-defaults and deregistering on purge, etc), or static
(mysql-defaults just looks for data directories and has a static
database of what they mean).

>  2. If the removal is associated with mysql-defaults, then in
>     co-installed setup will mysql-defaults remove all data dirs at once
>     or allow selection ?

N/A - removal happens on purge of individual variant server package
removal.

>  3. If all data dirs will be removed together, then it is possible to
>     accidentally remove more than required. How will we control this ?

Also N/A I think?

>  4. Since user might do manual data dir creation and also add the
>     required entries in config manually so the mysql-defaults package
>     may always not know if data dir is present and might remove user
>     accounts owning the custom data dir leaving data inaccessible. Will
>     we check for only standard data dirs or read them from config files ?

mysql-defaults is just some common ground so that variants' packages can
communicate, for read-only purposes only. mysql-defaults certainly
shouldn't be changing anything.

The way I see it, that reduces your concern to what exists for any other
server package that handles persistent data, and the solutions should be
the same.

>  5. I see possibility of config files getting custom location during
>     manual setup ? Do we see this as trouble ?

If a user repoints the data store to some other directory, then
mysql-defaults may become blind to this. That would rule out automatic
migration fork help, but I don't see that anything else would break. I
think this breakage could be handled gracefully - eg. by detecting that
the directory doesn't exist, and not presenting the option. In the case
of the user having left the original data files there, and running the
database live somewhere else, then the migration would appear to work,
but of course only migrate the files that were in the original
directory. I think this would be fine, and that we can't be expected to
do any better.

It does occur to me that there would be a need to temporarily stop
another variant's daemon during migration, and this breaks the read-only
ness. I don't think this is a showstopper though - we can figure out a
way to handle that.

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/c6e2b523/attachment.sig>