Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bidirectional Replication is coming to PostgreSQL 9.6

blog.2ndquadrant.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#61

Post by ukj »

simon2Q wrote: post #52
ukj wrote: post #28

Holy crap, I am scared! Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application's requirements before blindly using this. The moment I heard multi-master I thought Paxos, Raft or maybe virtual synchrony. Hmm, nothing in the documentation. Maybe a new consensus protocol was written from scratch then? That should be interesting! No, none of that either - thi…

"Everything after "Basically" is misleading and inaccurate. The conclusions here are not logical: The existence of some restrictions does not imply "Transactions are a lie", since that makes us think ALL transaction semantics are suspended, which is very far from the case. There are good reasons for the design and restrictions in the BDR design, offering performance about x100 what is possible with eager consensus. R…

Well, you can re-define the properties of a "transaction" within BDR architecture but you can't re-define your customer's use-cases.

But you have a point. Not all semantics are suspended, only atomicity, isolation and consistency.

Durability has become probabilistic, because merge conflicts with a concurrent mutation from another host can discard our change.

>offering performance about x100 what is possible with eager consensus

And what's the performance gain over regular asynchronous master-slave replication? All nodes have to process all mutations at some point, no?

>but this is multi-master - why would you read two nodes when all the data is on one node?

The "why" is because my use-case requires consistent reads and the business risk of inconsistent reads is unacceptable.

I am guessing you are working on the project? It scares me that you are asking this question.

It remains to be seen how many people are happy with such trade-off. I claim total ignorance here - it could be millions :)

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#62

Post by zerg2k »

ukj wrote: post #61
simon2Q wrote: post #52

Earlier quoted context omitted.

"Everything after "Basically" is misleading and inaccurate. The conclusions here are not logical: The existence of some restrictions does not imply "Transactions are a lie", since that makes us think ALL transaction semantics are suspended, which is very far from the case. There are good reasons for the design and restrictions in the BDR design, offering performance about x100 what is possible with eager consensus. R…

Well, you can re-define the properties of a "transaction" within BDR architecture but you can't re-define your customer's use-cases. But you have a point. Not all semantics are suspended, only atomicity, isolation and consistency. Durability has become probabilistic, because merge conflicts with a concurrent mutation from another host can discard our change. >offering performance about x100 what is possible with eage…

I could'n agree more. Be _very_ careful with this illusion. Multi-master replication implementation like this makes sense for very few use cases and even then the development team better know what the hell are they doing or a lot of unwanted/unaccounted things will show up in production

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#63

Post by nine_k »

vidarh wrote: post #50
nine_k wrote: post #39

Earlier quoted context omitted.

Doesn't Oracle offer such an option?

You can't guarantee low latency and consistency without setting geographical boundaries on the distribution of the servers, unless you have very generous definitions of "low latency", as the speed of light (and more realistically: the speed you can transmit a signal via the internet, which is substantially lower) between the servers will place lower bounds on latency. This is the case as you can't guarantee consisten…

Yes, I meant a strictly one-cluster solution for machines within the same datacenter and preferably the same rack.

Synchronous replication across such a cluster can give much more read performance with write consistency and durability guarantees even when hardware failures occur. I don't know if any potential write performance increase would be worth the increased complexity, compared to a standard single-master setup.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#64

Post by CodeWriter23 »

lmm wrote: post #60
gaius wrote: post #58

Earlier quoted context omitted.

Active-active DR scenario, zero failover. Done this loads with Oracle. Or mostly-read regional DBs separated by a slow WAN, ditto.

> Active-active DR scenario, zero failover. I guess, but I don't see the advantage over master -> slave failover? You lose unreplicated writes either way. > Or mostly-read regional DBs separated by a slow WAN, ditto. If it's just reads then regional slaves work well. If your writes don't need to be transactional then a RDBMS seems unlikely to be a good fit in general.

mostly reads != just reads

Think mutiple fulfillment centers changing state orders as they are shipped. Read mostly, write a little.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#65

Post by lmm »

CodeWriter23 wrote: post #64
lmm wrote: post #60

Earlier quoted context omitted.

> Active-active DR scenario, zero failover. I guess, but I don't see the advantage over master -> slave failover? You lose unreplicated writes either way. > Or mostly-read regional DBs separated by a slow WAN, ditto. If it's just reads then regional slaves work well. If your writes don't need to be transactional then a RDBMS seems unlikely to be a good fit in general.

mostly reads != just reads Think mutiple fulfillment centers changing state orders as they are shipped. Read mostly, write a little.

