maria-discuss team mailing list archive

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

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.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