https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
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?
No idea why people would be using serializable reads for ETL jobs though! :O
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.
What is surprising about a multi-AZ database having higher latency than one that runs in only one AZ?
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.
I’ve never used Aurora because I don’t want to code anything to the idiosyncrasies of AWS (or any other cloud provider).
If you're seeing spikes in RollbackSegmentHistoryListLength that coincide with dips in DB performance, you've probably identified the culprit. In the scenario described in our post, that metric would have grown monotonically for the duration of the long-lived ETL query – probably a more overt problem than what you're describing with short spikes to 100,000.
