Overview

When working with Amazon AWS Aurora, there are some steps to consider when trying to get data out of an active Aurora master into a slave, potentially into a EC2 instance or offsite in another data centre. Creating an external mysql to Aurora gives the option to move out of Aurora, or to have the flexibility to move data around as desired. With AWS RDS instances this task is pretty simple because you can do the following :

1. Create a read replica
2. Stop the slave process
3. Capture the positioning
4. Dump the database

With Aurora it’s a little trickier, because a read replica in Aurora has no slave process. All of the replication is handled on the back end and cannot be controlled. However, setting up an external slave can be done.

Amazon AWS Documentation

In …

In this blog, we’ll use some test results to look at the rationale for using provisioned IOPS volumes for AWS databases.

One piece of advice you often hear running MySQL, MongoDB or other databases in the AWS EC2 environment is that you should use volumes with provisioned IOPs. This kind of makes sense on the “marketing” level, where provisioned IOPS (io1) volumes are designed for IO-intensive database workloads, while General Purpose (gp2) volumes are not. But if you go to the AWS volume type description, you will find that gp2s are shown to have pretty good IO performance. So where do all these supposed database performance problems for Amazon Elastic Block Store (EBS), with no provisioned IOs, come from?

Here is what I found out running experiments with a beta of …

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 →