Global Transactions Identifiers are one of the new features regarding replication in MySQL 5.6. They open up a lot of opportunities to make the life of DBAs much easier when having to maintain servers under a specific replication topology. However you should keep in mind some limitations of the current implementation. This post is the first one of a series of articles focused on the implications of enabling GTIDs on a production setup.

The manual describes very nicely how to switch to GTID-based replication, I won’t repeat

This Wednesday, May 15 at 10 a.m. Pacific, I’ll be leading  a Webinar titled, “Using MySQL 5.6 Performance Schema to Troubleshoot Typical Workload Bottlenecks.”

In this Webinar I will offer an overview of Performance Schema, focusing on new features that have been added in MySQL 5.6, go over the configuration and spend most time showing how you can use the wealth of information Performance Schema gathers to understand some of the typical performance bottlenecks.

Other areas of focus

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

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

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

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 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

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,

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

“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

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

MySQL 5.5 lock_wait_timeout: patience is a virtue, and a locked server

Like Ovais said in Implications of Metadata Locking Changes in MySQL 5.5, the hot topic these days is MySQL 5.6, but there was an important metadata locking change in MySQL 5.5.  As I began to dig into the Percona Toolkit bug he reported concerning this change apropos 

I’ve never been a very big fan of MyISAM; I would argue that in most situations, any possible advantages to using MyISAM are far outweighed by the potential disadvantages and the strengths of InnoDB. However, up until MySQL 5.6, MyISAM was the only storage engine with support for full-text search (FTS). And I’ve encountered many customers for whom the prudent move would be a migration to InnoDB, but due to their use of MyISAM FTS, the idea of a complete or partial migration was, for one reason or another, an impractical solution. So, when FTS for InnoDB was first announced, I thought this might end up being the magic bullet that would help these sorts of customers realize all of the benefits that have been engineered into InnoDB over the past few years and still keep their FTS capability without having to make any significant code

A high-level comparative overview of the features

With the recent GA release of MySQL 5.6, there have been a lot of questions about where MariaDB stands with regards to MySQL 5.6.  SkySQL will of course support both as Patrik explained in his recent blog post, but there are many questions about the technical differences. Rasmus from Monty Program gave a detailed view on MariaDB 10.0 here but I thought it would be beneficial to share a comparison table of the two. MariaDB recently released a benchmark including various versions of both MariaDB and MySQL (as did DmitriK from Oracle), but this post will

Get up-to-date on MariaDB, MySQL, Cloud Databases and SkySQL’s expertise: whitepapers and presentations now available on skysql.com

The weekend is almost here and we thought we'd share an update with you on some of the resources that you can access on our website. Here is some good reading and viewing material that we have recently made available that we hope can be of use to you.

read more

SkySQL confirms commitment to support the newly released Oracle MySQL 5.6

Tuesday, February 5th was an important day in the MySQL ecosystem due to the release by Oracle of the long-awaited MySQL 5.6 GA. Many MySQL users have been looking forward to this release in order to benefit from the improved performance and scalability. Features such as online operations/schema changes, NoSQL access from memcached to InnoDB, multi threaded-replication and Global Transaction ID significantly improve the competitiveness of MySQL.

read more