Exploring performance differences between Amazon Aurora and vanilla MySQL
1–10 of 21 posts
Re: Exploring performance differences between Amazon Aurora and vanilla MySQL
#2Every once in a while there is a well written blog post about database internal. Uber's Postgres-MySql switch saga produced a few of them. This one is pretty good too
Re: Exploring performance differences between Amazon Aurora and vanilla MySQL
#3Every once in a while there is a well written blog post about database internal. Uber's Postgres-MySql switch saga produced a few of them. This one is pretty good too
We worked closely with AWS on this (problem and blog) and they were great and quite transparent. Glad it's interesting/useful to you.
Re: Exploring performance differences between Amazon Aurora and vanilla MySQL
#4The 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 / logs.
I see folks doing serializable reads for historic ETL jobs with one read in the transaction - why? Is there some history / tool issue I'm not familiar with?
Re: Exploring performance differences between Amazon Aurora and vanilla MySQL
#5We had similar problem where a running ETL job caused a production outage due to binlog pressure.
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.
Re: Exploring performance differences between Amazon Aurora and vanilla MySQL
#6The 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 / logs. I see folks doing serializable reads for historic ETL jobs with one read in the transaction - why? Is there some history / tool iss…
For Aurora MySQL, the default for read-only replicas is repeatable read. As we mentioned towards the end of the post, read committed support appears to have been introduced to Aurora MySQL just last year. But you're right – now that it's supported, switching to read committed is by far the easiest fix.
No idea why people would be using serializable reads for ETL jobs though! :O
Re: Exploring performance differences between Amazon Aurora and vanilla MySQL
#7We had similar problem where a running ETL job caused a production outage due to binlog pressure. 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.
This seems plausible given our understanding of the database internals. In general we found our AWS contacts to be knowledgeable and forthcoming about complex tradeoffs between Aurora and vanilla MySQL, even if some of that information is hard or impossible to find in the docs.
Re: Exploring performance differences between Amazon Aurora and vanilla MySQL
#8We had similar problem where a running ETL job caused a production outage due to binlog pressure. 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.
> 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
What is surprising about a multi-AZ database having higher latency than one that runs in only one AZ?
Re: Exploring performance differences between Amazon Aurora and vanilla MySQL
#9H3 tags on this could really use a bump in size and contrast from the regular text.
Re: Exploring performance differences between Amazon Aurora and vanilla MySQL
#10We had similar problem where a running ETL job caused a production outage due to binlog pressure. 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.
> 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 What is surprising about a multi-AZ database having higher latency than one that runs in only one AZ?
From what I can tell, they provisioned their DB instance(s) in a single AZ, but weren't aware that Aurora automatically provisions its own storage and always uses multiple AZs. We touch on the separation of compute and storage in the post.
I think the surprise is that it's not possible to have a truly "single AZ" Aurora database, even though you might have thought you provisioned your DB instances that way.