Hacker News Reader

Hacker News

Comment by koolba | Hacker News Reader

Parent Full thread

koolba

Anybody in the HN crowd have experience using this? How does it perform on a WAN?

View on HN

We used it for a few months now, it works. we have 3 datacenters with ~10ms of delay between them and no problems.

Over WAN will work, but not sure how reliable will be. Regards.

Have you tried PostgresXL and if yes, can you make a high level comparison?

Those are solutions for very different types of deployments.

BDR is asynchronous multi-master, without global transaction management etc.

XL is a distributed database with global transaction management, strong consistency, etc.

Say you have geographically distributed application (managing customers in US, EU, ...). You can deploy a node in each area and direct local users to this node with low latency etc. It also means "no conflicts" (which is a major concern in multi-master), and the changes will asynchronously replicate to the other nodes.

XL would perform poorly in this scenario (at least I believe so), and it's meant more for local deployments, when hitting vertical scalability limits.

No, I didn't try. So I can't compare. I saw the contributors/support from postgres, and I chose BDR.

Well, we're also Postgres-XL contributors, so ... ;-)

I use on it to keep my postgres data in sync in a high available setup. I host two nodes, each in a different DigitalOcean datacenters (AMS2 and AMS3).

It's fast enough to not notice delays for users. As in, have a user log in on host1, switch the user to host2 and the session is there.

Disclaimer, we're not write heavy and have around one hundred active users.

https://rvanlaar.github.io/Django-HA-presentation/#/

you should create a new node. Less than 3 is a bit dangerous ;-)

Actually with two nodes, if one node goes down, you don't have a BDR cluster anymore ;-)

If you're interested, I'm trying just this over the weekend. Standard streaming replication over WAN was pretty awful. It would work reliably for a few weeks then cause both the master and slave to block writes when they got out of sync because something was dropped.

What do you mean by "got out of sync"? That's a fairly strange issue with physical streaming replication.

Reply on news.ycombinator.com