With the upcoming release of MySQL 5.7 I begin to see a problem which I think needs attention at least for 5.8 or whatever comes next. The GA release cycle is too long, being about 2 years and that means 3 years between upgrades in a production environment More people use MySQL and the data … Continue reading Making MySQL Better More Quickly
When you're testing out a new version of MySQL in a
non-production environment there is a temptation to go wild and
turn on all kinds of new features. Especially if you're
reading the changelogs or the manual and scanning through
options. You want to start with the most reasonable set of
defaults, right? Maybe you're even doing benchmarks to
optimize performance using all the new bells and whistles.
Resist the temptation! If your goal is to upgrade your production environment then what you really want is to isolate changes. You want to preform the upgrade with as little to no impact as possible. Then you can start turning on features or making changes one-by-one.
Why? Anytime you're doing a major upgrade to something as fundamental as your core RDBMS, there are many ways things can go wrong. Performance regressions & incompatible changes, client/server incompatibilities …
While doing some testing (that I published later here) on the still-in-development MySQL 5.7 I wanted to do some analysis on the configuration to see if the changes in performance were due to the code changes or just to the new MySQL defaults (something that is very common in the migration from 5.5 to 5.6 due to the default transaction log size and other InnoDB parameters). This is a quick post aiming to identify the global variables changed between these two versions.
You could tell me that you could just read the release notes, but my experience (and this is not an exception, as you will see) …[Read more]
A bit of history
The latest version of Red Hat Enterprise Linux, one of the most popular and respected Linux distributions in the server market, was released in June 2014, followed by CentOS 7 and Oracle Linux releases in July of the same year.
There are very interesting changes for database administrators in these new releases, among which I would like to highlight the fact that installer now chooses XFS as its filesystem by default, which substitutes ext4 as the preferred format for local data storage. Red …[Read more]
This comes from an issue that I worked on recently, wherein a customer reported that their application was working fine under stock MySQL 5.6 but producing erroneous results when they tried running it on Amazon RDS 5.6. They had a table which, on the working server, contained two TIMESTAMP columns, one which defaulted to CURRENT_TIMESTAMP and the other which defaulted to ’0000-00-00 00:00:00′, like so:
CREATE TABLE mysql56 ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, ts1 TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, ts2 TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00', );
However, under Amazon RDS, the same table looked like this:
CREATE TABLE rds56 ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, ts1 TIMESTAMP NULL DEFAULT NULL, ts2 TIMESTAMP NULL DEFAULT NULL, );
They mentioned that their schema contains TIMESTAMP column definitions without any modifiers for nullability or …[Read more]
MySQL, the original brand, the one developed by the MySQL team at Oracle, is steadily evolving. You can feel it if you try every new release that comes out of the milestone release cycle. Or even if you don’t try all of them, just testing a release once in a while gives you something to think about.
The engineers at Oracle are trying hard to improve the defaults. If you are the out-of-the-box type, and just install the new version on top of the previous one, leaving the same setup in place, you may be up for a for a few surprises. It’s the marketing, see? They tell you that just by replacing your old MySQL (5.1 or 5.5) with MySQL 5.6 you get 30% to 70% performance improvement. Which happens to be true, not only because the server is better, but also because they have changed the defaults. However, this change in defaults may come with some serious consequences for the ones who …[Read more]
MySQL 5.6.17 will probably be announced loudly at or immediately
before Percona Live MySQL Conference & Expo next
week. But official release announcement via email was made on
March 28, release notes and binaries to download are
already available, so why not to check them carefully to find out
what to expect from this 8th minor release of MySQL 5.6
First of all, it seems Oracle still does not hesitate to introduce new features and behavior in the process. Just check these major changes:
- Starting with 5.6.17, MySQL now supports rebuilding regular
and partitioned InnoDB tables using online DDL (
ALGORITHM=INPLACE) for …
A colleague and I have been looking at GTID on MySQL recently and you may be interested in the blog post that results from that. You can see it here. http://blog.booking.com/mysql-5.6-gtids-evaluation-and-online-migration.html.
MySQL 5.6 has been GA for just over a year now. See MySQL 5.6.10 Release Notes. Congratulations on your birthday! That is quite a long time. I was using it earlier in production because it worked and could do things that 5.5 could not do, but earlier versions were to use at your own risk, and indeed if prodded incorrectly would fall on the floor. That is fair enough because they were work in progress, yet if you poked them the right way they did a very good job. Those dev versions have been long since upgraded which is good so they do not need quite as much care and attention.
So from where I see 5.6 it works very well. One big change that has made a large difference but which I think a lot of people may not really understand or use is the …[Read more]