Jepsen: MySQL 8.0.34

Re:Jepsen: MySQL 8.0.34 by Freeaqingme on Tuesday December 19, 2023 @10:27AM (#38696760)

Also from an operations point of view it's quite easy to manage. I'm not that experienced with Postgresql, but my understanding is that until recently you had to vacuum it every once in a while. Besides, it's also using some kind of threading model that most people handle by putting a proxy in front of Postgres to keep connections open.

Also, Mysql has had native replication for a very long time, including Galera which does two-step commit in a multimaster cluster. Although Postgres is making some headway in this regard, it is my impression that this is only quite recent and not yet fully up to par with Mysql yet.

[ Parent | on HN ]

Re:Jepsen: MySQL 8.0.34 by stonemetal12 on Tuesday December 19, 2023 @10:53AM (#38697139)

>my understanding is that until recently you had to vacuum it every once in a while.

You still do. The auto Vacuum daemon was added in 2008ish, so it isn't too bad. Just more complexity to manage.

> it's also using some kind of threading model

It does a process per connection just like web servers did back in the day when C10k was a thing. A lot of the buffers are configured per connection so you can get bigger buffers if you keep the number of connections small.

[ Parent | on HN ]

Re:Jepsen: MySQL 8.0.34 by dgellow on Tuesday December 19, 2023 @03:21PM (#38700938)

I think what you reference is known as Transaction ID Wraparound, Postgres still needs to be vacuumed to avoid that problem: https://www.crunchydata.com/blog/managing-transaction-id-wra...

[ Parent | on HN ]