On Mon, 2009-06-22 at 20:48 -0400, Gerry Reno wrote: > > Anyway, you seem to be unaware that built-in replication for > > PostgreSQL already is moving along, with an implementation that's just > > not quite production quality yet, and might make into the next version > > after 8.4 if things go well. > No, I'm aware of this basic builtin replication. It was rather > disappointing to see it moved out of the 8.4 release. We need something > more that just basic master-slave replication which is all this simple > builtin replication will provide. We need a real replication solution > that can handle statement-based and row-based replication. Multi-master > replication. Full cyclic replication chain setups. Simple master-slave > just doesn't cut it. Statement-based replication is, frankly, scary. Personally I'd only be willing to use it if the database would guarantee to throw an exception when any statement that may produce different results on master and slave(s) was issued, like the limit-without-order-by case mentioned on the MySQL replication docs. Even then I don't really understand how it can produce consistent replicas in the face of, say, two concurrent statements both pulling values from a sequence. There would need to be some sort of side channel to allow the master to tell the slave about how it allocated values from the sequence. My overall sentiment is "ick". Re multi-master replication, out of interest: what needs does it satisfy for you that master-slave doesn't? - Scaling number of clients / read throughput in read-mostly workloads? - Client-transparent fault-tolerance? - ... ? What limitations of master-slave replication with read-only slaves present roadblocks for you? - Client must connect to master for writes, otherwise master or slave, so must be more aware of connection management - Client drivers have no way to transparently discover active master, must be told master hostname/ip - ... ? I personally find it difficult to understand how multi-master replication can add much to throughput on write-heavy workloads. DBs are often I/O limited after all, and if each master must write all the others' changes you may not see much of a performance win in write heavy environments. So: I presume multi-master replication is useful mainly in read-mostly workloads ? Or do you expect throughput gains in write-heavy workloads too? If the latter, is it really multiple master replication you want rather than a non-replica clustered database, where writes to one node don't get replicated to the other nodes, they just get notified via some sort of cache coherence protocol? I guess my point is that personally I think it'd be helpful to know _why_ you need more than what's on offer. What specific features pose problems or would benefit you, how, and why. Etc. > > That's probably why it's not on the survey--everybody knows that's > > important and it's already being worked on actively. > Ok, I just felt it should still be there. But, I hope development > understands just how important good replication really is. "development" appear to be well aware. They're also generally very willing to accept help, testing, and users who're willing to trial early efforts. Hint, hint. Donations of paid developer time to work on a project you find to be commercially important probably wouldn't go astray either. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
