[debian-mysql] Discussion on handling 5.6 related matters

[Akhil Mohan]

On Thursday 10 July 2014 01:48 AM, Robie Basak wrote:
> 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.
But then what else remains for mysql-defaults to handle ?
>
> 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).
Need of dynamic meta-data is needed because of manual steps. If we can
make migration completely automatic then static meta-data would be
sufficient.
>
>>  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.
Yes, thanks for clarification.
>
>>  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?
Yes, thanks for clarification.
>
>>  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.
But all variants by themselves can give read-only access to their
specific data dirs like we have for /var/lib/mysql currently.
>
> 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 is okay for migration, but while removing a variant, if default data
dir is not present, then as per the current logic during post removal
the user account will be removed. Since same user would be used for
custom data dir, it will make that dir completely inaccessible.
>
> 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
If you agree then we can work on initial prototype to see how your
proposal works and then improve it further as needed. I can try to setup
a temp repo with the new set of packages for everyone to review and
comment. Initially we may delegate following responsibilities to
mysql-defaults:

 1. It will breaks/ replaces existing MySQL 5.5 and 5.6 packages. (I am
    limiting to MySQL for POC)
 2. IIUC, it will contain shared scripts to manage data dir, user
    accounts, permissions etc that would be called from
    mysql-server-5.x.postinst.
 3. server packages will pre-depend on mysql-defaults.

Please let me know if you agree for prototype implementation. I
apologise if I am burdening you by asking again but I want you to review
the list above and modify as per your proposal in mind so that we are
sure efforts would go in right direction.

Regards,
Akhil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20140710/c9ef24a6/attachment-0001.html>