11–17 of 17 posts
What's the use case for database branching?
I'm curious if split brain cases already experienced. At scale, it should be so https://github.com/cloudnative-pg/cloudnative-pg/issues/7407
One of my mentees worked with Xata in their app using Prisma and it wasn't great. The need for a second db for the 'shadow' db that prisma needs, and they would throw Out of Memory errors frequently without any significant usage. The app now moved to Prisma's postgres hosting and it works like a charm, only thing that changed is the db.
Oh yeah that prisma that decided doing joins in memory was a good idea? Yeah def would trust them to run a db hosting platform too /s https://github.com/prisma/prisma/discussions/19748
nice seeing stuff like this go open source tbh, always makes me pause though - for stuff you’ve already solved and run yourself, you think anything ever convinces you to switch or is it just about trust at that point
> we deploy the Postgres instances on Kubernetes via the CloudNativePG operator. I'm curious if split brain cases already experienced. At scale, it should be so https://github.com/cloudnative-pg/cloudnative-pg/issues/7407
My understanding after looking into it, it seems that Xata+SimplyBlock is expected to use ReadWriteOnce persistent volume access modes. This means the claim can only be bound to one node.
I think this solves the split-brain problem because any new postgres readwrite pods on new nodes will fail to bind the volume claim, but it means there's no high-availability possible in the event the node fails. At least, I think that's how kubernetes handles it - I couldn't find too much explaining the failure modes of persistent volumes, but I don't see many other solutions.
At Neon, we solve this issue by having our storage nodes form a consensus protocol with the postgres node. If a new postgres node comes online, they will both contend for multi-paxos leadership. I assume the loser will crash-backoff to reset the in-memory tables so there's no inconsistency if it tries to reclaim the leadership again and wins. In the normal mode with no split-brain and one leader, multi-paxos has low overhead for WAL committing.
> we deploy the Postgres instances on Kubernetes via the CloudNativePG operator. I'm curious if split brain cases already experienced. At scale, it should be so https://github.com/cloudnative-pg/cloudnative-pg/issues/7407
> we deploy the Postgres instances on Kubernetes via the CloudNativePG operator. I'm curious if split brain cases already experienced. At scale, it should be so https://github.com/cloudnative-pg/cloudnative-pg/issues/7407
How on earth is reporting a broken consistency promise a "discussion". That is dubious behavior from the project management.