On Thu, Dec 19, 2013 at 7:12 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> On Wed, Dec 18, 2013 at 1:16 PM, John R Pierce <pierce@hogranch.com> 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
