←back to thread

Show HN: Open source, logical multi-master PostgreSQL replication

(github.com)
131 points pgedge_postgres | 2 comments | 09 Oct 25 22:53 UTC | HN request time: 0.001s | source
Show context
sgarland ◴[10 Oct 25 00:33 UTC] No.45534417[source]▶
You do not want multi-master. If you think you do, think again.

Source: I have operated a large multi-master Postgres cluster.

replies(4): >>45534725 #>>45534761 #>>45535023 #>>45535213 #
phs318u ◴[10 Oct 25 01:52 UTC] No.45534761[source]▶
Multi-master can be useful in cases where writes to the data are usually logically grouped by an attribute that correlates to the distribution of masters e.g. sales info by geography. The chances of write conflicts become much smaller (though not zero.
replies(1): >>45537431 #
1. ownagefool ◴[10 Oct 25 11:00 UTC] No.45537431[source]▶
That's not multi-master in the typical sense, it's sharding, and done correctly, you shouldn't have any write conflicts because each shard should be strongly consistent within itself.

Typically a strongly consistent (CP) system works by having a single elected master where writes are only ack'd when they're written to the majority of the cluster. The downside of this system is you need majority of the cluster working and up-to-date and the performance impact of doing this.

A multi-master system is generally ( AP ) allows writes to any master node, but has some consensus algorithm where it picks and chooses winners based on conflicting writes. It should be faster and more available at the cost of potentially lost data.

There are some systems that claim to beat CAP but they typically have caveats and assurances that are required. After-all, if you ack a write, and then that node blows up, how will it ever sync?

replies(1): >>45538050 #
2. sgarland ◴[10 Oct 25 12:12 UTC] No.45538050[source]▶
> There are some systems that claim to beat CAP but they typically have caveats and assurances that are required.

If by “caveats and assurances,” you mean “relax the definitions of CAP,” then yes. CAP, in its strict definition, has been formally proven [0].

> After-all, if you ack a write, and then that node blows up, how will it ever sync?

That’s just async replication.

0: https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConjecture-...