Percona Live 2021: A First Look at Aurora Serverless v2

The world of serverless databases on the cloud and on AWS is changing fast: I am very looking forward to be a speaker at Percona Live 2021, a community-focused event corganized by Percona for database developers and administrators and take a first look at Amazon Aurora Serverless v2. The event is free and will be held online running over two days. Abstract below, see you there!

A First Look at Aurora Serverless v2

During the latest re:Invent, AWS announced the next version of Amazon Aurora Serverless. The new version for the MySQL 5.7-compatible edition of Amazon Aurora scales in fraction of a second and introduces multi-AZ support, global databases, and read replicas. What are the di erences between v1 and v2? Why did AWS introduced an entirely separated new product? Is Aurora Serverless v1 a service to be already forgotten? A journey on the latest changes and a few tests running serverless databases on AWS.

TheCloudFirst 2021

Looking forward to be a speaker on March 11th at TheCloudFirst, the cloud native conference, and talk about one of my favorite topics, serverless databases on AWS.

For the first time, I will cover the preview of Aurora Serverless v2, the new serverless MySQL compatible database announced by AWS at re:Invent 2020.

Is Serverless the Future of Relational Databases?

From AWS to Google Cloud, the major cloud providers offer different options to run a relational database on the cloud. You can spin up virtual machines and configure your own cluster or rely on managed services. But the new trend is serverless (relational) databases that offer both traditional interfaces and HTTP API access. This talk is personal journey on AWS moving from a managed MySQL to a serverless Aurora. Can serverless really be the future for the enterprise databases?

Percona Live Online 2020

“Serverless Databases: The Good, the Bad, and the Ugly” is the topic of my talk at Percona Live Online. After a lightning talk at Percona Live Europe in Dublin and a few posts for the Percona Community Blog, I am looking forward to be (virtually) on stage at Percona Live Online!

The conference will run for 28 hours on 20-21 October 2020 and will cover topics on Open Source Databases and Applications using MySQL, PostgreSQL, MongoDB, and MariaDB. You can find the full agenda online and register for free.

A blog preview of my talk is available on the Open Source Database Community Blog

InfoQ – July 2020

A recap of the news articles I wrote for InfoQ in July 2020.

The AWS Serverless LAMP Stack: the Future of PHP or Vendor Lock-in?

In a series of three technical articles, AWS has recently introduced the new “Serverless LAMP stack”. But not everyone in the open-source community believes that the successor of the LAMP stack is proprietary technologies from a single vendor, and alternative approaches have been suggested.

The AWS Serverless LAMP Stack: The Future of PHP or Vendor Lock-in?

AWS Announces General Availability of Amazon RDS Proxy

Amazon RDS Proxy is a new fully managed, highly available database proxy for MySQL and PostgreSQL databases running on Amazon RDS and Aurora. The service is tailored to serverless architectures and other applications that open and close database connections at a high rate

A Second Look at Amazon RDS Proxy

At re:Invent in Las Vegas in December 2019, AWS announced the public preview of RDS Proxy, a fully managed database proxy that sits between your application and RDS. The new service offers to “share established database connections, improving database efficiency and application scalability”.

Does RDS Proxy make MySQL more elastic?

A first look

In January I shared some thoughts and first results at the AWS User Group Meetup in Berlin and I wrote a post for the Percona Community Blog: A First Look at Amazon RDS Proxy.

One of the key features was the ability to increase application availability, significantly reducing failover times on a Multi AZ RDS instance. Results were indeed impressive.

But a key limitation was that there was no opportunity to change the instance size or class once the proxy has been created. That means it could not be used to reduce downtime during a vertical scaling of the cluster and made the deployment less elastic.

Time for a second look?

Last week AWS announced finally the GA of RDS Proxy and I thought it was a good time to take a second look at the service. Any further improvements in the failover? Can you now change the instance size once the proxy has been created?

Weird defaults?

One of the first and few values you should choose when you set up an Amazon RDS Proxy is it the idle client connection timeout. It is already hard to figure out the optimal value in an ideal scenario. But having a user interface that suggests a default of 30 minutes with a label that states “Max: 5 minutes” makes it more difficult. Almost all if the drop down list let you set any value up to 1 hour.

5 or 30 minutes?

Let us play!

I created again a test-rds and a test-proxy and I decided to perform the very same basic tests I did last December. I started two while loops in Bash, relying on the MySQL client, each one asking every 2 seconds the current date and time to the database:

$ while true; do mysql -s -N -h test-proxy.proxy-***.eu-central-1.rds.amazonaws.com -u testuser -e "select now()"; sleep 2; done
$ while true; do mysql -s -N -h test-rds.***.eu-central-1.rds.amazonaws.com -u testuser -e "select now()"; sleep 2; done

Both return the same results:

2020-07-04 20:24:12
2020-07-04 20:24:14
2020-07-04 20:24:16
2020-07-04 20:24:18

So far so good. I then trigger a reboot with failover of the test-rds instance. What is the delay on the two endpoints?

test-proxy

2020-07-04 20:24:56
2020-07-04 20:24:58
2020-07-04 20:25:20
2020-07-04 20:25:22

test-rds

2020-07-04 20:24:56
2020-07-04 20:24:58
2020-07-04 20:27:12
2020-07-04 20:27:14

The difference between the test-proxy and the test-rds is significant: it takes 132 seconds for the RDS endpoint to recover versus only 20 seconds for the proxy. Amazing difference and even better than what AWS promises in a more reliable and significant test.

But what happens when I trigger a change of the instance type? 

While the numbers for the test-rds do not change significantly, the proxy is simply gone. Once the database cluster behind changes, the proxy endpoint is still available but it does not connect to the database anymore. Changing time out does not help, with no simple way to recover.

test-proxy

ERROR 9501 (HY000) at line 1: Timed-out waiting to acquire database connection
ERROR 9501 (HY000) at line 1: Timed-out waiting to acquire database connection
ERROR 9501 (HY000) at line 1: Timed-out waiting to acquire database connection
ERROR 9501 (HY000) at line 1: Timed-out waiting to acquire database connection
ERROR 9501 (HY000) at line 1: Timed-out waiting to acquire database connection
Photo by Andrew Winkler on Unsplash

As for today, at least for MySQL 5.7 on RDS, introducing the proxy in the architecture makes the environment less elastic. As you have no option anymore to introduce any manual or automatic (vertical) scaling of the database to match traffic. Any change to the database becomes more problematic.

Anything else? There are a few other well documented limitations still present, including the lack of support for MySQL 8.0.

A final recap

Amazon RDS Proxy is a very interesting service. And it could be an essential component in many deployments where increase application availability is critical. But I would have expect a few more improvements since the first preview. The lack of support for changes of the instances makes it still hard to integrate it in many scenarios where RDS is currently used.

Generating reports and KPIs with throw-away databases

We all love metrics. We all need numbers. And different stakeholders need different numbers. Numbers that will drive key decisions inside your organization and for your customers. Becoming a data driven organization requires having reliable data in the first place (…)

You can read my post about generating reports and KPIs with throw-away databases on the Funambol Tech Blog: how we decoupled reporting and user activity, leveraging RDS snapshots to generate throw-away copies of our MySQL databases on AWS.

Funambol Tech Blog – Walking the tight rope of cloud development.