On Thu, Dec 19, 2013 at 7:12 AM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > On Wed, Dec 18, 2013 at 1:16 PM, John R Pierce <pierce@xxxxxxxxxxxx> wrote: >> that sort of replication is very problematic. its virtually impossible to >> maintain ACID (Atomicity, Consistency, Isolation, Durability) and maintain >> any semblance of performance. Yep, there's usually a trade-off between performance and data consistency. OLTP applications can benefit from MM with a shared-nothing architecture, more than data warehouse type of things that need to transfer a lot of data for join operations, or SQL operations that use non-pushable clauses (for example stable/volatile functions). >> question for you, what do you expect to happen if the communications link >> between the servers is interrupted, and updates continue to be sent to both >> servers? Split-brain is another problem, hard to solve. Even harder if you have several types nodes in your cluster dedicated to provide some piece building the MM system. > When people start talking multi-master replication my first response > is to ask what problem you're trying to solve. Sometimes MM Rep IS the > answer. But quite often it's not the best one for your problem. So to > OP I'd ask what problem they're trying to solve. Yes that's actually the right approach, multi-master replication is often cited as a marketing term for a fantastic technology that can solve a lot of problems, which could be solved with a couple of Postgres servers using a single-master, multiple-slave approach, or by simply design a system that can do data sharding among a set of Postgres servers to achieve some kind of write scalability. Regards, -- Michael -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
