[debian-mysql] Discussion on handling 5.6 related matters

[Robie Basak]

On Thu, Jul 10, 2014 at 04:24:50PM +0530, Akhil Mohan wrote:
> 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 ?

Only common code, together with any mechanisms that variants wish to
share to meet their own responsibilities.

To be clear, I'm separating policy from mechanism here. Policy remains
the variant packages' responsibilities. This includes everything,
including removing their data directory on purge, etc.

But clearly there will be common code, so I'm proposing a place to put
them - that's all.

Additionally, we will want variants to be able to see other variants for
migration purposes. mysql-defaults is a place where they may cooperate
(via dynamic registration or a static table or whatever) to implement
mechanisms to do so.

But responsibility would still remain with each variant's packaging.

> > 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.

Why? What exactly would break if static meta-data were the only
available mechanism?

> >>  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.

Sure - and where that's sufficient, mysql-defaults won't need to do
anything.

But I imagine there will be common code for poking around (read-only) in
other variants' data directories. mysql-defaults provides a place where
this code can go, instead of being duplicated across all variants'
packaging.

I also wonder about the need to stop a daemon before grabbing its data
directory. Perhaps each variant's packaging will need to provide hooks
so that other variants' packaging can ask it to stop the daemon while
data is read out - and to start the daemon again.

> >>  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.

I think this is fine. If you moved your data directory somewhere else,
you're expected to be able to look after it. If you additionally use the
user account that the packaging provides, and you remove the packaging
such that the user account is deleted, then of course you would expect
the data directory to be cleaned up by root only.

This is no different to what would happen with any other package that
supplies a daemon that writes data that should be persisted. I don't see
this as a MySQL packaging challenge - we should just do what every other
package does.

Have I misunderstood you? If so, can you describe the exact steps and
what's going on with the sysadmin moving things around, and the
packaging creating and deleting user accounts, that leads to the
situation you describe?

> > 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)

Agreed.

>  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.

I think this makes sense. We should probably leave out anything that we
don't expect other variants to use, though.

>  3. server packages will pre-depend on mysql-defaults.

Depend - certainly. I'm not sure about Pre-Depends. Is there a reason
we'll specifically need Pre-Depends?

> 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.

I think so. What exactly am I agreeing to? Maybe we should arrange a
Hangout to go through the details and make sure?

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/20140711/6a01d2fb/attachment.sig>