In this blog post, we’ll look at some tips on how to configure Aurora RDS parameters.

I was recently deploying a few Aurora RDS instances, a process very similar to configuring a regular RDS instance. I noticed a few minor differences in the way you configure Aurora RDS parameters, and very few articles on how the commands should be structured (for RDS as well as Aurora). The only real literature available is the official Amazon RDS documentation.

This blog provides a concise “how-to” guide to quickly change Aurora RDS parameters using the AWS CLI. Aurora retains the parameter group model introduced with RDS, with new instances having the default read only parameter groups. For a new instance, you need to create and allocate a new parameter group (this requires a DB reboot). After that, you can apply changes to …

Next up in the "quick look" series is a discussion of connection management best practices and the memory usage implications of idle connections in Aurora and MySQL. I'll also throw in some notes on how to configure your connection pools to avoid unpleasant surprises.

Thread handling in Aurora vs MySQL Community MySQL editions use "one-thread-per-connection" approach to thread handling. It means that each individual user connection receives a dedicated OS thread within the mysqld process. This comes with issues, such as: 

• Relatively high memory usage with large number of user connections, even if the connections are completely idle.
• Higher internal server contention and context switching overhead when working with thousands of user connections.

To avoid such issues, some servers support a thread pool approach. Examples include Percona Server and Amazon Aurora.

…

In this part of the "quick look" series, I evaluate the performance of DDL operations in Amazon Aurora and vanilla MySQL. I'll use a few examples to demonstrate how fast the DDLs run and what impact they can have on regular workload. I'll also take the Aurora's Fast DDL feature for a spin.

Introduction DDL operations are a well-known source of pain in MySQL-based environments. They are not very fast, they're not fully online (non-blocking), and they're difficult to run on top of regular workload without serious performance degradation. MySQL has not seen much improvement in this area for quite some time, which is we have tools such as pt-online-schema-change, now considered to be an industry standard rather than a workaround.
Amazon Aurora tries to shake things up a little bit with the Fast DDL feature, which (as of this writing) allows you to add a nullable column at the end of a table nearly instantaneously. You can …

If you like to read (a lot) and you're considering to migrate your database workloads to AWS, this might be something for you. Nearly 75 pages of ideas for planning, executing, and troubleshooting database migrations to Amazon Aurora.

I recently published an Aurora Migration Handbook in the form of an AWS Whitepaper. The document can be downloaded from here:

https://d0.awsstatic.com/whitepapers/Migration/amazon-aurora-migration-handbook.pdf

Happy reading!

It's not always obvious what makes one database type distinct from another. What are the most significant ways that Amazon Aurora is different from MySQL? Clear separators aren't always featured or widely known, but even slight variables between two databases can prove valuable in choosing which one is right for you and your organization.

In the case of Aurora, there are at least three interesting things that make it unique and that present opportunities for particular uses. (Thanks in advance to @saileshkrish for helping us stay in-the-know on what Aurora can do.)

Adaptive Thread Pool

wow pic.twitter.com/KeVY5VBEMS

— Preetam (@PreetamJinka) December 21, 2016

Aurora's thread pool …

This post introduces PyMyTools v0.1: my first version of a simple diagnostic toolkit for automating boring DBA tasks. Read on for tool descriptions and demonstrations!

Introduction No lengthy introductions this time:

• I wrote these tools to make my own everyday tasks less time consuming. I hope you too will find them useful.
• Tools can be downloaded from GitHub and are provided under the MIT License.
• Your feedback is very welcome (use GitHub Issues).

Tools: general description The tools are designed to automate some of the simple DBA tasks:

• Monitor the values of server status variables.
• Report on basic status variables (buffer/cache usage, uptime, query traffic).
• Dump …

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 …

MySQL replication performance is a topic that requires no special introduction. Replication was never designed to be extremely fast and there isn't a single MySQL DBA who wouldn't learn it the hard way.
Today, with the improvements introduced in MySQL 5.7, as well as a complete re-implementation done by Amazon Aurora, it seems like we can finally see the light at the end of this very long tunnel.
Let's take both products for a spin and see how they behave. Introduction Before we get busy with the benchmarks, let's quickly explain why MySQL 5.7 and Amazon Aurora are so special. I wouldn't spend a weekend testing them if they weren't, right? MySQL MySQL 5.7 finally uses multi-threaded slave (MTS) implementation that makes sense. Long story short: instead of doing poor man's multithreading that requires you to split your data into multiple schemas (and doesn't guarantee consistency for cross-schema modifications), it can simply replay …