search

apache / pekko-persistence-r2dbc

Asynchronously writes journal and snapshot entries to configured R2DBC databases so that Apache Pekko Actors can recover state
https://pekko.apache.org/
Apache License 2.0
14 stars 7 forks source link

Support MySQL #158

Open ptrdom opened 4 hours ago

ptrdom commented 4 hours ago

Since MySQL is still one of the most popular RDMS, it makes a lot of sense to add support for it, hopefully helping with adoption of Pekko Persistence R2DBC.

Looking through the existing Postgres implementation for potential challenges with MySQL support, it seems to me that the main difference between the databases is that MySQL does not have concept of a transaction_timestamp. There are ways to implement it - for example wrapping a write operation in a procedure that has a local variable with a timestamp that gets reused in a transaction that is started, but I am not sure if there is much benefit in trying to implement database-side timestamps - I do not understand why it should be a dealbreaker for a production-ready implementation, because no matter where you get your timestamps from, whether it is the application or the database, you will still be dealing with potential clock skews, just that the risk levels might be different, dependent on the architecture of a particular deployment. So my thinking is that we could implement MySQL support by requiring the use of use-app-timestamp = on and possibly db-timestamp-monotonic-increasing = off. Could there be any issues with this approach?

Are there any more issues with the implementation or can we just proceed with it?

pjfanning commented 3 hours ago

I think it would be good to do an experimental implementation where we document that the behaviour may change over a few releases. The initial version can use the simplest approaches to begin with and we can replace those if they prove to be problematic.

@ptrdom if you interested in taking this on, I'll be happy to review it. Presumably, https://github.com/asyncer-io/r2dbc-mysql will be used.