Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.0.21, 10.1.22
-
None
-
Debian 8 (Jessie) and OpenSuSE 13.2
Description
We had in a MariaDB Training Standard Linux distros with standard MariaDB Installations and wanted to upgrade to the newest MariaDB 10.1 from MariaDB repository.
We later found out because of an error in journalcontrol that an upgrade from the DD never happened:
InnoDB: Error: Column last_update in table "mysql"."innodb_table_stats" is INT UNSIGNED NOT NULL but should be BINARY(4) NOT NULL (type mismatch)
|
we have the opinion that during upgrade MariaDB package should:
a) either upgrade with mysql_upgrade directly or
b) alternatively clearly should state that an upgrade is needed!
Regards,
Oli
Attachments
Issue Links
- duplicates
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
- relates to
-
-
- Closed
-
Activity
Hi elenst,
is there any update on this?
I think this is clearly linked to what you are describing:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897428
elenst, I'd optimize for a common use case. And that's a user who doesn't have a huge amount of data or high concurrent load, and is not MariaDB expert.
That means, automatically run mysql_upgrade during upgrade. I'd even say — run mysql_upgrade during upgrade if mysqld is up. So MariaDB experts can stop mysqld for the duration of the upgrade and that'll disable auto-mysql_upgrade too. Or there could be an option somewhere in /etc/mysql/?
faust, what do you think?
serg if possible (and compatible with OS upgrade guidelines) I think we should always ask users what we should do (expert or not).
For me, message should contain the following:
- brief explanation on what is going to happen and why we need user interaction;
- warning that on huge base myslq_upgrade process could be very long and progress indicator if possible (Michael Schaller suggested this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865534#15).
Expert users can always bypass these interaction with specific apt-get option (for example '--force-yes') if they perfectly know what they are doing.
Missed finding this when I created MDEV-24172. This has been corrected.
Here is the opposite complaint about 10.0:
MDEV-12275. This one is just about output, but it's not the first complaint about mysql_upgrade.In general, this discussion has been back and forth for long time, either decision has its disadvantages.
When we turn off the automatic mysql_upgrade, many installations stay with the old schema, and when their users get mysterious problems, we observe months of errors in the log.
When we turn on the automatic upgrade, people report that on big installations it takes days, if not weeks, during which time their instance is out of order, often unexpectedly.