Sure. Either global transactionality for writes is important (in which case this style is useless, you need a master to accept the writes (or else some kind of distributed consensus protocol which this doesn't have) and single global master + distributed read slaves is a good model), transactionality is only important per-center (in which case I'd rather have explicit sharding rather than invisible differences in behaviour between queries that look the same), or you don't need transactional behaviour at all (in which case an RDBMS is probably a poor fit).

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#66

Post by jhugg »

gabriel wrote: post #34
ukj wrote: post #28

Holy crap, I am scared! Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application's requirements before blindly using this. The moment I heard multi-master I thought Paxos, Raft or maybe virtual synchrony. Hmm, nothing in the documentation. Maybe a new consensus protocol was written from scratch then? That should be interesting! No, none of that either - thi…

I kind of agree with the assessment. I've been prototyping with VoltDB be/c it has a pretty interesting model that should be able to achieve a near-linear scale of write operations for tables that are partitioned. After reading the docs on VoltDB [1] is became clear to me that they are putting the design constraints up front and if you can work through those constraints [2] you can achieve some wicked scale. But it's…

If you have any question about whether VoltDB could fit or not, let us know. It's surely not as general purpose as PG, but yes, it's faster for many use cases and its clustering is fully consistent.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#67

Post by simon2Q »

ukj wrote: post #61
simon2Q wrote: post #52

Earlier quoted context omitted.

"Everything after "Basically" is misleading and inaccurate. The conclusions here are not logical: The existence of some restrictions does not imply "Transactions are a lie", since that makes us think ALL transaction semantics are suspended, which is very far from the case. There are good reasons for the design and restrictions in the BDR design, offering performance about x100 what is possible with eager consensus. R…

Well, you can re-define the properties of a "transaction" within BDR architecture but you can't re-define your customer's use-cases. But you have a point. Not all semantics are suspended, only atomicity, isolation and consistency. Durability has become probabilistic, because merge conflicts with a concurrent mutation from another host can discard our change. >offering performance about x100 what is possible with eage…

Postgres-BDR works very well for its intended business use case, which is geographically distributed multiple master database. Master-slave replication is not comparable cos there is only one master. You should use as few masters as your business case requires, so it is possible you don't need BDR at all. The underlying technology is roughly the same between master-slave and master-master, so that is not a big distinction and not the key point.

Postgres-BDR is designed to solve a common problem: access to a database from users all around the world. In cases where you have a single master and multiple standbys then all write transactions must be routed globally to the same location, adding 100s of milliseconds latency and in many cases making applications unusable.

Postgres-BDR offers the opportunity to make those writes to multiple copies of the database in different locations, significantly reducing the latency for users.

What BDR doesn't solve is what you do if all your users want to update the same data at the same time. But that type of application is just not scalable. If you run such an application on any database that gives you perfect consistency and lots of other shiny buzzwords, all you get is a really, really slow application, just like you had in the first place. But it will tick all the keywords.

All distributed systems require you to understand the business case and the trade-offs required to make it work. This is not fancy technology to use because you think its cool, its for use where it is useful and important to do so. BDR gives you the tools to know whether your application will work in a distributed manner and to keep it working in production without fear.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#68

Post by gabriel »

jhugg wrote: post #66
gabriel wrote: post #34

Earlier quoted context omitted.

I kind of agree with the assessment. I've been prototyping with VoltDB be/c it has a pretty interesting model that should be able to achieve a near-linear scale of write operations for tables that are partitioned. After reading the docs on VoltDB [1] is became clear to me that they are putting the design constraints up front and if you can work through those constraints [2] you can achieve some wicked scale. But it's…

If you have any question about whether VoltDB could fit or not, let us know. It's surely not as general purpose as PG, but yes, it's faster for many use cases and its clustering is fully consistent.

Thanks! I certainly will. It looks pretty cool. I'm certainly learning it and finding the technical details in the documentation to be quite interesting.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#69

Post by simon2Q »

_Codemonkeyism wrote: post #6

The title is misleading, the replication is not coming to stock Postgresql 9.6. A replication extension got the patches it needs to run into Postgresql 9.6 so you can use the extension without patching Postgres.

The purpose of extensions is they allow you to run stuff without including it in core database. What language should be used for this case to avoid confusion in future?

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#70

Post by segmondy »

ukj wrote: post #28

Holy crap, I am scared! Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application's requirements before blindly using this. The moment I heard multi-master I thought Paxos, Raft or maybe virtual synchrony. Hmm, nothing in the documentation. Maybe a new consensus protocol was written from scratch then? That should be interesting! No, none of that either - thi…

We need a jepsen test.
Post reply on HN