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

31–40 of 71 posts

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#31

Post by jeffdavis »

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…

Do you know of any relational products which offer high-throughput, low-latency, high-availability transaction processing using perfectly synchronous multi-master replication?

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#32

Post by ukj »

jimktrains2 wrote: post #29
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 am sure there are use-cases where the risk of this design is acceptable (or necessary), but ensure you have a plan for dealing with data inconsistencies! I'd argue most non-financing applications would find these risks acceptable. This form of Multi-Master is what most people writing web-based applications actually are looking for. It simplifies having fail-over, at the costs you mentioned, but those aren't a maj…

>acting like there aren't any is blatantly ignoring many types of workloads.

I agree in principle, and if you have the knowledge and means to understand/mitigate the risk, this warning isn't aimed at you ;)

It is aimed at the ignorant, not the negligent e.g the engineer I was 15 years ago - who didn't know what he didn't know and would've chosen BDR simply for its master-master promise without understanding what I am really getting myself into.

I nearly ruined a business by choosing MySQL + NDB few years ago.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#33

Post by ioltas »

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…

It is amazing to see the number of projects based on Postgres mentioning that they are trying to achieve multi-master with their own restrictions:

* Postgres-R is not multi-master, got discontinued in 2010, and lots most of its meaning after WAL-shipping has been added in-core with hot-standby. http://www.postgres-r.org/

* Postgres-XC, that says to do multi-master, the first project based on PostgreSQL that I heard of doing sharding (term not used at the beginning of the project, and that I first heard in 2010). The project began in 2009, got discontinued in 2013. There are limitations like non-support for triggers and savepoints. XC was designed to be good for OLTP workloads, sucks for long-transactions and data warehouse type of workloads. The design of the project has been done in coordination by NTT and EnterpriseDB. https://sourceforge.net/projects/postgres-xc/

* Postgres-XL, that forked from Postgres-XC, and enhanced the data-warehouse case with improvements for data analytics by introducing a communication protocol between Datanodes. The project is still being maintained by some folks at 2ndQuad. http://www.postgres-xl.org/

* Postgres-X2, which has been an attempt to unify Postgres-XC and Postgres-XL efforts under the same banner. I don't know where this is moving to but things look rather stalled. https://github.com/postgres-x2/postgres-x2

* Postgres-XZ (look for PGXZ!), which is something I heard recently, based on Postgres-XC, and developed by some folks in China. Visibly this has its own limitations, and is used in production where the constraints induced by the scaling out are thought as acceptable.

So, that's cool to see many efforts, BDR being one. And all of them are trying to address the scaling-out problem with their own way. Now each application should study carefully what to use and if the limitations and constraints used are acceptable or not.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#34

Post by gabriel »

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 a bit more complex than your typical single host database.

The work that VoltDB makes you deal with up front are a lot like the work that would have to be done for a multi-master setup in PostgreSQL to function correctly. I like how VoltDB puts those problems up front, but I'm having problems seeing VoltDB as a general purpose solution. The old PG database I work on right now I can't see in the VoltDB, but maybe parts of it would fit OK.

I look forward to the tooling in PG to get better and better. It's a great community and I do like the work that 2ndquandrant is doing. I like how they approach the community with their work. I do the BDR work is important to understand so that when you're in a situation that calls for it you can take advantage of it (same with VoltDB).

[1] https://docs.voltdb.com/UsingVoltDB/IntroHowVoltDBWorks.php#... [2] https://docs.voltdb.com/UsingVoltDB/DesignPartition.php#Sche...

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#35

Post by developer2 »

dcosson wrote: post #19
anthony_franco wrote: post #9

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…

utf8 collations. mysql's utf8mb4_unicode_ci is fantastic for real-world multi-language support. postgresql's utf8 charsets require you to attach a language-specific collation. It makes real-world applications impossible to support on potgres.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#37

Post by pgaddict »

rgacote wrote: post #25

Do all nodes need to be up 100% of the time? If not, how long can a node be down without replicating (perhaps because a server is under maintenance). Does BDR have rules for primary key insertion conflicts? I have a (perhaps odd) situation where identical data is already being written to multiple servers. Currently handling with a custom replication mechanism.

The nodes don't need to be up 100% of the time. Thanks to replication slots, the WAL on the other nodes will be kept until the node connects again and catches up. So it really depends on how much disk space you have on the other nodes.

Regarding the PK conflicts - I'm not sure I understand the question, but it's possible to use global sequences (which is one of the parts that did not make it into core yet). Otherwise it'll generate conflicts, and you'll have to resolve them somehow (e.g. it's possible to implement a custom conflict handler).

See http://bdr-project.org/docs/stable/conflicts.html

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#38

Post by nine_k »

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 can imagine a reasonable use case. If every node only accepts writes to a particular set of tables (or partitions), and serves as a read slave wrt the rest, the database may remain consistent and more available than a single-master setup. Imagine one node per a geographical region, with each node having a (read-only) picture of the whole.

This is a relatively limited use case.

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#39

Post by nine_k »

jeffdavis wrote: post #31
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…

Do you know of any relational products which offer high-throughput, low-latency, high-availability transaction processing using perfectly synchronous multi-master replication?

Doesn't Oracle offer such an option?

Re: Bidirectional Replication is coming to PostgreSQL 9.6

#40

Post by tracker1 »

no1youknowz wrote: post #22

I look forward to when this lands on PostgreSQL 9.7 without the need for an extension. But more so when I can also include the Citus DB extension. Running CitusDB with just 1 master made me nervous. They did talk about having multi-master replication as a belt and braces solution, but I don't know how far they got. Thinking about this. Both being used may give you a 100% fully fault tolerant solution?

Looking at the defects potential, I'm not sure I would rely on this as more than a "hotter spare" configuration... ex: only write to primary, then secondary if initial fails. Read from wherever.

That said, It seems like this doesn't have the reliability constraints I'd really want to see... however as a "hotter" spare option, that might be nice. It seems like it wouldn't take much to turn this into a fast auto-failover master-slave model.

Post reply on HN