Live data from Hacker News

Bidirectional Replication is coming to PostgreSQL 9.6

blog.2ndquadrant.com

11–20 of 71 posts

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#11
post #8

Some info from 2nd Quadrant on what BDR is: https://2ndquadrant.com/en/resources/bdr/ Bi-Directional Replication for PostgreSQL (Postgres-BDR, or BDR) is the first open source multi-master replication system for PostgreSQL to reach full production status, developed by 2ndQuadrant and assisted by a keen user community. BDR is specifically designed for use in geographically distributed clusters, using highly efficient…

> anything from 2 to more than 48 nodes in a distributed database Why specify a range if you're going to leave it open-ended?

Possibly, it means that they have tested it with 48, and any more is left as an experiment for the daring. Just guessing.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#12
post #8

Some info from 2nd Quadrant on what BDR is: https://2ndquadrant.com/en/resources/bdr/ Bi-Directional Replication for PostgreSQL (Postgres-BDR, or BDR) is the first open source multi-master replication system for PostgreSQL to reach full production status, developed by 2ndQuadrant and assisted by a keen user community. BDR is specifically designed for use in geographically distributed clusters, using highly efficient…

> anything from 2 to more than 48 nodes in a distributed database Why specify a range if you're going to leave it open-ended?

I guess it means they reached production stability on 48 nodes, but there is nothing keeping you from adding more nodes if need be.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#13
As the developer who also manages the servers we deploy on, and not a full time PgDBA, things like multi-master replication scare the hell out of me. They really make me worry about what happens after downtime. And latency.

Could anyone here recommend good reading material for scaling out your first database on to multiple servers? How do I know which scheme is the best for me?

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#15

As the developer who also manages the servers we deploy on, and not a full time PgDBA, things like multi-master replication scare the hell out of me. They really make me worry about what happens after downtime. And latency. Could anyone here recommend good reading material for scaling out your first database on to multiple servers? How do I know which scheme is the best for me?

The answer really depends on what you mean by "multi-master" - particularly whether you're looking for synchronous or asynchronous solution, what consistency model you need (strongly consistent cluster or nodes consistent independently), and what are your goals (write scalability, read scalability, disaster recovery, ...).

BDR is meant to be asynchronous multi-master, i.e. a collection of nodes that are strongly consistent on their own, but the changes between the nodes are replicated asynchronously. Great for geographically distributed databases (users access their local node), for example.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#16
post #8

Some info from 2nd Quadrant on what BDR is: https://2ndquadrant.com/en/resources/bdr/ Bi-Directional Replication for PostgreSQL (Postgres-BDR, or BDR) is the first open source multi-master replication system for PostgreSQL to reach full production status, developed by 2ndQuadrant and assisted by a keen user community. BDR is specifically designed for use in geographically distributed clusters, using highly efficient…

> anything from 2 to more than 48 nodes in a distributed database Why specify a range if you're going to leave it open-ended?

Yes, it means it was tested with up to 48 nodes.

There's no hard limit on the number of nodes, but at the moment BDR uses full mesh topology (each node has connections to all other nodes), which becomes an issue as the number of nodes increases.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#17

While indeed very exciting, it's important to note that this makes the BDR extension from 2ndquadrant compatible with stock Postgres. This does not include BDR shipping with core Postgres. This continued improvement with the core code and extension APIs will make more and more extensions feasible which will mean more are able to plug-in and add value without things having to be committed to core. Though in time this…

Not exactly. It means that enough infrastructure was moved into PostgreSQL 9.6, making it possible to run BDR on unmodified PostgreSQL. Before 9.6 it was necessary to use patched PostgreSQL packages.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#19

Looking forward to playing around with this. Native master-master replication is the only thing keeping me on MySQL.

Just curious, what Postgres features are you missing on MySQL?

I had only used MySQL until a year or two ago, and wondered what I was missing since Postgres seems to get more love/hype from the developer community for whatever reason.

Now using Postgres in production, there are few if any features that I notice our team using which don't exist in MySQL (maybe Json landed in Postgres first is one big one?). One thing I have noticed is I find the user/permissions model for Pg less intuitive. It's as if it's designed for use in a computer lab or something where there's one human who is the owner/dba and some things can only be done by them, which doesn't map well to a web app trying to follow "principle of least privilege".

This combined with the fact that we're on RDS where MySQL/Aurora is the clear first class citizen makes me wish we were using MySQL.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#20

Can someone explain to me the point of BDR? Since the writes must happen on all servers anyway, why not just have a master-slave?

It means you can write to any master, so your application need not be aware of "master" or anything. That's master/master anything, really. It just makes replication strategy transparent to applications and is far simpler to reason about. It's also far harder to implement on the server side, which is why most software you see that handles master/master (especially cross-DC master/master) comes with severe caveats, probably this included. Distributed systems are extremely difficult and come with lots of corner cases.

There's no reason you can't hang slaves off such a setup for various purposes either, I would assume, though I haven't used BDR and I'm not sure if that's supported in this software. The best replication strategy I've played with in general is a master/read slave setup in each facility with master/master between each facility. A lot of stuff is built that way, but most people never worry about datacenter failover so it's not the sort of thing you find on StackOverflow.

If I give you the knowledge that your Gmail inbox "lives" in one datacenter, imagine how you'd architect a backup for when that facility fails. That's where stuff like master/master starts to come in handy, because then you start thinking about things like "why would we build a backup facility and never use it? The user's latency to the backup is lower today."

Post reply on HN