3 ms·

I appreciate the write-up and the nod to AWS RDS. However, I was wondering if there was any focus on AWS Aurora (MySQL)? For those that don't know, AWS build

I appreciate the write-up and the nod to AWS RDS. However, I was wondering if there was any focus on AWS Aurora (MySQL)? For those that don't know, AWS build a protocol compatible database platform that pretends to be MySQL or PostgreSQL. It would be interesting to see if Aurora MySQL has the same "features" as RDS or even MariaDB.

Reubend 3y ago
No, because that would be a totally different DB engine with different concurrency issues. Although that would also be super interesting to read, and my intuition is that because Aurora is a much newer DB, it probably has some subtle issues that haven't been discovered yet versus MySQL, which is quite old by now.
- evanelias 3y ago
  Aurora MySQL is based heavily on MySQL/InnoDB's codebase. It's not a complete reimplementation from scratch. My guess would be that it exhibits some or all of these same issues [edit to add: see footnote 2]. With a single-node cluster, I don't ever recall reading anything about Aurora offering different MVCC or isolation level semantics than upstream InnoDB. AWS documentation says "These isolation levels work the same in Aurora MySQL as in RDS for MySQL" [1] and keep in mind standard non-Aurora RDS is much closer to unmodified upstream MySQL. That said, there are some unique wrinkles in Aurora's cluster behavior due to the shared storage. For example, if you keep the default isolation level of repeatable read, long-running queries on Aurora Replicas will inherently block purge of old-row versions on the whole cluster. In contrast, a traditional MySQL replica set (using async binlog replication) does not behave that way, because each replica has its own storage and own purge threads. [1] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.IsolationLevels.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide... [2] Re-reading the Jepsen results, it appears all of these anomalies come from the exact same documented InnoDB behavior: "If you update some rows in a table, a SELECT sees the latest version of the updated rows, but it might also see older versions of any rows" as per https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-re... -- and presumably Aurora maintains the same behavior, since otherwise it would break compatibility with MySQL in extremely subtle and confusing ways.
  - Reubend 3y ago
    Ah, I didn't know that. I suppose my comment above is probably wrong then! My apologies.
BigGreenTurtle 3y ago
I use MySQL Aurora quite heavily and, for our purposes(very high usage, but simple query pattern) there's no obvious differences outside of one major annoyance. The engineers at Plaid wrote a really useful article on the differences: https://plaid.com/blog/exploring-performance-differences-between-amazon-aurora-and-vanilla-mysql/ https://plaid.com/blog/exploring-performance-differences-bet... The biggest, for me, is that Aurora clusters use shared storage and therefore the isolation model is slightly different(plus other ramifications), read committed is only possible by setting a cluster wide parameter and read uncommitted is not possible, as far as I can tell.

Reubend 3y ago

No, because that would be a totally different DB engine with different concurrency issues. Although that would also be super interesting to read, and my intuition is that because Aurora is a much newer DB, it probably has some subtle issues that haven't been discovered yet versus MySQL, which is quite old by now.

evanelias 3y ago
Aurora MySQL is based heavily on MySQL/InnoDB's codebase. It's not a complete reimplementation from scratch. My guess would be that it exhibits some or all of these same issues [edit to add: see footnote 2]. With a single-node cluster, I don't ever recall reading anything about Aurora offering different MVCC or isolation level semantics than upstream InnoDB. AWS documentation says "These isolation levels work the same in Aurora MySQL as in RDS for MySQL" [1] and keep in mind standard non-Aurora RDS is much closer to unmodified upstream MySQL. That said, there are some unique wrinkles in Aurora's cluster behavior due to the shared storage. For example, if you keep the default isolation level of repeatable read, long-running queries on Aurora Replicas will inherently block purge of old-row versions on the whole cluster. In contrast, a traditional MySQL replica set (using async binlog replication) does not behave that way, because each replica has its own storage and own purge threads. [1] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.IsolationLevels.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide... [2] Re-reading the Jepsen results, it appears all of these anomalies come from the exact same documented InnoDB behavior: "If you update some rows in a table, a SELECT sees the latest version of the updated rows, but it might also see older versions of any rows" as per https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-re... -- and presumably Aurora maintains the same behavior, since otherwise it would break compatibility with MySQL in extremely subtle and confusing ways.
- Reubend 3y ago
  Ah, I didn't know that. I suppose my comment above is probably wrong then! My apologies.

BigGreenTurtle 3y ago

I use MySQL Aurora quite heavily and, for our purposes(very high usage, but simple query pattern) there's no obvious differences outside of one major annoyance. The engineers at Plaid wrote a really useful article on the differences: https://plaid.com/blog/exploring-performance-differences-between-amazon-aurora-and-vanilla-mysql/ https://plaid.com/blog/exploring-performance-differences-bet... The biggest, for me, is that Aurora clusters use shared storage and therefore the isolation model is slightly different(plus other ramifications), read committed is only possible by setting a cluster wide parameter and read uncommitted is not possible, as far as I can tell.