Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, Postgres' built-in replication doesn't support multi-master.

With one of the many third-party replication packages that have grown around PostgreSQL (specifically, Bucardo v5 which is in beta right now), you can do multiple — as in more than two — writeable masters, though, as the linked page notes, the replication is asynchronous. With older versions of Bucardo, you can do two masters — again, asynchronously (though you can technically get more than two if you want to engage in some significant configuration gymnastics).

What they're calling "synchronous multi-master" replication is actually implemented using "two-phase commit", which isn't replication per se, but rather application code using a database feature that allows specifically crafted database interactions to be written to multiple databases, and only successfully committing if the participating nodes agree that they've all committed.



> What they're calling "synchronous multi-master" replication is actually implemented using "two-phase commit", which isn't replication per se, but rather application code using a database feature that allows specifically crafted database interactions to be written to multiple databases, and only successfully committing if the participating nodes agree that they've all committed.

I am not sure I understood, what is the difference between the two?


As commonly defined, "replication" is something that happens in, and is managed by the database itself, or a daemon written for that purpose (whether the daemon works at the logical level, replicating database tuples, or at the physical level, replicating disk blocks), and of which an application can be largely, if not wholly agnostic. With two-phase commit, OTOH, an application has to be specifically written to take advantage of that functionality.


What happens if one of the nodes goes offline? System stops accepting requests or it keeps going and ends up in an inconsistent state?


Failure modes are defined by the two-phase commit protocol, the standard way of managing distributed database changes:

http://en.wikipedia.org/wiki/Two-phase_commit_protocol




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: