There were two nasty MySQL replication bugs in two different 5.6 releases that would make it difficult to upgrade slaves to MySQL 5.6 while still connected to MySQL 5.5 master. The first of those bugs is MySQL bug 72610 which affects 5.6.19. Essentially this bug is triggered when the table structure on the slave is different from the table structure on the master which leads to unnecessarily large amount of RAM usage while replicating events that affect that table. The amount of RAM used would generally be more noticeable when the replicated transaction consists of thousands of RBR events. The most common way this affects how we upgrade a replication hierarchy, is when we have the master running MySQL 5.5 and the slave running MySQL 5.6 and we have transactions involving DATETIME column(s). Tables with DATETIME columns will have different underlying structure when created on MySQL 5.5 versus when created on MySQL 5.6. Ideally you would avoid creating …[Read more]
MySQL upgrades are necessary tasks and we field a variety of questions here at Percona Support regarding MySQL upgrade best practices. This post highlights recommended ways to upgrade MySQL in different scenarios.
Why are MySQL upgrades needed? The reasons are many and include: Access to new features, performance benefits, bug fixes…. However, MySQL upgrades can be risky if not tested extensively beforehand with your application because the process might break it, prevent the application from functioning properly – or performance issues could arise following the upgrade. Moreover, I suggest keeping an eye on new releases of MySQL and Percona Server – check what has changed in the …[Read more]
Do you know how to do rolling maintenance on your database hosts so you can make changes without stopping applications? How about upgrading schema and applications themselves? Tungsten clusters have a host of features that can help you with everything from basic administration to complex application upgrades. This webinar shows you the different types of administration you need to perform, and
Any person with half a brain would see from the error messages below that the MySQL server is not operating optimally, or more specifically the MySQL upgrade has not completely successfully and let users can go happily use the website. It amazing me when web hosting providers tell their paying client that an upgrade has been performed yet they did not have the intelligence to actually look at the error log for confirmation. Got a mysql> prompt, it’s all good. One of the first things I check is the error log.
When will people learn the MySQL error log is a valuable resource both for what it contains, and what it should not contain.
120426 17:36:00 [Note] /usr/libexec/mysqld: Shutdown complete 120426 17:36:00 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 120426 17:36:00 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 120426 17:36:00 [Note] Plugin 'FEDERATED' is disabled. /usr/libexec/mysqld: …[Read more]
MySQL 5.5 has created a lot of hype and its not just hype, there are major performance enhancements not only in the MySQL server itself but in the newer InnoDB plugin shipped with MySQL 5.5. That's exactly the reason why I have myself upgraded to MySQL 5.5 (The server running this blog run MySQL 5.5). Now since I haven't come across a guide to help in upgrading to MySQL 5.5, I thought why not make one myself