4 ms·

with hot master failover and command forwarding [...] like I get with MongoDB. Failover is documented to not work very well in MongoDB (data loss): http://aphy

by moe 12y ago

with hot master failover and command forwarding [...] like I get with MongoDB. Failover is documented to not work very well in MongoDB (data loss): http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb On the postgres side RepMgr makes dealing with replication quite easy: https://github.com/2ndQuadrant/repmgr https://github.com/2ndQuadrant/repmgr See also this recent thread on the PostgreSQL mailing list: http://postgresql.nabble.com/Fully-automatic-streaming-replication-failover-when-master-dies-td5788393.html http://postgresql.nabble.com/Fully-automatic-streaming-repli...

Xylakant 12y ago
I'd be careful quoting the aphyr post in that context. PG also had some failures, even in the non-replicated setup: http://aphyr.com/posts/282-call-me-maybe-postgres http://aphyr.com/posts/282-call-me-maybe-postgres Failures are just a property of distributed systems, some fail in ways that are better for you, some fail in ways that are worse, but sooner or later they all fail. It's a tradeoff which one you choose.
- moe 12y ago
  PG also had some failures MongoDB loses acknowledged writes in its supposed "highest consistency" mode. PostgreSQL does not. That's a pretty fundamental difference, don't you think?
  - Xylakant 12y ago
    MongoDB was tested in a replicated setup, PG not, that's a pretty fundamental difference. Loosing acked writes in a master-slave replication with failover would be expected with a sufficiently large replication lag even for PG. MongoDB is about the last database I'd pick for any given scenario, but I acknowledge that there are people that have a usecase where it might be a good fit because the tradeoffs work out for them.
    - moe 12y ago
      Loosing acked writes in a master-slave replication with failover would be expected with a sufficiently large replication lag even for PG. Bullshit.

by moe 12y ago

Xylakant 12y ago

I'd be careful quoting the aphyr post in that context. PG also had some failures, even in the non-replicated setup: http://aphyr.com/posts/282-call-me-maybe-postgres http://aphyr.com/posts/282-call-me-maybe-postgres Failures are just a property of distributed systems, some fail in ways that are better for you, some fail in ways that are worse, but sooner or later they all fail. It's a tradeoff which one you choose.

moe 12y ago
PG also had some failures MongoDB loses acknowledged writes in its supposed "highest consistency" mode. PostgreSQL does not. That's a pretty fundamental difference, don't you think?
- Xylakant 12y ago
  MongoDB was tested in a replicated setup, PG not, that's a pretty fundamental difference. Loosing acked writes in a master-slave replication with failover would be expected with a sufficiently large replication lag even for PG. MongoDB is about the last database I'd pick for any given scenario, but I acknowledge that there are people that have a usecase where it might be a good fit because the tradeoffs work out for them.
  - moe 12y ago
    Loosing acked writes in a master-slave replication with failover would be expected with a sufficiently large replication lag even for PG. Bullshit.