If you are looking for a class that is designed to jump-start your knowledge on MySQL 5.6 features, a class that provides hands-on labs, and a class that shows various migration methods – look no further.

We have been hard at work building a new class to ensure you have the knowledge and skills needed to verify your applications, and plan for the migration to MySQL 5.6. The class is called Moving to MySQL 5.6 and is a 2-day workshop.

The Moving to MySQL 5.6 workshop is being offered over the summer in numerous European countries and throughout …

A common practice to offload traffic from MySQL 5.6 is to use a caching layer to store expensive result sets or objects.  Some typical use cases include:

• Complicated query result set (search results, recent users, recent posts, etc)
• Full page output (relatively static pages)
• Full objects (user or cart object built from several queries)
• Infrequently changing data (configurations, etc)

In pseudo-code, here is the basic approach:

data = fetchCache(key)
if (data) {
  return data
}
data = callExpensiveFunction(params)
storeCache(data, key)
return data

Memcached is a very popular (and proven) option used in production as a caching layer.  While very fast, one major potential shortcoming of memcached is that it is not persistent.  While a common design consideration when using a cache layer is that “data in cache may go …

A few weeks ago I wrote about “MySQL Performance at High Concurrency” and why it is important, which was followed up by Vadim’s post on ThreadPool in Percona Server providing some great illustration on the topic. This time I want to target an opposite question: why MySQL performance at low concurrency is important for you.

I decided to write about this topic as a number of recent blog posts and articles look at MySQL performance starting with certain concurrency as the low point. For example, …

I actually don’t remember exactly whether it was in 2006, 2007 or 2008 — but around that time the MySQL community had one of the greatest MySQL conferences put on by O’Reilly and MySQL. It was a good, stable, predictable time.

Shortly thereafter, the MySQL world saw acquisitions, forks, times of uncertainly, more acquisitions, more forks, rumors (“Oracle is going to kill MySQL and the whole Internet”) and just a lot of drama and politics.

And now, after all this time some 6 or 7 years later, it feels like a MySQL Renaissance. All of the major MySQL players are coming to the Percona Live MySQL Conference and Expo 2013. I am happy to see Oracle’s engineers coming with talks — and now with a great MySQL 5.6 release — and I have great …

Percona CEO Peter Zaitsev leads a track at Percona MySQL University in Raleigh, N.C. on Jan. 29, 2013.

Percona MySQL University, Toronto is taking place this Friday and I’m very excited about this event because it is a special opportunity to fit a phenomenal number of specific and focused MySQL technical talks all into one day, for free.

Over the course of the day we will cover some of the hottest topics in the MySQL space. There will be talks covering topics like MySQL 5.6, MySQL in the Cloud and High Availability for MySQL, as well as Percona XtraDB Cluster for MySQL. We have talks planned for nearly every …

MySQL 5.6 introduces a number of new features designed to improve the security of MySQL. There's the new master_info_repository variable that lets you store replication connection information in a table instead of a lowly text file, new warnings telling users that they should use SSL/TLS, there is a new option to give replication user & password with START SLAVE instead of CHANGE MASTER, and there's mysql_config_editor to encrypt passwords. The problem with these features is that they are a form of Security through Complacency: these things make you feel more secure, but the realistic benefits disappear behind the curtains of Security Theater as soon as an even marginally-determined intruder comes along. In this post, I'll look at some of the new security features in MySQL 5.6 and, however well-intentioned they may be, the danger of relying on these features.

…

Download PDF Presentation

At the recent MySQL Tech Tour Events in New York and Boston I gave a presentation on MySQL integration with NoSQL,Big Data and the Cloud.

This covered discussion on topics including:

• Memcached API for InnoDB
• InnoDB Online Alter
• InnoDB Full Text Search (FTS)
• Partitioning inprovements for import/export
• SSD Optimisations
• Replication Improvements
• And much more …

MySQL 5.6 vs MySQL 5.5 & the Star Schema Benchmark

So far most of the benchmarks posted about MySQL 5.6 use the sysbench OLTP workload.  I wanted to test a set of queries which, unlike sysbench, utilize joins.  I also wanted an easily reproducible set of data which is more rich than the simple sysbench table.  The Star Schema Benchmark (SSB) seems ideal for this.

I wasn’t going to focus on the performance of individual queries in this post, but instead intended to focus only on the overall response time for answering all of the queries in the benchmark. I got some strange results, however, which showed MySQL 5.6.10 to be much slower than MySQL 5.5.30 even with only a single connection. I felt these results warranted deeper investigation, so I did some research and …

“MySQL 5.6: Advantages in a Nutshell.” March 6 at 10 a.m. PST with host Peter Zaitsev.

This Wednesday (March 6 at 10 a.m. PST) I’ll be presenting a webinar titled “MySQL 5.6: Advantages in a Nutshell.” In this presentation, I will provide a brief overview of the advantages MySQL 5.6 offers. My focus is a practical one – to identify the conditions in which one or another feature can be successfully used providing significant gain, explicitly or transparently. There has been a lot of pretty cool stuff done in MySQL 5.6 and my goal is to get you excited to learn more and try it out.

Reserve your spot now and join me on Wednesday by …

InnoDB Full-text Search in MySQL 5.6: Part 2, The Queries!

This is part 2 in a 3 part series. In part 1, we took a quick look at some initial configuration of InnoDB full-text search and discovered a little bit of quirky behavior; here, we are going to run some queries and compare the result sets. Our hope is that the one of two things will happen; either the results returned from a MyISAM FTS query will be exactly identical to the same query when performed against InnoDB data, OR that the results returned by InnoDB FTS will somehow be “better” (as much as it’s actually possible to do this in a single blog post) than what MyISAM gives us.

Recall that we have two different sets of …