MySQL 8.2 Introduces Transparent Read/Write Splitting
1–10 of 16 posts
Re: MySQL 8.2 Introduces Transparent Read/Write Splitting
#2I’m a big fan of MySQL, but this is something you can do with ProxySQL [0] already. While connection pooling isn’t quite as drastic of a need as with Postgres, the other benefits ProxySQL gives you (aforementioned R/W split, dynamic query rewrites and blocking, query cache, HA failover and LB…) makes it a no-brainer.
Re: MySQL 8.2 Introduces Transparent Read/Write Splitting
#3I’m a big fan of MySQL, but this is something you can do with ProxySQL [0] already. While connection pooling isn’t quite as drastic of a need as with Postgres, the other benefits ProxySQL gives you (aforementioned R/W split, dynamic query rewrites and blocking, query cache, HA failover and LB…) makes it a no-brainer. [0]: https://github.com/sysown/proxysql
Yeah, in the last 2 releases of PostgreSQL there is not even a single feature that was useful for me, so I'm kinda disappointed. and there are so many missing features in postgresql (stop using threads for connections, automatically precompile all parameterized queries, "real" materialized views, etc...)
Re: MySQL 8.2 Introduces Transparent Read/Write Splitting
#4Can PostgreSQL do this?
Re: MySQL 8.2 Introduces Transparent Read/Write Splitting
#5Glad to see it.
Any scalability simplification features like this are very welcome, and necessary to compete with other databases at this point such as CockroachDB and Vitess
Re: MySQL 8.2 Introduces Transparent Read/Write Splitting
#6I’m a big fan of MySQL, but this is something you can do with ProxySQL [0] already. While connection pooling isn’t quite as drastic of a need as with Postgres, the other benefits ProxySQL gives you (aforementioned R/W split, dynamic query rewrites and blocking, query cache, HA failover and LB…) makes it a no-brainer. [0]: https://github.com/sysown/proxysql
ProxySQL is a complex jet engine requiring manual tuning. 99% of MySQL users will be satisfied with the simple configuration and automatic query parsing of MySQL Router.
Re: MySQL 8.2 Introduces Transparent Read/Write Splitting
#7Handling stale data needs to be considered when implementing it.
ORMs like Prisma execute an update query and follow it up with a select. This would result in stale data being returned most of the time. If you use this data expecting your update to be contained in it you are going to have a bad time (statemachines, etc.)
Re: MySQL 8.2 Introduces Transparent Read/Write Splitting
#8Handling stale data needs to be considered when implementing it. ORMs like Prisma execute an update query and follow it up with a select. This would result in stale data being returned most of the time. If you use this data expecting your update to be contained in it you are going to have a bad time (statemachines, etc.)
Why would it result in stale data being returned most of the time?
Re: MySQL 8.2 Introduces Transparent Read/Write Splitting
#9Glad to see it. Any scalability simplification features like this are very welcome, and necessary to compete with other databases at this point such as CockroachDB and Vitess
> compete
Isn't Vitess built on top of MySQL?
Re: MySQL 8.2 Introduces Transparent Read/Write Splitting
#10Can PostgreSQL do this?
Not natively, no. You’d need to front it with something like PgCat [0].