maria-discuss team mailing list archive
-
maria-discuss team
-
Mailing list archive
-
Message #05129
Re: Upgrade paths through more major versions
-
To:
maria-discuss@xxxxxxxxxxxxxxxxxxx
-
From:
Reindl Harald <h.reindl@xxxxxxxxxxxxx>
-
Date:
Wed, 6 Jun 2018 15:01:50 +0200
-
In-reply-to:
<CAC2Uqrsn-Fg6ikMWru6Mw-eijjOm2NbOOcXdCUxZFSYrhS=C5w@mail.gmail.com>
-
Openpgp:
id=9D2B46CDBC140A36753AE4D733174D5A5892B7B8; url=https://arrakis-tls.thelounge.net/gpg/h.reindl_thelounge.net.pub.txt
-
Organization:
the lounge interactive design
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
Am 06.06.2018 um 14:20 schrieb Guillaume Lefranc:
> That's a waste of time. Such an upgrade is perfectly possible through
> the means of mysqldump and reload. In-place upgrades might cause some
> issues because of innodb version changes, but for example, from 10.0 to
> 10.1, they are rarely an issue because the version of InnoDB hasn't
> changed. The recommended upgrade path from any version is always the
> same e.g. dump and reload.
sorry, but this is not postgresql where you where f**ed for ages when
your distribution at dist-upgrade shipped a major upgrade and you forgot
to dump before
i work with MySQL since 2001 and in-place updates followed with
'mysql_upgrade' worked between all vesions including skip a release
when i have to dump and reload something is terrible wrong - how do you
do that on servers with thounsdands of tables and hundrets of users
uninterrupted? and yes my distupgrades from Fedora 9 to Fedora 27 where
*online upgrades* followed by a reboot with a downtime of a few seconds
while the upgrade itself takes 2-5 minutes on a VMware clusert
References