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 customers
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
seriously? 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 context
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.sy..., 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