On Thu, Feb 02, 2017 at 05:04:57PM +0000, Julian Gilbey wrote: > On Thu, Feb 02, 2017 at 04:36:02PM +0000, Robie Basak wrote: > > I think the right thing to do is the same as the MySQL->Postgres > > scenario. The data should be able to stay put. The new daemon should > > start (perhaps with a new empty database, as MariaDB is currently doing > > if I understand correctly). And the user should be able to seamlessly > > switch back. That the packages conflict shouldn't come in to it. > > That would be a great step forward! If mariadb were able to have its > databases stored in /var/lib/mariadb instead of /var/lib/mysql, then > this bug would be solved instantly (and in a much better way than my > suggestion). If an existing /var/lib/mysql were present, then mariadb > could ask on first installation whether to import the databases from > there (assuming that they could be), and otherwise leave it (and > /etc/mysql) alone entirely.
This is (roughly) my plan in bug 841345. Except that since various third party tooling expects /var/lib/mysql, I want to maintain that as a symlink or something. So the data directories would be separate (keep their own inode numbers, if that helps explain it), just that we rename and/or symlink them around when switching variants to keep the name /var/lib/mysql always leading to the current variant's data directory. Users who migrate from one variant to another may be presented with options to create from scratch, use what was previously there for the variant being switched to (if any) copy (dump/restore or cp -a or otherwise as appropriate), or rename and cross-grade (with big warnings about not being able to go back). Unfortunately this is non-trivial to implement because users have edge case symlinks in /var/lib/mysql, mount /var/lib/mysql in its own partition, and so on. I don't expect to have anything in time for stretch. Robie
signature.asc
Description: PGP signature
