Bug #45121 | mysql_upgrade not working by automatism | ||
---|---|---|---|
Submitted: | 27 May 2009 9:03 | Modified: | 4 Oct 2010 13:21 |
Reporter: | Susanne Ebrecht | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server: General | Severity: | S3 (Non-critical) |
Version: | 5.1 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[27 May 2009 9:03]
Susanne Ebrecht
[27 May 2009 10:51]
Simon Mudd
If possible also fix triggers, and stored functions and thus avoid the DBAs having to drop them prior to the upgrade. If this can not be done please indicate to the DBA the procedure to fix the problem. (URL to documentation).
[22 Sep 2009 15:51]
Simon Mudd
I've just been running mysql_upgrade on 5.1.39 (enterprise version) and see that now at least with Innodb tables it's possible to see the db which is affected. This makes it much easier to separate the tables which are OK from those which mysql_upgrade can't handle and manually a ALTER TABLE XXXX ENGINE=InnoDB manually. So thanks for helping a bit. There is another bug report which I can't find now which suggests automatically doing this. That would be the next step.
[29 Apr 2010 11:41]
Sveta Smirnova
mysql_upgrade also doesn't upgrade data in help tables and prints no word about this should be done.
[29 Apr 2010 15:02]
Sveta Smirnova
Note for case when mysql_upgrade fixes help table: please ensure SET SQL_LOG_BIN = 0 is called to ENSURE that these commands are NOT replicated downstream. There also can be new option --upgrade_help_tables[=0|1]
[24 May 2010 10:18]
Sveta Smirnova
Help tables part was moved to bug #53938
[4 Oct 2010 13:21]
Susanne Ebrecht
This is a duplicate of bug #47205