On Sat, Apr 21, 2012 at 11:28 AM, Aphyr <ap...@aphyr.com> wrote:
> >>
>> How hard is it for a cluster-aware application to tell that the clocks
>> are out of sync? You probably can't do better than NTP at fixing it,
>> but why even continue to run in that state? If all it takes is a
>> good clock for reliability, let's build good clocks.
>
>
> You are a network packet. It is very dark. You are likely to be eaten by a
> partition.
You are buying hardware to build a service. You wonder what piece of
hardware can keep working usefully for some time on its own.
> It is *OK* to accept the clock issue sometimes, especially with the
> understanding that it provides probabilistic constraints on conflict
> resolution. Being right 80% of the time can be better than 50% of the time.
> But you *have* to be willing to understand and accept the risks; it's
> something most people have no idea exists.
But that's what we are talking about here. Riak handles the scenario
where you continue in spite of risks nicely, but there are things your
application may do where it is better to fail than be wrong. Do you
maintain a separate relational/transactional db for that?
--
Les Mikesell
lesmikes...@gmail.com
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
