On Thu, Jun 3, 2010 at 10:17 AM, David King wrote:
>>> So with the row cache, that first node (the primary replica) is the one
>>> that has that row cached, yes?
>> No, it's the closest node as determined by snitch.sortByProximity.
>
> And with the default snitch, rack-unaware placement, random p
>> So with the row cache, that first node (the primary replica) is the one that
>> has that row cached, yes?
> No, it's the closest node as determined by snitch.sortByProximity.
And with the default snitch, rack-unaware placement, random partitioner, and
all nodes up, that's the primary replica,
On Wed, Jun 2, 2010 at 10:39 PM, David King wrote:
> If I go to fetch some row given the rack-unaware placement strategy, the
> default snitch and CL==ONE, the node that is asked is the first node in the
> ring with the datum that is currently up, then a checksum is sent to the
> replicas to tr
If I go to fetch some row given the rack-unaware placement strategy, the
default snitch and CL==ONE, the node that is asked is the first node in the
ring with the datum that is currently up, then a checksum is sent to the
replicas to trigger read repair as appropriate. So with the row cache, tha
