MySQL Upgrade Problems | FromDual - MySQL, Galera Cluster, Ma... http://www.fromdual.

com/mysql-upgrade-problems

How to upgrade to MySQL 5.x (#how-to-upgrade)

Problems we hit in real life: from MySQL 5.x to 5.y (#problems-in-real-life)
Sidegrade (MySQL - MariaDB - Percona Server) (#sidegrade)
Migration from MyISAM to InnoDB (#migration-from-myisam-to-innodb)
Switching from Statement Based Replication (SBR) to Row Based Replication (RBR) (#switching-from-sbr-to-rbr)
Switching to partitioned tables (#switching-to-ptn)
Sidegrade from MySQL to Galera (#galera)

Reasons to upgrade your MySQL database are (by priority):

Problems/errors
New features
Performance improvements (response time and scalability)
Application requirements
End of Life/Support
Better manageability
Bug fixes
Security issues (/mysql-security)
Specific know-How about old releases get lost over time

How to upgrade from different releases you can find here:

to 5.0 (http://dev.mysql.com/doc/refman/5.0/en/upgrading.html)
to 5.1 (http://dev.mysql.com/doc/refman/5.1/en/upgrading.html)
to 5.5 (http://dev.mysql.com/doc/refman/5.5/en/upgrading.html)
to 5.6 (http://dev.mysql.com/doc/refman/5.6/en/upgrading.html)
to 5.7 (http://dev.mysql.com/doc/refman/5.7/en/upgrading.html)
It is advisable to go through the Change Lists as well:
What is new in MySQL 5.0 (http://dev.mysql.com/doc/refman/5.0/en/mysql-nutshell.html)
What is new in MySQL 5.1 (http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html)
What is new in MySQL 5.5 (http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html)
What is new in MySQL 5.6 (http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html)
What is new in MySQL 5.7 (http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html)
The recommended way to do an upgrade is to dump (mysqldump) and reimport (mysql) the data. This is often not possible especially when you
have a huge amount of data.
Binary upgrade is done as well and with 5.0 and higher we have not seen any issues with binary upgrades any more (but there might be some!).
When you have Master/Slave set-ups keep in mind, that Slave should always have a newer version than Masters. So upgrade Slaves first. We
have not heard any problems replicating from MySQL 5.0 to 5.1 or even 5.5. But test this carefully on your own.

Because Change Lists are huge we collected here the problems we or our customers were running into:

MySQL is more strict in data type checking and throws warnings. This caused us some troubles with the application (Canias ERP): Data
were written in some cases correctly in some cases not written at all. Some results were retrieved wrongly from the database (rounding
problems). We considered to roll back the whole upgrade. Dumping the database with mysqldump --compatible=mysql40 and restoring
back into 4.1 gave some errors about too long indexes. So it seems to be a bug in mysqldump/mysql.
Cases were:

DECIMAL(6,2) 123.345
DATE '2012-10-09 12:12:12'

1 de 4 24/11/2015 11:48
MySQL Upgrade Problems | FromDual - MySQL, Galera Cluster, Ma... http://www.fromdual.com/mysql-upgrade-problems

According to a customer replication from 4.1 to 5.6 does not work at all!

Optimizer did some wrong Query Execution Plans. It was in one case so bad, that we have to rollback the upgrade.
There are some new reserved Keywords (http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-reservedwords-5-1.html) in MySQL
5.1. Especially the following: RANGE, ...
Test binary upgrade carefully (Canias 6.0.2, MySQL 5.0.28). mysql_upgrade complains for the majority of tables.
MySQL introduced the Index Merge Optimization (http://dev.mysql.com/doc/refman/5.5/en/index-merge-optimization.html) with 5.1. This leads sometimes
to non-optimal Query Execution Plans. With the optimizer_switch (http://dev.mysql.com/doc/refman/5.1/en/server-system-
variables.html#sysvar_optimizer_switch) variable you can revert to the old behaviour, either globally or per session if you do not want to use
hints.

Optimizer did some wrong Query Execution Plans.

Little performance slow down. When Buffer Pool Instances was set higher (# of CPU) the slow down went away.
There are some new reserved Keywords (http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-reference-reservedwords-5-5.html) in MySQL
5.5. Especially the following: GENERAL, MAXVALUE, RESIGNAL, SIGNAL, SLOW, ...
mk-table-checksum reports differences but there are none.
Keep in mind, that from MySQL 5.5 on InnoDB is the default Storage Engine.
Datatype timestamp is not allowed as partition key any more in combination with several date functions. See MySQL bug #42849 () . This is
a problem since MySQL 5.1.43 but it will possibly manifest during upgrade.
A new ugly bug (#68148 (http://bugs.mysql.com/bug.php?id=68148) ) was introduced possibly with the Fast Index Create feature affecting InnoDB
tables with Foreign Key Constraints. This bug is fixed in 5.6.12 and 5.7.2
DDL commands behave differently due to the Fast-Index-Create feature in MySQL and MariaDB 5.5. This seems to be fixed in MySQL 5.6
and MariaDB 10.0:

ALTER TABLE active DROP INDEX server, ADD INDEX ( server, callid, stale );
ERROR 1280 (42000): Incorrect index name 'server'

MySQL 5.5 introduces metadata locking (http://dev.mysql.com/doc/refman/5.5/en/metadata-locking.html) which opens up a new possibility of deadlocks.
Especially if an application contains transactions which might run somewhat longer, it is essential to test not only the functionality with 5.5
but also do some load tests.
mysqldump and MySQL Enterprise Backup (mysqlbackup) will break when concurrently DDL statements are issued: Do not run the
DDL operations ALTER TABLE, TRUNCATE TABLE, OPTIMIZE TABLE, REPAIR TABLE, or RESTORE TABLE
while a backup operation is going on. The resulting backup might be corrupted or fail.
RESET SLAVE followed by a database restart behaves different in 5.5 compared to 5.1. Possibly use RESET SLAVE ALL instead.

Import of a MySQL 5.5 dump followed by the mysql_upgrade command while GTIDs are enabled causes troubles with some MySQL 5.6
releases. Do the upgrade with --gtid-mode=0 and enable it later on.
Some default values have changed (http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html) (18!): The most important one is
innodb_file_per_table = 1. Some old variables and some deprecated commands have been removed. So test carefully!
The Query Cache is disabled by default in 5.6. Change to the previous behaviour by setting query_cache_type=1 in my.cnf
8 new reserved key words have been defined. The most important ones are get and partition.
A new ugly bug (#68148 (http://bugs.mysql.com/bug.php?id=68148) ) was introduced possibly with the Fast Index Create feature affecting InnoDB
tables with Foreign Key Constraints. This bug is fixed in 5.6.12 and 5.7.2
Implicit GROUP BY sorting in MySQL 5.6 (http://dev.mysql.com/doc/refman/5.6/en/order-by-optimization.html) is deprecated.
When upgrading a master-master setup from 5.5 to 5.6 without downtime, take care: MySQL 5.6 (by default) writes checksums into the
binary log which MySQL 5.5 does not understand, so the 5.5 IO slave reports an error and replication stops. A Google search returns this:
"It's because of binlog_checksum = crc32 setted default at 5.6.5. If you use 5.6's master and 5.5 (or earlier)'s slave, you need to set
binlog_checksum = none on 5.6."
If you forgot this, upgrade the second node also, then replication will resume.
After upgrading to MySQL 5.6 a performance decrease is expected, especially, for the single-threaded applications. So, it is highly
recommended to test not only the application code with MySQL 5.6 but also the application performance under a high load before doing the
upgrade on production. Otherwise, you might need to downgrade to MySQL 5.5 because of the performance issues.
mysqldump and MySQL Enterprise Backup (mysqlbackup) will break when concurrently DDL statements are issued: Do not run the
DDL operations ALTER TABLE, TRUNCATE TABLE, OPTIMIZE TABLE, REPAIR TABLE, or RESTORE TABLE
while a backup operation is going on. The resulting backup might be corrupted or fail.
RESET SLAVE followed by a database restart behaves different in 5.6 compared to 5.1. Possibly use RESET SLAVE ALL instead.
The mysql.host table was removed. If you rely on those privilege rules you should chang this before upgrading to MySQL 5.6

In MySQL 5.7.6 and 5.7.7 the password column was removed from the mysql.user table. This might cause some old legacy admin tools
to fail (Bug #76655 (https://bugs.mysql.com/?id=76655) ). Possible evil workaround: ALTER TABLE mysql.user ADD COLUMN `Password`
CHAR(41) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT '' AFTER `User`; (has to be tested! SET PASSWORD =
'secret'; seems to NOT work any more afterwards...).
Various options, parameters and some MySQL syntax is removed an thus does not work any more and can cause errors in old legacy
applications.

2 de 4 24/11/2015 11:48
MySQL Upgrade Problems | FromDual - MySQL, Galera Cluster, Ma... http://www.fromdual.com/mysql-upgrade-problems

Some MySQL user want to switch from MySQL to Percona Server or MariaDB or the other way around. Up to now we have not seen any specific
issues. Both Branches of MySQL claim to be drop-in replacements for MySQL. Percona Server code is genetically closer related to MySQL than
MariaDB. So we expect less effects on this switch.
With RHEL/CentOS 7 and SLES 12 MariaDB becomes the default MySQL. Thus we expect some more findings in the close future...

Some customers experienced performance slow-down of some specific queries. This has to do with differences in the optimizers. Also
faster response time has to be expected but you will not complain about it... This can happen in both directions.
MySQL to MariaDB migration: handling privilege table differences when using mysqldump (http://www.skysql.com/blogs/kolbe/mysql-mariadb-migration-
handling-privilege-table-differences-when-using-mysqldump)

Significant slow-down experienced upgrading from MySQL 5.0 to MariaDB 5.5 on CentOS 7 due to wrong MariaDB optimizer decision for
sub-query optimization.

Sidegrade from MariaDB 10.0 to MySQL/Percona 5.6: MariaDB binary logs cause error messages in MySQL error logs. Purge of the old
(MariaDB) binary logs helps to get rid of the messages. The utility mysql_upgrade does not solve all problems. Needs some manual fixes
on the tables: mysql.event, mysql.innodb_table_stats and mysql.innodb_index_stats.

Sidegrade from MySQL/Percona 5.6 to MariaDB 10.0: InnoDB: in InnoDB data dictionary has unknown flags 40/50/52. The
command OPTIMZE TABLE solves these issues. The utility mysql_upgrade does not solve all problems. Needs some manual fixes on the
tables: mysql.innodb_table_stats and mysql.innodb_index_stats.
You get rid of these error messages. If it causes any technical harm we cannot say so yet. To be on the safe side use a dump/restore to
migrate the data (careful with huge databases!!!)

Since MySQL 5.5 InnoDB is the default Storage Engine. This has some impacts:
InnoDB does NOT have FULLTEXT search (introduced in MySQL 5.6) and GIS indexes (introduced in MySQL 5.7).
In InnoDB rows are sorted by the Primary Key. In MyISAM they are not.
InnoDB has a much bigger footprint than MyISAM (50 - 100%!).
In InnoDB AUTO_INCREMENT values must be located at the first position of any index (InnoDB AUTO_INCREMENT at 2nd position (/mysql-
hints#sequence) )

SELECT COUNT(*) FROM table; in InnoDB is much slower than with MyISAM. More details you can find here: Change MyISAM tables to
InnoDB and handle SELECT COUNT(*) situation (/myisam-to-innodb-table-and-select-count-star)
InnoDB seems to cope better with write load than MyISAM (Slave lag disappeared).
InnoDB mandatorily needs a Primary Key. If you do not provide one, InnoDB creates one itself. See also discussion Disadvantages of
explicitly NOT using InnoDB Primary Keys (/disadvantages-of-explicitly-not-using-innodb-primary-keys) and row based replication (RBR)...
Isolation level READ-COMMITTED is not allowed any more with Statement Based Replication S(BR): Binary logging not possible.
Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'.
Traditional MyISAM Locking with LOCK TABLE causes meta data locks (Waiting for table metadata lock) when mysqldump backup is
started with --single-transaction.
MRG_MyISAM tables/storage engine does not work for InnoDB tables. Use a VIEW or table Partitions instead.
A new ugly bug (#68148 (http://bugs.mysql.com/bug.php?id=68148) ) was introduced possibly with the Fast Index Create feature affecting InnoDB
tables with Foreign Key Constraints. This bug is fixed in 5.6.12 and 5.7.2
Copy of a single table on file system is not that easy any more. You have to use the Transportable Tablespace (TTS) mechanism instead
(since 5.6).
Badly designed tables can lead to the following error when the default InnoDB file format (http://dev.mysql.com/doc/refman/5.6/en/innodb-file-format.html)
Antelope (http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_antelope) is used. Redesigning the table or switching to Barracuda (http://dev.mysql.com
/doc/refman/5.6/en/glossary.html#glos_barracuda) file format will solve the problem:

ERROR 1118 (42000) at line 101: Row size too large (> 8126).
Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help.
In current row format, BLOB prefix of 768 bytes is stored inline.

In version 5.1 MySQL introduced row based replication (RBR). RBR is much more reliable than SBR when it comes to data consistency
(non-deterministic queries, etc.). So one should consider to leave SBR and start using RBR!
One customer had the situation, that binary log grew significantly after switching from SBR to RBR. This was caused because he just
updated a timestamp on a row which contained a BLOB. With RBR replication the whole row (including the BLOB) is transferred. This is
optimized and configurable in MySQL 5.6.
InnoDB mandatorily needs a Primary Key. If you do not provide one, InnoDB creates one itself. See also discussion Disadvantages of
explicitly NOT using InnoDB Primary Keys (/disadvantages-of-explicitly-not-using-innodb-primary-keys) and row based replication (RBR)...
We have seen some strange errors on Windows replicating from 5.5.11 to 5.5.24:

Last_Errno: 1677
Last_Error: Column 15 of table 'test.users' cannot be converted
from type 'decimal(0,?)' to type 'decimal(3,2)'

We have no solution yet. But it is reproducible.

pt-table-checksum/mk-table-checksum will complain about RBR.

3 de 4 24/11/2015 11:48
MySQL Upgrade Problems | FromDual - MySQL, Galera Cluster, Ma... http://www.fromdual.com/mysql-upgrade-problems

Since version 5.1 MySQL is aware of table partitioning (http://dev.mysql.com/doc/refman/5.1/en/partitioning.html) . Switching from non-partitioned tables to
partitioned tables has some impacts:
The partition key must always be part of the Primary Key. In most cases this does not cause problems but we have seen the following
scenario on a table with the PK on the first column:

REPLACE INTO test VALUES (1, 'Old', '2014-08-20 18:47:00');

REPLACE INTO test VALUES (1, 'New', '2014-08-20 18:47:42');

This query will not work as expect any more in a partitioned table when the last column is used as partition key!
Query Cache is no supported for partitioned tables (since MySQL 5.1.63, Bug #53775 (http://bugs.mysql.com/bug.php?id=53775) , MySQL Docu
(http://dev.mysql.com/doc/refman/5.1/en/partitioning-limitations.html) ). MariaDB 5.5 claims (https://blog.mariadb.org/the-query-cache-and-partitions/) to have fixed
this problem (July 26 2014).

See comments about Upgrade to 5.1/5.5 and 5.6 (#problems-in-real-life) , MyISAM to InnoDB (#migration-from-myisam-to-innodb) and Switching from
SBR to RBR (#switching-from-sbr-to-rbr) ...
See also our alter_engine.pl (/mysql-consulting-tools#alter_engine) script which helps you with the migration...
See also the Galera Limitations (http://galeracluster.com/documentation-webpages/limitations.html) .
Think about the hot-spot problem which occurs in such kind of distributed clusters...
If you are aware of any problematic situations upgrading MySQL we would like to hear about... (mailto:[email protected])

migration (/taxonomy/term/27) upgrade (/taxonomy/term/91) innodb (/taxonomy/term/116) problem (/taxonomy/term/329) erp (/taxonomy/term/332)
canias (/taxonomy/term/333) sidegrade (/taxonomy/term/344) GTID (/taxonomy/term/421) downgrade (/taxonomy/term/502)

rbr (/taxonomy/term/503) sbr (/taxonomy/term/504) tbr (/taxonomy/term/505) partition (/taxonomy/term/166)

4 de 4 24/11/2015 11:48