I can get down and dirty in the SQL Server world :) Best analogy is that cassandra is doing "high safety mode synchronous mirroring" http://msdn.microsoft.com/en-us/library/ms189852.aspx The replicating is effectively inside the Transaction commit, cassandra does not have transactions but you get the idea.
And in cassandra data is not replicated from a central point, it is written to all replicas at once. Mutations travel from the coordinator to the replicas (which may include the coordinator), never between the replicas. Except for forwarded mutations used when crossing data centre boundaries. If you've got a non error return for a write it has been committed at at least Consistency Level replicas. Network latency is included in the latency of the request. After that the changes may be sent to replicas at did not receive the original mutation at some point in the future. Depending on the mix of Read Repair, Hinted Handoff and nodetool repair. Hope that helps. ----------------- Aaron Morton Freelance Cassandra Developer @aaronmorton http://www.thelastpickle.com On 26 May 2011, at 05:56, Stephan P wrote: > Thanks for the reply. > > I agree about the eventual consistency feature but in "addition" I'm trying > to have an oversight if there is a slowness between nodes in a cluster > meaning sometimes "some" network slowness won't translate in CA slowness and > sometimes it will. I guess I'm looking for a process that tells me what the > actual travel time between CA Node A and B is. > > Here is very simple way how the same is done with SQL Server replication > (sorry to wonder off into the RDBMS world): > I insert a single timestamp into a small table and let SQL server replicate > it to nodes. Upon arrival on each node the insert will automatically generate > a default timestamp value into the same table/row. Taking the diff between > original inserted (source) and default insert (target) timestamp I know > precisely how long it took to push that content along within SQL Server. > > > > On Tue, May 24, 2011 at 11:46 PM, Aaron Morton <aa...@thelastpickle.com> > wrote: > Once the cluster has returned to the client you know the write has been > committed to Consistency Level number of nodes. > > i.e. If you send an insert using QUORUM consistency to a cluster with > Replication Factor 3, and you get a non error response you know the write has > occurred on at least 2 nodes (one may be the one the client is connected to.) > > After the initial request has completed it's up the "Eventual Consistency" > features of Read Repair, Hinted Handoff and Anti-Entropy to distribute > changes. > > Does that help or are you thinking of something else? > ----------------- > Aaron Morton > Freelance Cassandra Developer > @aaronmorton > http://www.thelastpickle.com > > On 25 May, 2011,at 03:11 PM, Stephan Pfammatter <steplmi4...@gmail.com> wrote: > >> What’s the recommended way of measuring latency between nodes in a cluster? >> By that I’m not referring to read/write latency for a given KS/CF. >> >> Basically I want to inject a row in a node A and want to see how long it >> takes to get to node B (assuming proper RF is set). >> >> >> >> I have already some network monitoring in our windows environment between my >> distributed nodes in place. But I still would like to get a handle on how a >> potential network and/or cassandra slowness affects inter-node latency. >> Maybe there is a tool/cmd that I'm not aware of? Tx. >> >
