Markus,
Okay, I have forwarded that to Bruce, who's editing the documentation
(and is a native English speaker). I'm not sure how we can cover this,
as we are very general in our description.
You might want to recheck the paragraph, which is now called
"Synchronous Multi-Master Replication":
http://momjian.us/main/writings/pgsql/sgml/high-availability.html
Ok, thanks I'll have a look at this on Friday.
I'm particularly unsure, where Sequoia would fit in. There is still
the split between "Statement-Based Replication Middleware" and
"Synchonous Multi-Master Replication".
Does Sequoia offer any form of async replication?
Yes. We provide to the user a consistent view of data as synchronous
replication would do, but behind the scene we allow asynchrony between
backends and results can be returned as soon as a backend has
successfully completed a query execution.
Yes but don't underestimate the capability of a single node to
execute transactions in parallel as well. Oftentimes sending 2
concurrent transactions to a single node or to 2 different nodes does
not make any difference (obviously it depends on the nature of the
transaction).
Okay, I just have to believe that. Up until now I'm mostly basing on
theoretical estimates, rather than hard facts. :-) You seem to have
made some real benchmarks. Did you publish them?
You can look at slides #63 & 64 in
http://www.continuent.org/uploads/sequoia/Resources/2006-08-15Cecchet_ApacheConAsia2006.pdf
It shows the response time with a single database and with a cluster of
2 dbs. Response time remains constant until you go beyond the sweet spot
of a single node.
We did not publish any official results with hard numbers. Note that you
can always build/tune a benchmark to show what you want to show. So
there is nothing better than testing with your application and see for
yourself. We have few recipes for performance but they are part of the
expertise we use for our commercial services.
May I ask what you use for automatic testing and benchmarking? I'm
currently stuck testing 90% of the time. Starting up the GCS, two
Databases and attaching the debugger to every process which could
possibly go havoc really takes a F***ING lot of time!
We have developed a complete automated distributed testing framework
(probably more code there than in the software to test itself!).
Software, databases and clients are deployed automatically with the
proper configuration, tests are run and outputs are captured for
diagnosis. On the failover side, some scenarios can be automatically
generated (about 7000 failover scenarios are possible with a simple MST
in a 4 nodes cluster ...).
On the benchmarking side we use a couple of different benchmarks that
are available in the open source. It is good to have both
microbenchmarks and also more 'real' macro workloads such as TPC-*.
This whole test infrastructure is proprietary code that we have not
decided yet to open source.
Best regards,
Emmanuel
--
Emmanuel Cecchet
Chief Scientific Officer, Continuent
Blog: http://emanux.blogspot.com/
Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
