Daniel Eckl wrote:
Hi Scott!
Your statements cannot be correct by logical reasons.
While on file locking level you are fully right, cyrus heavily depends
on critical database access where you need application level database
locking.
As only one master process can lock the database, a second one either
cannot lock the database or just crashes it with simultaneous write
access. I didn't try it by myself for obvious reasons...
If that didn't occur to you, then you had incredible luck, that there
was no situation where both processes wanted to change the same db
file simultaneously.
Hi Daniel,
Scott is not just lucky, he's using clustering technology that works.
When using a cluster filesystem that works, the locking semantics across
cluster nodes will be the same as those on a single node filesystem.
What you say above is simply not correct.
University of Pittsburgh is also running a 4-node active/active cluster
using Veritas Cluster Filesystem and it works very well. The
performance is incredible, and as Scott pointed out you don't need the
complexity of murder or application-level replication. Using a cluster
instead of Cyrus murder gives you both scalability and redundancy. The
big tradeoff is that Veritas Cluster Filesystem costs money, while Cyrus
does not.
Thanks,
Dave
----
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
