Some time ago, I published the article on AWS Aurora Benchmarking (AWS Aurora Benchmarking – Blast or Splash?), in which I analyzed the behavior of different solutions using synchronous replication in AWS environment. This blog follows up with some of the comments and suggestions I received regarding that post from the community and Amazon engineers.

I decided to perform another round of tests, keeping in mind comments and suggestions received.

I presented some of the results during the Percona conference in Santa Clara last April 2016. The following is the transposition that presentation, with more details.

Not interested in the preliminary descriptions? Go to the results section

Why new tests?

When your database undergoes a restart, whether it's a clean reboot or a crash, it will typically create two negative effects your application will have to face: blackout (downtime) and brownout (period of degraded performance after startup).

In my previous post, I described how Aurora makes downtime less stressful for you, now it's time to investigate yet another feature that should come in handy in mission-critical environments: the survivable page cache.

Introduction As usual, let's throw in a tiny bit of theory before looking at the demonstrations.
The InnoDB Buffer Pool is an in-memory area for caching data and index pages. That said, buffer pool can also be called a "page cache". Both terms mean …

Following earlier posts on replication and query cache improvements, this article will focus on a feature that can make Aurora more suitable for mission critical enterprise applications: near-instantaneous crash recovery.

While real-life performance is tricky to measure and may be evaluated differently in the context of different applications, downtime is a fairly straightforward thing to define and you most certainly want to avoid it regardless of what kind of service you're running. Let's take Aurora for a spin and see how it can make your life easier in this area.

Introduction This article doesn't pretend to be even remotely close to a proper technical description of MySQL startup and crash …

Following the recent post on replication performance and efficiency, I'd like to talk about another MySQL feature that has received some treatment in Aurora: the Query Cache.
We'll first discuss the limitations of "traditional" Query Cache implementation, we will then watch a sysbench read-only test take off and go from 250K reads per second to nearly 650K reads per second, all thanks to the improved Query Cache. Have fun!
Query Cache The MySQL Query Cache is a hugely useful feature that caches the result sets of SELECT statements in memory. It makes perfect sense in typical OLTP applications (especially web apps), where queries are quite repeatable because the same piece of data is often selected multiple times by many clients.
The following performance issues are associated with query cache implementation in vanilla …

Testing functionalities and options for a database can be challenging at times, as a live production environment might be required. As I was looking for different options, I was directed by Derek Downey to this post in the Percona blog.

The blog discussed an interesting and fun tool from Percona, tpcc-mysql. I was interested in testing the tool so I decided to play around with it in an AWS EC2 server.

In this post I will expand on the Percona blog post, since the tool lacks documentation, as well as explain how I used it to create a MySQL Benchmark in AWS.

Why tpcc-mysql?

There are various reasons why tpcc-mysql could be a good …

One of the most common engagements I do is working with firms in and around the NYC startup sector. I evaluate AWS infrastructures & applications built in the Amazon cloud. Join 32,000 others and follow Sean Hull on twitter @hullsean. I’ve seen some patterns in customers usage of Amazon. Below is a laundry list of … Continue reading 5 core pieces of the Amazon Cloud puzzle to get your project off the ground → …

Amazon EBS volumes come with a very cool feature called "lazy loading". In a nutshell: if a volume is created from an existing snapshot, it can become available almost immediately without waiting for all data to be restored. This allows for extremely fast provisioning of large data sets as long as you don't explicitly require the entire data set to be present before you start using it.
When an EBS volume is restored from snapshot, its blocks are fetched from Amazon S3. It happens either lazily in the background or explicitly on demand (think of a pagefault-like mechanism) and of course, fetching pieces of data from Amazon S3 is going to be one-two orders of magnitude slower than reading blocks directly from a volume.
In this short article, I will try to give you an idea of how this may impact the crash recovery time of your MySQL databases. Why talk about this? Depending on the workload and data set layout, crash recovery of a MySQL …

There’s a strong trend to automation across the cloud. That’s a great thing for startups because it reduces operational headaches & lets them focus on building products. Join 31,000 others and follow Sean Hull on twitter @hullsean. But as that trend begins to touch the database tier, all sorts of complications emerge. Let’s take a … Continue reading When hosting data on Amazon turns bloodsport →

When I joined Pinterest, my first three weeks were spent in Base Camp, where the newest engineering hires work on real production issues across the entire software stack. In Base Camp, we learn how Pinterest is built by building it, and it’s not uncommon to be pushing code and making meaningful contributions within just a few days. At Pinterest, newly hired engineers have the flexibility to choose which team they’ll join, and working on different parts of the code as part of the Base Camp experience can help with this decision. Base Campers typically work on a variety of tasks, but my project was a deep dive into a MySQL performance optimization project.

Pinterest, MySQL and AWS, oh my!

We work with MySQL running entirely inside Amazon Web Services (AWS). Despite using fairly high-powered instance types with RAID-0 SSDs and a fairly simple workload (many point selects by PK or simple ranges) that peaks around 2,000 …

Greetings everyone! Let’s discuss a 3rd Party auditing solution to MySQL and how we can leverage MongoDB® to make sense out of all of that data.

The McAfee MySQL Audit plugin does a great job of capturing, at low level, activities within a MySQL server. It does this through some non-standard APIs which is why installing and configuring the plugin can be a bit difficult. The audit information is stored in JSON format, in a text file, by default.

There is 1 JSON object for each action that takes place within MySQL. If a user logs in, there’s an object. If that user queries a table, there’s an object. Imagine 1000 active connections from an application, each doing 2 queries per second. That’s 2000 JSON objects per second being written to the audit log. After 24 hours, that would be almost 173,000,000 audit entries!

How does one make sense of that many JSON objects? One option would be to write your own parser in …