← Back to team overview

maria-discuss team mailing list archive

Re: Upgrading From MySQL 5.6 to MariaDB 10.1


Am 24.02.2017 um 00:09 schrieb mike bayer:

On 02/23/2017 05:22 PM, Reindl Harald wrote:

Am 23.02.2017 um 23:03 schrieb mike bayer:
On 02/23/2017 03:37 PM, Reindl Harald wrote:

normally you just update and run "mysql_upgrade -u root -p"
mysql/mariadb is not postgres

some of us could benefit from official language that we could give to

how do you imagine "official"?

in any sense "official" in teh software world means "you are going from
version x tro version y with *excatly* options z" - well, fine, but taht
don't match more than a few people of the real world anyways

to be honest: such questions are completly useless - if you don#t have a
machine where you can test your data with your configuration 1:1 step
back and get one - that's it and will always be independent of operating
system, software, configuration and data

and even if you have - be prepared that something unexpected happens on
the live machine which did not show on the clone - be prepeared to deal
with it - it's that simple

I work for well known vendor where thousands of customers will at some
point be getting 10.1 installed where they previously had 5.6 as part of
a larger installation.  All other aspects of the OS and configuration
remain identical

then you hopefully have some test instalaltions

We need to answer the question whether or not
customers are to be told to rebuild a new data directory from scratch
and run a full mysqldump, potentially taking many hours, or if the
installer can just run mysql_upgrade, taking a few seconds


the data-directory on the machine i compose this mail is from 2003 or so which was mysql-3.x and was in 2006 for some time on mysql-6.0.x-alpha, later downgraded

Asking all
our customers to try the whole thing out on a copy of their production
machine and to debug their own installation is not an option.

yes, because it's your job to grab some random datadirs, make a snapshot, try it out and know the outcome - whatever the outcome is it will never be granted that it works unconditional for every instance but you know wtihin 5 minutes if it's possible at all

If a piece of software shipped by a software vendor works or not with
the datafile from a given version of their software is an answerable
question.    The mariadb documentation encourages upgrades from
5.5->10.0 for example, and does not suggest that the data directory has
to be fully dumped and restored.  That's what "official" means in this

only if there wouldn't be that much storage engines, some like MyISAM living just in a folder per database, otehrs like xtradb/innodb with a global table space which is horrible in case of minor incompatibilities

without our crash 2009 it would have been a no-brainer

in the reality it was https://jira.mariadb.org/browse/MDEV-11898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel, remove that idiotic files and ignore the error message in the log until someone manages to get that fuckup cleaned from global table space *without* dump/restore for no good reasons

the crashes did not happen with mysql 5.5, mariadb 5.5 or mariadb 10.0 while the problem happened with mysql-5.1 - that said about knowing the outcome