Exploring performance differences between Amazon Aurora and vanilla MySQL

This is a wonderful article. I recently discovered an aurora gem that saved me from some flakey mysqldump: you can save the results directly to s3 with a “select into outfile s3” query. This is, according to the docs, an optimized operation when run from a read replica.<p><a href="https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;AmazonRDS&#x2F;latest&#x2F;AuroraUserGuide&#x2F;AuroraMySQL.Integrating.SaveIntoS3.html" rel="nofollow">https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;AmazonRDS&#x2F;latest&#x2F;AuroraUserGuide...</a>

Every once in a while there is a well written blog post about database internal. Uber&#x27;s Postgres-MySql switch saga produced a few of them. This one is pretty good too

The simplest is probably read committed especially if like many ETL jobs you are just going to grab stuff using one read for further processing. Another option, do a read committed and omit last 15 minutes of data if you are doing long running jobs to avoid churn at end of tables &#x2F; logs.<p>I see folks doing serializable reads for historic ETL jobs with one read in the transaction - why? Is there some history &#x2F; tool issue I&#x27;m not familiar with?

We had similar problem where a running ETL job caused a production outage due to binlog pressure.<p>One thing that surprised us that our TAM says that on a 1 AZ write-heavy workload normal MySQL would have higher performance as Aurora synchronously write to storage servers in other AZs. On immediate read-after-write workload that would mean it would take longer time to acquire lock.

I wonder why Aurora shares undo logs between replicas? It’s perfectly possible for the read replicas to each re-create their own copy of the undo logs, and retain those undo logs for different durations based on the different long-running queries on each replica.

It seems like the benefits of cloud infrastructure have normalized vendor lock-in.<p>I’ve never used Aurora because I don’t want to code anything to the idiosyncrasies of AWS (or any other cloud provider).

One huge difference is in locking we discovered. Do not expect Aurora to do you any kind of favors in you actually use these features.

Really great article! I have a question: in it you say to keep an eye on RollbackSegmentHistoryListLength, and I want to do that, but I don&#x27;t know at what number does it become something to worry about. There doesn&#x27;t seem to be any guidance on AWS&#x27; site. I&#x27;m seeing ranges of 1,000 to 5,000 and sometimes 100,000.

H3 tags on this could really use a bump in size and contrast from the regular text.