[debian-mysql] Discussion on handling 5.6 related matters

[Robie Basak]

Hi Akhil,

On Mon, Jul 07, 2014 at 07:30:59PM +0530, Akhil Mohan wrote:
> Thanks for your response which makes it easier to sort out the priority
> list at this moment. As I get it, I am placing the tasks in order of
> priority below:
> 
>  1. Upgrade Paths:
>      1. Separation of data directory.
>      2. mysql-defaults package should contain common functionality and
>         own data directory as well.
>      3. Handling upgrade scenarios from old format to new format that
>         depends on mysql-defaults.
>  2. Get remaining delta from 5.5 into 5.6 packaging source.
>  3. Import latest released version of 5.6 into experimental and trusty
>     universe.
>  4. Get 5.6 as default in Debian testing and Ubuntu 14.10.

Agreed, and thank you for the summary.

> For now, as you said already, lets discuss on upgrade paths first.
> 
> You proposal looks promising but I suspect that users might find it
> difficult to handle change of data directory location who wish continue
> with MySQL. Moreover, MySQL 5.5 data dir can be directly taken over by
> MySQL 5.6 using simple mysql_upgrade utility as it is being done at this
> moment. There will no need for having separate /var/lib/mysql-5.6 data
> dir for reason of binary incompatibility.

Does this include all variants which uptil now have written to
/var/lib/mysql/ as they wish?

I still don't like the idea of not having a clean break from the former
confusion of ownership of /var/lib/mysql. You might say that MySQL 5.6
owns the directory now, but what stops older versions of (for example)
MariaDB from writing to it? Or are we going to have some kind of
Breaks/Replaces the world and update all variants at once?

> Another trouble that I see with forking the data dir is related to the
> size of data dir. In case user has large data dir that goes into GBs or
> even TBs then the copy would take noticeable amount of time. We might
> need to show them a progress status/ bar and also handle situations like
> copy of data dir ending midway with an error.

How about a one-off rename instead? That should be quick.

> I would like to present a slight modification to the proposal with help
> of controlled links. This would keep /var/lib/mysql intact owned by the
> MySQL 5.x series keeping things simpler for all existing users who wish
> to continue with MySQL.

I don't think it's simpler, because variants already assume ownership of
this directory, and have potentially modified it. What if we instead
renamed /var/lib/mysql to a new name, so that the directory has clear
ownership again?

>                         In case a user wants to install another fork of
> MySQL then during installation fork.{pre,post}inst would detect existing
> MySQL 5.6 and would ask if the user wishes to fork the data dir or start
> fresh.

I'm with you so far.

>  1. Fresh start with blank data dir.
>      1. Uninstall MySQL 5.x as regular removal.

We want co-installability though, right? So removal would no longer be
required?

>      2. Create fork specific data dir /var/lib/fork or
>         /var/lib/fork-version in case there can be compatibility issues.

Agreed.

>      3. Move /var/lib/mysql to /var/lib/mysql.backup (snapshot)
>      4. Create link /var/lib/mysql pointing to /var/lib/fork
>      5. Install fork as regular installation.
> 
> The user can decide after installation to remove, backup or keep
> /var/lib/mysql.backup.

This is where I think the confusion starts, but I don't think it makes
sense to go into it without deciding on the co-installation question
first.

>                        Fork would be able to access data dir directly at
> /var/lib/fork. Same will remain accessible via /var/lib/mysql if needed
> for administration purpose by user scripts.

I think this could lead to trouble. Scripts should know what they're
accessing, in terms of their compatibility. It'd be better for scripts
to break, and be fixed to use some helper provided by mysql-defaults to
figure out which directory to use.

>  2. Fork the data dir.
>      1. Uninstall MySQL 5.x as regular removal.
>      2. Move /var/lib/mysql to /var/lib/fork and optionally copy
>         /var/lib/fork to /var/lib/mysql.backup (snapshot)
>      3. Create link /var/lib/mysql pointing to /var/lib/fork
>      4. Install fork as regular installation.

So what happens now if the user wants to go back to the MySQL variant?
With co-installability, the way I see it is that there's nothing that
needs to be done. The variant forks the data, and the original MySQL
carries on with the original side of the fork.

> Please let me know your views on the modifications suggested above to
> the initial proposal.

It feels more complicated to me, because to me it seems that it
necessiates consideration of more edge cases. IMHO, deprecating the
confused-ownership /var/lib/mysql is cleaner, since it massively reduces
the problem space where edge cases may lie.

What exactly is the problem with my initial proposal that you're trying
to solve here?

Would a rename solve your concern about time for the 5.5 to 5.6 (or
updated 5.6 with this proposal implemented) upgrade?

Giving the user the option of starting with a fresh empty database for
all variants (over automatically migrating data from a different
variant) makes sense to me - that could be a debconf question for which
the default could be decided later. But I think that's orthogonal to my
proposal, which only really provides the mechanism for migrations,
leaving it for variants to implement (with common code in mysql-defaults
as makes sense).

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/20140708/58578a5c/attachment.sig>