Reducing Risk Before Upgrading MySQL
Upgrading MySQL databases do not come without risk. There is no guarantee that no problems will happen if you move to a new major MySQL version. Should we just upgrade and rollback immediately if problems occur? But what if these problems only happen a few days after migrating to this new version? You might have a database environment that is risk-adverse, where you really have to be sure that this new MySQL version will handle the workload properly. Examples: - Both MySQL 5.6 and 5.7 have a lot of changes in the MySQL Optimizer. It is expected that this improves performance of my queries, but is it really the case? What if there is a performance regression? How will this affect my database performance? - Also, there are a lot of incompatible changes which are documented in the release notes, how do I know if I'm affected by this in my workload? It's a lot to read.. - Can I go immediately from MySQL 5.5 to 5.7 and skip MySQL 5.6 even though the MySQL documentation states that this is not supported? - Many companies have staging environments, but is there a QA team and do they really test all functionality, under a similar workload? This presentation will show you a process, using open source tools, of these types of migrations with a focus on assessing risk and fixing any problems you might run into prior to the migration. This process can then be used for various changes: - MySQL upgrades for major version upgrades - Switching storage engines - Changing hardware architecture Additionally, we will describe ways to do the actual migration and rollback with the least amount of downtime.
MySQL Practice Manager, Percona
Kenny is currently MySQL Practice Manager at Percona.
Technical Account Manager, Percona
Tom has been active in Unix system's administration for 10+ years. Before joining Percona, he has been working for several consultancy companies and system's integrators, always working, focusing and offering solutions based on OSS.